Fast and fluid, can it be a reality ?

I find it interesting all the emphasis on building applications which are “fast and fluid” for Windows 8. Yes, performance is important. Yet there is an issue which some in my opinion may be missing. It has to do with how we write software.

The state of software development

Do you think it would be possible to write a complex business application which runs on a computer with a 25 mhz (that is megahertz, not gigahertz) CPU, 640 KB ram (kilobytes, not gigabytes) and only a floppy drive for data storage ?

That is the kind of machine I used to have to write business software for. In those days programmers learned every trick in the book to keep applications smaller and faster. Today developers are using very fast multicore CPU’s with huge amounts of RAM and it still does not seem enough. Why ?

Programming has changed. The mindset today is simply put, wasteful. Software development is not easier today, but more difficult. Backward compatibility is often considered valueless. As a PowerBasic programmer this becomes all too obvious to me.

Object Oriented Programming adds complexity and bloat

When I used classic Visual Basic (VB 5.0 pro) I appreciated its simplicity and power, but often wanted more power and performance. It was not low level enough for me. The component model which was suppose to make life easier (it did initially) added bloat to the compiler. This was obvious when I wrote an HTML code generator for use with MediaForge, a multimedia development tool. The C programmer who wrote MediaForge was very good at what he did. He had a real grasp on the complexities of Windows. My nice little HTML code generator app, was written in Visual Basic and he liked it but asked if I could get rid of some of the dependencies it had. Just to display a common dialog, I had to use an OCX control. What a waste, really. Even the common controls required OCX controls. Now dependencies are not bad, but when simple things all apps need to be able to do requires a component, when the actual API code to do the task is minimal, then something is wrong.

One nice thing about classic Visual Basic, was that you didn’t have to use any OOP (other than the GUI commands) to write an application. Coding was simpler and easier to maintain. Years later when I tried my hand at Visual Studio, I found it confusing and overly complex. Why whould a development tool have to also be so large ? Two and a half gigabytes to install it ?

I have not be impressed with the direction dot.net has gone in. I applaud the many new features available, but did it really require such large runtimes ? Does it really require so much emphasis on object oriented programming ? The namespace concept which appears to solve some problems with libraries, in my opinion adds complexity.  The depth of levels in a namespace style library just goes too far. The idea of an object being coded as something like objectype.somethingelse.anotherlevel.maybesomethingelse.justanotherperiod.someproperty.williteverend . Ok, no object looks like this, but the depth of many objects and their properties and methods can have this many levels and even more. I think you can get my point. And how does all of this translate into machine code ?

An experience with the WIN32 APIs

To be able to do anything useful with PowerBasic (about ten years ago) I had little choice but to learn how to work with the Windows API (WIN32). Ok, the WIN32 API’s are not so easy to work with either, but compared to todays dot.net languages it makes a lot more sense to me. I can at least understand the code flow and what it is doing. Surely the Windows API could have been made easier to work with, but Visual Basic dot.net is it. True it may offer a lot of power features, but code is more confusing and one is more dependent upon drag and drop designers and intellisense based code editors. Imagine what would happen if the intellisense in Visual Studio broke down. Do you really think anyone could code in it anymore ? That does not speak of simplicity and ease of use.

Because I had little choice of building my own GUI framework for use with PowerBasic and even my own Visual Designer/Code Generator, I had to dig deep into the WIN32 API’s. I found that one could make things a lot easier to do if one really wanted to. I also found that well built libraries based on the WIN32 API’s which are procedurally based can be very small and with very good performance.

Consider Visual Basic 5.0/6.0. The core runtime alone was 1.4 megabytes in size. Just to add some basic functionality such as the common controls, richedit control, common dialogs, etc. one would have to include a number of OCX controls. The total runtime could be more than 3 megabytes in size. By todays standards that likely seems small and it is.

But when I developed my own GUI engine for PowerBasic, which taps directly into the WIN32 API, I added many features not found in Visual Basic, especially in its core runtimes. Not only does EZGUI handle all the standard controls and most of the common controls (ie. Listview, Treeview,Toolbar,Tooltips, etc.) it goes a lot further.

EZGUI 5.0 Pro has a number of built in custom controls, such as the hotspot/shape/splitterbar control, MCI control for multimedia, files listbox control and property listbox control. It has a built in drag and drop engine for building your own drag and drop style visual designers. It has a subclassing and superclassing engine built in. It has support for threads, game timers, precision timers, tray icons and multimonitors. It has its own ownerdraw and customdraw engine for customizing controls and menus. It can generate complex window regions on the fly by simply passing it a bitmap image. It has 2D and 3D colored button controls built in. It has a graphic engine and a print engine and can work with low level Windows DC’s directly. It has its own Turtle Graphics control with a Turtle macro language built in.

But that is not all ! It has its own Canvas control with a low level DIB engine for fast pixel manipulation and a built in 2D sprite engine which can animate sprites and even antialias and alphablend them.

Not done yet. It also has its own 3D OpenGL based canvas control with its own 3D scripting language built in. It supports high count polygon models using the STL file format and can load and display a model with a million polygons in just a couple seconds (most of that is load time from disk).

There is a lot more than this too and the core runtime is only about 1 megabyte in size. Consider how much smaller that is than the Visual Basic runtimes and its OCX’s and yet how much more it does.

The goal of fast and fluid has a lot more to do with how we write our software. Tapping into the WIN32 API’s using a language like PowerBasic allows one to build tiny apps with not only a small footprint but when excellent performance.

While the new Windows 8 and its WINRT are interesting, fast and fluid has a lot more to do with how we write our software than changes in the operating system. There is already a great deal of untapped power in the WIN32 API’s.