PB 6.10 x64 OpenLibrary

[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")

(I wasn't actually using version.dll, this is just an example.)

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

[ChrisR]

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.

[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!

[Little John]

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!

[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.

[HeX0R]

to keep fair against old codes/coders, at the beginning of PB, there were no integers and longs were the default.

[mk-soft]

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