Re: [fpc-devel] THandle and 64bit platforms

2005-08-02 Thread Vincent Snijders

Marc Weustink wrote:

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Florian
Klaempfl
Sent: dinsdag 21 december 2004 8:30

Peter Vreman wrote:



My proposal is to rename the current THandle to TFileHandle. And add an
platform independent type THandle=PtrUInt.
Note that this can still cause range check errors under Unix, because
invalid filedescriptors have (normally) value -1.


Sounds good to me.



This would be nice



As far as I could see in the sources, this renaming has not been done 
yet. Is there any time schedule? Should I make a bug report?


Vincent.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] THandle and 64bit platforms

2004-12-21 Thread Michael Van Canneyt


On Tue, 21 Dec 2004, Florian Klaempfl wrote:

 Peter Vreman wrote:

 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.
 
 
  It'll give a lot of Warnings when compiling the sources. And there is a
  risk for rangecheck errors.
 
  I checked Kylix, there THandle=longword which is also incompatible with
  our THandle=longint under Linux.
 
  My proposal is to rename the current THandle to TFileHandle. And add an
  platform independent type THandle=PtrUInt.
  Note that this can still cause range check errors under Unix, because
  invalid filedescriptors have (normally) value -1.

 Sounds good to me.

If we rename THandle to TFileHandle then we should use it where needed,
so we don't get any range check errors.

Michael.

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


[fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Marc Weustink
Hi,

From what I understand from the definition of THandle in sysunixh.inc it
is defined as a LongInt, even on 64 bit platforms.
Currently I'm porting Lazarus to x64 and there I need a 64bit THandle, how
to solve it ?

Marc


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


Re: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Peter Vreman
 Hi,

From what I understand from the definition of THandle in sysunixh.inc it
 is defined as a LongInt, even on 64 bit platforms.
 Currently I'm porting Lazarus to x64 and there I need a 64bit THandle, how
 to solve it ?

File descriptors are still 32bit on x86_64, therefor Thandle=32bit.




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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Marc Weustink

 Hi,

 From what I understand from the definition of THandle in
 sysunixh.inc it is defined as a LongInt, even on 64 bit platforms.
 Currently I'm porting Lazarus to x64 and there I need a 64bit
 THandle, how to solve it ?

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 ?

Marc



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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Peter Vreman

 Hi,

 From what I understand from the definition of THandle in
 sysunixh.inc it is defined as a LongInt, even on 64 bit platforms.
 Currently I'm porting Lazarus to x64 and there I need a 64bit
 THandle, how to solve it ?

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.








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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Marc Weustink
 Hi,

 From what I understand from the definition of THandle in
 sysunixh.inc it is defined as a LongInt, even on 64 bit platforms.
 Currently I'm porting Lazarus to x64 and there I need a 64bit
 THandle, how to solve it ?

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.

Woudl you suggest me to
  a) forbid the use of thandle
  b) change all records and places where thandle is used
  c) create a intermediate function which maps a handle to a pointer
 (and still change a load of records)

Marc



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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Peter Vreman
 Hi,

 From what I understand from the definition of THandle in
 sysunixh.inc it is defined as a LongInt, even on 64 bit platforms.
 Currently I'm porting Lazarus to x64 and there I need a 64bit
 THandle, how to solve it ?

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.

 Woudl you suggest me to
   a) forbid the use of thandle
   b) change all records and places where thandle is used
   c) create a intermediate function which maps a handle to a pointer
  (and still change a load of records)

The RTL should stay clean of Windows specific issues.THandle is defined as
the same type as filedescriptors on the target OS. When you need some
handle for Windows emulation you can create your own type TLCLHandle that
will be 64bit for all platforms.







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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Marc Weustink
At 20:34 20-12-2004, [EMAIL PROTECTED] wrote:
On Mon, 20 Dec 2004, Peter Vreman wrote:
  Hi,
 
  From what I understand from the definition of THandle in
  sysunixh.inc it is defined as a LongInt, even on 64 bit platforms.
  Currently I'm porting Lazarus to x64 and there I need a 64bit
  THandle, how to solve it ?
 
 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.
 
  Woudl you suggest me to
a) forbid the use of thandle
b) change all records and places where thandle is used
c) create a intermediate function which maps a handle to a pointer
   (and still change a load of records)

 The RTL should stay clean of Windows specific issues.THandle is defined as
 the same type as filedescriptors on the target OS. When you need some
 handle for Windows emulation you can create your own type TLCLHandle that
 will be 64bit for all platforms.
I guess this is supposed to be 64-bit on 64-bit platforms ?
Guess so :)
In general, Peter is right,
(sorry, I couldn't resist :)
and it would be better to introduce a
separate type for the 'windows handle': TWinHandle or TLCLHandle
which is platform dependent.
I've been thinking of a TLCLHandle, but one of the goals of Lazarus is to 
keep Delphi apps easy portable. And replacing all THandles with TLCLHandle 
doesn't sound very port friendly to me. Besides, since THandle is defined 
in system, if someone forgets to change it, the ported app will probably 
compile with only a easy to miss warning, whith all resulting errors.
But I understand that this has nothing to with the choice of a THandle 
beeing 32 bit.

OTOH, We could also reverse the argument and introduce TFileHandle, so as to
clearly mark the fact that it is for files only...
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.

Marc 

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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Tomas Hajny
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.

Tomas


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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Michael . VanCanneyt


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

Michael.

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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Tomas Hajny
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.


 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? 
If so, what would it be on Linux x86-64 (by pure coincidence, of 
course ;-) )?

Tomas


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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Michael . VanCanneyt


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


Re: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Florian Klaempfl
[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 ;)
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]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Michael . VanCanneyt


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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Marc Weustink
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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Michael . VanCanneyt


On Tue, 21 Dec 2004, Marc Weustink wrote:

 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

People who want to write portable apps should definitely not make any
assumptions about Thandle. Since TLCLhandle=Handle on windows, this 
should not really be a problem ?


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

But I cannot give you 2.000.000.000 EUR :)

Michael.

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


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Marc Weustink
At 00:15 21-12-2004, [EMAIL PROTECTED] wrote:
On Tue, 21 Dec 2004, Marc Weustink wrote:
 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

People who want to write portable apps should definitely not make any
assumptions about Thandle. Since TLCLhandle=Handle on windows, this
should not really be a problem ?
Except that they may have used it.
 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 :)

But I cannot give you 2.000.000.000 EUR :)
Bummer :(
Marc
___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread peter green
 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.
the only place I could see is var parameters.

and if needed that could be got around by overloading functions users were
likely to pass the thandles to.




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


Re: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Peter Vreman
 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.

It'll give a lot of Warnings when compiling the sources. And there is a
risk for rangecheck errors.

I checked Kylix, there THandle=longword which is also incompatible with
our THandle=longint under Linux.

My proposal is to rename the current THandle to TFileHandle. And add an
platform independent type THandle=PtrUInt.
Note that this can still cause range check errors under Unix, because
invalid filedescriptors have (normally) value -1.




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


Re: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Florian Klaempfl
Peter Vreman wrote:
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.

It'll give a lot of Warnings when compiling the sources. And there is a
risk for rangecheck errors.
I checked Kylix, there THandle=longword which is also incompatible with
our THandle=longint under Linux.
My proposal is to rename the current THandle to TFileHandle. And add an
platform independent type THandle=PtrUInt.
Note that this can still cause range check errors under Unix, because
invalid filedescriptors have (normally) value -1.
Sounds good to me.
___
fpc-devel maillist  -  [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] THandle and 64bit platforms

2004-12-20 Thread Marco van de Voort
 On Tue, 21 Dec 2004, Marc Weustink wrote:
  
  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 :)
 
 But I cannot give you 2.000.000.000 EUR :)

Wait till after newyear's sweepstakes. You never know (unless you, like me,
don't buy tickets)

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