Hi,

This code compiles happily for Win32, but refuses to compile for Win64:
====
program test;
{$mode objfpc}
{$h+}
uses
  Registry;
type
  TA = class
  private
    FRootKey: HKey;
  public
    //Win64/X86_64 Error: Range check error while evaluating constants
(18446744071562067969 must be between -2147483648 and 4294967295)
    property RootKey: HKey read FRootKey write FRootKey default
HKEY_CURRENT_USER;  //-2147483647
  end;
begin
end.
===

Is this "by design" or is it a bug?

On Windows HKEY_CURRENT_USER is defined as HKEY(longint($80000001)); HKey is defined as HANDLE = System.THandle = QWord on 64-bit, but it is DWord on 32-bit.
So infact the value of HKEY_CURRENT_USER would be 2147483649 (as a DWord) on 32-bit, and 18446744071562067969 (as a QWord) on 64-bit?

Shouldn't HKEY_CURRENT_USER et al. be defined as HKEY(DWORD(somevalue)) instead?

Tested with fpc 3.2.2 and fpc main 3.3.1-2495-g6453af40d8

If HKey is unsigned, then yes, the definition should be HKEY(DWORD($80000001)).  I do wonder why Win64 produces that particular error though because the final destination is an unsigned 64-bit integer.

Kit

PM J. Gareth Moreton wrote

If HKey is unsigned, then yes, the definition should be HKEY(DWORD($80000001)). I do wonder why Win64 produces that particular error though because the final destination is an unsigned 64-bit integer.

Because QWord(some not so big negative number) = some large positive number.

Yeah, of course, since LongInt($80000001), before typecasting to HKEY, is specifically a signed constant.  So obvious!!

Kit

J. Gareth Moreton wrote

Yeah, of course, since LongInt($80000001), before typecasting to HKEY, is specifically a signed constant.  So obvious!!

Declarations like this have been made on purpose:
HKEY_CURRENT_USER = HKEY(longint($80000001));

On Win64 HKEY_CURRENT_USER must be $FFFFFFFF80000001, but on Win32 it must remain $80000001.

See commit 2012220aec67494ac34329dabe8b6a05dacbb9c1 for details.

Don't break it if you decide to fix something.

Error "Range check error while evaluating constants (18446744071562067969 must be between -2147483648 and 4294967295)" is wrong here:

property RootKey: HKey read FRootKey write FRootKey default HKEY_CURRENT_USER;

Since HKEY = THandle = QWord on Win64, the reported range for it is incorrect.

Yuriy.

Afaik it's because "default" doesn't support qword values, iirc because of (at least old) Delphi compatibility.

Jonas

Found this piece of info:
(https://rt.cpan.org/Public/Bug/Display.html?id=108950)

The Windows SDK defines the HKEY values for the predefined keys by first casting an original literal value (>= 0x80000000) to LONG (signed 32-bit), then to ULONG_PTR (unsigned 32- or 64-bit, depending on architecture), then to HKEY, such as in the following macro definition for HKEY_CLASSES_ROOT in winreg.h:

#define HKEY_CLASSES_ROOT ((HKEY) (ULONG_PTR)((LONG)0x80000000))

For 32-bit builds this results in the final HKEY value being identical to the original literal value, but for 64-bit builds, because of the intermediate signed LONG cast which is then cast to the larger unsigned ULONG_PTR type, the original value is effectively sign-extended to 64-bits, resulting in the most significant 32 bits being set. So in 64-bit architectures HKEY_CLASSES_ROOT is 0xFFFFFFFF80000000, HKEY_CURRENT_USER is 0xFFFFFFFF80000001, and so on.

It seems that most of the Windows Reg* API functions (perhaps all of the ones exposed by Win32API::Registry) compensate for being passed 32-bit versions of those predefined key handles, which apparently is why Win32API::Registry isn't completely broken on 64-bit Perl builds. I only noticed the problem when trying to pass the Win32API::Registry::HKEY_* values to RegOverridePredefKey (used via Win32::API), which seems to be an exception and fails with error code 6 (ERROR_INVALID_HANDLE) when passed 32-bit versions of those handles.

If the reported range is incorrect, then the error is incorrect: the value is perfectly inside the range of a QWord...

So, the question remains: is the compilation error a bug?

PM Jonas Maebe wrote

Afaik it's because "default" doesn't support qword values, iirc because of (at least old) Delphi compatibility.

Would the original code example compile in a modern 64-bit Delphi (targeting Win64)?
My old D7 doesn't even know about QWord (or 64-bit for that matter), so I cannot test this.

Notice that it seems that I can use QWord($0000000080000001) for HKE_CURRENT_USER on Win64 (at least for RegOpenKeyReadOnly).

PM Jonas Maebe wrote

Afaik it's because "default" doesn't support qword values, iirc because of (at least old) Delphi compatibility.

OK, I removed the "default".

Theoretically would that lead to problems when storing the value in lfm and reading it back using different bitness versions of Lazarus? Should I even publish such a property?
(I don't think Lazarus has a property editor for HKEY...)

I wouldn't publish the HKEY property but create an own enumeration for it:

TRegKey = (rgClassesRoot, rgCurrentUser, ....)

and publish this instead. Pro: you can put only valid values into the property and object inspector shows you nice enum names instead of strange integers.

Then make a simple transformation to HKEY:

RegKeyToHKey: array[TRegKey] of HKEY = (HKEY_CLASSES_ROOT,
HKEY_CURRENT_USER, ...);

Ondrej

Yes, I also think this is the best solution...

Michael.

AM Ondrej Pokorny wrote

I wouldn't publish the HKEY property but create an own enumeration for it: TRegKey = (rgClassesRoot, rgCurrentUser, ....)

...

Yep, thought of that as too.
Perhaps the best options.
Thanks.

Reported: https://gitlab.com/freepascal.org/fpc/source/-/issues/40148 (with simplified example).