[fpc-devel] THandle and 64bit platforms

[Michael.VanCanneyt at Wisa.be]

On Mon, 20 Dec 2004, Florian Klaempfl wrote:

> Michael.VanCanneyt at Wisa.be wrote:
> > 
> > On Mon, 20 Dec 2004, Tomas Hajny wrote:
> > 
> > 
> >>Date sent:      	Mon, 20 Dec 2004 21:02:04 +0100
> >>To:             	"FPC developers' list" <fpc-devel at lists.freepascal.org>
> >>From:           	Marc Weustink <marc at dommelstein.net>
> >>Subject:        	RE: [fpc-devel] THandle and 64bit platforms
> >>Send reply to:  	FPC developers' list <fpc-devel at lists.freepascal.org>
> >>	<mailto:fpc-devel-request at lists.freepascal.org?subject=unsubscribe>
> >>	<mailto:fpc-devel-request at lists.freepascal.org?subject=subscribe>
> >>
> >>>>>>>>>File descriptors are still 32bit on x86_64, therefor
> >>>>>>>>>Thandle=32bit.
> >>>>>>>>
> >>>>>>>>A THandle is more than a file descriptor alone.
> >>>>>>>>Since the LCL is VCL compatible and thus MS biassed, there are
> >>>>>>>>more THandles than filedescriptors alone. To keep code
> >>>>>>>>compatible and portable, I need a 64 bit THandle on 64 bit
> >>>>>>>>platforms. (on win64 a handle is also 64bit). Or would you
> >>>>>>>>suggest to use HANDLE for a 64bit handle and THandle for 32bit
> >>>>>>>>?
> >>>>>>>
> >>>>>>>THandle is platform dependent. On win64 THandle=QWord.
> >>>>>>>
> >>>>>>>Currently Thandle=longint for unix, but Thandle=DWord for win32.
> >>>>>>
> >>>>>>Yes, I am aware of that, my question however is is how to get
> >>>>>>things working.
> >>>>>>
> >>>>>>In the LCL a THandle is used everywhere and in most cases it
> >>>>>>represents a pointer. It is also part of the emulated message
> >>>>>>records. All members of it are defined as PtrInt. On placed
> >>>>>>where a handle is iused, it should map on a PtrInt.
> >>
> >> .
> >> .
> >>
> >>>That would be my choice also.
> >>>For me a THandle is a generic abstract identifier, which can identify
> >>>a file, a window, a process, a thread, a event, a bitmap, a pen, a
> >>>brush, a region, a font, a DC, a whatever_I_forgot_more THandle is
> >>>used as basetype for all these types of handles. And personally I
> >>>think it is a bit limitted to use it only for a filehandle.
> >>
> >>Well, whereas I agree that handles can be more than file descriptors, 
> >>I don't see any connection between this fact and requirement to have 
> >>handles of the same size as pointers (although I understand your 
> >>reason)... In addition, having handles incompatible to file 
> >>descriptors would break Delphi compatibility as well. Proper 
> >>emulation of Windows handles would IMHO probably really require some 
> >>kind of mapping between handles and pointers as mentioned in one of 
> >>your previous e-mails.
> > 
> > 
> > In principle, a windows handle is an 'opaque' type. 
> > You're not supposed to make any assumptions about it's size or internal
> > structure.
> > 
> > That Windows uses the same handle type for the I/O API and it's GUI 
> > subsystem is an unfortunate coincidence.
> > 
> > Thinking about it some more I think the more 'correct' choice for Lazarus 
> > is to introduce a TLCLHandle type, which will be equal to a HANDLE 
> > (or THANDLE) type on Windows, but which probably will equal a pointer 
> > under e.g. GTK, and hence a 64-bit pointer on 64-bit platforms.
> > 
> > This will take some work :-)
> > 
> > That said, the RTL should also avoid confusion with the Windows/Delphi
> > THandle type, and introduce a cross-platform and opaque TFileHandle type. 
> 
> It's text/file/file of in pascal ;)

Not in sysutils and TStream, which is what Lazarus uses :-)

> 
> > Which will happen to be equal to THandle on 32-bit windows. 
> > On 32-bit Linux, the definition of THandle will then also equal TFileHandle.
> > 
> > This will also take some work :-)
> 
> I guess this is no solution. It makes porting delphi apps very hard. 
> What's the problem if thandle is 64 bit on 64 bit systems? You can still 
> store a 32 bit file handle in it.

But, as far as I understood, this is exactly the problem: 
According to Peter, THandle is still 32-bit on Linux/64, and Marc wants it to be 64 bit ?

Michael.