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

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

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

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" ?

In general, Peter is right, and it would be better to introduce a separate type for the 'windows handle': TWinHandle or TLCLHandle which is platform dependent.

OTOH, We could also reverse the argument and introduce TFileHandle, so as to clearly mark the fact that it is for files only...

Michael.

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

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

.
.

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

Date sent: Mon, 20 Dec 2004 22:50:06 +0100 (CET) From:
To: ,
"FPC developers' list"
Subject: RE: [fpc-devel] THandle and 64bit platforms Copies to: Send reply to: FPC developers' list

.
.

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.

.
.

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

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.

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

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.

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.

Not in sysutils and TStream, which is what Lazarus uses :-)

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.

You still can store a TFileDescriptor in a THande

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)

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

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

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 ?

But I cannot give you 2.000.000.000 EUR :)

Michael.

Except that they may have used it.

Bummer :(

Marc

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.

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.

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

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

Michael.

This would be nice

Marc

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.