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 APIs 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 (i.e., 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 (i.e., 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 APIs 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?
