The Software Developer

Let me start with why I designed EZGUI the way I did. No matter what anyone says, writing Windows applications is not easy. For those who are engulfed in writing software using mainstream development tools (aka. Visual Studio) everything revolves around the development environment. From intellisense to drag and drop design, the idea appears to be “make things easier for the programmer”. I agree with the sentiment, but disagree with the method.

For programmers like myself who are engulfed into the world of the WIN32 API’s, programming can be just as complex. The Windows API is by no means simple. I recently downloaded two of the better Visual Designers (demos) created by the PowerBasic community and I have seriously considered how they differ from the approach I have taken with EZGUI. One designer attempts to emulate classic Visual Basic in many ways,  while the other appears to be taking some cues from Visual Studio, with a design environment similar to Microsofts Blend designer. I was impressed with the designer which emulates Blend, but at times I found it bit overwhelming, which is the same experience I have felt using Blend with XAML. I have a good bit of experience with graphic designers for 2D and 3D drawing and for me, I just don’t view visual design of a graphic user interface to be the same thing and I prefer the more old fashioned classic Visual Basic style of laying out of forms. So in this case something more akin to Visual Basic is likely more user friendly.

Now as far as working with code, the two worlds I have to compare are the WIN32 world of PowerBasic developers and the Object Oriented World of Visual Studio. I don’t think WIN32 is easy, but compared to all the OOP stuff in Visual Basic (dot.net) and the huge dot.net framework, even the complex WIN32 is easier in my opinion. If you want some of my feelings about OOP read some of my other blog posts (  ie.   http://cwsof.com/blog/?p=612  )

So back to PowerBasic and the WIN32

The Visual Designers for PowerBasic which have been developed, do a great job of building a powerful front end. One weakness, in my opinion,  though is their dependency upon the Windows API and WIN32 coding. As applications get larger and larger with more complex user interfaces, I find that the WIN32 API’s are like a dangerous iceburg just waiting underneath the water ready to sink the ship. When working with the Windows API, I don’t want any surprises. This means that I personally am more inclined to want to build reusable library code and use it, rather than keep writing (or generating) more WIN32 API code. EZGUI was not originally designed to be a commercial product. It was designed as an inhouse library so I could keep myself as far away from the Windows API as possible. To me this was a more reliable method of coding.

If there is one thing I put far above “ease of use” in my software, it is reliability. I like to use the term “solid as a rock” when I describe my goals for EZGUI. No matter how fancy the user interface or the tools we use to build them, software has to be reliable. This is one of the reasons I don’t like the WIN32 API’s because of the huge set of include (header) files required. One slight change in a new version of the headers and you can break a lot of code. This is why when I created EZGUI using PowerBasic, when I got started using PowerBasic 6.0 I determined to keep the original header files (includes) from that compiler as my core headers. Then as I needed anything which may be missing, I modified my own include files, rather than use the new versions provided with the compiler. I didn’t want any surprises. Also I also determines to write all my own code for the library. No copying others code (even open source or freeware) to save time either. I had to fully understand all the stuff I was doing with the Windows API, before I added new code to EZGUI’s runtime. The library had to be rock solid, “no surprises”.

The Windows API is also not intuitive, in my opinion. Tasks which should have been easy, often are complex or tedious. Why couldn’t the API’s be simpler and easier to use ?

To be honest, I find it confusing that most of the third party developers of Visual Designers for PowerBasic, have preferred to generate SDK (pure WIN32 code, much like old fashioned C) style code, rather than to take advantage of the GUI command set built into the compiler (called DDT or Dynamic Dialog Tools) which does a decent job of simplifying the Windows API and it produces more reliable code in my opinion (it may be simple, but it just works). There needs to be a balance between access to the power of the Windows API and ease of use and reliability. DDT does some nice tricks to make coding easier to read and reliable.

I have considered building a full Visual Designer for use with DDT, but I really don’t want to compete directly with the PowerBasic PB Forms designer. I have a utility designer I sell for generating DDT code, but that is as far as I currently plan to go with DDT. DDT does its job well and PB Forms supports a good portion of the PowerBasic users. For me, I chose a totally different route.

A GUI Framework

I don’t find working with the Windows API, directly, reliable, so building a Visual Designer which concentrates more on the drag and drop experience which generates pure WIN32 code is out of the question. PowerBasics DDT GUI command set is quite usable for many smaller to medium sized applications which have a minimal user interface, so there is little reason for me try to out do PowerBasics own PB Forms designer for those users.

My own needs and goals are far more extensive than that. I wanted to be able to build as large an application as I wanted, with as complex a user interface as possible. One goal was that I didn’t want to be dependent upon a bunch of third party custom controls (like classic Visual Basic programmers). I wanted everything to be possible with just one system. It had to be easy to use, powerful, extensible, reliable and have as small a footprint as possible. While a drag and drop design environment was vital, the designer experience would not be the key to the product. The real power would be in the GUI engine or framework. The framework would be so easy to work with that one could even write applications without the benefit of a Visual Designer if need be (and a number of my customers actually prefer to write apps that way). How many programmers today can write a complex Windows application using just a simple code editor, a single source code file for most of the source code and be able to design the user interface only with code ?

With this idea, EZGUI was born. The Visual Studio world has its framework, dot.net, so why shouldn’t the PowerBasic community have its own GUI framework ? Well, it does and it is called EZGUI (for Easy GUI). But there is one problem ! The Windows API is a complex and large set of API’s. How can you keep a GUI framework small and tight, while tapping into as many features as possible ? I decided on the old 80/20 rule (or close to that ratio). The principle goes like this. That 80 percent of users only use about 20 percent of the features available. I found this true with using the Windows API. So in my mind, the goal was to try to tap into that smaller 20 percent of the Windows API, so it would provide mostly what is needed for 80 percent or more of what a developer needs, to be able to build a complex user interface.

There was a key though which was important. What if a developer needed something not found in that 20 percent ? This is why making the GUI framework extensible was vital. I designed it so it was easy to integrate pure WIN32 code when it was necessary to solve a problem. This is exactly what my customers have done. I encourage them to use only the framework if possible, but in the few instances where something they needed was missing, I explain to them how to extend the GUI framework using the WIN32 API. I even show them how to avoid having to use any of the WIN32 header (include) files when they do this. EZGUI has its own header file which basically has the entire command set declared in it. Most applications can be written without the need for a single Windows API header file. This was by design. EZGUI applications compile very fast because they are not dependent upon a huge number of API headers. The primary EZGUI header file is only 92 KB in size. That is tiny compared to the typical WIN32 application requirements. Previous versions of PowerBasic put the majority of API include (header) code in a single file about 1 megabyte in size. The current version (10.0) uses multiple header files more similarly layed out like Microsofts C headers and it amounts to more than 1 megabyte in size and spans multiple files. EZGUI has its entire command set declares in just three include files which total about 97 Kilobytes in size (primary one is 92 KB and the other two are very small). That is one tenth the size of the include files needed using any other methods of coding using PowerBasic. Compile time is significantly faster and less prone to error.

Compile times for EZGUI applications are very fast, because there is minimal code to compile. Another factor contributes to faster compile times. That is the unique GUI command set in EZGUI. Unlike the WIN32 API’s many tasks only require a single line of code and the syntax of most EZGUI commands have been designed for minimal characters to be typed into the code editor. For example, the code necessary to create a Toolbar control, with all the buttons defined using one of the built in system Bitmaps would look like this:

EZ_Toolbar 50, “#LargeSTD”, “BBBBBBBBB|{New File |Open|Save|Close|Cut|Copy|Paste|Print|Redo}”, “ALONF24X24{1}VT”

By defining certain aspects of the toolbar using simple macro property strings, the amount of code is minimal. The GUI engine handles interpreting the property strings into meaningful API calls internally. The above code defines a toolbar using the large standard bitmap system images, with nine buttons, each with a text string in them and defaults to using the images (indexes) in sequential order for the image icons. This command can even define image indexes which are not sequential, using a single character per button. The images are 24 x 24 pixels and the last string parameter defines all the properties of this control.

Better than XAML, the GUI command set allows you to manually define a user interface but using a syntax which requires minimal code, but is still dynamic since these are actual sub/function calls into the GUI framework. The parameters could be passed variables instead.

Now new EZGUI users actually find there is a difficult learning curve at first. Not because EZGUI was not designed to be easy to use, but because it is so different than what they may have been used to. Once they understand the common syntax of the command set and how things work, often the learning cycle speeds up significantly.

The secret to a GUI framework

One of the secrets to the EZGUI framework is something so simple and obvious, programmers often fail to appreciate its importance. As programmers we get so used to “plug and play” we may find ourselves not wanting to write much code. It is so much easier to just pop in that third party custom control (typically OCX with Visual Studio) rather than create something ourselves. Maybe we want the Visual Designer to do all the work and simply add a little code here and there in some event routines. But you may say, “I don’t have time to write a custom control from scratch” and I would agree with you. But there are problems in being too dependent upon a number of third party controls. Every new third part component added to a project, adds the possibility of some incompatibility between components. Second, most component models today are based on COM (ie. OCX) so the components may need to be registered with the operating system, which prevents apps from being truly portable. The size of the applications also tends to increase significantly. So what I decided for EZGUI was this. First if a third party custom control must be used, I would encourage users to opt for those in DLL form which don’t need any special kind of system registration. This would make them portable, so you can just copy and run. EZGUI’s own framework is built of just DLL’s and they are all portable. Just copy them into the same folder as the application and they will work.

Second, why not design the GUI framework itself to have an extensive set of customization features built in, so you could simply create new controls by using existing ones and simply use some sort of customization feature. Actually, this was a perfect thing to impliment, since the WIN32 API’s already had this built in (albeit not that easy to do), so I could tap into these features in the Windows API, make them easier to use so developers would have almost limitless choices for customization. I chose to impliment both OwnerDraw and CustomDraw for controls which supported them. I provided the mechanisms to use these methods of customization, such as a graphic drawing engine.

The key to EZGUI’s nearly limitless potential is customization. Add to this, access to many low level features in Windows, but made easier, such as subclassing, superclassing, using worker threads and syncronization (critical sections). There are three different Graphic engines, one for the Canvas control, one for the printer and the other for low level drawning into any Windows DC (this is used for ownerdraw).

Filling in the gaps

The interesting thing about the Windows API is that while there is a great deal of power in it, often it is either not easy to accomplish certain tasks or there is no medium or high level ways to accomplish some tasks, which really should have been in the operating system from the beginning.

With EZGUI, I chose to fill in some of those gaps. First, tasks which were a bit difficult using the Windows API’s, I found ways to simplify them or even automate them. For example, there are two sets of ownerdraw commands in EZGUI. Once is more low level, but still much easier than using the Windows API alone. There is also a “simplified” version of the ownerdraw command set, which with just one line of code allows you to draw using a variety of ownerdraw features. For example, I impliment a simplified ownerdraw command set for 2D and 3D colored button controls. Customization need not always be overly complicated.

But the customization features alone were not enough. There were many things missing in the Windows API or at least no medium or high level ways to accomplish some tasks. These I had to build myself. I took on this challenge in a variety of ways. First, I created new controls which simply didn’t exist in Windows. True some of these may exist in the dot.net world, but that is because they are using a large GUI framework, instead of the Windows (WIN32) API. Somebody had to create these new controls, because they didn’t exist before.

I started with easier control concepts, but progressively added more and more to handle a variety of common tasks. Again the the 80/20 rule applied. I wanted new controls which were more generic in their use, but would cover a larger variety of common tasks. I created an MCI control, because multimedia is important. I created my own Canvas control because it was the most useful graphic oriented control to create. I wrote my own Files Listbox and Property Listbox controls.

More was needed though

The downside to the 80/20 rule is that programmers could easily get into a rut using only the more popular and simpler controls. There was a need to actually break the 80/20 rule and find ways to encourage programmers to push the envelope when it comes to user interfaces. One of the downsides of the new Metro interface in Windows 8 is that it tends to encourage conformity, when at times there is a need for something new and fresh which better handles the task. It is not a matter of simply breaking the rules just for the sake of breaking the rules. At times something better may really be needed. To illustrate, most birds fly since that is the norm for birds, but penguins don’t. Why not ? Because they serve a different purpose. They are birds, but they swim in the water like other birds fly in the air. They are a beautiful bird in their own right, but they are different and in their case different works, because they have a different purpose. So too with designing user interfaces. Doing something different just because it is different does not make sense. But what happens when there is a better design, by doing it differently ? Maybe the different task or purpose requires something different, something better.

While in versions 1.0 to 3.0 of EZGUI, I concentrated on the 80/20 rule, with EZGUI versions 4.0 and 5.0 it was time to break the mold. It was time to provide the tools so developers could push the envelope a bit. At a time when the devices we run Windows on are changing more and more, there is a need for more choices in software, not less.

While previous versions of EZGUI contained a built in drag and drop command set, it was time to push it beyond the basics. I needed the drag and drop for building my visual designer, but my customers also benefit from using it too to build WYSIWYG style applications. I improved the drag engine so it could drag multiple objects (controls) at one time, with speed and minimal flicker. Try selecting a couple hundred controls in your favorite designer and drag them all around together and see how difficult a task that is. This is a very useful feature for building enterprise and commercial applications which need the ability to do real drag and drop.

More and more PC users are using multiple monitor setups, so it was important to add that functionality. Because of the different device sizes which applications may have to run on, I added a new AutoSize engine for automatically resizing controls when a Form changes size. This autosize engine is very sophisticated, even with some unique customization features to handle many of those situations where a simple rules based system won’t handle it. I added a number of features to improve the graphics engine. Starting with EZGUI 4.0 I added a 2D sprite engine. Sprites have been around since the days of the Commodore 64 and Atari home computers, so why didn’t Windows have them ? I built my own sprite engine and embeded it into my Canvas control. Sprites can do more than just games, but have many business applications as well. EZGUI does this also without the need for DirectX too.

In EZGUI 5.0 I added a new superclassing engine, which I used to build the latest new control which is the glCanvas control, a hybrid control based on my Canvas control but which adds a 3D scripting language on top to display OpenGL based 3D objects. Now 3D is easier than ever. No need to learn the OpenGL API, the control handles it all via its extensive 3D scripting language.

The point is that, a GUI framework like EZGUI pushes the limit of software development, but it has one more significant benefit.

Windows 8, the desktop and tablets

With Windows 8, all the emphasis is on the Metro (or Windows Store) side of Windows. But the desktop is not only still alive, it can be more powerful than ever. The challenge of building Windows 8 desktop applications, which are not only fast and fluid, but are also emersive and exciting is being able to break out of the mold and being able to design something totally different and something dynamic as well. EZGUI was designed for this challenge (and more will be added in a future version). First, the entire EZGUI framework is only about 1 megabyte in size. The core runtime engine DLL is only 700 KB. Because EZGUI uses only DLL’s in its framework it is portable and you can create applications where you simply copy and run. Because the size of framework is so small and the executables which use the framework are significantly smaller too, you can build applications with an amazingly small footprint. This makes a difference when drive space may be a premium on a tablet. Applications can even be run using SkyDrive. Just copy and run, no installation needed. How about installing them on a jump drive and run anywhere ?

One problem many face is how do you support older legacy computers, while still support Windows 8 ? Applications built using EZGUI will also run on a variety of versions of Windows. Because the GUI framework was designed to be as universal as possible, it will run on Windows XP to Windows 8, dynamically changing itself when possible for the latest versions of Windows. Actually EZGUI applications can run even on Windows 95/98/ME and 2000 also (some features only available on 98 or later and some only on XP and later). System requirements for applications are minimal, so you can write software which will run on more Windows devices, even with as little memory as 256 megabytes or less. How many XP computers are still being used, even in the Enterprise, which only have 256 meg ram ? EZGUI applications can handle it.

At a time when software needs to be more dynamic and be able to run on a greater variety of devices (x86 only though), EZGUI 5.0 provides an amazingly large feature set but with a minimal footprint. All of this is only possible with a GUI framework. This is why I chose to build a framework, rather than simply a Visual Designer front end. But don’t worry. EZGUI comes with its own drag and drop Visual Designer, designed specifically for this unique framework. So whether you are designing for Windows XP, Vista, Windows 7 or Windows 8, EZGUI provides a framework up to the task. EZGUI keeps the desktop alive in Windows 8 and makes writing small footprint applications for tablets much easier.

Right now there is a lot of bad news about Windows 8. Sales of Surface tablets is not what was desired. So what could be done to make Windows 8 tablets more popular ? What are some hurdles which need to be tackled ?

This is one software developers take on the current Windows 8 situation.

Windows tablets, the real problem !

The real problem right now with Windows tablets is the price. It has been said that the average price of a laptop today is about $400 or less. Sure, there are more expensive computers, but many consumers (and business users) want a reasonably priced device. I am a programmer, but even for me anything over $400 is expensive. I only opted to purchase an ExoPC Windows 7 tablet because it went on sale and rather than pay $700, I only paid $400 for it and even that was a lot of money to me. To make Windows tablets more popular requires a much lower price point than what is current. I think $400 is the sweet spot for a 10 inch or larger Windows tablet and I also feel that we need some 7 inch Windows tablets which are as low as $200  ($250 at the most). So if price is part of the problem, then why don’t we have such devices now ?

Hardware is part of the problem !

You aren’t going to have such low priced Windows tablets if you stick with the more powerful CPU’s, like Core i3 or i5. I am convinced that the key to Windows mobile is Intels Atom SOC’s (system on a chip). The power is decent and the battery life is excellent. Atom CPU’s make it possible to have much lower priced tablets. Battery life has to be significant for mobile Windows devices to gain popularity, without a doubt. Ten hours, or more, of battery life needs to be the goal. Intel has done an amazing job, in my opinion, with the Atom line of SOC’s. Another part of the equation is the size of the SSD’s (solid state drives) used. As much bloat as possible has to be removed from the operating system and installed applications so smaller SSD’s can be used (16 gig, 32 gig). Screen resolutions need to be more reasonable. The love affair with high res screens makes the cost higher and it also forces the CPU to work harder. This is a reasonable middle ground here which would suffice.

Backward compatiblity is the key !

While the Metro (or Modern UI) interface is nice, it has one significant weakness. It only works on Windows 8. That in my opinion is a serious flaw.  Ok, much of the existing software is not well designed to run on mobile (touch) devices, but that is the fault of software developers and not Windows. For that matter, Windows has had some form of touch for a number of generations now, since Windows XP. Albeit the early generations were pen based, but Windows 7 introduces true touch capabilities, which makes it just as capable as Windows 8.  There are millions of Windows 7 devices being used today which have a number of years left in their lifespan. They can not be ignored. If software developers only concentrate on Windows 8 modern apps, then a huge user base is being ignored and that is a big mistake, in my mind. Computers and tablets cost money and manufacturers can’t expect consumers and businesses to just throw away existing devices. Even if people are willing to opt for a new device, they have to be reasonably priced and capable of running existing software that they have (meaning true Windows 8, not RT). Backward compatibility has always been an advantage of Windows and now is no time to throw that advantage to the wind.

One plus One equals better software !

If you combine the above (one plus one) you get a problem. How can you work with such minimal hardware like the Atom SOC, and small solid state drives, plus maintain backward compatibility (so software can run on Windows XP to Windows 8), when much software today may not fit the bill ?

To quote the creator of Turbo Basic (and PowerBasic) , “smaller, faster, smaller, faster”. Yes we need smaller, faster software which has a minimal footprint (less disk space, less memory and less CPU power). We need software which is optimized to run with decent performance even on the lowly Atom CPU’s. We need software which is backward compatible which can run on Windows XP to Windows 8. We need software which is truly transportable (meaning just copy and run, so you can run it from a flash drive or SD memory) which does not require large  frameworks to be installed (if possibly not available on all target PC’s) and does not require complex installation (no components need to be registered with operating system).

If software has less requirements, then the hardware would not need to be as powerful. No place like mobile devices is this so important today. But how is this possible ?

Time for better software and more intelligent software.

When it comes to Windows, Native coding (WIN32) has many advantages and one of them is smaller, faster software, which we really need today for mobile devices. As an experienced WIN32 programmer for the last ten years I can attest to the power of native coding and its ability to produce small, compact, transportable applications. In three words, “no dot.net needed”.  But another problem arises and that is how to build intelligent software ? The Windows API is rich with features, as well as information about the device it is being run on. Software needs to be smart enough to know the size of the screen it is using, whether the system is touch enabled and what version of Windows it is running on and then adjust to the needs of the system. Applications need to look different when run on a full blown desktop compared to when run on a tablet. They need to be dynamic, smart if you will. This is not really all that difficult if you use the right development tools. Now I am not saying that all mainstream development tools will handle this task well, but if they don’t they should. In my own case, I build my own development tools (other than the compiler and code editor) from GUI libraries (DLL’s) to even the Visual Designer/Code Generator.  Having spent the last ten years developing such tools I have been amazed at how rich the Windows API is for allowing software to be not only dynamic but also for allowing customization. I have written a number of custom controls which tap into this power of the API.  I know for a fact that one can build dynamic software if they choose too.

Now as far as performance, this again leads back to the Windows API and native coding using native code compilers. I was very impressed with Herb Sutter’s (Microsoft C++ expert) discussion about performance in his talk “Why C++?”:

http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

If you haven’t watched this video, you should. While I don’t use C++ (or even C), I am a native code programmer who uses a native code compiler, so I get similar results to what Mr. Sutter is referring to. If a software developer learns how to build software which has excellent performance, then the lowly Atom SOC’s are plenty enough to run that software. Also by tapping into the Windows API features which allow software to be more dynamic, applications can be written so they change depending upon the operating system they are run on. Lastly by writing software which taps into the core operating system (Windows API), using API’s which are very backward compatible, not only can you get powerful software, but you also can write software which can traverse a variety of versions of Windows which makes it more useful to consumers and businesses. Smaller, faster is possible ! I know, because that is what I develop for. I build software which is transportable, dynamic and has a tiny footprint and this is all possible because of the native API’s in Windows.

So bring on the next generation of Windows tablets !

I look forward to seeing more Atom based Windows 8 tablets. Rather than the higher end tablets, these lower priced (and better battery life) and smaller tablets are what is needed more. I am also waiting for the 7 inch Windows 8 tablets, even running real Windows 8 and the desktop. Again Intel’s Atom CPU’s could make this possible. Now if Microsoft can lower the price of Windows 8 (not just RT, but real Windows) for OEM’s, manufacturers could start producing low cost ($200 range) 7 inch Windows tablets and now that would be a hit to both consumers and businesses.  As a software developer I am already geared up for building smaller, faster, transportable and dynamic applications for Windows. Are you ?

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 ?