PureBasic Forums - English

Hello, the following code compiles successfully under PureBasic x86, but an error occurs under PureBasic x64. Perhaps adding InterlockedExchangeAdd64 and InterlockedCompareExchange64 could fix this bug?
https://learn.microsoft.com/en-us/windo ... xchangeadd
https://learn.microsoft.com/en-us/windo ... reexchange


// Moved from "Bugs - Windows" to "Coding Questions" (Kiffi)

Not a bug, InterlockedExchangeAddoperates with 32 bit values. Using InterlockedExchangeAdd64 will work.

The sources you linked also say this.

jacdelad wrote: Fri Nov 14, 2025 5:15 am Not a bug, InterlockedExchangeAddoperates with 32 bit values. Using InterlockedExchangeAdd64 will work.

The sources you linked also say this.

[13:20:01] [COMPILER] Line 3: InterlockedExchangeAdd64_() is not a function, array, list, map or macro.
[13:21:20] [COMPILER] Line 11: InterlockedCompareExchange64_() is not a function, array, list, map or macro.

This is a Windows API call. Just because it's not defined, doesn't mean it's a bug. You can define it by yourself.
BTW: A lot of APIs are not defined by default...

jacdelad wrote: Fri Nov 14, 2025 7:16 am This is a Windows API call. Just because it's not defined, doesn't mean it's a bug. You can define it by yourself.
BTW: A lot of APIs are not defined by default...

"I understand your explanation, but I don't quite agree with it. When the same code, compiled with the same compiler version, compiles correctly for the x86 version but fails for the x64 version, the compiler's error message is the first thing an end user sees. In such cases, it's most intuitive for the user to initially suspect the compiler itself. It's less obvious to understand that the issue might be because the required API is already defined as a built-in in the x86 version but is missing in the x64 version, requiring a manual definition.
Therefore, while categorizing it as a bug might not have been entirely accurate, it didn't seem completely inappropriate at the time. Furthermore, I was unsure which forum section was the most suitable for this post, so I posted it in the bug report section based on my own understanding.
Finally, thank you for your reply. The reason I made this post was simply to hope that the official team might consider improving this situation by adding the missing definition in the x64 version. Since it's defined in x86, an end user would naturally expect that the same function should probably be already defined in the x64 version as well."

There's a thread for missing API definitions and the wishing section.l and in sure Fred will include it in the next version.
viewtopic.php?t=64838

Again, this is not an error by the compiler: The function you call is not defined. Not more, not less. The defined one does exactly, what it shall do. A missing API definition outside the PureBasic command set is not a bug. Regardless of the compiler (x86 or x64), both compiler produce the same right code. InterlockedExchangeAdd64 is not defined for the x86 compiler too, so following your logic, the x86 compiler would be faulty too.

That being said, just wait for the next version or define it yourself.

I am a big fan of the PureBasic language—it is excellent. Both its syntax and the resulting executables are straightforward and efficient. I understand your explanation and have tried to comprehend it from the perspective of code generation by the compiler. Regarding Windows API functions like InterlockedExchangeAdd, it seems that such functions are already built into the x86 version but not the x64 version, requiring users to introduce or resolve them manually.
This situation left me quite confused until I read your reply and checked the APIFunctionListing.txt file, which helped me understand the root cause. So, can I take it that if a similar situation arises in the future—for example, when using a certain Windows API function, if the x86 version compiles successfully while the x64 version (or vice versa) prompts that the API function is undefined—it indicates that one of the compilers (x86 or x64) has it built-in, while the other does not, and we need to pay attention and resolve it ourselves?
The purpose of my post was to feedback the issue I encountered to the PureBasic development team. Of course, as you mentioned, perhaps future versions of PureBasic will improve this circumstance, and I hope so. Actually, for such issues, I'm not very inclined to treat it as a feature request and post it in the "Feature Requests" section, hoping the development team will eventually build the corresponding API functions into the respective versions. Finally, I wish PureBasic continued growth and improvement, and I hope every PureBasic user and forum friend has a happy day!

Many APIs can be maintained with import yourself if they are also present in windows lib file.
If not, you have to load the function with OpenLibrary, or replace the lib file.

mk-soft wrote: Fri Nov 14, 2025 6:28 pm Many APIs can be maintained with import yourself if they are also present in windows lib file.
If not, you have to load the function with OpenLibrary, or replace the lib file.

Thank you. Yes, I found the root cause and solved it myself by importing references.

gltianya wrote: Fri Nov 14, 2025 5:28 pmhoping the development team will eventually build the corresponding API functions into the respective versions

Won't happen. It's been discussed before. It's because (1) PureBasic is cross-platform, and (2) the entire API data is over 1 GB. It says at PureBasic.com:

"Even if PureBasic supports natively nearly all of the Windows API functions, it's impossible to include all their descriptions as it's more than 1 GB of data. You can get all the needed information on the Microsoft site."