I started developing custom software for local businesses in the 1990′s. Amazingly some of my DOS applications are still in use today. Hard to believe isn’t it ?
About 14 or so years ago I switched to developing programming tools for programmers. I had been using classic Visual Basic for awhile and it was one of my favorite programming languages. I actually used Visual Basic to port one of my DOS applications to Windows, but did so in a way where I created a hybrid application which emulated the DOS version, but on Windows (not a console app either). Visual Basic was great, but I kept hitting limitations with it, especially when it came to performance and less dependencies. I found PowerBasic which was originally sold as an addon to Visual Basic for writing DLL’s. It lacked all the polish of Visual Basic and had no way to build full blown applications, like you could with Visual Basic, but instead required you to learn the low level Windows API (WIN32) to be able to write an application. As long as what you wrote didn’t require a GUI, it was great, but once you had to start building a GUI, it was tough going. It was no Visual Basic, not having a Visual Designer. No RAD developer here. That was PowerBasic 1.0 for 16 bit Windows and then PowerBasic 5.0 (they jumped from version 1.0 to 5.0 when switching to 32 bit if I remember correctly) for 32 bit Windows. But that was about to change !
Building inhouse tools
From my early days of programming I was one who saw the advantage of building my own inhouse tools to speed up development. Back in the days of the Commodore 64, I moved from interpreted Basic to a real compiler for the Basic language (made by Abacus) and when I decided to write my own game, which required even more speed than the Abacus compiler could put out, I used that compiler to write my own compiler which was kind of like a hybrid part assembler, part basic, language which worked very well for me. It allows me to produce software with the speed of one written in assembler but partly with the ease of Basic.
When I developed software for DOS, again I saw the need to build reusable code libraries and even to use RAD tools. For example I got a tool called SoftCode by Bottleworks, which allowed you to design you application visually (character based screen though) and then generate the code for the application which could then be compiled using QuickBasic (or PDS 7.1). The tool was great, but the code template was not so good in my opinion. But Softcode had one nice feature. The code templates for in seperate files and there was a template definition language they were written in, so you could write your own templates, which I proceeded to do. In time I built up a powerful code template which generated some very unique QuickBasic source code. It was capable of scrolling grid style windows (kind of like a listview control today), supported a multi-user database (of my own design) which could allow you to use multiple servers to break up the work so one server handled a few workstations and another server would handle others, but maintaining a mirror of the database on all the servers at all times. I could draw my application visually and then generate a complete working application in QuickBasic source code. QuickBasic code was easy to maintain and customize, so it was a great solution.
When I switched to PowerBasic, realizing it had no GUI command set or even a Visual Designer, what was I going to do ? Learning the low level Windows API was challenging enough, but this made it even harder. Once again, I did what I had done in the past and I started building inhouse development tools. PowerBasic was no an easy language to work with in those days. The Windows API documentation (and the API itself) was designed for C programming, not Basic. Because Windows was likely written in C and later C++, the WIN32 API is not really that friendly. Some Powerbasic programmers experienced with the Windows API would often say that the Windows API is not that difficult to learn, but I strongly disagree. Not that it is bad, but it is overly complex and one has to watch every detail. Unlike programming with Visual Basic, which shielded you from that complexity, coding using PowerBasic with the Windows API was actually very difficult, time consuming (so not so productive) and it lent itself to bugs because one simple error in calling an API and it could be dissastrous (aka. GPF). So what was I to do ?
Step one ! Build my own reusable libraries which gave me the power of the Windows API without all the complexity. Step two ! Make the library easy to use and simple in design. So I proceeded to start writing this inhouse library. I would research the necessary Windows API to do tasks, write a function or subroutine with it so later I would not ever have to go back a WIN32 API again. I called the library something like PBV standing for PowerBasic Visual or something like that. A bunch of my early subroutine names started with PBV and are still being used today in EZGUI. I created this library, not to sell, not for other programmers, but for myself. I knew what I wanted in a GUI engine. I later got a few other PowerBasic programmers to beta test my library and it eventually turned into a commercial product when Isaw that others found it easy to use too.
EZGUI was born !
EZGUI 1.0 was born from my inhouse development. I did something quite unique though from the start. My first application that needed to be built with this library was a Visual Designer, because I was not planning on hand coding my GUI’s for the next few years. PowerBasic had no Visual Designer, no GUI command set, so it made sense to build my own, not own the GUI command set (or GUI framework), but also a designer. But I made a decision early on, that when I build an application (my designer), I would never use the Windows API again. Only my GUI framework would ever call the Windows API. One thing my Visual Designer needed was a drag and drop engine, so I created it, but made it part of my GUI engine, rather than code it with the Windows API in the designer. My first designer, while rudimentary, worked and worked well. It generated the code I needed and allowed me to copy it to the clipboard and paste it into the PowerBasic code editor.
But I had a rule about my GUI framework. No matter the task, the code to do it must be easy to use. The internals of the framework were quite complex, but applications written using the framework must be easy to code and easy to read, plus requiring as little code as possible.
For example a nice little sample is this:
It is nothing fancy, but just a Form (window) with two floating popups, each with toolbars. The main window has a regular style menu as well.
Now the code for the complete application looks like this:
$DIM ALL ‘ This is helpful to prevent errors in coding
$INCLUDE “ezgui20.inc” ‘ Load EZGUI Include file
DECLARE SUB SetTips1(N&)
DECLARE SUB SetTips2(N&)
$INCLUDE “ezwmain.inc” ‘ EZGUI Include file for WinMain
hMenu1&=EZ_DefMainMenu( 900, “&File”, “”)
EZ_Form “Main”, “”, “This is a test of the Toolbar Control”, 0,0, 70,25,”C”
SELECT CASE FormName$
EZ_AddMenuItem hMenu1&, 910, 0, “&Edit”, “”
EZ_AddMenuItem hMenu1&, 920, 0, “&View”, “”
EZ_AddMenuItem hMenu1&, 930, 0, “&Help”, “”
hSubMenu1&=EZ_DefSubMenu(901, “&New”, “”)
EZ_AddMenuItem hSubMenu1&, 902, 0, “&Open”, “”
EZ_AddMenuItem hSubMenu1&, 903, 0, “-”, “”
EZ_AddMenuItem hSubMenu1&, 904, 0, “-”, “”
EZ_AddMenuItem hSubMenu1&, 905, 0, “&Configure”, “”
EZ_AddMenuItem hSubMenu1&, 906, 0, “E&xit”, “”
EZ_SetSubMenu hMenu1&, 900, hSubMenu1&
hSubMenu2&=EZ_DefSubMenu(911, “&Cut”, “”)
EZ_AddMenuItem hSubMenu2&, 912, 0, “C&opy”, “”
EZ_AddMenuItem hSubMenu2&, 913, 0, “&Paste”, “D”
EZ_SetSubMenu hMenu1&, 910, hSubMenu2&
hSubMenu3&=EZ_DefSubMenu(921, “&Window”, “X”)
EZ_AddMenuItem hSubMenu3&, 922, 0, “&Palette”, “X”
EZ_AddMenuItem hSubMenu3&, 923, 0, “&Toolbar”, “X”
EZ_SetSubMenu hMenu1&, 920, hSubMenu3&
hSubMenu4&=EZ_DefSubMenu(931, “&About Program”, “”)
EZ_SetSubMenu hMenu1&, 930, hSubMenu4&
hSubMenu5&=EZ_DefSubMenu(915, “Option 1″, “”)
EZ_AddMenuItem hSubMenu5&, 916, 0, “Option 2″, “”
EZ_SetSubMenu hSubMenu1&, 905, hSubMenu5&
EZ_Toolbar 100, “#LargeSTD”, “BBB XXX RRR BBB|123CDE456789″, “R”
EZ_Form “Page1″, “Main”, “”,0,3,8,15,”P”
EZ_Toolbar 100, “#LargeView”, “XXXXXXXXXXXX”, “O”
EZ_Form “Float1″, “Main”, “ToolBar”,60,0, 8,10, “RN”
EZ_Form “Float2″, “Main”, “ToolBar 2″,0,20, 67,3, “RN”
EZ_Toolbar 100, EZ_LoadPicture(“toolbar2.bmp”), “BBBBBBBBBB”, “24X24O”
EZ_Toolbar 200, “#LargeSTD”, “BBB BBBBBB BB BBB B|0123456789ABCDE”, “FB”
SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
LOCAL X&, CP$, D$
SELECT CASE FormName$
SELECT CASE CID&
CASE 101 TO 115
IF CMsg&=%EZ_Click THEN
EZ_MsgBox “Main”, “You clicked Toolbar Button #”+STR$(CID&-100), “Toolbar Message”, “OK”
IF CMsg&=%EZ_ToolTip THEN
EZ_SetToolTip “This is Button #”+STR$(CID&-100)
SELECT CASE CID&
CASE 101 TO 112
IF CMsg&=%EZ_ToolTip THEN
EZ_SetToolTip “This is View Button #”+STR$(CID&-100)
SELECT CASE CID&
CASE 101 TO 112
IF CMsg&=%EZ_ToolTip THEN SetTips1(CID&-100)
SELECT CASE CID&
CASE 201 TO 215
IF CMsg&=%EZ_ToolTip THEN SetTips2(CID&-200)
SELECT CASE N&
SELECT CASE N&
The code is not complex, but notice how easy it is read, how little code it takes to define the toolbars with all of the buttons. Now remember, PowerBasic didn’t have any GUI commands, so the entire GUI above uses the framework I designed. Not a single Windows API call was necessary to write this app either.
Now the early GUI frameworks I developed were pretty rudimentaty, but they did the job and had most of the features I required. The important thing was that the code be easy to write and it was. I had some customers who didn’t even use my Visual Designer, but prefered to hand code the entire application just using the framework alone. Imagine doing that today with say a Microsoft language.
Desiging for myself
My GUI framework (and designer) , known as EZGUI, has gone through five development cycles now (current version of 5.0) and during the development when I dealt with my beta testers, while I tried to incorporate their suggestions, in reality I was designing it for me just as much as for them. I always followed my gut feelings about things and even if beta testers really wanted something one way, if I really was convinced that the way it fit my vision of the product was better I would stick with that, even if my customers did not initially appreciate what I was doing. Why ?
Too many cooks spoil the stew ! We have heard that before. I appreciate suggestions, but there had to be a single vision of what the product would be. Remember, EZGUI was originally an inhouse tool designed for me, so I always kept that goal of designing for myself first, because if no one ever wanted to use my tool, I know that I would and that I could build what I want with it.
In time I think my customers began to see the mindset behind the product and that there was a hidden agenda they might not have appreciated at first. Advanced, complex software tasks need not be wrapped up in complex code. True some tasks are complex, so one can not expect the code to be extremely simple. But the code need not be overly complex either.
For example when I added support for dragging an item in a listview or treeview control, the Windows API code was quite complex to impliment (hundreds of lines of code). But in my GUI framework the code in an application to impliment it looks like this:
IF CMsg&=%EZ_DragItem THEN
EZ_StartDrag 1,0,0,8, “TAH”
Just one event and one line of code to start the drag operation and even impliment autoscrolling of the control when the drag icon reached the top or bottom of the visible area of the control.
There is no need for complex tasks to have to require complex code, if one builds the higher level libraries correctly.
My shock with Visual Studio
If you have read my blog before, you know I am not a fan of object oriented programming. I beleive it has its place, but it has gone too far and overtaken programming to the point where code is not longer simple and easy to read. Oh, if you use Visual Studio all the time you may find this hard to believe. But I spend almost a decade and a half away from Microsoft languages, using PowerBasic. I understood complex coding because I spent those years learning the Windows API (what I do is more akin to the C coding of the early 1990′s). There is a lot to learn about the Windows API and it is overwhelming at times. I can see why Microsoft created tools like MFC (Microsoft Foundation Classes), ATL, etc. Coding use the WIN32 alone was difficult, let’s face it.
So when Windows 8 came out, because I was a WIN32 programmer and PowerBasic can not be used to write Windows Store apps (aka. Metro), I decided to download Visual Studio Express so I could dabble making some Windows Store apps. I figured that I had been coding the hard way for years with the WIN32 API, surely Microsofts latest high level languages would be easy to use and refreshing. But actually it was the opposite. While assume the latest languages are very powerful, I was shocked by how confusing the coding was now. Wasn’t high level languages suppose to make coding easier ?
Sure, the many namespaces and features in the languages allow one to tap into all sorts of things in Windows and that is great. But what ever happened to the idea of easier to read code ? Has coding gone so far off the edge that we have made it worse, not better ?
Has programming become so complex it is only for the select few now who muddle through the mire of complex programming languages ?
Now some may say that I am an oldtimer out of touch with todays technology and maybe that is so. But I do wonder about something. If code is so complex today then how do you debug it ? The easier it is to read code and to follow its flow, the easier it is to debug it. I don’t do any unit testing (I just run my software and manually test its functionality as needed), don’t using any built in debuggers, don’t use any automated debugging tools. About all I use is a few well placed messageboxs when needed (which will be removed later) and a popup debug window I wrote in my GUI engine where I can just print to it from code when I want a separate window to display something, outside of the app itself. Beyond that I do not require any debugging tools at all.
While the likes of Visual Studio require a couple gigabyte of disk space to install, my entire development system (when using my gui engine) only tales up about 20 megabytes of disk space. Now of course when I am coding my GUI framework, I need to have access to the Windows API documentation which for Windows 7 is 461 megabytes. But the size is not from my development tools, but from the complexity of the WIN32 documentation. But the WIN32 is the low level stuff right ? It represents the entire opertaing system, so 461 megabytes is not so bad. But surely when doing high level programming to just write an application, one is shield from all of the complexity of the operating system, so why can’t they make programming languages to day that even come close to the small size of classic Visual Basic ? For me, even Visual Basic is a bit bloated in size, but by todays standards the old Visual Basic was a lean development system which allowed to write applications in record time. Where is the Visual Basic of today (and I don’t mean VN dot.net) ? If in the 1990′s they could create Visual Basic, which allowed many a hobby programmer to go professional and make a living off it, where is the Visual Basic language of today ?
I think it is a valid question. I would think that 14 years of WIN32 development would qualify me as an experienced programmer, rather than a novice. How many programmers today can write a complete application say in just C using the WIN32 ? Probably not many. But if I find the lastest Visual Studio to be overwhelming and far too complex, then maybe I have a point. What has happened to programming today ?
Now for those are visiting here for the first time, you may be wondering, who is this guy and does he even know how to write software ? Valid question.
But consider this: My company built a GUI framework which is about one megabyte in size. It is a couple of simple DLL.s with no COM, no need to be registered with the operating system and is truly portable (meaning you just copy and run, even from a jump drive or sky drive). In that GUI framework, not only does is support all the standard native controls in the WIN32 , most of the common controls, most of the common dialogs, but it also has an event engine, a low level subclassing engine, a superclassing engine and even a thread engine. It has its own print engine for printing to the printers and a graphic engines for drawing on the screen. But there is more. It has a number of custom controls which I wrote from scratch, such as a Canvas control (with graphic command set and a 2D proprietary sprite engine built in), a masked edit control, an MCI control for multimedia, a shape/hotspot/splitterbar control (all in one), a Files listbox control and property listbox control. But there is more. It was designed for multi-monitor support, drawing with theme support, supports tray icons. But there is more. It has a OpenGL based 3D graphic control which has all the features of my canvas control with an opengl layer built on top. It has a 3d scripting language for working with 3D models and it supports the STL model format for displaying high polygon count 3D models in amazing speed. And lastly, it is a WYSIWYG drag and drop engine built in for building Visual Designers.
And all of this in about one megabyte of disk space.
So is anyone using this GUI framework in the real world ?
How about Fathom Systems in the UK (see: http://www.fathomsystems.co.uk/ ) One of their customers is Chevron. Watch this video about a project Chevron is working on:
Pause the video at about 4 minutes and 33 seconds and notice the laptop computer with the control software for their device. That software was written by Fathom Systems using Powerbasic and it uses my GUI framework. So yes, my GUI framework has found itself being used as the backend of some industry software.
Another example is Clearcom’s wireless belt pack hardware system comes with its TDesk software was also written using Powerbasic and it also uses my GUI engine in the backend.
So yes my GUI framework is finding its way into some key industries. Why do my customers use it ? Because it is easy to use.Why did I write it ? Because I wanted my own inhouse tool to make programming for Windows easier. So less complexity is software development is possible, so why is that not the gola of more companies who create development tools. My tools are not the only one which does this, but simply demonstrates the coding need not be complex to do complex tasks. Maybe someone out there will take this idea and run with it and create the next generation classic style Visual Basic.If you do, I will buy it ! Classic Visual Basic demonstrated that programming need not be complex. Tool developers like myself today also demonstrate the coding need not be complex. So why aren’t more companies picking up on the “it can be easy and powerful too” goal ? A valid question I pose to my peers.
So do you have an idea for the next great programming language which has the goal of powerful yet easy to use ?
Want to learn more about EZGUI 5.0 Professional, check out the rest of my web site at http://cwsof.com