[fpc-devel] THandle and 64bit platforms

[Florian Klaempfl]

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 ;)

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