Tuesday, 28 of April of 2015

The importance of a low level native flat API in Windows.

Innovation in software development is always important.  New ideas for better software often requires “thinking outside the box” as they say. In the Windows world, software development can easily become stagnated if developers push too much for more higher level functionality at the expense of low level functionality.


Having been a WIN32 API programmer for the last 15 years, while most programmers are using the much higher level dot.net and WINRT runtimes, I see more and more why low level flat APIs are so important. Actually, the term low level is deceptive. Low level does mean more work compared to high level, but actually low level also means simplicity.  The concepts of low level, once learned, are actually simpler in many ways, not being hindered by overly complex higher level concepts. It is the extra work that low level requires which often turns off programmers, since it is easy to desire a quick fix for a solution (meaning little or no work). But low level coding also provides more choices for customization. It encourages new ways of doing things, since it is only limited by ones imagination and skill.

Windows, while still based on its core WIN32 API, has lost much of its simplicity. The use of object oriented programming promotes the building of more and more complex code bases, which may seemingly help programmers by providing more higher level functionality, but it actually strays away from the beautiful simplicity of a low level flat API like the WIN32 API. So while one sees the benefits of the higher level code base, why should one even care about the low level native API ?

The high level must be built from the low level.

What we may fail to appreciate is that the high level functionality must be built using the low level.  The more one improves the low level functionality, the more options one has to develop the higher level engines software is built upon. I see this more and more when new hardware devices come to market. For example, why does a hardware manufacturer first provide access to its devices via a high level class library, rather than first via a low level simple flat API say for C, rather than C++ ? Build the low level API’s first. Then one can more easily build better higher level libraries. If low level libraries are available first, some software developers may find ways to exceed the functionality first intended by the hardware manufacturer.  What few may appreciate is that some times a low level, simple, flat API may provide better performance than a high level class library might. Even things like COM , namespace classes, etc are built upon more simpler low level API’s. For example, if one were to see how a class object used in C++ could be emulated via just using C (with things like vector arrays) one would appreciate that the higher level is actually much more complex than one might think. True, modern compilers hide such complexity from us, but that does not mean it is no longer complex. There was a simple rule in programming. Less code means less work for the CPU. The problem though is that if the code is very high level, then the less code may hide the reality of what a compiler is generating and programmers lose control of performance. Less code no longer means less work for the CPU.

High level libraries are important for faster software development. But if an operating system like Windows is only improved at the higher level, then what happens is that innovation decreases. True, the average programmer may seem more productive, but the real innovators, the ones who tinker with the low level, have less and less to work with. Where are the new compiler builders ? While innovation increases when it comes to scripted languages, where are the new native code compilers coming from ? In the “indie” (independent) world of programming languages, who is building the next generation of native code compilers ?

A lesson learned from building a GUI framework.

Having spent the last 15 years developing a GUI framework for use with a native code compiler, working only with the native WIN32 API, I have learned a thing or two about Windows, programming languages and native code programming. First, I have a deep appreciation for the WIN32 API and how much it offers. Sadly though, with the advent of dot.net little has been done to improve the low level WIN32 API. The API docs often make reference now to some API’s being labeled as legacy. Yet likely the functionality of such API’s is still maintained in some form or fashion in the Windows core DLL’s since the higher level functionality may be based on it. In the old days, when there was a need to update an API, Microsoft at times would create a similar API call, but simply append an EX at the end of the function name. For example, CreateWindow became CreateWindowEx. This made sense when significant functionality needed to be added. But at least the core API continued to be improved. Today, the core APIs in Windows seem to have little or no improvement, but instead have been replaced by COM object calls instead. This programmer suggests that it may be better to provide both, low level API improvements and higher level companions. Sadly though native API’s are an afterthought rather than the primary concentration today.

Watch the video of Herb Sutters talks “Why C++?” on Channel 9.

If high level functionality becomes more important than low level, then we may lose the real software innovators who create totally new ways to do things.

The richness of the WIN32 is, simply put, amazing! Microsoft put so many different ways of customizing things into the core WIN32 API, the choices are almost endless.  Manufacturers of new hardware could learn a thing or two from this, by building low level libraries for their hardware which would appeal to C (not simply C++, but real C) programmers first and then build higher level wrappers over them for other languages. I had the opportunity to beta test a unique user input device which is now becoming popular and was shocked to find the interface libraries were only provided in C++ class libraries. The idea of providing the library in a simple DLL for use with C appeared to not have been considered and workarounds for languages like C had to be done via a C++ wrapper converting the library to a simple flat API usable by C. Personally, I would have thought that C would be the first choice, a simple flat API and then build a C++ class on top of that.  It is the old “cart before the horse” syndrome.

In building my own GUI framework (on top of the WIN32), I found that building the framework in levels made a lot of sense. Often I would start adding functionality as a low level feature first and then build upon it. For example, I wanted to tap into OwnerDraw so I could customize controls. Rather than build a high level engine on top of OwnerDraw, I simply built a simpler low level ownerdraw engine which allowed me to have access to the core functionality of ownerdraw. It would take a lot more work for a user to draw something, but it provided more choices at a lower level. Then I built upon that engine a higher level (I called it Simplified OwnerDraw) where common tasks were built into higher level functions, so many common tasks could be done with just one line of code. But users of the framework though had a choice. They could use the higher level functions (ie. draw a 3D Button) if it sufficed, but if they needed more they could fall back to lower level drawing and draw things exactly as they desired. But I learned that the low level had to come first.

It would be nice!

As a Windows programmer I think it would be nice to see a resurgence in interest in improving and building upon the low level WIN32 API. By going back and improving the core APIs in Windows, even higher level layers like dot.net could benefit. It could even be possible to see new innovations in the Windows world beyond what we think possible currently. Imagine a full blown version of Windows capable of running on Intel’s Edison device ! By fine tuning the WIN32 API and building upon it, it is possible. This is not simply wishful thinking or theory. When I was designing my own GUI framework (on top of the WIN32 API), I purposedly didn’t use the latest version of Windows or the latest computers. Unlike most programmers who write their software on the lastest, fastest computers and then test them on a legacy PC to see if it will work, I did the opposite. For example, when Windows XP was the current version of Windows I developed my GUI framework on a Windows 95 computer with a very slow 233 mhz CPU. While most XP computers were running CPUs in the gigahertz ranges (2 ghz average), I was developing on a 233 mhz CPU based computer and less RAM than typical for an XP computer.  If my GUI framework ran on a less powerful machine, then imagine how well it would run on the latest PC. That is the power of the raw WIN32 API ! Minimal hardware and better performance.

It is not inconceivable to be able to write powerful Windows software which could run on an Intel Edison device (aka. Quark chip). Windows currently can’t, but it could if the operating system was slimmed down and the WIN32 API was tapped into.


Comments Off

The rise of the tiny Windows device!

Beginning in the fall of 2014, something exciting started to happen. Microsofts new approach of low cost (and some times free) versions of Windows (x86) for OEM’s building small and low cost devices began to take shape. There is little doubt in the mind of this developer that this was a smart move on their part. But things would not really have taken shape if it were not for Intel’s amazing efforts in bringing to market extremely small , yet powerful PC form factors. The 7 inch Windows tablets, TV Box style mini-PC’s and soon the PC-Stick form factor. While likely this opens up all sorts of possibilities and markets for consumer oriented products, it also opens up all sorts of possiblities for education and business. Inexpensive $99 Windows tablets brings many new options for business and education. TV Box and PC on a Stick Windows devices turn already available large screen televisions into powerful educational and business tools, as well as brings many opportunies in the consumer markets.

What this means for developers

These amazing new devices though come with a hitch. While in many ways it may provide even more power and choices than either Android or Chrome (in my opinion) it also has its challenges for Windows software developers. Much of software development has gone cross platform today and with that, limitations which are simply part of the nature of cross platform design. Cross platform usually means some compromise, compared to coding for a native platform. Cross platform tends to lean towards machine independent programming methodologies, such as scripting languages or compile on the fly on the end user machine. Yet, experienced programmers likely recognize the raw power of using actual native code compilers for a specific platform. One can code for high performance using every tool available for that platform as well as for the hardware (in this case Intel x86 SOC’s).

The new Windows PC form factors though bring a challenge to developers, since some current development systems tend to lean towards the more powerful PC platforms, rather than the new PC form factors with minimal hardware. For years the lowly Intel Atom CPU (SOC actually, which means System on a Chip) was sadly the laughing stock among some software developers. Having been spoiled by the ICore CPU’s, large and fast SSD disk drives and huge amounts of RAM memory (8,16 or more gigabytes) software developers , if they were honest about it, likely didn’t want to see their software run on such lowly devices. Rather than see the Atom SOC as a benefit (small size, low power requirement, low cost), they likely saw it as a problem to be avoided.

But the new breed of tiny Windows devices, along with the new low cost Windows solutions from Microsoft, are bringing some very exciting opportunities for developers if they can simply realize the opportunities here. The Intel Atom SOC is no laughing stock in my mind, but a very smart, well calculated design which combined with the low cost Windows is an industry game changer. Low cost, small size and reasonable power (if properly used) makes this a very positive thing for the tech industry, which should be utilitized.

As a long time programmer and having helped a number of businesses find cost effective solutions to their computer and software needs, I have found that cost matters. If a business (or a school) can accomplish something for significantly less money, while still getting a solid solution, then it is something a software developer or IT person should serious consider and promote. So hows does a software developer help others get more from the new generation of small Windows devices ?

Its been there all the time, but you may not have noticed

One of the amazing things I have noticed about the Windows operating system over the years has been how consistant it has been in supporting the core WIN32 API. Programming techniques I learned over 15 years ago, still work almost flawlessly today. I have been an active WIN32 programmer for the last 15 years now and the more I learn the better it gets. But what really amazed me is how tiny native coded WIN32 apps can be and how fast they can run and how little hardware resources they require. Since Windows 95, core features in Windows have not changed but they also demonstrate the well planned design of the core operating system. How I have learned how to do all sorts of tricks with the simple and lowly DLL (Dynamic Link Library). It is simple to design software which can even deal with the slight changes in the operating system over the years, while maintaining full backward compatiblity, even as far back as to Windows 95. Even the lowly GDI still has some amazingly raw power in it. One of my favorite features in the WIN32 API is the lowly DIBSection (device independent bitmaps). It has been there since Windows 95 and yet this simple API engine can be used to build all sorts of powerful homemade graphic engines. Once I tapped into the DIBSection API’s all sorts of possibilities arose. Another feature of the Windows API which still amazes me is the customization features built into it. Things like OwnerDraw, CustomDraw, Subclassing and Superclassing allow programmers to customize almost anything. Even core API functionality like the Common Dialogs were designed for customization. One can easily create their own “hook” procedure into them and change their functionality. For an experienced WIN32 programmer, rather than see limitations in the WIN32 API, they more likely see all sorts of possibilities.

The real power of the WIN32 API

But the real power of the WIN32 API is how little resources it requires and how tiny and fast ones applications are. The typical programmer today requires a heavy weight PC for development and their tools usually take up not megabytes, but usually many gigabytes of disk space just to be installed. Not so with WIN32 programmers. Some WIN32 programmers entire development system (aside from API docs of course, but that one can get online) may only take a few megabytes of disk space. In my case the IDE and Compiler I use only takes up about 20 megabytes of disk space and I can run it on literally any Windows (x86) PC made in the last 15 years, possibly even further back with even as little 256 meg RAM or less. My Visual Designer front end, which my company built, as well as a complex, full featured GUI framework, only takes about 3 megabytes of disk space (plus another 6 megabytes for the help file). It too can run on most likely any Windows PC made during the last the 15 years.

Native code compilers are an area which deserves a closer look by software developers. The coming mini-device Windows PC’s can be made to perform amazingly well, despite their limitations, if we as programmers learn how to tap into the native WIN32 API. The extra expense in software development will be easily compensated by the savings when using these low cost devices. Imagine a school system only paying $99 per student for a tablet and still getting a powerful system. Imagine the savings to businesses by finding ways to use such inexpensive devices. Personally, I would like to see a real Windows version device of a Raspberry PI size and cost. Get rid of the operating system bloat (like dot.net) and provide simple and easy to use compilers capable of tapping into the WIN32 API directly and it is conceivable to have a tiny Raspberry PI size Windows PC device which could sell for only $49 (or less) and be more powerful than the PI.

If you doubt the importance of native code compiling, watch the video of Herb Sutter’s talk “Why C++?”.

Still doubt the power of writing software using the native WIN32 API (as well as OpenGL, Direct-X, etc.) ?

Check out two programing libraries this French developer has created:

GDImage, a powerful graphic engine with a tiny footprint.

WinLift, a powerful window skinning engine also with a tiny footprint.

Both were written using native WIN32 coding and even without any object oriented classes typical of C++.

Both were written using Powerbasic for 32 bit Windows and GDImage was ported to C++ for a 64 bit version.

2015 will be an interesting year for tiny Windows (x86) devices

I am excited about the new tiny Windows form factors coming along. My thanks to both Microsoft and Intel for all their efforts to make this possible.


Comments Off

EZGUI, the missing part to PowerBasic

Having used PowerBasic for a good 15 years now, I think I have a good feel of the strengths and weaknesses of the compiler. I started programming with PowerBasic (version 5.0) before the compiler implimented any GUI features, which is why I created EZGUI in the first place. When PowerBasic first added the GUI command set (called DDT or Dynamic Dialog Tools), I questioned myself about whether this would make EZGUI obsolete. It did not take long to realize that the compilers GUI command set would not make EZGUI obsolete, but instead it demonstrated how far ahead EZGUI was (and would continue to be) as far as GUI features are concerned.

The EZGUI 1.0 version predated the first PowerBasic compiler (6.0) with DDT, by a year or two and PowerBasic’s PB Forms came out some time after PowerBasic 6.0 did. PowerBasic’s first compiler with GUI features only supported the standard Windows controls and none of the common controls or even the common dialogs. EZGUI 1.0 not only supported the standard controls, but also supported a number of the common controls such as the Toolbar, Tab control, ProgressBar, UpDown control and Tooltips. It also supported a number of the common dialogs, such as fonts, colors and file dialogs. EZGUI 1.0 had a number of proprietary engines in it, such as its Layer engine and Drag and Drop engine (for building visual designers). EZGUI came with its own visual designer/code generator, while it was a year or so after Powerbasic 6.0 was released that they released the first PB Forms visual designer.

Now it is true that PowerBasic always supported coding directly using the Windows API (often refered to as SDK style coding), but coding using the WIN32 API is quite difficult and it takes a long time to learn to become proficient with it. I am a WIN32 programmer and I know how much effort it takes to become proficient with it. Most modern programming languages do not resort to using the WIN32 API for doing GUI tasks, but they normally provide some kind of high level GUI command set or framework. This is what PowerBasic always needed. Its DDT command set, while sufficient for typical usage, lacks important features when one wants to build a more complex user interface which takes advantage of some of the more powerful features in Windows. From its first compiler with the DDT command set, PowerBasic has continually added more and more GUI features (versions 6.0 to 10).  For each new version of PowerBasic, there is also a similar new version of EZGUI Professional  (1.0 to 5.0) and in each version, once again EZGUI was years ahead of the compiler when it comes to GUI features.

PowerBasic, an excellent compiler

PowerBasic is an excellent compiler, despite any lacks it may have had. The compiler is fast (compile speed) and produces amazingly small executables which are also perform very well. It is comparable to any C compiler in performance. One thing which always struck me about PowerBasic, was how reliable it was. When they added new features to the compiler, they worked and they worked well, that one could be sure of. Reliability has always been one of my priorities when it comes to software development. The language is also very rich in all the low level stuff and general commands. It has one of the best string engines in the industry (it uses OLE for handling variable length string data types, which most compilers do not). No other BASIC compiler, that I know of, comes close to the richness of the language, especially in how it handles data types, like strings. For a WIN32 programmer, PowerBasic is rich with features for low level coding, with things like code and data pointers, embeded arrays (embed an array into any memory location, even a string) and even different calling methods for subroutines and functions. It also has an inline assembler for those who need really low level.

Here are some past blog posts where I talk about why I like PowerBasic:

PowerBasic, worth the investment

The PowerBasic advantage

PowerBasic, why ?


EZGUI, the missing part of the compiler

EZGUI is what is missing in the compiler. Yes, you can code user interfaces using the DDT command set in the compiler, but you will quickly find that you most likely will have to resort to the WIN32 API for a number of things. You could also simply write your application just using the WIN32 API, but the average programmer today usually lacks enough experience with the low level WIN32 API or they may simply find that even with the necessary experience it is a very slow process writing applications that way.

EZGUI, is more than just some extra GUI commands. It is a GUI framework specifically designed for use with PowerBasic. EZGUI 5.0 Professional (current version) was written using PowerBasic 9.0. It is the integration of features into a single GUI framework which gives EZGUI its power and features. The EZGUI engine takes advantage of some of its own features to build even higher level features. For example, two custom controls in EZGUI, the Files Listbox and Property Listbox controls, are hybrid controls. They are superclasses of the listbox class, but they also are ownerdraw and EZGUI uses its ownerdraw engine to impliment the visual look of the controls. EZGUI uses its own graphic engine for drawing the controls.

EZGUI has a number of proprietary engines, you not only won’t find in the PowerBasic compile but, you won’t find in the Windows WIN32 API. For example its Layer engine, allows one to easily work with Tab controls or build Wizard style dialogs without the need for child forms. Layers make designing such interfaces easy visually in the designer. The layer engine is one of the most popular features of EZGUI and no other visual designer for PowerBasic provides a similar feature (as far as I know). I don’t think I have ever seen a similar feature in other BASIC programming languages. EZGUI also has its own proprietary Canvas control. Unlike PowerBasic’s graphic control, which is only an ownerdraw STATIC control, EZGUI’s Canvas control is a high level custom control I wrote from scratch. I wrote a graphic command set for it and also designed it to use double buffers and DIB buffers so you cna have direct access to the pixel data. But the most powerful feature of the Canvas control is its proprietary 2D Sprite engine, which even has alphablending and anti-aliasing. It was designed for speed and while it does not use DirectX, it performs quite well. Its 100% software based design (rather than hardware support) makes it compatible with most versions of Windows, from Windows 95 to Windows 10, and even works well on Linux using WINE.

But the real power of EZGUI is how it taps into many of the low level customization features in Windows. For example, PowerBasic’s DDT can display an Open File dialog simply enough, but EZGUI allows you to customize the dialog and change its controls and even add a child form to the dialog. EZGUI taps into the low level “hook” features of many of the WIN32 API’s so it can provide customization features. Even with controls, EZGUI subclasses every control so it can add features to it via a low level subclass engine. EZGUI also taps into important features of later versions of Windows such as multi-monitor support, theme support (you can draw in ownerdraw using some theme effects).

EZGUI even goes beyond the compiler, by implimenting similar features in a better way. For example, PowerBasic supports defining Thread functions, but EZGUI provides mechanisms which can improve Thread functions and it even impliments its own, easier to use Thread engine which even support syncronization using Critical Sections. Syncronization is important to make Threads play well with each other. EZGUI also follows the rule of “Threads only for non-GUI tasks” and doing all GUI tasks in the primary thread (the main thread of the applications process). This is something I learned from an excellent book on how to properly use threads in Windows.

Want to learn more about what makes EZGUI different ?

Here are some blog posts where I discuss more about what makes EZGUI different and how it can benefit programmers:

EZGUI, compared to Visual Basic

Why I created EZGUI

Why EZGUI ? (why use it)

EZGUI, the backend to some important industry software


Windows devices getting smaller and the Internet of Things

The coming “Internet of Things” means smaller and smaller Windows capable (x86) devices are coming. Right now, 7 inch Windows tablets are available for only $99. But such devices may have limited memory, limited disk space and even limited CPU performance. So how does one build applications which thrive on such minimal hardware ?

Combine PowerBasic with the EZGUI framework and you have a powerful combination. PowerBasic produces very tiny applications which perform very well. EZGUI is one of the tiniest GUI frameworks around. It does many high level things like 2D sprites, 3D graphics (OpenGL based) and more, but the entire GUI framework only takes up about 1 megabyte of disk space. This means it also takes up less RAM when loaded into memory (DLL’s are loaded in memory). EZGUI was designed so it can run even on legacy PC’s with 1/4 of the resources of the least powerful PC (or tablet) found today. It can thrive on minimal hardware.

So EZGUI makes a great tool for those interested in building applications for small Windows tablets and GUI capable Internet of Things devices.

Here are some blog posts about how EZGUI benefits developers for such devices:

EZGUI, the solution to bloatware

EZGUI and small tablets

How to develop for minimal hardware


EZGUI is now priced at a more affordable price !

EZGUI 5.0 normally sells for $249 and in my opinion it is worth every penny. But for a limited time, you can purchase EZGUI for only $99 . If you already own a previous version of EZGUI you upgrade now for only $49 (limited time offer).

If you are not a PowerBasic user, then consider buying the PowerBasic compiler and then add EZGUi to your toolbox for this low price. Now most new users of PowerBasic probably prefer the latest compiler, which currently sells for $199. The typical PowerBasic user also tends to use the built in DDT command set, so they likely will also purchase the PB Forms designer (a PowerBasic product) for an extra $99, for a total of $298.  EZGUI though has all the GUI features of latest compiler and much more, so you can save money by purchasing the Classic PowerBasic for Windows compiler (which is simply their previous version) for only $99 and then purchase EZGUI on sale for only $99 and save.












Comments Off