A collection of code snippets, small pearls of wisdom and bits of knowledge, that may come handy at times.

This is a specialized page for things related to the Windows operating system, the Windows API (Win32) or the Visual Studio IDE/Microsoft Compiler (and maybe later also other compilers that can be used to generate executables for Windows); the more generic page is C++ Snippets.

Don’t expect well thought out descriptions or highly structured content here; these are snippets. (But there are some links spread around for further reading.)

On catching exceptions

The attempt to catch all exceptions by (try {} catch (...) {}) on Windows will by default not catch “platform level” exceptions like access violations or divide by zero errors.
Those are thrown on Windows as SEH (Structured Exception Handling) exceptions; one could enable to catch them via the /EHa compile option:

• /EHs (or /EHsc): Standard C++ exception handling
• /EHa: Structured and standard C++ exception handling

But even Microsoft discourages that:

Specifying /EHa and trying to handle all exceptions by using catch(...) can be dangerous.

In most cases, asynchronous exceptions are unrecoverable and should be considered fatal. Catching them and proceeding can cause process corruption and lead to bugs that are hard to find and fix.

Even though Windows and Visual C++ support SEH, we strongly recommend that you use ISO-standard C++ exception handling (/EHsc or /EHs). It makes your code more portable and flexible. There may still be times you have to use SEH in legacy code or for particular kinds of programs. […]

Also, this may have an impact on performance and size (read on a few StackOverflow comments), but I guess the compiler optimization improves over time; so, that’s maybe not the important point here…

Windows OS identification preprocessor macro

After I’ve read up on this a bit, it seems that _WIN32 is preferred to WIN32 and should be used as the primary identifier:

#ifdef _WIN32
//...
#endif

… or alternatively:

#if defined(_WIN32)
//...
#endif

Unfortunately, the official statement on Microsoft’s Docs page on Predefined Macros reads a bit vague, I think:
(On the other hand: WIN32 is not even mentioned there, only _WIN32 is — that should tell you something…)

_WIN32 Defined as 1 when the compilation target is 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined.

Plus some (more or less convincing) arguments from other places:

• _WIN32 is automatically defined by the compiler and is reserved for the implementor (i.e. the C/C++ toolchain provider, in this case Microsoft), because it begins with an underscore, followed by an uppercase letter: You are not allowed to define reserved names in your own code, so there can be no clash.
• The symbol _WIN32 is defined by the (Microsoft!) compiler to indicate that this is a Windows compilation.
  Unfortunately, for historical reasons, it is defined both for 32-bit and 64-bit compilations.
• Windows 64-bit compilers define _WIN32 as well, so _WIN32 is always correct, whether it’s a 32-bit or 64-bit Windows platform.

Why not to rely on WIN32:

• WIN32 is defined by the SDK or the build environment, so it does not use the implementation reserved namespace.
  WIN32 is a name that you could even define in your own code and so might clash with Microsoft’s usage.
  WIN32 is a user-defined flag which may be required by some headers.
• “WIN32 as a preprocessor macro seems to be deprecated. Recent compilers seem to define only _WIN32 (not WIN32), particularly if used with modern C++ standards (C++11, C++14 etc.).”

Distinction between 32-bit and 64-bit

The symbol _WIN64 is defined by the compiler to indicate that this is a 64-bit Windows compilation (Microsoft’s Docs page on Predefined Macros):

_WIN64 Defined as 1 when the compilation target is 64-bit ARM or x64. Otherwise, undefined.

• To identify whether the compilation is for the Windows platform in general, test for _WIN32.
• To identify unambiguously whether the compilation is 64-bit Windows, test only for _WIN64.
• To identify unambiguously whether the compilation is 32-bit Windows, check both that_WIN32 is true and that _WIN64 is false.

Some sources:

• https://stackoverflow.com/questions/662084/whats-the-difference-between-the-win32-and-win32-defines-in-c
• https://accu.org/journals/overload/24/132/wilson_2223/
• https://groups.google.com/g/fltkcoredev/c/BwKvvtJ_Mog