[fpc-devel] THandle and 64bit platforms

[Michael.VanCanneyt at Wisa.be]

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. 
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 :-)

The 2.000.000.000 EUR question is then, who will do this work? ;-)

Michael.