Back when I first added the 64-bit compiler options for us, READ and DATA statements didn’t work with it. (There’s a difference of an extra leading underscore needed for the c++ data linking syntax, which was so subtle I never picked up on it at all. Luke is the one who finally found and corrected the glitch.)
But that was back all the way in the [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there] days, when I bundled and offered the 64-bit version as a personal option via my dropbox. (Much like I currently offer my expanded SDL-version, which I need to get back to work on sometime to bring further up to current language standards…)
Before QB64.org ever started to include the 64-bit compiler within the github repo, and before it ever offered QB64x64 as an “official” download version, the DATA glitched was found and fixed. As far as I know, the only real differences you might see between the two versions now might be hardware related.
64-bit may use 64-bit floating point math instead of 32-bit math…. Of course, 64-bit can use unlimited amounts of system memory without an issue, whereas 32-bit has about a 1.5GB limit…
There’ll always be *some* differences due to the nature of the two systems being different (such as 32-bit pointers being 4-bytes in size, and 64-bit pointers being 8-bytes), but 99.99% of programs should work interchangeably between the two systems. Those that don’t, probably would, with just a little tweaking to them. (To adjust to windows data packing if a declare library is used, or to allow for larger offset sizes, or minor fpu math variations…)
Honestly, unless you’re just pushing the boundaries of what QB64 can do normally, you probably won’t ever see any difference in the two, And, when you DO start to push so hard that things get wonky, just remember to post here on the forums for help. There’s several of us now who can help with those little mem/packing/syntax/$IF tweaks required to make things work fully — and we’re all always happy to help!
