About the long (.l) on recent PB...

[Caronte3D]

Question:
On what PB version introduced the need to change .l to .i in order to be able to work the same as past?
Sorry I don't know how to explain it (my bad English), but hope you understand

[Demivec]

Are you referring to the process that returns memory allocation addresses that are more random instead of sequential, like low ones first and high ones later, as an added security feature? If so, then you realize that change merely exposed that the variables that needed to be changed were previously declared with the wrong size because they couldn't hold the range of possible memory addresses that could be returned.

I believe it was PureBasic version 6.10.

Here's a link to a reference by Fred: https://www.purebasic.fr/english/viewtopic.php?p=633695#p633695

[TI-994A]

On what PB version introduced the need to change .l to .i in order to be able to work the same as past?

If I understand correctly, you're referring to the introduction of the first 64-bit version of PureBasic, v4.30, released in December 2008.

It effectively changed the size of integer and long data types, causing some legacy code to break.

[Caronte3D]

I think Demivec's answer is exactly what I need. Thanks
to both of you!

[Andre]

There should be more helpful topics on this forum, but I found another one by 'freak' in the PureBasic Team Blog describing the changes for 64bit: Is your 64bit program really solid ?

[TI-994A]

...it's because your DLL doesn't support ASRL (random memory allocation using all 64-bit range meaning than pointer can be greatly above 32-bit).

Oh dear! That's something new that I hadn't heard about.

[idle]

So that's the reason. Makes perfect sense now.