The Software Developer

With all the emphasis on the Windows Store (aka. Metro) side of Windows 8, one may wonder what about the desktop ? Can the desktop be a viable platform for future touch enabled applications, especially for tablets ?

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.

EZGUI (combined with the PowerBasic compiler) has one nice advantage for software developers and that is the ability to create applications which are truly portable.

What is a portable app ?

A portable app is one which can be installed on any media (Flash Drive, SD card, etc.) and then run on any PC without the need for installing anything on the PC itself. The application must not require any components be installed to the system folders, be registered with the operating system or require a system runtime which may not be already installed on the end users PC (ie. dot.net runtimes) and requires a large download to be installed if not present.

One advantage of PowerBasic is that you don’t have to register anything with the operating system for your apps to run.

Now combine this with EZGUI which uses the standard DLL format for its library and you have a development system that does not require any special installation for your apps. You can simply copy and run or something better !

There appears to be market for apps which can be considered Portable ?

EZGUI’s design makes it an excellent tool for building unique Portable apps. Not only does EZGUI come in DLL format (so it is truly portable), but there are some other aspects of EZGUI which makes it well suited to building portable apps.

(1) Extremely small footprint !

The entire runtime comes in at about 1 meg in size (main runtime is only 700 KB) so it is tiny for the feature set it supports.

(2) Shared runtime !

Because the EZGUI runtime is shareable (meaning you can write multiple EXE’s which all share the same runtime) you can build complex suites of apps which can all be installed on one small external media (ie. SD card) and only need one copy of the runtime for all the apps (put all in the same folder).

EZGUI apps (the EXE’s) are tiny in comparison to their standalone counerparts (if you wrote an app as one EXE only and no runtime), so they take up little room.

(3) Windows versions not critical !

Because of EZGUI’s unique design it can handle multiple versions of Windows with little problem. You can easily write apps which run on Windows XP, Vista, 7 and Windows 8 without the need to worry about installing any special runtimes for a specific version of Windows or whether it has a special runtime installed on the end users PC (like some have with dot.net runtimes).

This makes EZGUI apps even more portable. Imagine advertising your apps as truly portable and able to run on Windows XP to Windows 8 !

Now consider what this means. End users could install your apps on tiny external media (how about 1 gig or less jump drives or SD cards). The media is inexpensive (you could even use a 256 meg jump drive) and very portable. Because EZGUI apps are so small in size and require minimal resources, they should load fast and run fast too !

Developers who write apps using dot.net based languages can’t do, so easily, what you can do with EZGUI.

Imagine your end users being able to install the app on a 256 meg jump drive (so cheap they can buy dozens) and then running the app from almost any Windows PC (Windows RT not included) !

Businesses with love this feature. Just plug it in any PC and run !

So if you want to create real portable applications, take a closer look at EZGUI (and PowerBasic).

For more info about EZGUI:  http://cwsof.com

For more info about PowerBasic:  http://powerbasic.com

It is so easy for a programmer to want the programming language to do all the work for them, but for myself I just want a core compiler which allows me to build what I want, the way I want it. I have noticed that my style of coding doesn’t actually use many of the more current features of the PowerBasic compiler. What is most important to me is the ability to access the Windows API (WIN32) and the core Basic command set necessary for most logic and low level coding.  Few may realize that I have been programming using PowerBasic since version 5.0 (current version is 10), when it was still called PBDLL rather than PBWIN. My latest software, EZGUI 5.0, was written using PowerBasic 9.0, but it almost was written using a much older version which was 6.1. I actually started coding EZGUI 5.0 using the 6.1 compiler, but I maxed out the compiler (meaning it could not handle the size of the source code I had), so I was forced to move to a newer compiler. I decided on jumping straight to the 9.0 version, since I would have the benefit of a few new features which would compensate for the larger embeded runtime code of the compiler. Each new version of the PowerBasic compiler has added a few kilobytes to its embeded runtime code. I was trying to keep the EZGUI runtime DLL’s as small as possible so this mattered a lot to me.

The point of this discussion is that even a much older version of PowerBasic had the majority of features I required. While some PowerBasic users are always looking to the next version of the compiler to solve their problems, I have been learning how to maximize the use of the core parts of the language which have been there for years. PowerBasic has been so rich of a language for so long that there aren’t many new features that turn out to be a “must have” for me. I upgrade to the new versions only to be current, but I can live with a much older version of the compiler.

The real power of Powerbasic is its core language and the ability to access the Windows API. Things like the OLE string engine (for variable length strings), memory management built in (no need to allocate and deallocate memory), rich logic command set (ie. IF THEN, DO LOOP, FOR NEXT), rich string command set and plenty of low level stuff (ie. pointers) and I am happy.

The real challenge when using PowerBasic has been the GUI (graphic user interface) stuff. That is why I created EZGUI. By tapping into the power of the Windows API and building a reusable library which simplifies coding (aka. RAD), I have the best of both worlds. EZGUI taps into features of Windows that most PowerBasic programmers aren’t even using right now. One good example is the ownerdraw engine in EZGUI. The ability to be able to customize the look of existing controls is so very useful.

The problem with programming today is that it is too “plug and play”. Programmers want the programming language to do all the work. True, building reusable code makes sense, but I have always felt that reusable code is something the programmer does for himself according to his own needs. For me, I wrote my own GUI library so I didn’t have to “reinvent the wheel” as they say. Even with a high level library like EZGUI, I also made it quite low level too, since I felt that it would not make sense for me to try to build everything a customer would want, but instead provide the tools for them to build what ever they required. There is no way to build a library which does everything. At best it can be a stepping stone which gets you closer to what you want.

At first glance, programming languages which allow you to quickly drag and drop components seem so productive. That was the allure of Visual Basic. It was a great tool for designing a user interface, but at some point you have to start writing some real code to get some work done and that is where problems may occur. Experienced Visual Basic programmers often found themselves having to tap into the Windows API to solve many a problem. The real power was the ability to go beyond what was considered standard user interface design to create something totally new.

This is why even with an addon tool like my own EZGUI, it does not limit the programmers ability to customize and to go beyond what the library may provide. Even though EZGUI is a GUI framework of sorts, it was designed so you can easily integrate pure WIN32 API’s into it. I actually want customers to go beyond EZGUI it they have to, to solve a problem. EZGUI is just a stepping stone getting you closer to the power of the Windows API. Yet, I also designed EZGUI so it has plenty of its own low level features, so you can do an amazing amount of customizing without having to resort to the Windows API. The rule is, “try to do it with EZGUI first, but if you can’t then there is always the Windows API”. This has worked well for my customers.

The BASIC language makes the code more readable (more natural) as well. Modular design is easy using simple, standard subroutines and functions. While PowerBasic can do some degree of OOP and classes, I don’t require it. I find OOP only gets in the way of clean simple code. The idea that everything needs to be in a class is just wrong in my opinion. Purely procedural code produces faster and smaller applications and is easier to debug.

I am sure some who read this blog may object and think “what can you do with a simple language like Basic ?”. Yet I have been very pleased with what I have been able to accomplish with EZGUI 5.0 Professional. The feature continues to get more and more advanced.  One of my favorites has been the new OpenGL based glCanvas control, which makes 3D so easy to do. Yes, PowerBasic has done me well. As Bob Zale put it, one can “compile without compromise”. !