At 22:50 20-12-2004, [EMAIL PROTECTED] wrote:
On Mon, 20 Dec 2004, Tomas Hajny wrote:
> From: Marc Weustink <[EMAIL PROTECTED]> > > > > >>>>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.
You still can store a TFileDescriptor in a THande
> 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 is true (however you need the size of you want to ut it in records)
When I was programming win16, a handle was 16bit. And there it was indeed a handle (or index) to an internal table. On win32 handles became 32bit and more and more the internal pointer behind it.
To go back to the old way on win64 and add an extra indirection is a bit overhead (not in acessing, but in managing)
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.
Since it is an opaque type, it now is a type Integer. On win32 it way contain a Handle, on gtk it may contain a pointer. A handle/pointer to what is oficially undefined.
This will take some work :-)
For adapting Lazarus I've no problems with it. For ppl wanting to port apps I see more problems. Especially when a shorter version of it exists. Besides I don't know what other Lazarus devels think
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? ;-)
I did some counting:
Rtl: 489 times (excluding win32, including os2, including comments) Lazarus: 105 times (exluding win32 and docs)
Hmm..... I can give you an answer :)
Marc
_______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
