A better Windows experience for Maker devices and IOT

Cross platform seems to be the goal of most mobile software design today, but cross platform loses many of the benefits of a truly native experience. For those who require a truly cross platform experience many of todays solutions may suffice. But for those who are looking for a better Windows experience on low cost devices (aka. IOT or maker devices) or devices with minimum hardware, then learning how to tap into the WIN32 API is the key.

Microsoft and Intel could learn a lesson or two from the past

I really like the idea of the Raspberry PI. All sorts of things can be accomplished in the “maker world” using the PI. But why isn’t there a viable x86 version of the PI today. Does ARM really have all the advantages ? There is no reason that Intel couldn’t produce a PI like device at a low cost of less than $50 (or even less) other than the obvious one. There is something innately wrong with how Windows software is written today. Yes the problem lies with Windows itself and how Windows software is written. This is not a criticism of Windows. Windows is a great operating system. This is simply an observation from a long time WIN32 developer.

It seems that with each new version of Windows the minimum requirements for Windows to run reasonably well increased significantly. I remember Windows 95 running on systems with just a 33 MHz (that is megahertz, not gigahertz) CPU and only 8 meg RAM (that is megabytes, not gigabytes). True, displays have increased in resolution and colors over time, but many of the overall tasks in Windows have not changed much. But think about it, a low end Atom CPU running at 1.4 GHZ (or 1,400 MHz) is probably 50 times faster (take into account changes in cache as well as speed), or more , than its 1995 33 MHz counterpart.  The typical ram on a low end Windows device (2 GB) is 256 times greater than its 1995 counterpart of 8 meg.

So what has changed in Windows other than significant improvements in the hardware ? It is how software is written. I won’t go into detail about the pros and cons of such development styles, but let’s consider an overview.

  • Object Oriented Programming (aka. OOP)

OOP has changed how software is written significantly. Older versions of Windows were primarily procedural in nature. OOP came into style with later versions of Windows with things like MFC (Microsoft Foundation Classes) and ATL and then later with the adoption of Dot.net, becoming the de facto standard. Watch Herb Sutter’s talk about “Why C++ ?” and see his honest observations about the “Long Horn” era.

“Why C++ ?”  :  https://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

Do a google search for things like:

“What’s wrong with OOP”

“Is object oriented programming necessary”

etc.

This does not mean that OOP is all bad or even wrong. The point is that when performance is critical and low hardware resources sets limits, then something has to go and be replaced with something better suited to the situation. Low level development which is procedural (like core WIN32) and native (WIN32) produces the fastest running software possible. If cross platform is the goal, then fine use whatever fits that need. But minimum hardware Maker and IOT devices require a unique solution and that means performance.

Windows is already up to the challenge, but it is how we develop for it which matters. If a lighter weight Windows with little or no OOP in it (drop the dot.net and the scripting languages) were produced and more leaner development tools along with leaner WIN32 frameworks were used, one would be shocked at how much could be accomplished with a very minimum hardware device. In short order, Maker and IOT devices with surprisingly minimum hardware (try 1 ghz CPU or less, 1 gig ram or less and an 8 gig or less EMMC or SD card) could be massed produced for probably less than $50 or even as low as $25 (retail). Imagine the Maker world flooded with $25 x86 based maker boards ? For IOT, the minimum requirements could be dropped to even half, or one quarter, of what I suggest for maker boards and x86 based IOT boards could be made available for possibly as little as $10 and actually run Windows (lite). This is not a pipe dream, but could easily become a reality. Don’t believe it ?

If I were not a long time WIN32 programmer with experience, then you might be right, but I have experience behind me as proof this is possible. I know what the WIN32 is capable of and this is not just theory.  (I will explain more later in this article about this)

  • Software Bloat versus the benefits of native code

Be honest when considering this next thought. As a programmer, what is your typical development PC equipped with ? How fast is your development environment ?

Now you may likely say, my development tools run extremely fast. But I would venture to say that your development PC is likely running a Core I7, has 1 TB disk drive (or a 256 GB SSD) or more and at least 16 GB of RAM. Am I close ?

Could you develop software, and quickly, on a low end PC with just a cheap Atom CPU in it (say 1.4 ghz), 2 GB ram and a 250 GB hard drive ? WIN32 programmers, like myself, could do so probably on even half that or less. My entire (not counting Windows documentation of course) development system is only about 20 megabytes in size and it can run well on something as little as 500 MHz CPU , 500 meg disk space (beyond what Windows requires) and 1 GB ram (or less).

Simply put, end user software is bloated today and development tools are even worse.

  • OOP GUI Frameworks not necessary, try procedural for a change

Now this may seem the strangest point yet in this article, but there is a reason for this. Procedural programming styles produce leaner and faster software compared to their OOP based counterpart. The problem here is that early on in Windows history (Windows 98) somebody got the idea that OOP was the only way to go and few, if anyone, tried to build procedural based frameworks. True, writing purely native WIN32 code is just too complex and slow and surely no one would want to go back to that. But why were the early approaches to better GUI frameworks OOP based ? Windows was procedural in nature, so why not develop procedural style frameworks ? Sadly, few if any tried. In learning the WIN32, I had to go back to books about Windows 95 because by time Windows 98 came along, things like MFC and ATL took over and most Windows programming books concentrated on OOP based code rather than procedural.

If I could do it, surely Microsoft could do it better

Do you like a programming challenge ? Code Project often has challenges for programmers and it is amazing what some of the many talented programmers can do. So this WIN32 programmer asks the question, “if I can do it, why can’t Microsoft do it and obviously do it better” ? So here are the specs for this programming challenge (anyone is free to try it):

Write a GUI framework using just the WIN32 (no dot.net, no Java, just pure WIN32 using a native code compiler, like C, Pascal or Powerbasic). The minimum size for a start would be 2 megabytes for the entire framework (doesn’t have to do everything, just the important stuff to start with). The framework must be procedural in nature and absolutely no OOP. So what should it be able to do ?

  • Basic Print Engine (for printers)
  • Basic 2D Graphics Engine
  • Basic Thread Engine for non-GUI work
  • Basic Event Engine (convert Windows messaging into easy to use events)
  • Basic UI Engine (Forms, most system controls, menus, etc.)
  • Basic Common Dialog Engine

Can you do it ? It doesn’t have to be complex, since it would be for a Windows Lite just for Maker devices and IOT. How about you Code Project readers ? Have you built one or could you ? The current Windows for IOT can’t even do GUI stuff yet, so for Microsoft the challenge is something worth working on (Windows itself would need some thinning down). Do you need some motivation ? Remember how I started this paragraph  with the thought “If I could do it, surely Microsoft can do it better”. So let’s provide a reference for programmers to compare their results. I know many of you could do better than I, but I am simply providing this (my GUI framework) as a reference :

How about a GUI framework which contains all of the above, plus:

  • 2D Sprite engine
  • 3D OpenGL based scripting language
  • Low level DIB drawing engine
  • Custom controls (ie. Files and Property Listbox, Canvas, MCl, Splitterbar, 3D)
  • Theme drawing support
  • Multi-Monitor support
  • Ownerdraw and Customdraw engines
  • Subclassing and Superclassing engines
  • Autoresize engine (resize controls when form resizes)
  • Bitmap Image Filters
  • Hot Mouse Tracking
  • Private Timers
  • Multiple Document Interface (MDI)
  • Game Loop engine and precision timing
  • HTML help display and standard Help file display
  • Layers Engine for controls (kind of like Graphic layers in design)
  • Vector Graphics (Turtle Graphics)
  • Visual Designer engine for building programming Visual Designers
  • GUI framework of over 1000 GUI commands, plus 3 script engines

So I probably broke the 2 megabyte limit in the original challenge with all the extra stuff, right ?

No, actually the entire GUI framework comes in at about just 1 megabyte and can fit on an old fashion floppy disk.

You might say, “it probably looks like old Windows 95 apps”. No, the WIN32 allows one to tap into many of the best features in Windows such as transparency and to customize how many system controls look using things like Themes, ownerdraw and customdraw. Here are some videos from my youtube channel which shows how the UI can have many modern features in them:

A demo app for a Code Project contest

2D Sprite animation

2D and 3D animation

Download a simple demo app which shows many of the Windows features a small UI framework can handle and see it run in real time:  Demo App    (zip file less than 4 meg)

You can download the primary part of the source code for the Demo App here: Source

Note: Windows Messages are converted to Events by the framework and all Events are sent to a single procedure called EZ_Events (then forwarded to child routines). The overall code (subroutine layout and declarations) was generated using a Visual Designer made specifically for the framework.

My UI framework is nothing special and likely many an experienced WIN32 programmer could do more than what I have, but the point is that it is possible to build procedural based GUI frameworks which are tiny in comparison to todays OOP based frameworks. Such WIN32 frameworks can also run on minimal hardware. Try your hand with the Demo app above and download it and run it on the least PC you can find. Try it on Windows 8, 7, Vista, XP or even Windows ME or 98. Find the lowest PC that it will run on and post the specs in the comments below.