On Mon, 20 Dec 2004, Florian Klaempfl wrote:
> [EMAIL PROTECTED] wrote: > > > > 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 > >>>>>>>>>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. _______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
