+Crash when loaded in high adress space

[peterwesterstrom]

If I set the registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference (DWORD)
to 0x100000

64-bit totalcomander do not start. I get a dialog "Access violation".

That usually mean there is some pointer (64-bit) that is stored in a 32-bit word and can cause a crash whenever pointer happen to be in above the 4GB point in address space.

/Peter Westerström

[Horst.Epp]

If I set the registry key
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference (DWORD)
to 0x100000

64-bit totalcomander do not start. I get a dialog "Access violation".

That usually mean there is some pointer (64-bit) that is stored in a 32-bit word and can cause a crash whenever pointer happen to be in above the 4GB point in address space.

/Peter Westerström

There is no need in a x64 Windows for any address manipulation
to start an x64 program.
Looks like you are searching for trouble no one else has.

[Sob]

Looks like he is searching for hidden bugs. Just because they usually don't manifest themselves, does not mean they don't exist.

[MarcinW]

This setting in the registry, that peterwesterstrom described, is useful during a software development. And it's normal that during software development he uses TC ;)

[ghisler(Author)]

Thanks for your report. I have tried to find the reason for the last several hours, without much success. It seems to happen somewhere in the handler of WM_MEASUREITEM, but probably not in my own code. The biggest problem is that the Lazarus/free pascal debugger "gdb" crashes immediately after starting any program when this switch is set.

[ghisler(Author)]

The problem was indeed WM_MEASUREITEM, because it doesn't pass a window handle to the window function. Lazarus uses the WPARAM value (control ID), which is set to the memory address of the control object.

There were two bugs involved, one in Lazarus and one in Windows itself:
1. Lazarus uses SetWindowLong instead of SetWindowPtr to set the control ID.
2. Although WPARAM is 64-bit, WM_MEASUREITEM only passes the lower 32-bit of the control ID to the window function.

I have implemented a workaround now, please try it!

[Lefteous]

2ghisler(Author)

Although WPARAM is 64-bit, WM_MEASUREITEM only passes the lower 32-bit of the control ID to the window function.

WPARAM is defined as ctlID of MEASUREITEMSTRUCT. It is of type UINT which is clearly 32 bit. I don't see the Windows bug here. The only member of MEASUREITEMSTRUCT that can be 64 bit is itemData.
Can you explain where the 64 bit value is coming from?

[ghisler(Author)]

WPARAM should be the control ID, and the control ID can be 64-bit on 64-bit Windows. The field in the struct is 32-bit only, but the WPARAM is 64-bit, so there is no reason to pass only the lower 32-bit of the 64-bit control ID.

[MarcinW]

The GetDlgCtrlID API function returns 32-bit integer, so control ID's are 32-bit.

This is probably for interoperability reasons - 32-bit applications can exchange CtlIDs with 64-bit applications. For the same reason, some handles, although have 64-bit size in Win64, are guaranteed not to exceed lower 32-bits.

More info here: Interprocess Communication Between 32-bit and 64-bit Applications.

[ghisler(Author)]

Why is it then possible to set 64-bit ID with SetWindowLongPtr? Reading it back with GetWindowLongPtr works with full 64-bit.

Anyway, that's irrelevant for the current bug - can anyone try the fix?

[MarcinW]

I can confirm, that TC 8.51 Beta 1 64-bit raises Access Violation exceptions during the startup, and there are no AVs anymore in TC 8.51 Beta 2 64-bit.

Tested with Windows 7 64-bit.

[ghisler(Author)]

Thanks!