On Mon, 20 Dec 2004, Tomas Hajny wrote:

> Date sent:            Mon, 20 Dec 2004 22:50:06 +0100 (CET)
> From:                 [EMAIL PROTECTED]
> To:                   [EMAIL PROTECTED],
>       "FPC developers' list" <[EMAIL PROTECTED]>
> Subject:              RE: [fpc-devel] THandle and 64bit platforms
> Copies to:            Send reply to:          FPC developers' list 
> <[EMAIL PROTECTED]>
>       <mailto:[EMAIL PROTECTED]>
>       <mailto:[EMAIL PROTECTED]>
> 
>  .
>  .
> > > > > > > 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.
> > >  .
> > >  .
> > 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.
> 
> Probably more design decision than "coincidence" - the same type is 
> used for everything, not just I/O and GUI, but processes, threads and 
> all kinds of system resources too.

A matter of preference, I prefer the Unix way of pid_t, mode_t, size_t. 
Allows more freedom, in my opinion.

The handles are not compatible anyway. It doesn't make much sense to send a
windows message to a file handle ;-)


> > 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 :-)
>  .
>  .
> 
> Would THandle exist on non-Windows platforms under your concept then? 

Yes. But only for compatibility.

> If so, what would it be on Linux x86-64 (by pure coincidence, of 
> course ;-) )?

Whatever TFileHandle is, obviously :)

Michael.

_______________________________________________
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to