Saturday, 19 of April of 2014

Tag » Windows

Software development is simply too complex !

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 “”                          ‘ Load EZGUI Include file
‘ ——————–

GLOBAL hMenu1&
GLOBAL hSubMenu1&
GLOBAL hSubMenu2&
GLOBAL hSubMenu3&
GLOBAL hSubMenu4&
GLOBAL hSubMenu5&
GLOBAL hSubMenu6&
‘ ——————–
$INCLUDE “”                          ‘ EZGUI Include file for WinMain
‘ ——————–

SUB EZ_Main(VerNum&)
    hMenu1&=EZ_DefMainMenu( 900, “&File”, “”)
    EZ_Form “Main”, “”, “This is a test of the Toolbar Control”, 0,0, 70,25,”C”

SUB EZ_DesignWindow(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&)
            CASE %EZ_Window
            CASE 906
               EZ_UnloadForm “Main”
            CASE 101 TO 115
               IF CMsg&=%EZ_Click THEN
                  EZ_MsgBox “Main”, “You clicked Toolbar Button #”+STR$(CID&-100), “Toolbar Message”, “OK”
               END IF
               IF CMsg&=%EZ_ToolTip THEN
                  EZ_SetToolTip “This is Button #”+STR$(CID&-100)
               END IF
            CASE ELSE
        END SELECT
    CASE “PAGE1″
            CASE 101 TO 112
               IF CMsg&=%EZ_ToolTip THEN
                  EZ_SetToolTip “This is View Button #”+STR$(CID&-100)
               END IF
            CASE ELSE
        END SELECT
            CASE 101 TO 112
               IF CMsg&=%EZ_ToolTip THEN SetTips1(CID&-100)
            CASE ELSE
        END SELECT
            CASE 201 TO 215
               IF CMsg&=%EZ_ToolTip THEN SetTips2(CID&-200)
            CASE ELSE
        END SELECT

SUB SetTips1(N&)
    LOCAL D$
       CASE 1
       CASE 2
       CASE 3
       CASE 4
       CASE 5
       CASE 6
          D$=”Progress Bar”
       CASE 7
          D$=”Tab Control”
       CASE ELSE
    EZ_SetToolTip D$

SUB SetTips2(N&)
    LOCAL D$
       CASE 1
       CASE 2
       CASE 3
       CASE 4
       CASE 5
       CASE 6
       CASE 7
       CASE 8
       CASE 9
       CASE 10
       CASE 11
       CASE 12
       CASE 13
       CASE 14
       CASE 15
       CASE ELSE
    EZ_SetToolTip D$

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”
            END IF

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 ? 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: ) 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 ?

If so, tell me about it. I would like to hear form you or

Want to learn more about EZGUI 5.0 Professional, check out the rest of my web site at




Comments Off

Windows is about work !

Despite being a programmer, I am not your typical mobile device user. I don’t have a smart phone, but instead share a cheap Tracfone with my wife simply for emergencies (really useful when your car breaks down on the highway). I now have two Android tablets, but simply purchased them so I have the option of getting into Android App development. I don’t really use them much right now. Got a great deal on a Nook HD for only $68, so it was not a big investment. I definitely am not going to be buying a $200 or $300 Android (or iPad) any time soon. Just don’t have any value to me.

Now I did invest a good bit on my ExoPC Windows tablet and in the future I hope to maybe get one of the 8 inch Windows tablets, now that Intel seems to have gotten it right with the latest generation of Atom SOC’s (system on a chip). So why would I invest in Windows tablets, where as I wouldn’t for an Android tablet ?

Computers for me have been mostly about work.

I started programming in the late 1980′s, early 1990′s, and some of my first work was for local businesses writing custom software. I was writing software before DOS and IBM PC’s became the fashion. Some of my first applications for businesses were written for CPM machines. When the IBM PC became the industry standard, computers were very, very expensive. It was nothing to spend 2 to 3 thousand dollars on a PC and they didn’t come with much power (can anyone say “640 KB Ram”). Computers were not for consumers. True some hobby computers existed back them like the Commodore 64, TI-99/4A, Atari, etc. But even they were in the $500 range initially (not cheap for what you got compared to a PC). Home computers were almost affordable, but by the time you started adding all the extra devices (ie. monitor, disk drive, expansion devices) it would start to add up. So for me computers were all about work, not play.

Windows computers eventually became mainstream and even consumers began to buy them. First it was people who used them at work and then wanted one at home. Finally most people began to buy computers when they became so cheap. Today you can buy a decent computer for about $300 and that is affordable. At some point the PC became a consumer device, even though the average user only used a small portion of what it was capable of. But when low cost tablets came along, particularly Android, consumers shifted from the PC to cheap tablets. Tablets were smaller, portable, but still allowed them to play games and do email and browse the web. So what about the PC ?

PC’s are for work and that is where they shine.

Attempting to try to turn the PC into a consumer device really isn’t the best course for PC’s, in my opinion. Let consumers have their cheap tablets. People who need to do real work will likely still need PC’s. For one, touch typing will never come close to what can be done with a keyboard. Personally, I am so picky about keyboards that I still use an almost 30 year old IBM Model M keyboard with my modern PC. Why ? Because I type fast when I code and the mushy cheap keyboards which come with most computers today won’t suffice. I need the feel of a real keyboard like my good old Model M. Touch can never replace the mouse. Trust me when I say that there is more to a mouse than meets the eye. Not only is touch not as detailed and accurate, but touch by its nature works very differently than a mouse (for examine a mouse can move the cursor but not have to register a click or touch event) and touch has some downsides. A mouse can make the cursor hover, touch can not. Touch for text is counter productive because you have to steal some real estate from the screen for the touch keyboard. Touch typing is slow at best. This is why so many tablet users struggle with finding a decent external keyboard for their tablets, so they wrap up their tablet in some kind of carry case shield embeded with a bluetooth keyboard. So the price of the tablet now includes a case and a keyboard. So why didn’t they get a laptop instead ? Oh, everybody has a tablet today and laptops are not “cool”. Personally I like my wifes little Netbook. Very light, but still a computer with a keyboard. Even when a bought a Windows 8 laptop (15 inch) I opted for a Lenovo (who bought out IBM PC business) because it got great reviews for the keyboard. Laptop keyboards are often poorly designed and have a poor feel compared to a quality desktop keyboard. The Lenovo keyboard has a real nice feel to it and with a 15 inch laptop the keyboard is of decent size too.

PC’s were originally designed for business and now with consumers all flocking to tablets, maybe business is where PC makers should concentrate on. Even with Windows 8 this should be a consideration. The Windows Store (aka. Metro) side of Windows 8 does make sense for tablets to some degree, but Windows machines are for business and even when it comes to Windows tablets this should be kept in mind. The Windows desktop was designed for more choices, not less. It is an “open book” rather than a “sandbox”. This is what business needs. Windows Store apps weren’t needed for Windows to be successful on tablets, at least for businesses. Developers simply needed to learn how to write small, high performance, touch friendly apps for the desktop. A forced look and feel, like what we see with WINRT apps, is not what businesses need. They need more choices, not less. One thing I learned from years of custom programming for businesses, was that software needed to be designed for the needs of the end user (business customer), not for the needs of the programmer or the operating system.

Dynamic software needed.

In the old days, programmers were always looking for ways to push the limits of the hardware. In the days of the Commodore 64, some really talented programmers created an operating system called Geos, which turned the Commodore 64 in a Mac like computer. The Commodore 64 only had 64 KB ram, part of which was for the screen  and the CPU was only 1 mhz (that is megahertz, not gigahertz for you young people). Most programmers today likely couldn’t even imagine how a Mac like operating system could be written for hardware like that. Programmers understood that the job of software was to push the limits of hardware, rather than be limited by it.

Modern Windows tablets are no different. The possibilities are almost endless. But instead of being forced into a sandboxed environment with look alike apps (at least the non-games), developers need to be allowed to push the limits of the hardware. They need to have complete control of what they display on the screen and how they build user interfaces. To be able to build powerful business apps which can push the limits of the tablet, they need to be able to build apps which perform at the fast speed possible (meaning native coding rather than slow scripting languages or bloated dot net) and to be able to design unique user interfaces which are totally different. User interfaces need to be smart, dynamic, changing based on their need. Apps should be able to be smart and know the difference between whether it is running on a tablet of running on a PC and reshape themselves accordingly. Rather than all aps working exactly the same, developers need to be able to experiment with new and unique interfaces.

One thing I learned a long time ago was that a user interface need not work just like the other guys apps to be easy to use. Ease of use has more to do with how natural and intuitive the user interface is and that has a lot to do with how creative the developer is in trying to satisfy the needs of their end users. Businesses can afford a slight learning curve to learn a new app, especially once they get use to it they are more productive than before.  I use to write custom apps in the DOS days and each new app I wrote often totally different than the last one. I would write the apps with the end user in mind. One common method I used was to ask the client, how do you do this task now on paper ? Often I would emulate what they do on paper, so when the employees started using the software they saw something they recognized. The learning curve was easy, even for a 60 year old lady who never used a computer before. Why ? Because the software was not designed with some kind of fixed user interface rules. It was designed for the end user and their needs.

But today with so much more complexity in the hardware and software, developers need to make their software smarter, more dynamic. In appreciated this when developing a demo apps for the Intel App Innovations contest. I was writing an app for a large all in one PC with touch. I found that some of the controls which worked well with the mouse were a bit unwieldy with touch. This required changing the size of common UI elements. Fortunately, I used ownerdraw for some of the user input controls. I was able to customize the controls to change their look and feel and the size of each element. But as I created the app, what seemed common sense at first, brought with it other issues. For example as I made UI elements larger, I quickly lost screen real estate. To solve this problem I then build slide in windows (rather than popups) which could be slide into view with more controls on them. But this raised issues with parts of the main window which now got covered. So I added alphablending to one slide in window, so one could still work with it and see what was behind it. I found that the more I worked on the app, the more I found myself customizing this and customizing that. Rather than force the user interface into some kind of fixed mould, I would customize it in what ever seemed useful, even if no other software did it the same way. I spent so much time doing this, I didn’t get to finish the app to the degree I would have liked for the contest, but I learned an important lesson. Developers simply need to take the time to build their apps so they are more dynamic, more customized to the need of the task at hand rather than simply be a clone of the last apps user interface. Customization is the key.

Windows tablets have a big potential in the business market and with prices dropping, hardware getting better and sizes getting smaller and more portable. But developers don’t need more UI rules, but less. They don’t need a fixed sandbox, but a rich environment to do different things. Just like in the old days when programmers had to be more creative to push the limits of the hardware, so to today developers need more ways to build better software, with more creativity, more customization and with less overhead.

It is possible

I learned an interesting lesson from the Intel contest. For nearly fourteen years I have been developing tools for programmers. My EZGUI user interface engine was designed for such customization as I speak about. While most of my customers only have used a small portion of the feature set in my tools, I was grateful to have them when I was building my app for the all in one PC. I finally realized why I put so many low level features in my software tools. My experience from the past in finding ways to push hardware to its limits had affected my attitude towards developing programmer tools. I build features into EZGUI, even knowing that most of my customers might now use them. It turns out, I built them for me. I built them so I would have the power features I needed. For years I have tried to explain to potential customers why customization features are so important. Now with Windows tablets take hold, customization is more important than ever. If ones user interface doesn’t work then change it, customize, create something totally new if you have to. Just don’t feel your app must look and feel like everyone elses. Don’t feel you have to follow some kind of fixed UI rules. Programmers need to design creatively. They need to build totally new user interfaces which are smarter, more dynamic. Have you ever taken a close look at nature and how different plants have different seeds ? Rather than all of them being carbon copies of each other, each one is unique to the specific needs of the plant. I use to wonder why bean tree in my yard had such long bean like seeds. I knew these type of trees tend to grow best near a lot of water, but mine was getting all of its water from an under ground stream so it wasn’t apparent how these trees grow in other places where they might be more common. These kind of trees grow well even in deep swamps. They love the water, but guess what happens when they drop their seedlings ? A normal seed would simply sink in the water and likely never grow. The bean like seeds of these trees are so long they can drop into shallow water or the mud and the stick upright with part of it above the water. The seed is perfect for shallow water around the trees or mud. Its unique design, though different, is perfect for its task.

So too with software. Business software needs to be designed for unique needs. Windows tablets for business require totally unique software, designed to be optimize for the task and the device. Rather than fixed UI rules, developers need to be creative instead. This is one reason I like native coding in Windows. The WIN32 has so many options for customizing user interfaces, the choices seem endless. As a WIN32 programmer I can build new controls from scratch if I have to. I can also customize existing controls to add new features and make them work differently. For example in my contest app demo I needed a customized listbox control which displayed 3D models. Each item had to be large so it was easy to touch them with the finger. The image of each model needed to be large enough so you can see what it really looks like. I had to actually copy images from the Files Listbox viewer part of the app when it displayed the 3D models using OpenGL, so I had to do screenshots directly from the desktop to get the images intially and then stored them in a bitmap array and then draw them dynamically in the custom listbox control. By using ownerdraw this was relatively easy. Since EZGUI supports all of these low features it was not too difficult to accomplish. Here is how the control looked in the app:












The point is that I build what I needed. If what I needed didn’t exist I created something new. Native Windows coding really lends itself to this kind of customization. The apps are fast and small, but also you have many choices for customization. Windows tablets offer many choices for developers who need to build business apps for the mobile world. The Windows Desktop still has many advantages to it. Windows for me is about building apps to do work, not play games. It is more about choices, not limitations. It is more about finding ways to push the hardware to new limits, rather than feeling limited and building apps which are all look alikes.

Comments Off

The possible Windows advantage or how to make Windows 9.x better !

While Windows is facing over consumerization because of mobile devices, there is one aspect of Windows which should not be overlooked. Windows is at the core of business computing. I started programming back in the day when a simple PC cost $2000 to $3000 and most software was quite expensive. Now we see low cost PC’s and mobile devices so cheap than consumers are dictating the market, rather the businesses. Personally I think it is time to recognize this and to concentrate on bringing Windows back to its original state, an operating system for businesses. Why ?

So if Microsoft wants to produce an operating system for consumers, fine, but Windows 9.x really needs to be the operating system for businesses. Windows 8.1 is the operating system for consumers, but 9.x needs to remember its roots. This means more than simply something trivial like the old fashioned start menu. It means the core of Windows and how software is developed.

Consumer mobile devices, some even with free operating systems, are causing software to be turned into cheap or free apps, with low profit margins. It costs money to develop software and even more to develop good software. Businesses though don’t need cheap apps. They need quality software, which does the job intended for it. While businesses can ill afford having to keep updating their computers every few years and worse buy new software, surely they are willing to pay to keep what they have running well and to be well maintained. Why ?

There is more to the bottom line for a business than simply cheap software. Businesses want something that works, works well and lasts so they don’t have to keep reinventing how they do their work. The time it takes to retrain employees on how to do their job (using computers) costs money and once something works, you know the old saying “if it isn’t broken, don’t fix it”. Computers today often do some serious work and even some lives may depend upon it, so businesses need reliable software, so forcing the software industry to keep “reinventing the wheel” every few years, is a big mistake, a very big mistake. Why can I say this ?

The lessons from being a custom software developer

When I started programming in the late 1980′s and early 1990′s, I wrote custom software for local businesses. I have written software for local “mom and pop” operations (ie. video rental stores) to large corporations and manufacturers. I have written accounting software, manufacturing job tracking software, engineering software and quality control software. I recognized how expensive it was for a business to pay me to write custom software (even though I charged very low prices compared to my peers). I did something as a software developer that likely very few if any developers would ever consider doing today.  I built the software they wanted at my own expense and when finished, they only paid me if they liked it and wanted to keep it. If they didn’t like it, I simply took the software back and they paid nothing. I never had one customer not want to pay me for the software. Why ? Because it did the job they required so well, that they literally had to have it.

Now the software I wrote, was a big investment up front for my customers. But I was planning on longevity of the software. If they only used the software for one or two years then it may not have been a good deal for them. But if they used it for many years, then it was a very good deal.  My job was to help them maintain the software so it could grow with their needs. For example, one early customer had an application I wrote which they literally depended upon. It was written first in GWBasic, then later ported to QuickBasic 4.1 (so translation not too difficult) and when DOS went out of fashion, they used the DOS app for a few years until it was necessary to port the app to 16 bit Windows. I did this using Visual Basic, but instead of rewriting the app so it looked totally different, I did some tricks to make it emulate the old DOS app in look and feel, but with a few new Windows like features added. It was not a console app, but a real GUI app, but it worked so closely to what they had been using with the DOS app, that retraining was almost nill for the customer. I later created a 32 bit version of the app using Visual Basic.

Amazingly, the customer is still using this app today and he has commented to me that it works better than anything else on the market for his needs. So my app, while going through some changes over time, has lasted a significantly long time and that has made it a good investment for my customer.

One of the things I appreciate most about Windows is the decent backward compatibility is has. I understand that some things simply must change, but backward compatibility allows end users to make the choice of whether they want to stick with something that works or not.

The change to a tool developer

For nearly fourteen years now I have moved away from end user software to being a developer of tools for programmers. I built a commercial product (a GUI engine) for use with the PowerBasic compiler. So why BASIC ? Because many programmers have a long, long history with Basic, like myself. Much of the code they wrote 10, 15 or even 20 years ago still works, with little translation needed. Some of my best customers actually came from a DOS Basic programming background and they found it hard to make the transition to Windows. I designed my early tools to make it easier to make the transition from DOS to 32 bit Windows. I also made sure my customers had features which would be easily learned, knowing their background.

I also did something probably underheard of by most programmers. When my first generation of GUI tools were designed, Windows ME/2000 was the current Windows platform and in short order soon Windows XP became the primary Windows platform. Now I had a Windows ME and later and XP computer, but instead of developing on them, I chose to pull out an old PC with Windows 95 on it and it was my core development system for many years. Why would I develop on Windows 95, when most programmers were using the latest Windows XP ? I used a reversed system of development. I developed on the older platform, but tested on the more current. It allows me to see how well the software worked on the older platform. It allows me to test in real time how to leverage a newer platform, while maintaining backward compatibility on an older one. Because backward compatibility require calling WIN32 API’s at times dynamically (load a DLL using LoadLibrary and then get the address of a procedure if available and call it via pointer), it taught me a lot of how to overcome the differences between Windows platforms. The amazing thing though was that I was surprised to see how much of the WIN32 API remained unchanged over many different versions of Windows. Some of my best code used core API’s which have existed since Windows 95 and have remained unchanged even in Windows 8.0.

By developing my software this way, I guaranteed to my customers (who were software developers themselves) that the software they write will run on a wider range of Windows PC’s. This was very important since their customer base often needed this. Today, my core development PC is a Vista Home Basic PC, which I upgraded to 2 gigabytes memory and a slightly newer dual core CPU. I have Windows XP, Windows 7 and Windows 8.1 PC’s as well, but they are not my primary development systems. As computers become more powerful, I still though concentrate on backward compatibility and low system resource requirements. I have even for fun tried testing some of my software on a very, very old Windows 95 laptop and it worked better than I expected (I wasn’t expecting it would work at all, but it did, albeit very slowly). I even have some customers who prefer to use Linux with Wine and my tools have shown themselevs quite compatible with Wine.

So what does it all have to do with Windows 9.x ?

Backward compatibility has been one of Windows key secrets. Please read this article by Joel Spolsky ( ) and you will better appreciate how much effort Microsoft put into backward compatibility. True they have broken to some degree with this concept in recent years, but if Microsoft would like to see the next version of Windows get praises from the business world, then they should seriously consider this path. So how could they do this ?

Go back and add new features to the core WIN32 API, but in a way that developers need not learn something new to use them. For example, the core system controls (ie. treeview, listview, listbox) should be reworked so they better support touch when it is available. Go back and rework any programming technologies which are still being used to develop software for businesses and make them available to developers ar reasonable prices. This will better allow longer maintainance of key business software. For example, bring back classic Visual Basic and improve it. It could be done and it could bring in a new generation of Basic programmers. Make classic visual basic theme ready and add better support for low level access to the operating system. Things like adding threads or subclassing to a VB app should be built into the language. Add native support for ownerdraw to Visual Basic.

But what about object oriented programming ? It will still be there for current programmers, but there is mounting evidence the OOP is not the panacea it has been touted to be. If you find this statement hard to believe, read my article about it ( )

There are thousands, if not millions, of programmers who are still trying to maintain quality software using older technologies, which is vital for many businesses. There are many programmers who have spent a great deal of time learning technologies, like Silverlight ( ), MFC, WPF, ATL. Microsoft needs to make Windows 9.x more friendly to not only newer versions of these technologies, but even older ones. This will make moving older software to the next version of Windows easier. Why should a business stick with Windows XP, if Windows 9.0 handles Windows XP better than Windows XP does, without the need for virtualization. If Microsoft could make Windows 9.x a better XP than even the original XP, then they would have something there.

Imagine a new version of Windows, where Microsoft could say, not many new features, but it runs your XP apps better than APP with more choices and is more reliable and more stable than XP !

Imagine Microsoft telling its business customers that their legacy software is still important to them and that Windows 9.x simply makes it better, rather than break it.

Is this really possible ?

Absolutely ! You see, I have been advanced WIN32 programmers for nearly 14 years now and know what the operating really can do and how it is very possible to make software (even an operating system) more dynamic and intelligent. True it would require some core changes to the operating system, but Windows was designed for such customization. I have found so many ways in the WIN32 to customize Windows apps and to build more dynamic apps. Much of it has been there since Windows 95, amazingly.

While consumers may be willing to waste money and buy the latest technology (and throw away the old) every few years, businesses are more rational and desire more longevity of their software. Even if Microsoft has to break off the consumer version of Windows from a business version, by concentrating on the needs of business and the importance of backward compatibility, then Windows 9.x could be a real success. Remember, that with very new piece of software or new technology, it also comes with its own share of bugs. Why not go back and make the existing core of Windows, simply better, more stable and more reliable.

Also, here is a little secret. In the era of mobile devices, there is a little secret which some may not have shared with you. Us old timers fully appreciate why a scripting language simply can never compare to a native language. The closer a programming language is to the operating system and the hardware, the better the performance.  Watch this video on Channel 9 of a talk by a Microsoft C++ expert, Herb Sutter ( ) as he discusses the power of native coding. It doesn’t matter what languages you current use to appreciate this talk. I am a BASIC programmer, but I enjoyed it a great deal. Despite the compiler I use being BASIC, it is more akin to C (not C++) in nature. it is very low level. Yes, I work with things like threads, pointers, subclassing, superclassing, writing custom controls, etc, just like some C programmers. The video discusses why native coding is so important.

Native coders, especially on Windows, can produce applications which require minimal resources and are fast. The Windows operating system is a rich environment, with so much untapped power, it would likely surprise you. Microsoft kept changing technologies so fast, that few programmers likely have had the time to see much they could push the limits of the operating system. Just when classic Visual Basic programmers were learning how to tap into these deep resources (there were a lot of books about using the WIN32 API from Visual Basic), then the language came to an abrupt death. My biggest complaint about Visual Basic was that  there were a lot of things I wanted to do with it, it was not designed for. But after spend nearly a decade and a half learning how to tap into the Windows API, I better realize how mucy untapped power there is in Windows.

Now many programmers today likely don’t think highly of classic Visual Basic programmers, but one thing you have to say about them. They were an energetic bunch, always looking for ways to push their favorite language to the limits. Many a hobby programmer used Visual Basic to make the jump to professional programmer and likely did things wity Visual Basic, that even Microsoft did not expect. I get the impression that Microsoft never viewed classic Visual Basic as a professional language, which may explain why they so easily gave it up. But to their surprise, it was used to write some very important business software, some of which is likely still be used today.

A good programmer is not one who constantly wants to throw away their favorite languages, just for the sake of the latest technology. A good programmer is one who used his experience to find ways to push his favorite language to the maximum. It takes time to gain experience and if every few years new technology makes what we have obsolete, then we will have less experienced programmers. Remember the old saying, “better to be the master of one trade than to be a jack of all trades, but master of none”. The same applies to programming.

So if I had one desire as a programmer, it would a new version of Windows (and developer tools) which was based on this concept. If Windows 9.x were to take this course, I would venture to say that businesses would not leave Windows for a very long time.





Comments Off