2016 article.

Yes, they will. My crystal ball shows that future. My bold prediction is the earliest by 2025 and latest by 2030.
Year 2020 is the key milestone when legacy BIOS is officially dead. With new hardware requiring and mandating UEFI and 32-bit UEFI has never been a focus for x86, booting 32-bit x86 OS is going to be difficult, so it paths the way to naturally get rid of Win32. That's a death sentence to all the Microsoft OS'es predate Windows 8.

In fact, there are several possibilities that Intel may also remove x86 real-mode and have the CPUs start in x86_64 directly with flat selectors. Legacy BIOS has always been the major road block to realize such vision. When legacy BIOS is dead, then it makes sense for such a plan to materialize.

The article apparently was written in a time when UWP/Metro Apps were seen as the future of Windows.
In the meantime, MS went another route and now allows more Win32 development again. They state the separation of Win32 and UWP was "a mistake".
https://www.thurrott.com/dev/206351/microsoft … of-windows-apps

Personally, I wonder what Windows will be worth for without its broad compatibility.
Once Win32 is truely gone (no WoW for 32-Bit x86 apps anymore), there's perhaps little reason to stick to Windows.
I mean, even now people spend work and thoughts on porting Wine and NTVDM to Windows because 16-Bit support on Win x64 isn't available. 😉

Microsoft may remove Win32, "when they're ready".
As in: when 99% of their userbase won't notice it.
Same with NTVDM, there's still 32-bit versions of Windows, and they still support it. Most people have been using x64 Windows for years though, and never missed it.

We're nowhere near the point that Win32 will not be missed, ergo we're nowhere near the point where it gets removed.
If it ever will. Because at least part of the market (eg high-end gaming and other types of high-end applications) doesn't appear to be moving away from C++/Win32.

^I don't disagree, but I'm afraid the 32-Bit releases of Windows will be near of their end.
Once the BIOS (or rather, CSM) is gone, as planned, the 32-Bit releases of Windows can't boot anymore.

Unless, of course, Microsoft give them the ability to use UEFI.
32-Bit versions of UEFI were available for years, but except for a few *nix distros, no OS had support for them (only for 64-Bit UEFI).
In pratice, these 32-Bit UEFIs were reduced to fancy BIOSes with a mouse driven GUI.

Win32 is not 32-bit versions of Windows, it's the Windows API that was introduced for the 32-bit version (as opposed to the Win16 API).
Even for 64-bit applications you still use the Win32 API.

Aside from that, I would think that 32-bit versions of Windows should and will die out soon, but the 64-bit versions should and will support 32-bit applications for a long time to come.

If Microsoft release a version of Windows that won't run 32 bit software, then it won't be at all popular with gamers, as many of the best PC games were and are 32 bit, and quite a lot of gamers wouldn't want to learn how to set up a virtual machine just to run the same games that already work fine on the older version of Windows.

Kerr Avon wrote:

If Microsoft release a version of Windows that won't run 32 bit software, then it won't be at all popular
with gamers, as many of the best PC games were and are 32 bit, and quite a lot of gamers wouldn't want to learn how to
set up a virtual machine just to run the same games that already work fine on the older version of Windows.

Well, there are at least two basic kind of video/computer game players, I'd say (or let's say there are two kinds of stereotypes):
a) Computer/video game players who just play games they like, not caring so much for the platform or age of games.
b) PC Master Race "Gamers" who are into the newest tech and are never satisfied with current gen (higher, faster, farther). 😉
Unlike the first, more casual kind of gamer, the second group usually aims for highest resolution and best visual effects.
It also constantly invests money into upgrading PC hardware, uses online platforms (Steam etc) to aquire games and items,
rather than relying on physical media and is not so bound to/interested in a specifc OS rather than the underlaying game engine.

Ok, that's perhaps not the whole story. There are also console fans, handheld fans, retro gamers, arcade addicts, flipper fans, etc. 😀
What I mean to say: These socalled "Gamers" (type b) perhaps don't rely on Win32 or old APIs so much as somone should think.
They love to be on the cutting edge of technology and are satisfied with recurring "HD remakes", "anniversary special editions" etc. of the titles they love to play.
Also, popular franchises are using all the same popular game engines which are constantly beeing updated and ported over the years.
It's very likely that these use or require 64-Bit editions of Windows since several years already.

That beeing said, there are of course also folks like us, which spend a lot of work and time into resurrecting old hardware,
or just love to play old classics on modern hardware/operating systems by using patches, workarounds or the wonders of emulation.
But by comparison, we're rather a niche, I suppose. Not that this would be a bad thing, though. 😀

You can't rely on people to care since the majority do not. When they see an advertisement for something or a friend who is in debt shows off their fancy gadget then they NEED to buy it and play it NOW so they can be happy. Best you can hope for is that there is a vocal minority that will complain to give enough bad press where a company will re-evaluate and if not that there is a fanbase that will maintain support in some fashion. For Windows there are too many 32bit programs out there for MS to pull an Apple or Canonical any time soon and all the hard work was done years ago, they just have to maintain which MS seems willing to do while no one else cares.

16 bit is the future

For a while, browsers still ran in Win32, though I would imagine that's mostly changed (dunno, I'm pretty much Mac / Linux / mobile these days for web stuff). A great deal of everyday general consumer software is moving more and more towards the cloud, and it matters much less which platform you use as the client. Gamers will move wherever the games go, which is dependent on the underlying engines only, really, and those are already set to be multi-platform.

It's the niche stuff and the enterprise management that still keeps Windows relevant. With BYOD, the AD stranglehold is starting to show signs of uncertainty, but there's still a lot of non-consumer software infrastructure that resides on Win32. Professional audio software still depends heavily on VST-32 (although the majority of studios seem to use Mac), and I'm sure that scenario is similar in other industries as well. It would be disruptive to a lot of business if Win32 were to go away, and those are the applications that don't get replaced on a whim, so it will likely take a while for attrition.

I'd like to reiterate the point that 'Win32' does not mean 32-bit.
See MSDN: https://docs.microsoft.com/en-us/windows/win3 … indows-api-list

Using the Windows API, you can develop applications that run successfully on all versions of Windows while taking advantage of the features and capabilities unique to each version. (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)

So what we call 'the Win32 API' is actually also supported in 64-bit applications. MIcrosoft has recently started referring to it as the 'Windows API'.
It is basically the standard native C interface to the OS, as opposed to a .NET/UWP environment or other subsystem.

The Tim Sweeney article is about moving from native applications to .NET/UWP/Store-based applications. This was something that many developers feared when Windows 8 first introduced the Store and the new environments.
Ultimately, Microsoft's goal with UWP was to unify the desktop and mobile markets, so that a single application could run on phones, tablets, regular PCs, IoTs, embedded systems and whatever else.
However, Microsoft has since ended development on Windows 10 Mobile, so there is less reason to move to UWP in the first place. But Microsoft never claimed they would abandon Win32 altogether. They just figured that for many apps, it would make more sense to write them as UWP (which is exactly what people are doing on Android... they are using a Java-derived platform-independent language, very similar to the .NET/UWP environment, even though Android has linux underpinnings, and it is possible to compile native code for your target CPU).

Since Win32 is also supported for 64-bit applications, you can simply recompile your C/C++ code (or Delphi, or what other language interfaces directly with the Win32 API).
Only problem is with some legacy functions whose prototypes have been updated slightly to make them 64-bit compatible, and obviously the standard 64-bit compatibility issues.

Mind you, even Windows Mobile supports a subset of the Win32 API.
Back in the day, I had a Windows Phone, and ported my Direct3D 11 engine to it. The engine was written entirely in C++, and used a combination of D3D11 and the Win32 API.
Porting it was just a few days work. I wrote a blog about it:
https://scalibq.wordpress.com/2013/04/23/just … eping-it-metro/

UWP is dead (being deprecated iirc)... long live .NET Core!

oeuvre wrote:

16 bit is the future

640k aught to be enough for anyone.

Scali wrote:

So what we call 'the Win32 API' is actually also supported in 64-bit applications. MIcrosoft has recently started referring to it as the 'Windows API'.

Well that's not at all confusing (</sarcasm>), as MS seems to issue a new new way to write Windows applications about every 5-10 years, so "The Windows API" is about as specific as a term like "RAM". sigh..

I used to dabble in VB from 3.0 to just after the transition to .NET, and then finally (way too late) got sick of how utterly terrible VB is as a language, and how it never really could access a significant portion of the native Windows API without all kinds of workarounds. I moved to Linux to learn C, and have recently wondered what it would take to get back into being able to write Win GUI applications, but with the mess of APIs I wasn't even really sure what you can do in C anymore, or if you have to buy into "managed code" (and thus learn a completely separate, essentially single-platform language for the privilege), or if these days MS' idea of the way forward is really HTML 5 and XML.

C obviously still exists since it's still in VS, but I find myself almost back at the bottom of the learning curve, since Windows can't even seem to handle something as basic as strings the normal way, with a legacy of UTF-16 making it difficult to just straight port over some of my POSIX-style code.

I could very possibly be mistaken or out-of-date about a lot of what I know about the Win API these days. It's extremely confusing looking in from the outside, and I haven't had enough motivation to wade through the muck yet. I actually considered going back to Win 3.x to learn the C API, then moving forward through the progression of versions to cover what I missed along the way, but that presents its own challenge of finding instructional resources for a specific point in time. It's all out there -- and that's the problem. I never quite know what's current, what's old, what's old but still relevant...

Well, VB Classic vs VB .net is a bit like being a bus driver vs a fighter jet pilot. 😉
Claiming that a VB.Net/C++ programmer is making better programs per se is misleading.
Sometimes the "best" programs have horrible code underneath, but a good worklow and easy interface.
That's because, say, some botanist who knows old VB might be a lousy programmer but is very proficient in his field, who has a feel for the needs of others, too.
His fellow botanists likely prefer his quick&dirty program much more than a professionally made alternative (by a random hired VB.Net/C++ programmer).

SirNickity wrote:

I used to dabble in VB from 3.0 to just after the transition to .NET, and then finally (way too late) got sick of how utterly terrible VB is as a language, and how it never really could access a significant portion of the native Windows API without all kinds of workarounds.

???

Classic VB has a well-documented and consistent way of making calls into non-ActiveX DLLs.

Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long

In fact, it's not too far removed from what you'd do in C# to make calls into native/unmanaged code

[DllImport("user32.dll", EntryPoint="FindWindow", SetLastError = true)]
static extern IntPtr FindWindowByCaption(IntPtr ZeroOnly, string lpWindowName);

SirNickity wrote:

I moved to Linux to learn C, and have recently wondered what it would take to get back into being able to write Win GUI applications, but with the mess of APIs I wasn't even really sure what you can do in C anymore, or if you have to buy into "managed code" (and thus learn a completely separate, essentially single-platform language for the privilege), or if these days MS' idea of the way forward is really HTML 5 and XML.

I think there are some gaps in your knowledge, it's not really a "mess" of APIs any more than the array of libc variants, desktop environments, and widget toolkits available to you on Linuxes.

"Managed code" refers to code that executes on the CLR (whether's that's the actual .NET runtime, or Mono), and isn't as much about the programming language used or the APIs, but the fact that application's runtime environment is literally managed by the runtime (e.g. memory allocation and garbage collection).

SirNickity wrote:

C obviously still exists since it's still in VS, but I find myself almost back at the bottom of the learning curve, since Windows can't even seem to handle something as basic as strings the normal way, with a legacy of UTF-16 making it difficult to just straight port over some of my POSIX-style code.

Technically the C language doesn't have a string datatype.
It is convention to use a zero-terminated ASCII byte-array as a string.
Which is obviously supported just fine by Visual Studio, since you get a POSIX-compliant libc.

Obviously, most computer systems (including linux) support way more than just ASCII these days, for all the foreign languages and extended character sets they support.
So you have various ways to store these strings with extended (unicode) characters, such as UTF-8 or UTF-16.

Obviously most programming environments (including Windows) come with simple conversion functions between the various string types.

You *can* still write a Windows program entirely in ASCII. The Windows SDK is set up in a way that all string-handling functions have two versions, an ASCII version and a UTF-16 version.
For example, if you look at the MessageBox API, there are actually a MessageBoxA and MessageBoxW.
Depending on how you set up your project environment (ASCII/Multibyte or UTF-16/Unicode), it will either #define MessageBox MessageBoxA (ASCII) or MessageBoxW (UTF-16).

Obviously it is not recommended to still write ASCII code.
Windows does you one better by offering the TCHAR datatype.
TCHAR is the 'native' character type depending on your project environment, so either ASCII bytes or UTF-16 words.
The tchar.h header file then offers you all the relevant conversion macros:
T2A, T2W, A2T, W2T, A2W and W2A.
If you are in ASCII mode, then T2A and A2T will result in no-operation. And in UTF-16 mode, likewise, T2W and W2T will be no-operation.
All the standard libc functions, such as strcat, strcmp, strlen, sscanf, sprintf etc also come in a 'T' variation.

This way you can write code that can compile in either ASCII or UTF-16 without changing a single line of code, just changing the compiler switch.
This is the recommended way of writing string code in Windows.

See here for more info:
https://docs.microsoft.com/en-us/cpp/text/gen … -h?view=vs-2019

UTF-16 is a messy kludge. Most of these APIs were originally designed in the 1990s when UTF-16 didn't exist. Shoehorning UTF-16 into routines designed for UCS-2 causes endless headaches.