On Mon, 20 Dec 2004, Tomas Hajny wrote:

Date sent:              Mon, 20 Dec 2004 21:02:04 +0100
To:                     "FPC developers' list" <[EMAIL PROTECTED]>
From:                   Marc Weustink <[EMAIL PROTECTED]>
Subject:                RE: [fpc-devel] THandle and 64bit platforms
Send reply to:          FPC developers' list <[EMAIL PROTECTED]>
        <mailto:[EMAIL PROTECTED]>
        <mailto:[EMAIL PROTECTED]>

File descriptors are still 32bit on x86_64, therefor

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

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.

fpc-devel maillist  -  [EMAIL PROTECTED]

Reply via email to