IOT and Windows – What is Needed, A Lesson from the Past

The exciting Internet of Things is the next frontier for programmers. Most interesting is the possibility of Windows running such devices. But what is needed to make this possible? Is a shift in mindset needed to make this possible?

A Lesson from the Past

Programmers who got their start back in the 1970s and 80s remember what it was like to write software for computers with very little raw power. It amazes me how the current mini-devices like the Raspberry PI and in the Windows world, the existing x86 mini-PC devices seem so underpowered and it is a wonder why they don’t perform better. In considering this, an old time programmer may come to a number of conclusions.

In the old days, the key to performance in computers was the software and even the operating systems (past home some computers didn’t have a full operating system in the same way they do today, but simply supported basic input and output via direct hardware access). Let’s consider one example that demonstrates how powerful even limited hardware can be with the right software.

How any computer device today with a CPU (or SOC , System on a Chip) running at 1 gigahertz or better can have a problem with performance boggles the mind. Consider a home computer from the past, the Commodore 64 (C64). The C64 was a powerful little computer back in the day. Its CPU ran a blistering 1 megahertz (that is megahertz, not gigahertz). Ok, I am using some humor here. By today's standard, one would not refer to 1 megahertz as blistering (fast). Yet back in the old days, some programmers felt that such a computer was capable of much more than most would think. C64 users likely remember how slow interprted BASIC was on those machines. It was “turtle slow” be correct. But programmers back then found that when they learned how to write software using a real native code compiler or even by using machine language, they could make that turtle slow computer do some amazing things. Personally, I started using the Abacus BASIC 64 compiler which was a huge improvement. One could actually write software with some decent performance. Using that compiler, I then wrote my own mini-compiler with a limited command set so I could write code which would perform closer to assembly language speeds. My mini-BASIC compiler generated machine code directly (no assembler in the middle). I quickly found out that how you write software makes a big difference. Using my mini-compiler, I wrote a family friendly video game and sold it to Compute Gazette magazine, earning myself $1500 for just a few weeks work, which was not bad for a self taught hobby programmer back in the late 1980s.

Some amazing programmers, likely using assembler to code, built an amazing operating system for the Commodore 64, called Geos. Geos turned the Commodore 64 into a Macintosh (Apple) like computer (which cost 4 times as much and has 8 times the speed as the C64). Berkeley Softworks, which created Geos pushed the limits of the C64 far beyond what even its manufacturer (Commodore) ever considered. All of this on a computer with a 1 megahertz CPU, 64 kilobytes of ram and an external disk drive with only 170 kilobytes of disk space.

The lesson learned? Software written using native code compilers and which are closer to the hardware can perform at amazing speeds. How you write software makes a difference.

The Windows World

In the early years of 32 bit Windows (Windows 95), a typical PC likely was only using a CPU which ran at 100 megahertz or better, likely with less than 24 megabytes of ram. Compared to todays PC’s (ie. 1.5 ghz CPU, 2 gig ram) this would be nothing. Most current software for Windows likely could not run on hardware with so little power. Now consider some of the mini-PC, hobby prototyping devices which are now coming out which are x86 based. In the ARM world, the Raspberry PI has been a big successful among hobbyists. In the x86 world, devices like the Intel Galileo, MinnowBoard and SharksCove are being offered, but at prices still a bit too high for the typical hobbyist. While I do think they need to get the prices down for such devices to the $50 range and add in the free version of Windows 8.1 now being offered OEMs building tablets to make a complete package, the real challenge will be writing software for these devices which push them to their limits.

As a programmer, I have been looking at such devices with excitement, but two barriers still exist which I feel need to be addressed. First, is as mentioned, price. To be comparable to the Raspberry PI and to be affordable so they can be the basis of the coming “Internet of Things” devices, the price needs to come way down, even if it means less raw power (CPU, memory, etc.) in the hardware. Manufacturers of such devices are still thinking with the Windows PC mindset so the hardware specs are probably too high, which may explain the higher costs than ARM devices. With the next generation of small Windows tablets (7 inch) coming out selling at $100, surely a prototyping, hobby mini computer device could be built for much less. Second, Windows needs to be sheared down a bit to make it more practical for smaller devices, yet with full user interface features. Now some may think that will be difficult. The typical Windows PC is so over powered today, yet most don’t realize it. Why ? Because of how software is written today. So how could Windows be pared down to make it more friendly to the coming Internet of Things ?

Get rid of all managed language engines in the operating system. Get rid of .NET. Get rid of WINRT. Leave just the core WIN32 API. This would decrease the overhead needed hardware wise. This would make Windows better suited to use on “tiny, tiny” devices. Target smaller screen sizes with resolutions as low as 1024 x 600 (even if you have to fake it like the Toshiba mini tablet does, making Windows think the display is larger than it is). The Windows API is a very, very lean and fast API. The core API likely requires a lot less memory and CPU speed than does the full blown operating system today.

Now at first glance, one might think this would seriously limit Windows development, but I would be more inclined to think that like the Commodore 64 and Geos, developers would learn how to tap into the raw power of Windows and they would find ways to push the limits of even minimal hardware. If Microsoft wants to put Windows everywhere (meaning devices in all areas of life), then the mindset towards Windows needs to be changed.

Not Possible, Some Would Say

Some might say, nice ideas but it simply is not possible , nor practical. I would beg to differ though and I have good reason. Unlike most Windows developers today, using managed languages via Visual Studio, for the last 15 years my company has been primarily using simple native code compilers and the raw WIN32 API. Likely because of my past experience in the “old days” of computing, back in the 1980’s, I purposely worked with older, legacy, computers for actual everyday software development so as to force myself to get used to minimal hardware. For example, back when Windows XP was the current Windows, I instead did most of my development on a 233 mhz computer running Windows 95, instead of Windows XP. I did supe it up a bit with 256 meg ram (a lot for Win95), but it was still only a 233 mhz CPU. I would develop my software on this PC and then test it on a more current PC. By forcing myself to get use to less hardware resources, it helped me learn how to write software which performed well no matter the hardware. Amazingly, the raw WIN32 API was well suited to this and it was designed for raw performance.

Also, I found that software developed with the WIN32 API required little memory and the executables were so small, it was amazing. It felt like the old days, writing software which could fit on a floppy disk ( less than 1.4 megabytes). Now some may think, with the WIN32 API programmers would not have a higher level GUI framework to work with, like .NET. While initially true, I am sure in time that developers with the right mindset would start building GUI frameworks (which only required the WIN32 API) which would be small in size and fast, like they did for the Commodore 64 with Geos. Not possible you may say ! Well, actually it is and my own company has been for the last 15 years following in the footsteps of those Geos developers, building a GUI framework designed for minimal hardware. I know it is possible, because it is already being done. Other companies should consider this approach as well, if they would like to build the next generation of software for Windows based Internet of Things devices. I am still amazed at powerful the WIN32 API is and what can be done with it. Having built a GUI framework with nearly 1000 commands in it which still can fit on a floppy disk (with room to spare at only about 1 megabyte) tells me that tiny, IOT (Internet of Thing) devices should not pose a problem.

WIN32 Programming, A Lost Art

WIN32 programming appears to have become a lost art, but it need not be. There are plenty of resources available for companies interested in adding this to their software development methods. You can still develop software using managed languages for PCs and some Windows tablets, but for the coming Internet of Things, why not consider adding WIN32 programming. Maybe you are wondering, most programming sites cater to managed languages, so where can I find information about WIN32 programming ? A quick search on Amazon.com can help you find plenty of older books on WIN32 programming (sadly there are none that I know of which are current). Some of the best resources can be found on support forums provided by companies which make native code Windows compilers . Microsoft's web site, while not teaching WIN32 programming, does have extensive documentation about the WIN32 flat APIs. While some may refer to these as legacy APIs, they are actually at the core of Windows. What do you think .NET runs on ? You can skip the “middleman” and go to the core of the operating system.

Not Convinced?

Let me provide an example of a company which has leveraged the WIN32 APIs so you can better appreciate what it is capable of (note: this company is not associated with mine). The point is to demonstrate what is possible when programmers write software using the core WIN32 API, rather than with managed languages, for Windows. This company is one of the best Graphic engine developers I have personally come across in a long time. One tool they write is called GDImage, a graphic engine, which can leverage multiple low level graphic APIs and merge them together, including the GDI, GDIplus and OpenGL. The original version was written using the PowerBasic 32 bit native code compiler, but the developer has ported it over to Microsoft C to get the benefit of 64 bit compilation. The developer also shares his knowledge of WIN32 programming on a number of programming forums. The point here is that the graphic library (DLL) is feature rich, performs very well (speed), was designed to only use the core WIN32 API and the entire runtime library is only 315 KB (kilobytes) in size. Now that is the size developers want to reach for the coming Internet of Things devices. That is 1/5^th the size of an old fashioned floppy disk. Download this developer's demo to better appreciate this. This developer even avoids using the C++ classes for GDIplus, but used the Flat GDIplus API’s provided in Windows. There are developers out there who are currently leveraging the raw WIN32 API (and OpenGL, etc.). There are still sources available for programmers to learn WIN32 programming.