The Software Developer

It is quite obvious that the future of Windows has to do with tablets and touch. But how do we write software which takes full advantage of the variety of devices that Windows runs on? The key to this, is to work with the strengths built into Windows.

One of the strengths of Windows often overlooked is backward compatibility. It is so easy to always be considering the latest computer hardware  , while forgetting about existing computer hardware and the need to find ways to write software which can run on both. Windows has a long history based on backward compatibility which can allow software developers to write software which can run on current as well as legacy hardware . The key to this is the WIN32 API’s which Windows was built upon.

So much has been written about how using touch on tablets is so much different then using the keyboard and mouse on a desktop computer.  Rather than force users to have to choose one or the other , why can’t software be written so it is dynamic and will change depending upon the hardware it is used upon.  While most programmers today depend upon complex software frameworks , few may appreciate the power of the low level Windows API.  This API was designed to be dynamic. As a WIN32 programmer, who builds tools for programmers, one of the problems I was faced with was how to build software which can take advantage of features found in a newer version of Windows, while still supporting previous versions of Windows. The solution was easy and has existed in Windows since Windows 95.  There are API’s which allow software to test to see if an API exists or not and then if it does, call it via a pointer and if it does not, you use an alternate solution. Also, Windows provides a great deal of information about the current specifications of the computer running it, so software can be written to impliment new features when available and to morph itself to that hardware.

Another problem with different versions of Windows is that the user interfaces continue to change. The look and feel may be different, between different versions of Windows. Once again, the Windows API comes to the rescue. Rather than be dependent upon the default look and feel for user interface elements, the Windows API, since Windows 95, has provided a variety of means to customize the look and feel of an application. Such things as ownerdraw, customdraw, subclassing (to change default behavior), superclassing (build new control classes upon existing ones) and even writing custom window classes from scratch, all provide ways to write applications which can look and act very similarly on multiple versions of Windows. The surprising thing is, that these features have been in Windows from the beginning, since Windows 95.

Even when it comes to graphics, one is not totally dependent upon the latest DirectX hardware and the latest version of Windows. Since Windows 95, the low level API’s supported DIBs (device independent bitmaps) which have been a cornerstone upon which later technologies (ie. video) have been built upon. When I needed a solution for graphic animation, I built my own custom Canvas control using the DIB API’s and created my own 2D sprite engine on top of it. The beauty of this, was that my graphic control was not dependent upon a specific version of Windows nor required DirectX (no special hardware or drivers needed).  While a few of the more advanced graphic features I wrote require at least Windows 98 or later, my 2D sprite engine runs on Windows 95 to Windows 8. It is also amazing how little has changed in the low level WIN32 API’s and how backward compatible even Windows 8 is (desktop of course).

The point is, the software can leverage features which have been in Windows for over 15 years. Now when you add dynamic features to such software so it can change depending upon which version of Windows it is run on and the hardware it has, then you truly have a powerful tool for software development. No need to worry about which version of dot.net is on the computer. No need to worry about which version of DirectX is on a computer. No need to worry about the size of the display or whether it is touch based or not (dynamically change the user interface based on what kind of device it is run on).

Imagine software, when run on a desktop computer it knows this and takes full advantage of all the available screen space for UI elements ? But when run on a smaller device, like a Netbook it dynamically changes itself to better use the limited screen space. And even more, when run on a touch device (ie. tablet) it changes the entire user layout to compensate for the need for larger UI elements for touch. Building dynamic software is what is needed now. Rather than complain how software runs well on a tablet, but wastes space and runs poorly on a desktop, why can’t we have both ? Why can’t software be dynamic ?

Another issue with trying to write dynamic software is that different computers may have differences in performance. A lowly Atom CPU on a Windows tablet is not going to be the same as running the software on a desktop computer with the latest CPU. The key here is to write software for the lowest denominator, the ATOM CPU. This requires smaller, faster software. The best way to do this is to write software using a native code compiler which produces small executables and fast software. This is how I approach software development. My goal is to write software which can run on a 10 year old legacy computer with minimal hardware. Software can be written so it fits on an old fashioned floppy disk and also is truly transportable (meaning you can copy and run). Software should be transportable today. It should be able to be simply copied to a jump drive and moved from computer to computer or even run directly from a jump drive on any computer. This requires software with a minimal footprint and no heavy system dependencies.

By using a native code compiler and the WIN32 API’s to build dynamic software, programmers can build better software which can leverage any Windows computer it is run on.

The real question though is, can this really be done ? The answer is definitely yes. But will we as software developers do it ?

Interesting news recently about Acer developing a low cost Windows 8 (x86 version, not RT) tablet. In my opinion that is what Windows 8 really needs right now. The problem though is that most Windows tablets are designed with a more powerful CPU (aka. costs more and uses more power) becauses a good bit of software for Windows just runs poorly unless you have a bit of power behind it. Even Windows 7 required 2 gig of memory (only starter versions comes with 1 gig). The operating system is bloated so you need a much bigger SSD (solid state drive) than say a comparible Android tablet.

So what is wrong with this picture ?

The problem is not the hardware, but the software. If you want a more detailed discussion of why I think this is so, read some of my other articles in this blog. To put it plainly, I feel that overuse of OOP and bloated GUI runtimes are partly to blame. Having been a WIN32 programmer for the last decade I find that one can build applications which use the native API’s, run fast and have a tiny footprint.  If Microsoft just dropped all the heavy OOP usage I don’t doubt the operating system could run on half the memory it does today. My Windows XP computer originally came with 256 meg ram and it sufficed for years.  Software tends to be slow today as well, yet the average CPU, even the lowly Atom CPU (single core) , can run rings around the CPU’s that were used when Windows XP was released.

Bob Zale (who recently died) of PowerBasic pushed his company with the goal of “faster, smaller, faster, smaller”, which is one of the reasons I use PowerBasic. By tapping into the native API’s in Windows and using a compiler which produces fast and small applications, one can produce applications with a minimal overhead. It is this kind of software which is need to make a low cost Windows tablet shine.

Now PowerBasic is not ready yet for building Windows Store apps (aka. Metro), but it can be used to produce some amazing software for the Windows 8 desktop (and it will be compatible with previous versions of Windows too, which is one reason the desktop is still vitally important).  The problem with building Windows apps using the native API’s is that the majority appear to think it just was too difficult, which is why Microsoft first moved to MFC (Microsoft Foundation Classes), then ATL and then dot.net (why not build a better GUI framework ?).  Now I have played with the latest Visual Studio and it is by no means easy to use.  The over use of OOP just adds complexity, rather than simplicity.  In my own personal experience, even the Windows API (WIN32) is easier to grasp than dot.net stuff. Sure it may be powerful, but there is more power in simplicity rather than complexity.

Now I am not saying the Windows API is easy to learn, just that as complex as it is, it is easier than what Visual Studio offers today, at least for me it is. But I am not satisified with the Windows API either, because it could have been made even so much easier than it is. This is why I developed EZGUI Professional. EZGUI was to be an inhouse tool, so I could shield myself from the Windows API, but it eventually became more than that. It was possible to make the Windows API easier to work with.  EZGUI became of a GUI framework of its own, but it simply accessed what was already there in the Windows API, simplified it and removing the mundane stuff so you could concentrate on the important stuff. What is so surprising about all of this, was how much power I was able to pack into EZGUI’s runtimes in such a small footprint.

Just think, EZGUI supports not only the major features of system controls, dialogs (forms), common dialogs, most common controls and even MDI (multiple document interface), but it also sports a graphic engine for Windows DC (for ownerdraw), its Canvas control and for the printer. It has a number of proprietary custom controls built in such as its Canvas control, MCI control, glCanvas control, Turtle Graphic control, property Listbox control and more. It has a 2D sprite engine, a 3D OpenGL based engine, low level DIB support, image rotation, alphablending, 22 image filters, vector graphics (Turtle), thread engine, ownerdraw engine, 3D buttons, subclass engine, superclass engine, precision timing, region generation (non-rectangular windows), clipboard support, registry access, tray icon support, autosize engine, built in scaling engine and a drag and drop engine (WYSIWYG style apps). And there is more than that.

And all of this fits into about 1 megabyte of space. Yes it all can fit on a single floppy disk ! Now imagine of one started building applications with such a tiny footprint ? You would not need so much memory, so much hard drive (or SSD) space or even so powerful a CPU. By decreasing the hardware requirements of software, you make building cheaper computer devices possible. One could build a tablet with the least expensive Atom CPU possible, a 20 gig SSD (all that Windows 8 needs) and only 1 gig memory and desktop apps built with EZGUI (and Powerbasic) would run very well. And guess what ? The same software could run on a 10 year old Windows XP computer, with 256 meg ram and a 20 gig harddrive.

To make cheaper Windows tablets possible, one must be able to use less expensive (and less powerful) hardware. To make the tablets still shine they would require a new generation of software which can run on minimal hardware and still impress the end users (fast and fluid).

So I will be watching to see what kind of Windows tablets show up in 2013 and I will be ready for them, even if they are extremely low cost with minimal hardware. Now I think the $199 price range would be a sweet spot for a Windows tablet (10 inch) and possibly $149 or less for a 7 inch Windows tablet. Yes, I think a 7 inch Windows tablet would be a great idea. So what will manufacturers come up with in 2013 ? Let’s wait and see.

Developing EZGUI 5.0 was challenging and it demonstrates the real power of the Windows API, particularly the more functional API’s, rather than COM.

Working with API’s which are simple functions, rather than complex COM objects and classes makes coding easy in my opinion. I like simple. Similar to the concept of STL (the Standard Template Library) in C++, EZGUI was designed using simple functional API’s and its own library code was designed to work in a similar way (simple and easy to use). If you read some of the posts of this blog, you will find that I am not impressed with object oriented programming. Actually, the Windows 8 WINRT is my opinion has been made overly complex and bloated because of this over dependence upon OOP.  The idea of passing objects for many key routines just adds complexity.

What few people may appreciate is that the core Windows API (commonly refered to as the WIN32) is amazingly simple in its design, yet quite powerful. The problem with WIN32 though is that too many mundane tasks are left to the programmer, which is likely why programmers found it so difficult to code apps using C and the pure WIN32. Microsoft later provided libraries like MFC, ATL to make life easier, but even there Windows coding was still complex. Why ?

Part of the blame I put on the C language. C (and its relatives, C++, Javascript, etc) is a language which is terse (meaning not natural). This actually adds to the complexity of coding using the WIN32. If I had to learn C and then learn the Windows API, I too would have found it likely too difficult. Fortunately, I was a BASIC programmer. From QBasic to Visual Basic (5.0) I always found the naturalness of Basic made coding easier. When I came across PowerBasic (which is what I use today), I was simply put, impressed with its power. The only problem was that I started with PowerBasic DLL 5.0 and there was no GUI features in the language at the time. I was forced to learn the Windows API to build GUI apps. To make things more difficult much of the literature on coding Windows apps was written for C++ programmers, much of it using things like MFC and ATL. Researching the WIN32 API’s was actually quite difficult at first. The MSDN documentation (and SDK docs) were also geared towards C++.

I finally found the key to understanding WIN32. I started buying old used programming books which dated back to the mid 1990′s. One really good book on building custom controls dated back to WIN16 (windows 3.1) actually.  I had to avoid books which used MFC too. Once I found the right, older, books, learning the WIN32 APIs and how to code GUI apps began to make sense.

Amaxingly, good old C (not C++) code was the easiest code to convert to PowerBasic. The simplicity of C, compared to C++ made things a lot easier. What made things even better, was when I started building my own code base written in PowerBasic. While WIN32 code using C is not too bad, WIN32 code written in Powerbasic is actually readable and makes a lot of sense. Now that I could tap into the WIN32 API’s (and later OpenGL which is also a well designed clean set of functional API’s), then some amazing things began to happen.

I am strong believer in building modular , reusable code. As I began to build my own GUI libraries (on top of the WIN32) I began to realize how powerful Windows really is (the WIN32′s). There are some core concepts in Windows which provides some amazing power, which sadly few programmers ever tap into themselves. I also realized that while high level libraries are important, medium level and especially low level are also vital.

For example, the DIB (Device Independent Bitmap) API’s in Windows are amazingly powerful. Direct access to bitmap data and control of the bitmap format (I use 32 bit a lot) opens up all sorts of possiblities. I tapped into the power of DIB’s in a lot of features in EZGUI.

Another really exciting feature is OwnerDraw. In essence ownerdraw allows you to create all sorts of new controls, simply be customizing existing ones by drawing the data in them yourself. Customdraw is similar, but allows you to just define fonts and colors of elements of a control (items).

The problem with WIN32 though is these powerful features, require some advanced coding which may not be easy for some. Even with my own experience I found them overly complex. So I decided to simplify much of these things, so you still had the power the API’s provide, but it could be more easily tapped into. Now things got interesting when I started to learn how to build my own custom window classes (custom controls) from scratch. My Canvas control was amazingly simple, yet powerful, one reason being that I allow you to tap into the Windows DIB engine. It was simple to impliment things like image filters for the Canvas control using DIB access.

By the time I created EZGUI 3.0, I was beginning to run out of common tasks to impliment, so I started building more complex things. I added a 2D Sprite engine to my Canvas control. I added more ownerdraw support. I started building hybrid controls via superclassing and ownerdraw combined. I started simplifying threading.

One of the problems with the WIN32 is that each new version of Windows may add some new features, so how do you support the new stuff, while maintaining backward compaitbilty with the prevsious versions ?

You see this with retail software where in each new version, the minimum version of Windows required kepy creeping up. First it had to be Windows 98. Then it had to be Windows ME. The Windows XP became the minimum version required. This is not necessary actually, because from day one (Windows 95) Windows had a core feature in the operating system which makes this unnecessary. The WIN32 provides you with the ability to load libraries (DLLs) dynamically at runtime (LoadLibrary API) and then poll the library to see of a specific function exists. If it does, then you can get the address of the function and then call the API dyanamically via its address. The PowerBasic language easily supports this too using the CALL DWORD (call by address) command. This allowed me to code features specific to more recent versions of Windows, while providing workarounds for older versions. For example in EZGUI some of the drawing commands can draw themed elements, but if theming is either off or does not exist, then it falls back to drawing a GDI version (not themed of course).  PowerBasic also has a rich set of commands for handling structures, even using low level pointers to data which also allowed me to write code which was dynamic. It could use data structures specific to the version of Windows which was running.

What is really amazing is how compatible all of my library code is even with the new Windows 8 (desktop).  The interesting thing about the recent versions of Windows (XP to 8) is that the look and feel has progressively changed, especially with Windows 8. Wouldn’t it be nice to write apps, which look similar on most versions of Windows. Well, EZGUI can do this because of its string support of ownerdraw and customdraw. EZGUI can override the defaults and customize a UI to any way you like. The possibilities are endless.

Windows (WIN32) is like a set of building blocks, so almost anything is possible. Why should we be stuck with a certain look and feel for our software. Even Microsoft can’t make up its mind on what is the best look and feel. In the past programmers were encouraged to copy the look and feel of Microsoft software. Now with Windows 8 basically considers all the “eye candy” of the past is considered obsolete and the new Metro Style (flat as a pancake) look and feel is in. Personally I find all this flatness distasteful. Programmers should be able to design a UI according to their own needs and preference. Some times color and 3D dimension is good. Some times a button needs to stand out in 3D rather than be a flat rectangle (how can you tell the difference between a button and a label now if they both look the same ?)

It is not a matter of using “eye candy” simply for the sake of eye candy. Some times a user interface needs 3D elements and depth to me truly natural and meaningful. I also don’t like (in Metro side) the over dependence upon the “BACK” or “PREVIOUS” button where navigation is done by clicking BACK. Navigation in a user interface can have many difference choices beyond the over simplification of Metro.

The WIN32 sadly was not fully tapped into at times, but it offers some amazing possibilities. It amazes me to see how some of my customers have used EZGUI 5.0 Professional to build some truly unique looking interfaces for their software. Also the power of Windows does not require software to be bloated either. Take for example the EZGUI 5.0 runtimes. In about 1 megabyte, the core runtimes accomplish things which may surprise you. Not only does it provide the basic UI elements of controls and forms (no OCX’s needed for controls either), but there are a number of proprietary custom controls included, a 2D sprite engine, a graphics engine, a print engine, a drag and drop engine and even OpenGL based 3D. All in one megabyte.

Now another amazing thing is because of avoidance of COM based programming (no OCX’s required), the runtimes don’t require any registration with the operating system (aka. registry). This means complex apps written using EZGUI and Powerbasic can simply be copied and run. Yes, you can put an app on a jump drive and run it from there. You can copy a folder with an app from one drive to another or  even one PC to another and run. No need for an installation program. No need for registering objects with the operating system. This provides complete portability, which few apps have today.

Yet, I am not using anything which was not available in the operating system to begin with. I am using features which have been in the WIN32 (and OpenGL 1.0/2.0) API’s for many years. The key is know how to tap into what is already there.

This blog, while about programming, is also about the software I develop and why I created it the way it is. EZGUI 5.0 Professional is a tool which makes coding easier, while tapping into the power of the Windows API. Rather than limit a programmer, it provides more choices. While it has many high level features and custom controls, it is also very low level providing programmers with a variety of ways to tap into the power of Windows.

So check out EZGUI 5.0 ( http://cwsof.com ) . If you have questions about it, email me: chrisboss@centurylink.net