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.

Now I am not talking about Windows store apps here, but real Windows desktop applications. Going native or writing directly to the Windows API (WIN32) using a compiler designed for building small and fast applications can produce software which will run not only on the latest Windows 8 tablets, but also on Windows 7 tablets and Windows XP, Vista , 7 and 8 desktop PC’s.

This is why I personally prefer to use the PowerBasic compiler.  PowerBasic has a number of advantages in my opinion. First, it is Basic. Basic is a programming language which has a more natural syntax to it. Simply put, it is more readable than other languages. Second, applications written using PowerBasic require minimal resources.

A compilers effectiveness means more than simply generating fast machine code for loops and calculations. It has more to do with the overall richness of the language and its ability to solve problems. For example one of PowerBasic’s strengths is its rich string command set and how it uses the Windows OLE engine (API’s) for implimenting variable lengths strings. Manipulating strings is a vital task when writing software. But PowerBasic goes further. It is also very low level. For example, one could build fixed data types within a variable length string using pointers to structures or even define arrays within a string using the DIM AT (dimension at) command to define an array within any existing block of memory, even a string.

PowerBasic handles all the memory management for you (and fast), so you don’t have to worry about allocating and deallocating memory for variables.  One thing I like about PowerBasic is that even though it supports Object Oriented Programming using its own classes command set or even COM objects, you don’t have to use any OOP if you don’t want do. You can write apps using 100% procedurally based code.

I have found that procedurally based code can produce amazingly small and compact executables, which is what is needed for writing software which can push the limits of a Windows tablet computer.

Now, learning the Windows API can be a challenge, so PowerBasic provides a simple GUI command set called DDT (Dynamic Dialog Tools) which makes coding user interfaces much easier. For those who want more, this is why I developed my product EZGUI 5.0 Professional. The idea is to make GUI development faster, easier and more powerful. Yet,  I designed EZGUI so it can easily be extended using the Windows API, so one can go beyond its feature set to tap directly into the Windows operating system.

EZGUI itself though, was written using PowerBasic using purely native code. The native API’s are so rich with features not often tapped into by programmers that a creative developer can do all sorts of things and not feel limited.  True, it took me years to learn many of the secrets of the WIN32 API’s, but it was worth it. One of my favorite sets of API’s are the DIB (device indepent bitmaps) API’s. They have been in Windows, since Windows 95, yet they offer a programmer an amazing ability to work low level with pixels. I wrote EZGUI’s 2D sprite engine using DIB’s. EZGUI 5.0 Pro has 22 image filters, based on the DIB engine. Another great feature in the native API’s is owner draw. Owner Draw allows you to custom draw how a control looks. It opens up all sorts of possiblities. I implimented EZGUI’s 3D colored buttons using owner draw. I created two custom controls (Files Listbox and Property Listbox) using owner draw (and superclassing).

Actually, some of EZGUI’s most powerful capabilities comes from providing direct access to a number of low level features of the native API’s, such as subclassing, superclassing, DIB’s, ownerdraw, customdraw, threading and more.

I am convinced that tapping into the native API’s allows programmers to build small, faster, more powerful applications.

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

So what is wrong with this picture ?

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

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

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

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

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

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

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

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