Windows 10 on ARM for mobile – Why native WIN32 coding could come back in style !

Exciting !    Amazing !    Wonderful !

OK, maybe that is a bit much, but it is exciting to see Microsofts move to support x86 emulation on ARM based Windows 10 mobile devices. From what I have read so far, the x86 emulation will only support 32 bit WIN32 (x86) applications, but that is fine by me. So how can a developer write applications which will work well on such devices ?

First, let’s talk about Intel

I have been hoping for some time that Intel would catch up in the mobile world. Windows 10 (x86 Intel based) tablets are now widely available and the prices are just amazing (really). Just today Microsoft Store had two amazingly powerful Windows tablets for sale for under $60 (one is $59, the other $49) sporting a high resolution display (1920 x 1200) on an 8 inch screen. So Intel has cornered the Windows 10 tablet market and the prices are not only competitive, but in my opinion are at times even better than comparable ARM based tablets (mostly Android). Businesses in particular should see the benefits of such low cost, yet powerful tablets. You can’t even buy a refurbished old generation IPad for that today.

But true mobile (meaning with more than simply WIFI but full cellular capability, plus very long battery life, on phones and phablets) has so far alluded Intel. I don’t think Intel is out of the game yet, but there is some catching up to do for them and I hope they meet the challenge. It should be pointed out, that while x86 emulation on ARM may push ARM forward with a seeming advantage right now, emulation is never as fast as true native execution. Emulation means there has to be a layer of software between the native hardware and the non-native executed code. There are significant differences between the architecture of Intel and ARM CPUs (or SOCs, “system on a chip”). x86 Emulation on ARM will require many more CPU cycles to parse and then translate into native code, than would native x86 execution on an Intel chip. This is just common sense. So Intel has not lost out totally in mobile because of this new option. So Intel, keep up the hard work and continue to push into the mobile market.

ARM will simply increase Windows 10 popularity on mobile devices

The coming capability of Windows 10 on ARM devices being able to emulate x86 code execution should increase the popularity of Windows 10 on mobile devices, from tablets to phones. The more choices for hardware manufacturers means more choices for consumers. Again common sense.

But whether it is running on ARM or Intel chips, software developers still have many challenges to face when it comes to writing software which will not only run well on such mobile devices, but will be smart enough to scale properly from a tiny screen to a full size monitor. I imagine the concept of just inserting your phone into a dock of some kind and now your phone is your PC with a full sized screen and a real keyboard will become more common place in coming years. Past Desktop applications just won’t fill the bill. A new generation of software needs to be developed.

Benefits of native WIN32 coding

Two things are needed for building the next generation of Windows 10 applications which will run well on native Intel mobile devices, as well as non-native ARM based devices using the coming x86 emulation. The first is small size and fast speed. Yes, performance! Having worked closely with the low level WIN32 API for nearly 2 decades, I find that the closer you are to the core operating system the better. Performance of native coded applications using the WIN32 (or as close to it as possible) produces some of the smallest (use less resources too) and the fastest applications possible. Dot.net built applications just can not compare. Also, low level WIN32 is more procedural in nature than is dot.net and most modern languages. Procedural coding produces smaller, leaner, faster applications than its OOP based counterparts. “But nobody wants to go back to old time C style coding using the WIN32 API” some may say. I agree, in part. The problem though is that much of the RAD development tools of recent years have gone the OOP (Object Oriented Programming) route which adds many layers on top of the WIN32 which slows things down. There is no reason RAD tools can’t be developed which follow the simpler procedural style of coding (aka. old style C) more akin to the WIN32 API. Whether it be visual designer front ends which simply generate code for you or it be simple GUI frameworks which shield you from the WIN32 directly, either way it produces smaller and faster applications. Before you read further I recommend watching the following video which is a talk entitled “Why C++?” by Herb Sutter:

“Why C++?” video

I will go one step further than Herb Sutter. Avoid the OOP stuff and go more procedural such as C or other more procedural languages (ie. BASIC). When you look at the history of WIN32 programming, when it became obvious that something easier than pure C coding using the WIN32 API was needed, for some reason the early generations of RAD went OOP too, rather than attempt RAD using a more procedural style of coding. MFC (Microsoft Foundation Classes) and Borlands OWL (Object Windows Library) went that route. Neither fully solved the problem. It did help coding a bit, but it lost the benefits of a more procedural approach. Why didn’t anyone think of building libraries or a GUI framework which was procedural in nature, more akin to the Windows API itself ?

Old time programmers from the DOS days likely appreciate the importance of performance and the benefits of a more procedural style of coding. Building applications which ran in just 640 Kilobytes of RAM was an unbelievable challenge to say the least. Oh how they loved it when extended memory came into being. Yet, todays mobile devices have similar challenges as well. We may have more memory to work with and faster CPU’s, but the demands are much greater with a lot more pixels to move around and things like multimedia.

As a WIN32 programmer I have found that language choice makes a big difference. Using a language like BASIC actually makes coding to the WIN32 API much easier. It is not as bad as you would think. Languages like Powerbasic (great grand child of Borlands famous TurboBasic) make WIN32 coding much easier. The compiler was written in assembler, so it compiles at lightning fast speeds. It has one of the best string engines in the industry (uses OLE to handle variable length strings) and it handles all the memory management for you. You can use inline assembler when required. And the executables it produces are as small and fast as it gets. It is on par with most C compilers, but is BASIC.  Perfect for x86 mobile and even x86 based IOT (Internet of Things). There is even now a FREE version available.

Do you find this hard to believe ? I would without proof. Download the following tiny sized app written in Powerbasic which only uses PowerBasic and the native WIN32 API to accomplish what it does. It demonstrates sprite animation without DirectX so it should run on almost any PC. The app executable in only 84 KB (that is Kilobytes) in size and the performance is quite good despite its small size. The app uses the Windows DIB apis to accomplish sprite animation. When was the last time you wrote an app which was only 84 KB in size ?

WIN32 Animation Tiny App demo

RAD, the procedural way

Yes, coding to the WIN32 API alone is probably too challenging for most programmers today. Even if one can handle it, it likely would be too slow for modern development. What is needed is RAD tools and GUI frameworks, but with a twist! Not object oriented, not dot.net, but procedural in nature like the core WIN32 API is. Not only is this possible, but it is currently being done. Powerbasic is a good example of this. PowerBasic programmers have three different styles of GUI coding choices. The first is using the built in GUI command set of the language. It is minimal, but still quite useful, even with its own Graphic control built in (Powerbasic uses the standard STATIC class system control as ownerdraw to accomplish what it does). No runtimes needed and little of the WIN32 knowledge required. The second is pure WIN32 coding, but with a twist. A number of third party developers over the years created Visual Designer front ends for the compiler which turns it into a real RAD tool and they generate pure WIN32 code out to make programming significantly faster. Two visual designers come to mind, one is called Phoenix and the other FireFly . Both are excellent tools. They demonstrate that RAD is quite possible using a language which is closer to the WIN32 API. The last way of coding is using a GUI framework. In the C world there are likely a number of GUI frameworks which are small and fast. Over 15 years I worked on developing a GUI framework for Powerbasic. While this article is not the place to discuss this in depth since it is a commercial product of my own, I do want to point out that not only are such tiny GUI frameworks possible using the WIN32, but they actual exist. But I need to use my GUI framework as an example of what is possible when one gets closer to the WIN32 API using native coding.

While classic Visual Basic went the object oriented route, I chose to follow the procedural route and the results are simply amazing. I used to think the classic Visual Basic runtime was small, but having developed my own procedural based GUI framework which is about 1/3rd the size of the Visual Basic runtimes and with much more raw power, it makes me wonder why more programmers never went the procedural route.

For example, just consider my own GUI framework for comparison purposes. With an entire GUI framework which is only about 1 megabyte in size, the size for a GUI framework is amazingly small. This is the kind of GUI frameworks we need to develop for mobile devices. GUI frameworks though should be designed to tap into more of the customizing features found in the WIN32 API. For example I tapped into both OwnerDraw and CustomDraw in my GUI framework so I could easily customize and create new control types. Customization I think will be key in developing apps for mobile devices. The core Windows API does lack a number of key features, so a GUI framework needs to fill in the gaps. For example, RAD tools are a must today. It is surprising Windows never added some kind of visual design drag and drop engine for building RAD tools. When I tested a variety of indie BASIC programming languages, I always found the form editors to be very limited and poorly contructed. The reason is that it is not easy to build a drag and drop visual designer. Even the earlier generations of classic Visual Basic were poor in comparison to todays standards. Just try to drag a couple hundred controls around on a form in classic Visual Basic 1.0 or 2.0. So I spent years learning the secrets of visual drag and drop and by the fifth generation finally built my own engine which can handle such things. I tested my own visual designer by dragging 300 controls around and it did so smoothly. A GUI framework needs RAD built into it.

OwnerDraw and CustomDraw are powerful customization features within the WIN32 API. Mobile devices need to have customized user interfaces with unique control design. They need to be “smart” controls for a lack of a better word. Not only is there a need for a resize engine within a GUI framework, but also the ability to customize controls look and feel based on the needs of the moment (ie. am I running on a tablet or desktop). I found out how challenging this is when I worked on an app for the Intel App Innovation contest (see my app info here).  To better appreciate what a tiny WIN32 based GUI framework can do, which may encourage more programmers to try their hand at developing GUI frameworks based on the WIN32 using the more older style procedural coding method, download and test the following demo apps:

Win32 Test app for Windows 8 (and 10)

Source code for above app which uses my GUI framework

3D Model Viewer (display 3D primitives and even STL 3D models)

Intel App Challenge entry (3D sandbox)

Customization is the key.

If there is one thing in a GUI framework, especially well suited to mobile devices, which I feel is vital it is the need for customization. The WIN32 API is full of customization features which allow one to customize existing controls. For example, one can take a normal Listbox control and using OwnerDraw and Subclassing turn it into a totally unique control specific to mobile needs. GUI frameworks need to tap into those customization features and allow programmers to build upon them. When it comes to low level pixel manipulation, I find the Windows DIB (device independent bitmaps) engine to be very powerful. Not only has this engine (API) existed since Windows 95, but it is amazingly low level and allows one to build upon it all sorts of high performance graphic engines and all without the need for DirectX. I wrote my 2D sprite engine using this and also my Bitmap Image filter engine using this. My Canvas control is based on the DIB engine as well.

Lessons to be learned from all of this

• Procedural style coding produces smaller and faster applications
• The WIN32 is the heart of Windows and direct access produces better performing apps
• Native coding is a great solution for the issues of Windows on mobile
• Try your hand using a native code compiler like C or Basic
• Build your own GUI framework based on your own needs
• Develop your own RAD tools to speed up development using your GUI framework
• Develop “Smart” apps which can change depending upon the device used