Are both A and W versions needed in Windows API declares

I see everyone everywhere declaring both the “A” and “W” versions of an API function.

I did quite a bit of searching, but cannot figure out when exactly the A version is required by the API and the W.
What I’ve read is that the APIs in Windows exclusively use the “W” version, and the “A” version just maps to the “W” version anyway.

I understand the differences between ANSI and Unicode, that’s not the question.

The question is why does everyone declare BOTH types instead of just using the “W” version?

Take a look at the CreateFileA and at the CreateFileW documentation.
The first parameter lpFileName (LPCSTR) is a pointer to an ascii string for CreateFileA but the same parameter for CreateFileW (LPCWSTR) is a pointer to an UTF16 unicode string.
Also the docs reports that the maximum string length is different for the two function version.
So “A” is for encoded ascii string and “W” is for UTF16 unicode strings.

Xojo does automatic conversion between WString (UTF16 unicode) and String (native default UTF8 unicode).
In general you will use only the “W” version of the API

W version is enough.

Ok, so why does everyone still create an “A” version?

A is ANSI, W is Unicode 16, Words. W doubles the size of parameters in case of you using only 0-255 char sets. When handling some international char sets there’s no option and you’ll need the “Words” version to use extended char sets. English speakers not caring much about internationalization usually just use the legacy ANSI coding with the simpler strings.

Also, on some versions of Windows, “Wide” declares may not exist.

As I said, I understand the difference between ANSI and UniCode.

Still haven’t gotten an answer yet as to why everyone uses both in their code. Just use the “W” version and all bases are covered, no?

What is the scenario where the API will pick the “A” version?

Aha. Now we’re getting somewhere. What versions?

Older versions like XP (maybe even Vista?) and below, generally. I still typically consider it unsafe to only implement the wide variant as we’ve seen MS not incorporate those functions in one area while doing so in another before.

As Xojo is Win7 and upper, the Vista and lower fear can be dismissed. (Soon win8 and upper).

But not the fear that MS makes a mistake. I’d rather add a couple of lines to my project now than try to track down an MS-caused bug later.

Some Xojo users go back and forth between Xojo versions to support older operating systems. It’s the whole reason API 2.0 went down as poorly as it did. There’s no reason to be ignorant of other people’s needs.

I have a number of projects that still need to function on legacy XP machines. :shrug:

If I remember correctly most A versions just convert text to unicode and call W function internally.
But not sure where I read that… long ago.

As I said earlier.

[quote=468325:@Christian Schmitz]If I remember correctly most A versions just convert text to unicode and call W function internally.
But not sure where I read that… long ago.[/quote]
On more modern versions of Windows, sure, that may be true.

Be nice to find a list of API functions that AREN’T supported in W but are still available on modern versions of Windows…

Long story short, if you want to cover your bases, check for the Wide variant function in your code with System.IsFunctionAvailable. If it exists, execute that. If not, fallback to the A function and you know you’re safe.

So this means overhead.

Not “ignorant”, such cited fact had not such intention, no need to be aggressive. Yes, sometimes I forget some users still use XP and Realstudio 2011, but I’m not being ignorant when doing so. Try to be a bit more polite please.

Sure, but WHEN would it ever need to fall back? From what I’ve read, it seems like the “A” versions of Windows API functions were deprecated 20 years ago.

Nothing wrong with covering bases, but if you’re still putting in support for RS-232 mice and Parallel printers, (if we actually had to do that because the OS didn’t take care of that), would it really be sensible?
I think it might be easier to just test the version of Windows in your app and then pop up a message when they try to run it on Windows 3.1 that they need to update their life! :wink: