4 ms·

It's fine, but you really should call MessageBoxA if you're not going to use _T() around your strings.

jeroenhd 3y ago
With the standard, retro compiler as used in the 90s Developer Pack example, the compiler will assume you're calling the ASCII methods unless you manually configure it to use Unicode by default. During modern Windows development you should probably default to wide characters, of course.
- garaetjjte 3y ago
  Can we finally go back to using *A functions, but with UTF-8?
  - NavinF 3y ago
    Yes, see sibling comment. > Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes.
  - skissane 3y ago
    Unfortunately there are still cases where the A API has bugs that the W API lacks, see e.g: https://stackoverflow.com/q/67427569 https://stackoverflow.com/q/67427569 Also, some APIs use buffers with a fixed maximum size, and the A API's buffer isn't big enough to handle the maximum possible data size for the W API. And some APIs are Unicode-only, and don't have A versions. For maximum reliability, better to use W APIs only and do the UTF-8<->UTF-16 conversion yourself. However, in practice, if you just use A APIs only and let Windows do the UTF-8 conversion for you, it is going to work 95% of the time. But maybe at some point you'll hit that 5% where it doesn't. It is more likely if you are using more obscure APIs (like my example at the start of manipulating Windows Terminal Server sessions). More likely for system-level stuff than application-level.
    - account42 3y ago
      > For maximum reliability, better to use W APIs only and do the UTF-8<->UTF-16 conversion yourself. You mean the WTF-8<->WTF-16 conversion. https://simonsapin.github.io/wtf-8/ https://simonsapin.github.io/wtf-8/
  - Dwedit 3y ago
    You can if you manage to call the secret API function that initializes the code page data for UTF-8 rather than your system default codepage. Or if you make it Windows 10+ only and add a particular manifest.
- NavinF 3y ago
  As long as your users have updated in the last 4 years you can use UTF-8: https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page https://learn.microsoft.com/en-us/windows/apps/design/global...
- versteegen 3y ago
  However, Windows 9X didn't actually support the 16-bit wide-char winapi. Apparently it did actually define the *W functions but they were nearly all just stubs. In 2001 Microsoft retroactively added support for the wide-char API to Windows 9X (according to https://stackoverflow.com/a/35329506/1185152 https://stackoverflow.com/a/35329506/1185152): > In 2001 Microsoft released an add-on for Windows 9x called the Microsoft Layer for Unicode (MSLU), which changed the W functions from failing-stubs to thunking proxies which converted the strings back into an 8-bit format and then called the A functions, so programs explicitly using W functions could run on Windows 9x.
  - Dwedit 3y ago
    Weirdly enough, the on-disk structure for long filenames used 16-bit characters. Also lots of 16-bit character stuff all over COM.
jussij 3y ago
You can get by using the agnostic names for the functions, because the windows header files will handle the conversions for you. For example, inside the WinUser.h header you'll find this MessageBox definition: #ifdef UNICODE #define MessageBox MessageBoxW #else #define MessageBox MessageBoxA #endif // !UNICODE These agnostic definitions help if you want the code to compile as both 32 bit and 64 bit without code changes.
- projektfu 3y ago
  Yes, then you should make sure UNICODE is not defined, probably by #ifdef UNICODE #error This is written only for ANSI windows. #endif Or you can use TCHAR and _T().
codeflo 3y ago
That fixes the problem, but goes in the wrong direction IMO. I argue that you actually should only use MessageBoxW, ignore all the macros, and just use wide strings whenever you interact with the OS. An Ansi-only program is broken in 2023, and actually has been for two decades.
- lmz 3y ago
  But now you can use the ANSI functions to support UTF-8: https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page#-a-vs--w-apis https://learn.microsoft.com/en-us/windows/apps/design/global...
  - account42 3y ago
    *terms and conditions apply If you are dealing with user-created files you should always use the *W functions as filenames are not guaranteed to be valid UTF-16 and thus might not be accessible via UTF-8 *A calls. At least until Microsoft adds WTF-8 [0] support to the *A functions. You can use WTF-8 yourself internally of course so no need for wide strings outside your platform abstraction code. [0] https://simonsapin.github.io/wtf-8/ https://simonsapin.github.io/wtf-8/
- projektfu 3y ago
  I agree, but we're also talking about Win95, which didn't support Unicode until 2001. The example compiles fine so long as UNICODE isn't defined but assuming, as a 90s dev, you'll eventually want to support NT when they make it run games, you should probably leave the door open with TCHAR.

With the standard, retro compiler as used in the 90s Developer Pack example, the compiler will assume you're calling the ASCII methods unless you manually configure it to use Unicode by default. During modern Windows development you should probably default to wide characters, of course.

garaetjjte 3y ago
Can we finally go back to using *A functions, but with UTF-8?
- NavinF 3y ago
  Yes, see sibling comment. > Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes.
- skissane 3y ago
  Unfortunately there are still cases where the A API has bugs that the W API lacks, see e.g: https://stackoverflow.com/q/67427569 https://stackoverflow.com/q/67427569 Also, some APIs use buffers with a fixed maximum size, and the A API's buffer isn't big enough to handle the maximum possible data size for the W API. And some APIs are Unicode-only, and don't have A versions. For maximum reliability, better to use W APIs only and do the UTF-8<->UTF-16 conversion yourself. However, in practice, if you just use A APIs only and let Windows do the UTF-8 conversion for you, it is going to work 95% of the time. But maybe at some point you'll hit that 5% where it doesn't. It is more likely if you are using more obscure APIs (like my example at the start of manipulating Windows Terminal Server sessions). More likely for system-level stuff than application-level.
  - account42 3y ago
    > For maximum reliability, better to use W APIs only and do the UTF-8<->UTF-16 conversion yourself. You mean the WTF-8<->WTF-16 conversion. https://simonsapin.github.io/wtf-8/ https://simonsapin.github.io/wtf-8/
- Dwedit 3y ago
  You can if you manage to call the secret API function that initializes the code page data for UTF-8 rather than your system default codepage. Or if you make it Windows 10+ only and add a particular manifest.
NavinF 3y ago
As long as your users have updated in the last 4 years you can use UTF-8: https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page https://learn.microsoft.com/en-us/windows/apps/design/global...
versteegen 3y ago
However, Windows 9X didn't actually support the 16-bit wide-char winapi. Apparently it did actually define the *W functions but they were nearly all just stubs. In 2001 Microsoft retroactively added support for the wide-char API to Windows 9X (according to https://stackoverflow.com/a/35329506/1185152 https://stackoverflow.com/a/35329506/1185152): > In 2001 Microsoft released an add-on for Windows 9x called the Microsoft Layer for Unicode (MSLU), which changed the W functions from failing-stubs to thunking proxies which converted the strings back into an 8-bit format and then called the A functions, so programs explicitly using W functions could run on Windows 9x.
- Dwedit 3y ago
  Weirdly enough, the on-disk structure for long filenames used 16-bit characters. Also lots of 16-bit character stuff all over COM.

jussij 3y ago

You can get by using the agnostic names for the functions, because the windows header files will handle the conversions for you. For example, inside the WinUser.h header you'll find this MessageBox definition: #ifdef UNICODE #define MessageBox MessageBoxW #else #define MessageBox MessageBoxA #endif // !UNICODE These agnostic definitions help if you want the code to compile as both 32 bit and 64 bit without code changes.

projektfu 3y ago
Yes, then you should make sure UNICODE is not defined, probably by #ifdef UNICODE #error This is written only for ANSI windows. #endif Or you can use TCHAR and _T().

codeflo 3y ago

That fixes the problem, but goes in the wrong direction IMO. I argue that you actually should only use MessageBoxW, ignore all the macros, and just use wide strings whenever you interact with the OS. An Ansi-only program is broken in 2023, and actually has been for two decades.

lmz 3y ago
But now you can use the ANSI functions to support UTF-8: https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page#-a-vs--w-apis https://learn.microsoft.com/en-us/windows/apps/design/global...
- account42 3y ago
  *terms and conditions apply If you are dealing with user-created files you should always use the *W functions as filenames are not guaranteed to be valid UTF-16 and thus might not be accessible via UTF-8 *A calls. At least until Microsoft adds WTF-8 [0] support to the *A functions. You can use WTF-8 yourself internally of course so no need for wide strings outside your platform abstraction code. [0] https://simonsapin.github.io/wtf-8/ https://simonsapin.github.io/wtf-8/
projektfu 3y ago
I agree, but we're also talking about Win95, which didn't support Unicode until 2001. The example compiles fine so long as UNICODE isn't defined but assuming, as a 90s dev, you'll eventually want to support NT when they make it run games, you should probably leave the door open with TCHAR.