T9xHandleTable = packed record
itemCount : integer;
items : array [0..maxInt shr 3 - 1] of T9xHandleItem;
Compile under 64-bit, it will generate the error of data size over 2G
function GetHandleTableNt : TNtHandleTable;
var c1 : cardinal;
p1 : pointer;
result.ItemCount := 0;
result.Items := nil;
if @NtQuerySystemInformation = nil then
NtQuerySystemInformation := GetProcAddress(GetModuleHandle(ntdll), 'NtQuerySystemInformation');
dword(p1) := LocalAlloc(LPTR, 20);
Pointer size is 8byte under 64-bit, Cardinal() will cause the high 4byte of the pointer value to be lost
tic.main.size := sizeOf(TTrayIconCommand2000);
tic.main.flags := $80000037;
integer(tic.main.tip) := integer(ptic) + sizeOf(TTrayIconCommand2000);
Similarly, Integer() causes the high 4byte of the pointer value to be lost
I fully respect that you are busy Madshi and I also completely understand that you don't have the time anymore to dedicate to maintaining madCollection, let alone upgrading it to 64 but and maintain it.
I do have a suggestion however, how about making madCollection Open Source ?
..apart from madExcept and madCodeHook of course, but the rest of madCollection, maybe there is people out there who have the time to port/convert/upgrade whatever little bit they are working with or need to 64 bit, then they can contribute it back to the benefit of everybody ?
I'm not sure who should be the auditor of the repo, as the contributors (i.e. the users of madCollection) should maybe not be able to make changes unhindred, potentially breaking and destroying the codebase beyond salvation.
Just my 2 cents..
Plus, if open source devs modify madBasic stuff, and I implement those changes into madExcept and madCodeHook, that could not only be difficult from a license point of view, but it could also risk the stability of madExcept and madCodeHook.
I was just thinking that there might be a way to get the community to chip in lifting madKernel, madShell and other stuff that is not x64 ready onto 64 bit, if not the Open Source way - then maybe some other way..
I mean, when calling madCodeHook I would pass a pid as parameter, but it seems a bit odd to traverse the list of running processes (and the intricacies of pulling said lists from the kernel) by more or less direct API calls or by use of another library, when the best library in the Delphi world is literally installed on the PC already..