The Software Developer

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

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

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

So back to PowerBasic and the WIN32

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

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

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

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

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

A GUI Framework

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

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

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

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

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

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

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

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

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

The secret to a GUI framework

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

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

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

Filling in the gaps

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

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

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

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

More was needed though

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

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

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

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

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

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

Windows 8, the desktop and tablets

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

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

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

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

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

Windows tablets, the real problem !

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

Hardware is part of the problem !

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

Backward compatiblity is the key !

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

One plus One equals better software !

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

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

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

Time for better software and more intelligent software.

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

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

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

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

So bring on the next generation of Windows tablets !

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

It has been interesting reading much of the news about things like “the Post PC world” and “Windows 8 not selling well” and the like. I am just as interested about where the computer world is headed as the next guy, but with one difference.

In a tough economy, we have to count are pennies !

An old saying I often like to repeat is “a penny saved is a penny earned”. For years when I helped local businesses computerize that was often a key goal in how I approached their needs. I didn’t want a customer to spend money he didn’t have to.

You can also see this in my own choices when I buy computer hardware and software for my own needs.  Programmers are notorious for wanting the leading edge in computer hardware. Myself though, I prefer to spend as little as possible on new computers (and software) which means learning how to get the most out of minimal hardware. Maybe others are learning this lesson too, since you just can’t seem to get some businesses to get rid of their old Windows XP computers (and for good reason). You know the old saying “if it isn’t broken, why fix it”.

By saving the old, you have more to spend on the new when it makes sense.

Personally I have nothing against a business wanting to get some of the latest computer hardware. Even if you are using Windows XP and like it, there are some benefits from getting a new Windows device (ie. more mobile and rouch friendly). They key though is to spend your money wisely. For example, rather than upgrade a bunch of computers from Windows XP to new Windows 7 (or 8) PC’s just for the sake of upgrading, why not find ways to extend the life of existing computers as long as possible and then use the saved funds to purchase newer and better computers when it really would make a difference, rather than enmass. Also consider when a low cost solution would suffice (ie. netbooks or low cost laptops) and then use saved funds to only buy more powerful hardware when it really would make a big difference (ie. where performance would significantly increase productivity).

Small footprint, minimal resources ! Software that makes a difference.

Do you realize that when I mention things like building software with a small footprint, which requires minimal resources, that I at times get laughed at by my own peers (other programmers) ? It is my experience that programmers tend to have a different mindset than the average person. It is so easy for a programmer to just say to end users “if the software runs poorly, you really need to buy a better computer”. Well, I have a different opinion. Having worked with small “mom and pop” local businesses over the years, I have tried to appreciate how hard they work for their money and that it is the programmers job to help them make their computers last as long as possible. So maybe we should expect programmers to be more concerned about help end users get more out of their existing computers rather than expect them to always have the leading edge stuff.

EZGUI, was designed with this in mind.

If you haven’t checked out my web site yet ( http://cwsof.com ) , please do and you will quickly notice that my primary product called EZGUI 5.0 Professional, was designed just for this purpose. I designed EZGUI so it would run very well on older versions of Windows with minimal hardware. When most programmers were developing their software on a Windows XP computer, I was developing on an older Windows 95 computer just to make sure it would run well on a legacy PC.  Today while most programmers are developing on Windows 7 or 8, I have been developing my software on Windows XP until just recently I switched to Windows Vista Home Basic because my XP computer died. I do have more modern computers, with Windows 7 and Windows 8 (and even a tablet), but I do most of my work on an older PC, because I want to make sure my software runs well on legacy computers first and then I test it on a newer one.

One can use EZGUI today, to build apps which run even on computers as old as a Windows 95/98 PC. Yet, it was designed to tap into the newer features of Windows Vista, Windows 7 and 8 when available. An even if you have a newer operating system, the kind of hardware you run it on may be minimal, like the recent netbooks which were popular. The Intel Atom CPU is no powerhouse, but yet well designed software can run very fast even on the minimal hardware like this. EZGUI was designed with CPU’s like the Atom in mind. Minimal memory is required as well.

By combining the power of the PowerBasic compiler with a GUI engine like EZGUI 5.0 Pro one can build applications with a minimal footprint which can even get the most out of legacy PC’s. You can even build applications which are truly portable. Just copy to a jump drive and your app can run on an computer with a USB port. No need for special frameworks (iel dot.net). No need to have components registered with the operating system. Just copy and run. EZGUI apps are also so small in size, you can even use very small jump drives for the apps.

This means that using EZGUI can be cost effective for software development. Imagine building apps which run just as well on a ten year old Windows XP computer as it does on the latest Windows 8 computer.