The product is named Visual C++, that it happened to do C was always kind of a sideshow as far as I could tell. Aside from that, I seem to recall that VC++ had the WORD, DWORD, and eventually QWORD macros to specify unsigned 16, 32 and 64 bit types respectively.

And their names are so frustrating. We don't run 16 bit systems any more. Word is a word that means something and I don't care what a word was on the 8086. The only honest things the WORD macro could expand to are size_t and ssize_t. 64bit is not a quad word, it's just a word.

I find Microsoft method of naming every type with a pointer a major annoyance. This is one reason I find reading non-Windows C applications easier.

Give me `int*` vs `PINT`. Microsoft really likes to over engineer causing you have to pointlessly remember more.

The worst is when they redefine the same structure or union under a different name. Example: `IP_ADAPTER_ANYCAST_ADDRESS_XP` is the exact same as `IP_ADAPTER_MULTICAST_ADDRESS_XP`.

Prior to Visual C++ (the first version of which shipped for Windows 3.x), Microsoft sold a “Microsoft C/C++” as well as Microsoft QuickC:

- https://winworldpc.com/product/microsoft-c-c/5x

- https://winworldpc.com/product/quick-c/10-for-windows

And in 2012 they officially considered C++ the way to go.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

There was a change of heart a few years later, but the wind seems to have stopped after all the security discussions,

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

They considered C done, for Windows SDK purposes.

https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

A few years later they backtracked on it,

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

Until the SFI came into play,

https://www.microsoft.com/en-us/trust-center/security/secure...

I always just defined these types in a per-platform portability header myself.

Microsoft had [unsigned] __int{8,16,32,64}