Page 1 of 1
PB 6.10 x64 OpenLibrary
Posted: Wed Apr 10, 2024 8:26 pm
by manu
Hi!
Code: Select all
Global my_lib.l
my_lib=OpenLibrary(#PB_Any, "version.dll")
Debug Str(my_lib)+" = $"+Hex(my_lib)
If my_lib = 0:End:EndIf
GetFunction(my_lib,"GetFileVersionInfoA")
Works with PB6.00 x64, crashes with PB6.10 x64.
The reason is the OpenLibrary actually returns a 64 bit value (>$FFFFFFFF) now. If you change my_lib.l to my_lib.i it works.
It is maybe better to use .i but many older programs have 32 bit variables when storing numbers returned by using #PB_Any.
Maybe it can be fixed to use 32 bit numbers only, as it was before?
Or is needs to be documented which functions now need a 64 bit storage for their Gadget/Image/Window/Whatever-Number.
Best regards,
Manu
Re: PB 6.10 x64 OpenLibrary
Posted: Wed Apr 10, 2024 9:32 pm
by ChrisR
Fred wrote: Mon Mar 11, 2024 11:03 am
BarryG wrote: Mon Mar 11, 2024 10:51 am
Changed to ".i" and all is working well again. Far out. Coding with 6.10 is so confusing now.
The confusing thing here is that wrong codes were 'correctly' working with previous version due to memory address fitting into long (.l) on x64. Again see this as an opportunity to finally have less hidden bugs in your apps.
Re: PB 6.10 x64 OpenLibrary
Posted: Thu Apr 11, 2024 4:47 am
by jacdelad
This is a terrible idea and also not possible. PureBasic has no power over which address is returned if an object (like a library) is assigned. That's why the help clearly states to use .i for handles. This is also fact for every programming language which uses x86-/x64-architecture. The simple fact that it worked before (by coincidence) is not a reason change something!
Re: PB 6.10 x64 OpenLibrary
Posted: Thu Apr 11, 2024 6:26 am
by Little John
jacdelad wrote: Thu Apr 11, 2024 4:47 am
That's why the help clearly states to use .i for handles.
... and that's been the case for at least as long as I've been using PureBasic (15+ years).
PS: Please don't post your coding questions in the “Bug reports” section of the forum!
Re: PB 6.10 x64 OpenLibrary
Posted: Thu Apr 11, 2024 2:03 pm
by boddhi
For those who haven't experienced it yet, please note too that this is often the reason why older codes on the forum crash. They use .l type instead of .i, the default type and equivalent under 32bits though. It often occurs, for example, with callbacks or subclassing...
As Chris said, this is sometimes an opportunity to update a code and, on Windows (I don't know about other OS) to change the name of some called APIs too (e.g. SetWindowLongPtr instead of SetWindowLong) to ensure compatibility.
Re: PB 6.10 x64 OpenLibrary
Posted: Thu Apr 11, 2024 4:34 pm
by HeX0R
to keep fair against old codes/coders, at the beginning of PB, there were no integers and longs were the default.
Re: PB 6.10 x64 OpenLibrary
Posted: Thu Apr 11, 2024 5:39 pm
by mk-soft
HeX0R wrote: Thu Apr 11, 2024 4:34 pm
to keep fair against old codes/coders, at the beginning of PB, there were no integers and longs were the default.
I remember it darkly
