The answer is yes, but software must change in how it is designed for the desktop side of Windows 8. It is not enough to simply make software scalable or even touch ready. What is needed is dynamic, hybrid software, capable of dealing with a variety of devices, as well as a variety of versions of Windows.

How do I plan on doing this, you may ask ?

Smart software

I have for a long time been a strong supporter of backward compatibility. Software needs to be able to run on older computers, as well as newer ones. Software needs to be able to know not only what version of Windows it is running on and then adapt, but it also needs to be able to know what hardware it is running on, for example a desktop with a large display or a tablet with a smaller sized display and with touch and then also be able to adapt. This means the user interface must be dynamic and changable as the need requires. What works with a mouse and a large screen may not work with a tablet, touch and a smaller screen. What do you do if you connect a tablet to a larger external display ? Software needs to be dynamic. But with all the dependence upon complex drag and drop development tools, do developers know how to make their software dynamic ?

Hand coded, customized software

An interesting thing has happened with my customer base. While most prefer a drag and drop Visual Designer for development, some actually prefer to hand code their applications without any Designer at all. Hand coding is likely unheard of today for many programmers, especially those who are using todays studio development environments. Hand coding though is not only possible, it also can provide more opportunities for developing dynamic software like I mention above.

EZGUI 5.0 professional (see:  http://cwsof.com/ezgui5pro.html  ), the latest version of my EZGUI development tool, was designed specifically with the hand coder in mind with many features geared towards building more dynamic software. I also have plans to work on an update (version 5.1) to improve its functionality specifically on Windows 8 (ie. add touch specific features, etc.). While EZGUI has a Visual Designer, I find that customers who are hand coders are able to create more dynamic and unique software than those who depend upon the Visual Designer/Code Generator. My goal is to improve the designer experience so it provides a little more of the flexiblity that hand coders currently experience.

Dynamic Customization

One of the advantages of EZGUI is its customization features. For hand coders, one has more options for dynamically customizing user interfaces. For example, EZGUI has a strong ownerdraw engine for customizing controls. One can easily write code which dynamically changes controls based on current need. Hand coders also can write dynamic code for control creation, so a forms controls can change as needed for the circumstance. It is the customization features which I feel are one of EZGUI’s greatest strengths. EZGUI was designed so you can even customize the common dialogs, like the open file dialog, to change how they look and even function. It is this ability to dynamically customize applications which can make the biggest difference in developing desktop software which can change as needed depending upon the hardware it is run on.

Windows Store applications can only run on Windows 8. Imagine software which can change as needed when run on a tablet, but morphs into something different when run on a legacy Windows XP or Vista computer. Smart software, you might call it. Not only would this be a good idea, but it is quite doable.

EZGUI and customization

EZGUI was designed with customization in mind. Not only does it have an ownerdraw and customdraw engine for customizing controls, but how it handles coordinates for user interfaces also makes a big difference. EZGUI uses a unique character based scalable coordinate system, rather than pixels. Unlike Dialog Units which is built into the Windows Dialog API’s, EZGUI’s character units are floating point so they can accurately define exact positions and sizes to the pixel level. You can change the character unit size dynamically, which will scale all forms and controls created after. EZGUI can also link the creation of fonts to this character unit, rather than to the system DPI settings (small fonts, large fonts on older systems). Fonts are defined via an indexing system, so rather than a fixed font for each control, you can have a fixed font index, but you can dynamically create any font you want for that index, before the controls are created so you can change an entire applications fonts on the fly.

Especially when hand coding an application, one can actually have multiple code blocks for the creation of the forms controls, but use only a single set of event routines for all of them. For example, you could dynamically determine what kind of hardware your application is running on and then when a form is created, select a different control definition routine depending upon what is needed. The different control definition routines, could all use the exact same event routines, so you only change how the controls are created, their properties, colors, fonts and position, but use only one set of event code for different layouts. Because EZGUI is not object oriented, you don’t have to create objects and work with their own event routines. Controls are created using simple function/procedure calls which can be dynamically changed, but all the events are sent to a different set of routines, no matter how the control was created. As long as the control ID matches, it does not matter how the control was created, the event routine can process the events for a specific control based on its ID.

Customization also is important to define the look and feel of an application. For example maybe on Windows 8 you would like a more flat appearance, but on Windows 7 or earlier you would like a more themed look or even something custom. Using ownerdraw to customize controls dynamically allows you to do this. Maybe you don’t like the flat appearance of desktop apps on Windows 8 and want your app to look the same on all versions of Windows or at least similar. EZGUI’s customizing features makes this more possible, at least to make them more similar than would be otherwise.

Working with more universal features

One problem one has when designing software for the latest version of Windows is that some times one may use features which only exist on the latest version. This makes designing software which works similarly on multiple versions of Windows very difficult. EZGUI was designed to add special features, but still within the confines of what exists in multiple Windows platforms. For example, EZGUI has its own proprietary 2D Sprite engine which   works on nearly all versions of Windows from Windows 95 to Windows 8. No DirectX is used and no special hardware is required. Even EZGUI’s 3D Canvas control was designed to use a more universal OpenGL 2.0 specification, so that the majority of Windows computers will support it.  By using a GUI framework which was designed for a larger range of Windows platforms, one can build software designed for the majority of Windows PCs in use today. EZGUI even dynamically loads some operating system dynamic link libraries and tests for the existance of some API’s before using them so the runtime libraries run well on most versions of Windows, but can take advantage of features which possibly may only exist in later versions of Windows. Even the GUI framework itself is dynamic.

Dynamic, Smart software is possible

So software developers should be able to create such dynamic, smart software so it runs well on a variety of devices (x86) from tablets, netbooks to full blown desktops. This how I designed EZGUI to work, to be dynamic, customizable.

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.

So how was Windows 95 possible with so little hardware ?

The operating system was designed around a set of flat API’s (basically function calls). Often refered to as the WIN32 API, the operating system provided a set of low level features which could be used to build applications. The efficiency of that operating system to run on such minimal hardware says a lot. But what many may not appreciate today is that how software which ran on Windows 95 was written is far different than how software is written today. While MFC (Microsoft Foundation Classes) was already being used by some developers at that time, many applications were still written using the pure Windows API’s alone. Doing this created applications with less dependencies. If you examine the Windows programming books available at that time, while some discussed using MFC, there were a number which taught programming using the pure WIN32 API’s alone. Having been exposed to WIN32 programming much later, nearly 15 years after Windows 95, I can appreciate why some programmers chose MFC over the the pure WIN32 API’s, since working with the WIN32 was not an easy task. But the WIN32 API’s though do have one real advantage. Working closer to the core operating system allows one to build applications which are smaller, faster and which requires a minimal footprint (less memory and disk space).

So what happened to Windows development ?

I am sure many programmers have a different perspective on this, but my own experience is quite unique and offers a different perspective on this. My programming started back on the days of CPM, before even DOS. When the IBM compatible PC came along, I started programming in Microsoft QuickBasic, then PDS 7.1 (professional version of QuickBasic). I even wrote some libraries for the compiler using assembler. There were three criteria for my development needs, (1) Fast development (2) Easy to read syntax and (3) Performance. Using a quality BASIC compiler along with a little bit of assembler provided me with all three.

When it came time to move to Windows, like many Basic programmers I quickly latched onto Visual Basic 1.0 (for 16 bit, and later 5.0 for 32 bit). I dabbled with a number of Basic programming languages such as GFA Basic and CA Realizer, but Visual Basic provided the easiest transition for me. But something happened to my programming experience which would change things drastically. I switched to a different Basic language compiler which was more akin to programming in C in Windows, which forced me to start learning how to work with the WIN32 API’s. There were no RAD tools for me to use at the time. Everything had to be coded manually in a code editor without a RAD front end. It was very difficult at first, not so much because the WIN32 API’s were too complex to work with, but because all the documentation about the Windows API were written for C (or C++) programmers. I had to port a lot of C code to Basic, which wasn’t easy because I was not a C programmer. To make things even more difficult, in the C world programmers had quickly adopted MFC, so many of the programming books dealt with MFC, rather than the WIN32 API’s directly. Over the years I would scan online looking for old copies of programming books which dated back to the early to mid 1990′s. For example I just could not find a book which explained how to write custom window classes using the WIN32. The only (and best) one I could find dated back to Windows 3.1, but it was amazing how little had changed since then.

It was interesting to see the direction that Visual Basic followed during these and later years. In the 16 bit days of Windows 3.1, Visual Basic added the VBX custom control format which was a real benefit to Visual Basic programmers back then. It was later replaced by the OCX (COM based) custom control format. While there were many advantages to these component models, the OCX would, in my opinion, introduce a downhill slide in the Windows programming model. I first experienced this when I wrote an application which could be used as a utility for a multimedia development tool. I was a beta tester for a product called MediaForge, a powerful multimedia development tool. The developer of that software was an amazing C programmer with an extensive knowledge of the Windows API. When I sent him my Visual Basic application (an HTML generator utility), the first thing he commented on was whether I could get rid of the OCX’s that had to be distributed with my app. I was forced to use OCX’s for simple things like the common dialogs. It would not be until some years later when I started digging into the WIN32 API’s myself, that I would come to appreciate how bloated some software became because of overuse of the OCX component model. The code needed to impliment a common dialog via the API was minimal compared to the size of the Visual Basic OCX. So what was the problem here ?

Object Oriented Programming changes things.

The real cause for the software bloat was, in my opinion, the overuse of the COM component model and the overuse of object oriented programming model. While they both have their value, their overuse has added a significant amount of extra overhead to Windows programming, far more than most programmers would like to admit. How do I know this ?

(For some more info about the weaknesses of OOP consider these articles:)

• http://www.csjournals.com/IJCSC/PDF1-2/9..pdf
• http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/
• http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf

When I started learning how to program using the pure WIN32 API’s, I had a few advantages that the early Windows programmers may not have had. First, I had a chance to see how the WIN32 API remained basically intact over multiple generations of Windows. The few changes made, were easy to work with since Windows from the days of Windows 95 has had a few very important features which have remained steadfast in every generation. One is the trusty DLL (dynamic link library). The DLL design, in my opinion, was simply ingenious. DLL’s are truly dynamic, produce reusable code and they tend to have a much smaller footprint than their OCX counterparts , plus they normally don’t need to be registered with the operating system, meaning the registry need not be involved. You can simply copy and run. The second important feature, associated with DLL’s again, is the ability to dynamically load DLL’s (via the LoadLibrary API), rather than staticly link them at compile time (the DLL is still separate, but the EXE header tells Windows to load the DLL automatically). Dynamic loading allows you to poll the DLL to see if an API exists or not, so you can take adantage of features in later versions of Windows if you like.

The second advantage I had was that I used a BASIC language compiler rather than C. The amazing thing about this was that working with the pure WIN32 API’s was so much easier using Basic, than it would have been using C. The language syntax made code more readable, the powerful memory management built in made coding easier, the compilers built in support for variable lengths strings (using the Windows OLE engine) made things much easier as well. For once, WIN32 code made sense and was readable. I didn’t need to use MFC. I could write applications using the WIN32 API alone.

Interesting results !

Of course to be able to write software faster it only made sense to design RAD tools, but once again the power of the WIN32 API’s proved an advantage. As I went from just a beginner API programmer to an experienced one, I began to solve more and more problems using the pure WIN32 API’s. Of course, every programmer needs some kind of higher level libraries, so I began to build my own. Because I used a Basic language compiler, I had no MFC to fall back on. I had to build my own libraries.

So while building a reusable GUI library was important, I had some basic rules. The library must be in DLL format. API’s which didn’t exist on some earlier versions of Windows, had to be polled for and then loaded dynamically, so the library would be compatible with all versions of Windows from 95 to Windows 8. If possible when an API was not available on an earlier version of Windows alternate code was added to support similar features if possible. At the minimum, the library must support all of its features on at least Windows XP forward.

Since I didn’t even have the benefit of a drag and drop visual designer to help me, I decided that I needed to learn how to build that from scratch using the WIN32 API’s. Any complex task using the WIN32 API’s which took some time to develop, I decided should be put into library code so it can be reused. Code reusability is not dependent upon the object oriented programming model as some may think. Procedural, flat API, programming models can also benefit from high level reusable code libraries. The key to working with the WIN32 API’s is to build such reusable libraries.

So the final results have been interesting. First, I found there are some very powerful low level features in Windows which have been there since Windows 95 and are still fully supported in Windows 8. For example the DIB (device independent bitmap) API’s are very useful and very powerful. The WIN32 API’s offer so many different ways of customizing user interface elements (controls). Such things as subclassing and superclassing are powerful tools. Fortunately I found one of the few books written about how to write custom window classes (controls) using the WIN32 API’s (and the term class does not mean it is object oriented in this case). I have written a number of custom window classes using the WIN32′s, such as my own Canvas control with a low level DIB engine and 2D sprite engine, an OpenGL based 3D Canvas control with a 3D scripting language, a Turtle Graphics control and a Property Listbox control. For me, as a WIN32 programmer, the possibilities seem endless.

But the most amazing thing about all of this was the size and footprint of the GUI libraries I was able to build using the WIN32 API’s. The entire GUI library can fit on an old fashioned floppy disk with room to spare. When I realized that I could write complex GUI libraries and applications which can run on most versions of Windows in use today with a minimal amount of memory (easily 64 meg or less), which are truly transportable (just copy and run, even from a flash drive) and can easily be run on the most minimal of computer hardware (ie. 233 mhz or less CPU), it is very exciting. While most programmers may be stifled by the minimal hardware on some Windows tablets today, for a WIN32 programmer the average Atom based Tablet is far more than adequate, but is a powerhouse.

So if you are looking for an alternative way of writing software which has a minimal footprint, then seriously consider what has been around since the days of Windows 95, the WIN32 API’s.

Quality software is the goal.

Likely all programmers can agree that we all want to produce quality software. We would like to be able to produce software faster, make it more reliable and improve its performance. So with such goals in mind, shouldn’t we be willing to at least consider all possibilities ? Also it is reasonable to conclude that no single tool can match all situations. For example, while few programmers today would even consider using assembler, there are times when low level coding such as assembler could be warranted. The old adage applies “the right tool for the job”. So it is fair to pose the question, “Has OOP been over used to the point of trying to make it some kind of universal tool, even when it may not fit a job very well ?”

Others are asking the same question.

I won’t go into detail about what others have said about object oriented programming, but I will simply post some links to some interesting comments by others about OOP.

Richard Mansfield

http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf

Intel Blog:  by Asaf Shelly

http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/

Usenix article:  by Stephen C. Johnson (Melismatic Software)

http://static.usenix.org/publications/library/proceedings/sf94/johnson.html

Department of Computer. Science and IT, University of Jammu

http://www.csjournals.com/IJCSC/PDF1-2/9..pdf

An aspect which may be overlooked.

I have watched a number of videos online and read a number of articles by programmers about different concepts in programming. When OOP is discussed they talk about thinks like modeling the real world, abtractions, etc. But two things are often missing in such discussions, which I will discuss here. These two aspects greatly affect programming, but may not be discussed.

First is, what is programming really ? Programming is a method of using some kind of human readable language to generate machine code (or scripts eventually read by machine code) so one can make a computer do a task. Looking back at all the years I have been programming, the most profound thing I have ever learned about programming was machine language. Seeing what a CPU is actually doing with our programs provides a great deal of insight. It helps one understand why integer arithmetic is so much faster than floating point. It helps one understand what graphics is really all about (simply the moving around a lot of pixels or blocks of four bytes). It helps one understand what a procedure really must do to have parameters passed. It helps one understand why a string is simply a block of bytes (or double bytes for unicode). It helps one understand why we use bytes so much and what bit flags are and what pointers are.

When one looks at OOP from the perspective of machine code and all the work a compiler must do to convert things like classes and objects into something the machine can work with, then one very quickly begins to see that OOP adds significant overhead to an application. Also if a programmer comes from a background of working with assembler, where keeping things simple is critical to writing maintainable code, one may wonder if OOP is improving coding or making it more complicated.

Second, is the often said rule of “keep it simple”. This applies to programming. Consider classic Visual Basic. One of the reasons it was so popular was that it was so simple compared to other languages, say C for example. I know what is involved in writing a pure old fashioned WIN32 application using the Windows API and it is not simple, nor is it intuitive. Visual Basic took much of that complexity and made it simple. Now Visual Basic was sort of OOP based, but actually mostly in the GUI command set. One could actually write all the rest of the code using purely procedural style code and likely many did just that. I would venture to say that when Visual Basic went the way of dot.net, it left behind many programmers who simply wanted to keep it simple. Not that they were poor programmers who didn’t want to learn something new, but that they knew the value of simple and taking that away took away a core aspect of their programming mindset.

Another aspect of simple is also seen in the syntax of some programming languages. For example, BASIC has stood the test of time and continues to be the language of choice for many hobby programmers. If you don’t think that BASIC is still alive and well, take a look at this extensive list of different BASIC programming languages.

http://basic.mindteq.com/index.php?i=full

While some of these BASICs are object oriented, many of them are also procedural in nature. But the key here is simplicity. Natural readable code.

Simple and low level can work together.

Now consider this. What happens when you combine a simple language with the power of machine language ? You get something very powerful. For example, I write some very complex code using purely procedural style coding, using BASIC, but you may be surprised that my appreciation for machine language (or assembler) also comes to the fore. For example, I use the BASIC language GOTO and GOSUB. How some would cringe to hear this. But these constructs are native to machine language and very useful, so when used properly they are powerful even in a high level language. Another example is that I like to use pointers a lot. Oh how powerful pointers are. In BASIC I can create variable length strings (which are simply a block of bytes) and I can embed complex structures into those strings by using pointers. In BASIC I use the DIM AT command, which allows me to dimension an array of any fixed data type or structure within a block of memory, which in this case happens to be a string.

Appreciating machine code also affects my view of performance. Every CPU cycle counts. This is one reason I use BASICs GOSUB command. It allows me to write some reusable code within a procedure, without the need to call an external routine and pass parameters. The performance improvement is significant. Performance also affects how I tackle a problem. While I want code to be simple, I also want it to run as fast as possible, so amazingly some of the best performance tips have to do with keeping code simple, with minimal overhead and also understanding what the machine code must accomplish to do with what I have written in a higher level language. For example in BASIC I have a number of options for the SELECT CASE structure. One option can optimize the code using jump tables (compiler handles this), one option can optimize if the values are only Integers or DWords. But even then the compiler can only do so much. What happens if a large SELECT CASE has to compare dozens and dozens of string constants to a variable length string being tested ? If this code is part of a parser, then it really can slow things down. I had this problem in a scripting language I created for an OpenGL based 3D custom control. The 3D scripting language is text based and has to be interpreted to generate 3D OpenGL calls internally. I didn’t want the scripting language to bog things down. So what would I do ?

The solution was simple and appreciating how the compiled machine code would have to compare so many bytes in so many string constants, one quickly realized that the compiler alone could not solve this. I had to think like I was an assembler programmer, but still use a high level language. The solution was so simple, it was surprising. I could use a pointer to read the first byte of the string being parsed. Since the first character would always be a letter in the scripting language, this meant there were 26 possible outcomes. The SELECT CASE simply tested for the first character value (convert to a number) which would execute fast. Then for each letter (A,B,C, …) I would only compare the parsed word to the scripting language keywords which started with that letter. This in essence improved speed by 26 fold (or better).

The fastest solutions are often very simple to code. No complex classes needed here. Just a simple procedure to read through a text string using the simplest logic I could find. The procedure is a little more complex than what I describe, but this is the core logic of the routine.

From experience, I have found that a purely procedural style of coding, using a language which is natural and simple (BASIC), while using constructs of the language which are closer to pure machine (or assembler) in the language produces smaller and faster applications which are also easier to maintain.

Now I am not saying that all OOP is bad. Nor am I saying that OOP never has a place in programming. What I am saying though is that it is worth considering the possiblity that OOP is not always the best solution and that there are other choices.

Here are some of my other blog articles which may interest you if this one interested you:

Classic Visual Basic’s end marked a key change in software development.

http://cwsof.com/blog/?p=608

Is software development too complex today ?

http://cwsof.com/blog/?p=579

BASIC, OOP and Learning programming in the 21st century !

http://cwsof.com/blog/?p=252

Why BASIC ?

http://cwsof.com/blog/?p=171

Reliable Software !

http://cwsof.com/blog/?p=148

Maybe a shift in software development is required ?

http://cwsof.com/blog/?p=134

Stop being a programmer for a moment !

http://cwsof.com/blog/?p=36

I can’t answer the question for others, but I can offer a perspective which I feel is often overlooked. The move from Visual Basic to VB.NET was so drastic for some that they just could not, or would not, make the transition. A number who moved to VB.NET quickly switched to C# and left Basic in the dust. So what was really going on here ? Was Visual Basic so poorly designed it just had to be left behind ? Was the managed language approach so superior that Visual Basic was just obsolete ?

One programmers perspective of Visual Basic.

I liked Visual Basic for a number of reasons, but the key reason was the ability to prototype an application very fast. The interaction of the development environment made building GUI’s extremely fast. The second reason was that it was BASIC. I had been programming in some form of Basic for years, before Visual Basic came along. I had some exposure to languages like Fortran, Lisp, dabbled with C, but none of them had the appeal of Basic. Coding was easy in basic and as one compiler developer commented, that Basic is a natural language. It is not cryptic, like C. So combining a natural language, which had a long history, with an easy to use drag and drop development environment (RAD), it was no surprise that Visual Basic was a big hit. The strange thing about Visual Basic though, was that it was a hit with a unique sector of software developers. Independent programmers, hobby programmers and the like just took to Visual Basic, like a duck in water. People who you never thought of as being programmer material, started picking up Visual Basic in their spare time so they could build their own software for use at home as well as at work.  They started creating applications for a specific need which they knew very well. Maybe they needed some software which just didn’t exist, so they created it themselves. Small businesses began to flurish from the flood of Visual Basic developers who literally were coming out of the woodworks, as they say.

The interesting thing about Visual Basic programmers though, was that even though they preferred Basic because it was an easy language to learn, they still had high expectations for themselves. If Visual Basic couldn’t do something, they often searched for ways to push the language beyond was it was designed for. So began the crop of books about how to integrate pure WIN32 API calls into Visual Basic. They were starting to tap into the deeper things of Windows.

So what happened ?

I can’t speak for Microsoft and their reasons for leaving Visual Basic behind. Likely they had good reasons in their own mind, but I believe they failed to appreciate what Visual Basic had become. I have the impression they did not expect Visual Basic to become so popular and didn’t know what to do with it. For example, initially Visual Basic only generated Pcode based applications so they were slow compared to their C++ counterparts. Visual Basic programmers wanted more though. My first version of Visual Basic which had a real compiler backend which generated decent machine code was VB 5.0 Professional. The interesting thing about this though, was that I have the impression that Microsoft didn’t plan this result initially. VB programmers were excited to have the ability to produce applications which were as fast as their C counterparts, but few may realize that to be able to get such a compiler required a little trick, which I one day read about. Now please correct me, if I am wrong about this, but I had read that Visual Basic used a C compiler backend. It was not actually a pure Basic to machine code compiler. Whether this is true or not, the point is that Visual Basic, one way or another had to become a true compiler. VB programmers wanted speed, performance. It wasn’t enough that they had one of the easiest to use GUI based programming languages, but they wanted the same performance as C programmers had and they got it, or at least pretty close.

So Visual Basic versions 5.0 and 6.0 were reaching a truly professional level, so why wasn’t there a Visual Basic 7.0 ? I can’t answer this question, but I did walk away with a very deep impression. This I say from years of hindsight. The problem was not with Visual Basic. The problem was with just BASIC ! You see, C and then later C++ was what was considered the true professional programming languages. Windows as build upon C and C++. BASIC was never intended to become the professional language it became. The shear growth of Basic and then Visual Basic, I do not believe was expected. It was that language to satisfy the hobby programmers and the kids. It was not intended to become a professional language. But with QuickBasic, then PDS 7.1 and then in the Windows world Visual Basic, it took on a new life. All sorts of people were writing commercial grade software and it worked great. RAD tools with Basic at their core, were able to produce software at an amazing rate.

So again, what happened ? Visual Basic was brought to its end (of life cycle as they might say). Now the programming world embraced managed languages like VB.NET and C#.  But something more was happenning here. The transition from Visual Basic to VB.NET also was weeding out two sets of programmers with a divergent style of programming. Why did some VB programmers make the transition, while others did not ? Were they simply just bad programmers, not willing to learn something new ? I don’t think so, and while this is my opinion I do feel there is a good reason to consider this other possibility. There is a clue in one of the reasons many managed language programmers say is why Visual Basic was a poor language. I have often read comments by programmers mentioning how Visual Basic was not truly object oriented. Key OOP features were missing in VB, so it needed to be left behind (or they say). I would like to offer a different perspective on this.

OOP versus Procedural based programming.

It was about this time (the shift to managed languages) that OOP (Object Oriented Programming) began to push procedural styles of programming into the background. This can be seen not only with Visual Basic compared to VB.NET, but also in the shift from C to C++ and then later to C#. I never realized how much managed languages effected the software industry until I watched the video of a talk by Herb Sutter (a Microsoft C++ expert) entitled:

“Why C++ ?”

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

He touches on how managed languages took over for awhile and even left C and C+ behind only to find in the long run one of the vital aspects of software was being lost and that was performance. Now I would like to go a step further. The transition to managed languages was much more than this. It was also the transition from procedural coding styles to OOP, trying to leave procedural behind too. This can be seen with Visual Basic. Those who made the transition to VB.NET likely also preferred OOP over procedural style coding. Those who did not, possibly had nothing to do with being poor programmers, but instead maybe they just simply preferred a more procedural style of coding. Visual Basic was quite unique. Where OOP succeeded the most, was in designing the interface (GUI). But the rest of the coding could be done using purely procedural style coding, much like we used in the DOS days. It was beautiful blend of the two.

So the desire of many to see a true Visual Basic programming language brought back is very understandable. But the real question before that could be possible is whether a more procedural style of programming has an advantages over using pure OOP ? Also, can the BASIC language maintain its syntax and still be used as a professional language, yet grow and advanced in a way more natural to Basic ? The answer to both questions is an absolute yes !

One step back and two steps forward.

The last Microsoft programmign language I used in my business was Visual Basic 5.0 Professional. For me, my experience was quite strange in that I had to take one step back first and then take two steps forward. I switched to PowerBasic which in those days had not GUI features at all. I still was a Basic programmer, still wrote code in a purely procedural style, but I had to write applications in the same way as the old time C (not C++) programmers had to using the pure Windows WIN32 API’s. Whereas Visual Basic programmers were extending Visual Basic by learning how to tap into the Windows API, I was writing software using the Windows API alone. From everything I read, one of the reasons C programmers began to leave behind using the pure WIN32 API’s was it was suppose to be too difficult to write any application. So along came things like MFC (Microsoft Foundation Classes) and ATL. As a Basic programmer though I had to dig into all that old C code to see how they wrote applications and they translate it into Basic. An interesting thing happenned though. The Basic version was more readable than the C version. Also the C code was purely procedural in nature, so it was a perfect fit for translating into Basic. MFC code often would confuse me more than the pure C code.  The point is that by being forced to learn how to code Windows software using what most would have considered old fashion techniques, I realized the advantage of Basic and procedural style coding, plus why Visual Basic programmers often pushed it to the limit by tapping into the Windows API, which is where the real power was.

Now imagine the power of say a Visual Basic 7, with its ease of development, combined with tools to extend it (other Basic language compilers) which simply allowed long time Visual Basic (and any Basic) programmers to be able to once again push the limits of Windows software development ? The huge existing codebase of VB code could be put to work.

Two steps forward.

Because I learned how to write Basic code using the pure Windows API, I realized something. Visual Basic never fully tapped into what is possible with Windows. The power that exists in Windows would boggle your mind if you really knew what is there. The Windows DIB engine is amazingly powerful and it has been there since Windows 95.  Threading in Windows would have been easy to impliment in Visual Basic if they only followed a simple rule, which I learned from an excellent book about Windows multitasking and threading. Threads are not needed for foreground GUI tasks. Threads are better suited to background tasks (non-GUI or preparing stuff for the GUI, but not drawing it).  I learned how to tap into using threads, even with a purely procedural style of coding. Visual Basic programmers often found themselves being forced to use third party (some even from Microsoft) OCX controls just to add features which should have been built into Visual Basic natively or could have been accomplished with a few lines of API code. Visual Basic should have exposed more of the underlying features of Windows and natively if possible. Things like subclassing and superclassing should have been introduced into the language. Things like ownerdraw and customdraw should have been introduced into the language. Visual Basic if done right, could have become one of the most powerful programming languages around, capable of producing small, fast and transportable (no installation required, just copy and run) applications.

Procedural style coding, as used in Visual Basic, has many advantages. One thing it can produce smaller, faster applications with a tiny footprint. Basic is a more natural language which allows you to use huge stocks of existing code and more easily maintain it (because it is more readable).

The key to future versions of BASIC is to first view them as a professional language. Second don’t force OOP on users. OOP has its place as an addition to the language, but one should be able to write an application with purely procedural style coding it they prefer. Third, maintain the language at its core, don’t try to make it like C or C#, but respect the long history of the language and its core syntax. Just maybe then, bringing back classic Visual Basic, would not be a step backward, but two steps forward.