WINRT versus WIN32 ?
The big question. Now with Windows 8 (now also Windows 10) and the new WINRT runtimes, should programmers opt for building WINRT applications or WIN32 applications ?
This is a fair question and I will discuss this from my own experience and viewpoint. This does not make my viewpoint necessarily the right one for you, but it is simply some observations that may be helpful to those who read this article.
UPDATE: Windows 100 has been in use for sometime now so this article is again being updated to reflect this. (date June 11, 2021) . Additional updated comments will be in Red text color.
Windows 8 for all practical purposes is now considered a failure. It really was not that bad IMO, but its failure seems to be attributed to users wanting the “original” Windows experience (aka. the desktop). I have been using Windows 10 for a good number of years now and I feel quite at home with it. Windows 10 is a solid operating system. So has it effected the WIN32 in any way ? As far as I can tell, the core WIN32 is still rock solid and well written 32 bit WIN32 apps should run without any serious issues. Windows 10 though does have a lot more lag time in it compared to older versions of Windows. It is not as responsive as it should be. Many may not notice this because they are using more current PC’s which help speed things up with solid state drives (SSDs), lots of memory (minimum of 4 GB is needed now and many laptops come with 8 GB). But this simply masks the problem. Windows 10 tends to be bloated in comparison to say Windows XP or Windows 7. As long as you have decent hardware you probably don’t notice this that much.
The WIN32 is more important than ever IMO. Why ? Because a well written WIN32 app will run circles around its dot.net counterpart. WIN32 apps will be more responsive and if a user is using a PC with lesser hardware, a WIN32 app should provide just as good an experience as it does on a better equipped PC. I think the WIN32 is still very viable for software development.
WINRT
WINRT has some exciting new features in it. The contracts feature (sharing data between apps) is a nice feature and could be very useful. The association between the apps and their tiles which can be dynamic is also very interesting. Now I have only experimented with some of the Metro (WINRT) apps which are currently available with the Release Preview version of Windows 8 (update, now also Windows 10). I haven’t been able to write any WINRT apps yet, since I don’t program using Visual Studio nor do I use any Microsoft languages right now. Initially, programmers will be locked into Microsoft languages to build WINRT apps. That is not a good thing since there are some excellent non-Microsoft programming languages.
So am I excited about WINRT apps yet ? Not really, since software is software. I don’t think WINRT offers that much more than what we had before (except maybe contracts, but that could have been implimented for WIN32 if they wanted to, but it wasn’t). My biggest concern about WINRT is that it is sandboxed. I understand everyone wants to be safer when they install new applications, but the sandbox concept has really grown around smart phones, rather than desktop computers, where consumers download apps like they do music files with little thought about the consequences.
A sandbox approach though tends to stifle power users and those who use computers in business or research environments. Having to use an app store to install apps is just limiting power users even more.
But the WINRT environment has that new, clean Metro look and feel to it. Isn’t that worth something ? Not really, since the WIN32 environment has long had the ability to be customized to what ever you want it to look like. The problem is that Microsoft set the standards of how applications should look and programmers simply followed this like lemmings. Anyone who designed an application which differed in its appearance from how Microsofts own applications looked, was viewed by many as “poor” design and not proper. But think about this for a moment. Windows 8 (and 10) is now throwing all of that away and applications will be forced to look flat and simple since Microsoft now views the old look and feel of Windows applications as obsolete. So why were WIN32 developers all those years writing apps to be just like Microsofts, when now even Microsoft doesn’t think it was all that good themselves ?
Once again, programmers are having a user interface concept forced upon them, when maybe they simply should write apps to what ever unique requirements their end users may have. Windows programming is losing creativity.
WIN32
Despite any benefits of WINRT, the WIN32 has one really, really big advantage. Backward compatibility ! Yes, you can write a WIN32 app which runs great on Windows 8 (and now 10), but also can run on all the other computers in your business (or school) which are running Windows XP, Vista or Windows 7. Now that is one big advantage !
But some may feel that the WIN32 is not rich enough an environment for developing apps which will look good on Windows 8 (and 10). Not so. The problem with WIN32 development is that programmers tend to stick with what ever is the current development system and so all the apps written using that system tend to look similiar. Because of sticking with built in components (controls) of the development system. For example, Microsoft uses the ribbon in their apps, so everyone wants to use a ribbon control in theirs. What some WIN32 programmers may not realize is that the WIN32 provides a number of mechanisms for customization, which may not often be taken advantage of. Now I don’t mean, simply more components. I mean real customization. For example the WIN32 has two well documented forms of customization for system controls, OwnerDraw and CustomDraw. Everything from menus, buttons, toolbars, listview or treeview controls can be customized. Even the common dialogs can be customized via hook procedures. Now experienced WIN32 programmers can even write their own custom window classes and build totally new controls with totally new features. You can even build upon existing control classes using what is called superclassing. Use an existing control class and create a new one from it and build upon it. Even the shape of a window is not limited. You can change the shape of a window to almost anything you want using regions.
The interesting thing about all of this, is that such features have been in Windows since Windows 95/98. Yes, one can customize applications and they will look just the same on Windows 95 to Windows 8 (and 10) (referring to desktop apps). I believe the ability to be able to write software which can run on so many different platforms is an amazing advantage.
Now another nice trick in Windows is the ability to poll operating system DLL’s to see if certain features are available. Windows, since Windows 95, has had the ability to load dynamic libraries and to poll them to see if an API exists and then to call such API’s dynamically via a code pointer. It is not that difficult to do. This allows an application to be dynamic. For example, if the application wants to take advantage of a feature in Windows 7/8, which may not exist on Windows XP, you can access such features dynamically and if the app is run on a later OS, make the features available to the end user and if not offer an alternative or simply tell the user the feature is not available. This ability to be dynamic is probably one of the most powerful features in Windows and it has been there since Windows 95.
Now some may feel that vital features like touch is only fully available in Windows 8 (and now 10), but even that is not true. Windows 7 has basically the same touch features as does Windows 8, it is just that some software was not written to take full advantage of it. The two key touch window messages, WM_TOUCH and WM_GESTURE exist in both Windows 7 and 8 (and 10).
An experienced WIN32 programmer can write software which can emulate the Windows 8 look and feel, even on older versions of Windows.
One other advantage of WIN32 is that you won’t have to use the Microsoft App store to install applications. Now an app store and a sandboxed environment may be good for consumers, who are used to downloading apps on smart phones, but it brings more limitations for software developed for businesses or institutions.
The WIN32 API’s are still alive and well !
My biggest concern about Windows 8 (and 10), was whether the WIN32 API’s were still pretty much intact. I wrote a test application which tests a number of features I use in my GUI engine, from ownerdraw, custom controls, customdraw, complex regions, MDI, MCI and even complex graphics such as low level DIB’s and OpenGL and guess what ? It all worked great. The WIN32 API’s are alive and well on Windows 8. Now I don’t know what the future holds for the next version of Windows after Windows 8 (I do now), but seeing how long Windows XP has stuck around, I expect support for the WIN32’s should be here for some time in the future. Even if Windows 9 (next version) (NOTE: Windows 10 skipped their being a version 9) attempts to remove the desktop, many businesses will likely be using Windows 7 or 8 for many years to come.
A well chosen path.
When I was developing even the early versions of my development tool, EZGUI, I recognized the value in taking advantage of customization. EZGUI uses the dynamic approach I mention above, having the ability to check the operating system to see if features are available and if not providing an alternative or simply just turn off the feature in the GUI engine. EZGUI also uses ownerdraw extensively to allow all sorts of ways to customize an application. The EZGUI runtime, even though it does access some API’s only found on Windows XP or later, can still run even on Windows 95/98/ME and NT/2000. It can sense what OS it is running on and act accordingly.
EZGUI also is very graphic in nature, going beyond many of the basics found in the WIN32. For example the Canvas control with its 2D sprite engine, alphablending and anti-aliasing, will run on any version of Windows (95 to 8). I also made a good choicing in using OpenGL, rather than DirectX , for the glCanvas control with its 3D scripting language. I have actually run the OpenGL control in EZGUI on an ancient Windows 95 PC to a newer computer running Windows 8 (and now 10). OpenGL is well supported by most developers of GPU’s and Graphic cards and even though OpenGL 3.0 and 4.0 deprecates a number of API’s, these manufacturers have seen the value in backward compatibility, so code which depends upon OpenGL 1.0 to 2.0 is quite universally supported.
By leveraging the WIN32 API’s EZGUI allows one to add powerful features, but have the largest range of PC’s which can run the software. For me, it was a good choice and a well chosen path. I can’t see what the future holds, but I find it hard to imagine Microsoft will drop the desktop in the version of Windows after Windows 8. Maybe they will risk it in Windows 10 (turns out they didn’t), but that is another story. Right now I am working on even adding touch support to the current version of EZGUI because I see where computers are going (tablets), but that is not overly difficult using the WIN32 API’s.
UPDATE (10/04/2018):
This article needed to be updated now that I have used Windows 10 for some years now and Windows 8 is old history. So what have I learned from Windows 10 ?
WIN32 is not only still alive, but still running strong!
I would have to believe that the WIN32 is the core of the Windows operating system still and that all the new features in dot.net and the WINRT are simply built on top of it. Now with a little digging using the Depends utility, one can see that Microsoft has moved a lot of functionality of the WIN32 into other more granular operating system DLL’s which do the same thing, but the original WIN32 API’s which may have been moved to such DLL’s are likely wrapped in the original DLLs, so one could conceivably call them from either the original OS DLL’s or the newer OS DLL’s deeper into the system. No matter, the Win32 still works as well on Windows 10 as it did on previous versions of Windows.
The WIN32 is more important that ever !
Why ? Because WIN32 is the lower part of Windows, rather than being a framework built on top of it. One could call the WIN32 the Assembly Language of Windows. If you want performance, then the WIN32 is the way to go. There are a number of areas where this could be a significant benefit. One is IOT (Internet of Things). IOT devices (based on x86 CPU’s) running even a minimal version of Windows 10 could be designed using minimal hardware, since the WIN32 is quite lean and fast. If Microsoft were to drop the WINRT, Dot.Net and any other heavy framework from Windows 10 for IOT, but simply support a core subset of the WIN32 API, one could build very fast and powerful GUI apps to run on an IOT device. If you want performance then it is time to sip scripting languages in favor of fast compilers for native code. IOT does not need the same protections as consumer based devices (aka. sandbox).
Another market is the so called “Maker” market. The Raspberry PI has ruled the maker market, but I do not see any reason why an x86 Windows 10 based tiny maker computer could not be created. By concentrating on the WIN32 instead and using native compilers, one could easily produce a maker device which is low cost (less than $50) which could be used for all sorts of things. But you may say, “WIN32 coding is too difficult and would not be well suited to a maker device”. While concentrating on the WIN32 is what I suggest, this does not mean that better higher level tools can not be created for running on a WIN32 system. The problem with WINRT and Dot.net is the mistake of thinking that object oriented programming is the solution to all problems. The core WIN32 is procedural in nature, not object oriented. OOP has slowed down PC’s and adds too much extra overhead. It is interesting to note, that when early higher level GUI frameworks were conceived for Windows, even Microsoft took the OOP route and never considered (as far as I can tell) the possibility of a GUI framework which is procedural in nature like the WIN32. MFC (Microsoft Foundation classes) an early framework was OOP based. Borland’s OWL was also. Now if someone actually tried to write a higher level procedural based GUI framework then we could compare the two. Well, I actually have done this. My EZGUI framework has been around a good 20 years now and is in its fifth generation and it runs on all versions of Windows from Windows XP to Windows 10 (and can even run on earlier versions such as ME, 98). It has now become almost a programming language in of itself with nearly 1000 commands and it comes with a number of custom controls built in, such as a Canvas control with 2D sprite engine, 3D Canvas with openGL scripting language and more. It supports low level features such as ownerdraw, customdraw, superclassing and more. It does threading, multi-monitor support, non-rectangular windows using complex regions and more. What is most amazing about all of this is that the entire framework is only about 1 megabyte in size. Yes, it all could fit on an old fashioned floppy disk. When I tried to explain to a friend who had years ago worked in the software industry about my GUI framework and then told him it was only 1 megabyte in size, his first gut reaction was that “it was impossible”. It seemed impossible I could cram so much into such a small library (DLLs). But the reason I could do this, had nothing to do with anything special about my coding style, but had more to do with the switch from OOP to procedural coding. By using a procedural coding style found in the WIN32, the results were astounding. Not only could I cram in a lot of features, but the ultimate size of the entire framework was an unheard of 1 megabyte. WIN32 coding can be used even with a higher framework on top, if the framework is procedural in nature. To top it off I wrote it all in BASIC rather than C++. Yes, using the Powerbasic 32 bit native Windows compiler produced executables which were as small and fast as if I wrote it in pure C.
WIN32 has also proven to be very reliable. I have one customer who wrote an app using Powerbasic and my GUI framework (EZGUI) and has let it run constantly on a test PC for over 4 years without rebooting the PC. How many WINRT or Dot.net apps can you find that would run on a PC for 4 years straight.
If you want performance, a small footprint and software which can run on the smallest and most minimal of x86 hardware using Windows, then the WIN32 is the way to go. If you can’t handle coding directly the WIN32, then there is always Powerbasic and my EZGUI 5.0 Professional GUI framework.
Would you like to see this in action ? Download my Windows 8 (and 10) test app written using my EZGUI framework and Powerbasic. The framework itself only calls the core WIN32 API OS DLL’s. No WINRT ! No Dot.Net ! No MFC ! No ATL! No C runtimes! Just the core WIN32 API. The test apps demonstrates things like ownerdraw, customdraw, custom controls, 2D sprite engine, 3D OpenGL, non-rectangular Forms (using regions) and more.
Download: Windows 8 (and 10) test app
Windows 10 keeps improving over time and Microsoft is giving developers more choices for creating user interfaces, but if a programmer learns how to tap into the raw power of the WIN32 API (particularly things like ownerdraw, customerdraw and custom controls) then one can build unique applications with amazing user interfaces. There are no limits ! To better appreciate this download the sample app below which I designed for an Intel contest on Code Project: