Monday, 28 of July of 2014

Tag » Windows

Windows tablets, smaller, faster and affordable !

I have been watching the directions that Windows mobile devices have been taking in recent years. I know it seems it is all about Android and IOS today when it comes to tablets, but something amazing is happening with Windows and maybe it is time for businesses to take notice.

For a number of years I wrote custom software for businesses, from accounts payables/receivables to quality control in manufacturing. One of my goals during those years was to make businesses more productive, yet at an affordable price. Computer hardware and software cost money and it only made sense for a business to invest in them if it had a valuable payback.

In recent years I have watched the direction Windows has taken in the mobile area and I think finally things are starting to fall into place. The first thing that caught my attention was what Intel was doing with the Atom line of SOC’s (system on a chip). Many programmers sad to say likely laughed at the Atom CPU. Why ? Because much of todays software is written in a way which makes it bloated and slow, requiring too powerful of hardware. This did not phase me personally, because for the last decade and a half I have been a WIN32 programmer, learning how to tap into the native Windows API. By using the Powerbasic compiler (a BASIC language, native code compiler) I found that I could build programming libraries and tools which could run on very minimal hardware. While the typical programmer today likely is coding on a PC with the latest ICore CPU with a huge amount of memory, I have been able to code on what most would consider a legacy PC (first Windows 95, then XP and current Vista) years behind the current models. Why would I do that ? Because if I could write software for an older PC with less power, image what it could do on the latest PC’s. So for me, as a WIN32 programmer, a Windows computer (or tablet) with only a 1 ghz CPU (or even less), less than 1 Gigabytes of memory and a minimal disk drive space is still a power house of a computer to develop for. My entire development system (PowerBasic compiler and my own proprietary GUI framework written using only the WIN32) only requires about 20 megabytes of disk space to install. Yes, you read that right ! I said 20 megabytes. While many development tools today require a a gigabyte of disk space or more, yes a native coder can code in less than a 100 or 200 megabytes of disk space. Even a decent C (not C++) compiler used for native coding can be installed within a minimal amount of disk space. Now the executables, a native coder can create, can require even a lot less hardware resources.

So previous generations of the Atom were already very inviting to a native coder like myself. But Intel has out done itself in its latest BayTrail generation of the Atom SOC. For a native coder it is a powerful platform to develop for.

Intel’s Atom SOC’s have made possible the latest generation of low cost Windows (real Windows and not just WINRT) tablets in the 7 and 8 inch display range. I just recently saw the Dell Venure 8 Pro for only $229 on the Microsoft Store. Very reasonably priced and worth considering by a business.

Today, things just got very exciting with the news that Microsoft is planning on cutting the cost of Windows (to the OEMs) on low cost devices below $250 and discounting it an amazing 70% off. This means Windows could cost as little as $15 for such tablets !

See:  http://windowsitpro.com/paul-thurrotts-wininfo/report-microsoft-drop-windows-licensing-fees-low-end-devices

All I can say is, now this is amazing !

Now this is where things can get interesting. Intel has gotten it right with the Atom SOC. Microsoft has gotten it right with Windows 8.1 and now the lost cost version for only $15. The last ingredient needed to put it altogether it to start teaching programmers how to be native coders again. Oh, I know, many may assume that it is all about Metro (Windows Store Apps). Yes, the WINRT apps have a benefit for consumers. But the real power in Windows is on the desktop and in native coding (WIN32). Why ? Because one can build applications with excellent performance which require minimal hardware. I am convinced that this is not only possible, but also very viable.

By putting all of this together, it is quite possible to see Windows (“real”) tablets in the $200 range or even lower capable of running amazingly powerful software. I would like to see it possible to get some Windows tablets as low as $100 and with the speed of technology improvements we see today, this could be a real possiblity. Now that would make Windows tablets truly a viable platform for business mobile needs.

Find it hard to believe that one could build powerful software for such possible future low cost Windows tablets ?

Check out my demo app I was working on the Intel App Innovation contest and download it and install it.

http://cwsof.com/forums/index.php?topic=921.0

The app is not finished yet, but it does demonstrate some powerful user interface features and the size of the application is tiny by todays standards. Even the applications EXE files size is mostly because of embedded bitmap images and not code.  The application is native code software (the EXE uses a GUI framework written using native WIN32 code).

Yes, by writing applications using the native WIN32 API, programmers can be able to build very powerful, high performing programs cable of getting the maximum out of the coming low cost Windows 8 tablets. Windows has the potential of becoming a powerful solution for businesses when it comes to mobile devices.


Comments Off

Smaller, Faster, with Windows programming

With mobile computing taking hold, programmers are looking for ways to produce smaller and faster applications. Soon with the so called “Internet of Things” concept bringing possibly even smaller mobile devices into all areas of life, the need for smaller and faster software capable of running on tiny mobile devices may bring even greater challenges. Developers of Windows software may wonder, is it possible to write such software for the Windows platform ? Are there any secrets to how this can be done ?

You are likely not going to like it !

Programmers often like to tell other programmers that they should be willing to learn new technologies if they want to be able to build better software. If that would work, fine, but sadly it hasn’t produced the kind of software we are really looking for. Why not ? Because much of our coding styles have revolved around building desktop software using faster and faster hardware. Each year, better CPU’s, more memory and faster GPU’s have allowed programmers to tolerate development methods which, while producing some very good software, also has pushed up hardware requirements for such software. What we really need today are some well trained programmers who know how to squeeze every cycle out of a CPU, know how develop software which can run on minimal hardware (less powerful CPU and less memory) and know how to write software so that it uses less disk space (SSD’s are small on moble devices). But where can you find such programmers ?

Well, let me first say, you won’t like it when I tell you. The truth though is that such programmers do exist, but they are not what you would have expected. They also are becoming more and more rare. So where are they ?

I told you, you would not like it !

Actually, such programmers have been around for a long time, but the mainstream development community tends to shun them for a variety of reasons, but mostly because they are considered old fashioned and out of touch. But are they really out of touch or do they know something that others may find hard to accept ? So before I discuss these unique programmers, consider this illustration. Which would you prefer to work on your motorcycle, an experienced car mechanic or an experienced motorcyle mechanic ? The answer is obvious. Why ? Because while a car and a motorcycle have many things in common, motorcycles are designed differently and you would want someone who understands the complexities of working on a much smaller driving machine. Now in the world of mobile devices, rather than “cars” (the desktop PC), many prefer the smaller “motorcycle” (the tablet and smaller devices) and this introduces new challenges.

When programming was really difficult

Youthful programmers may not appreciate this, but for any who have been around awhile you may appreciate what it was like back on the 1970′s and 1980′s in the programming world. The challenges seemed insurmountable. I can remember learning how to program a Commodore 64 home computer, with only 64 kilobytes of memory. To be able to do anything significant with the computer, one had to learn to how to make every CPU cycle count, learn how to manipulate the hardware to do things beyond what the hardware was designed for and learn how to work with minimal resources such as memory and disk space.  In my own case,  I also learned this when I decided write a family friendly video game for the Commodore 64. Interpreted Basic was definitely not going to work. I had already started using a real compiler on the Commodore, a Basic language compiler by Abacus, but even that was not fast enough, so I found myself using the Abacus compiler to write my own compiler, which I ultimately used to write the game. In essence I was doing what ever I could to squeeze out every bit of power out of every CPU cycle. I sold that game and it was published in the October 1987 issue of the Compute Gazette magazine. It earned me nearly $1500 for just a couple weeks work.

The Commodore computer had ony a 1 megahertz CPU and 64 kilobytes of memory. How many programmers today could work with such limitations ? But the things done in those early years on such minimal hardware were amazing. For example a group of programmers created an operating system for the Commodore 64 called Geos, which was quite amazing for the limitations of the hardware.  With the new, so called, “Internet of Things” on the horizon, surely we could benefit from programmers like this who know how to create amazing software which will run on minimal hardware. Actually, this is the point of this article.

Learning how to code software in the old days produced a mindset which some of these programmers, still around today, find hard to give up and maybe they shouldn’t. Is it really so bad a thing that a programmer wants to build fast running software which requires minimal hardware ? Actually, it is a very important consideration today ! Watch Herb Sutters talk, entitled “Why C++ ?” and I think you will appreciate what I mean. He discusses how important it is to develop faster , high performance,  software and how getting away from managed languages and using C++ for development can accomplish this. But I would like to go much farther than Herb Sutter, in this article.

I warned you, you really are not going to like this !

If I had little experience in programming then maybe what I am about to say would have little value. But that is not the case. I started doing custom programming for local businesses back in the early 1990′s. My first work was on CPM computers and then when the IBM compatible (and DOS) became popular, I started writing software for that. I wrote software which did real work in real businesses, from local Mom and Pop operations to large manufacturers. I wrote software for accounting, point of sale, engineering, quality control, job tracking and estimating. Some of the DOS software I wrote is still in use today. For the last decade and a half I have been developing tools and libraries for programmers which have become the backend of some important commercial software. The likes of Chevron, Disney and even some popular TV shows have been using software which was written using my tools and my libraries. One example should suffice here to demonstrate this.  Fathom Systems, in the UK, develop control devices used in the commercial diving, ROV and underwater engineering industries. They designer software for their equipment too and that software was written using Powerbasic and my own GUI tools. They sent me the link to the following video of a large project by Chevron, which uses their equipment and to run their equipment, software written using my own GUI engine. Watch the video and at about 4 minutes and 33 seconds into the video, pause it and notice the laptop which is controlling some of the equipment. The software doing this, was developed using my companies GUI tools. So, I do have some experience in writing real software and tools which have been used to write software which is being used by some very large companies.

Chevron Deepwater Pipeline project (video)

Now with that behind me, I continue. So what I am about to discuss next is not only possible, but actually practical for developing software for todays smaller mobile devices, particularly the Windows Desktop on x86 base systems. What can one learn from old time programming experience ?

Native coding

The first thing is that nothing compares to native coding for an operating system, especially Windows. Of one wants optimal performance, native coding definitely can produce very small applications which require minimal hardware. For Windows, this does not mean developing using DOT NET or even the WINRT, but means developing for the low level WIN32 API. My first Windows 95 computer (I upgraded from 16 bit Windows on that computer) only had 8 megabytes of memory, if I remember correctly. How could Windows back then run on so little memory ? Because of the design of the operating system itself. Windows was based on a flat API (not object oriented)  and amazingly that core API still exists in Windows and is a core part of what makes it run today. While a bit terse at first to learn how to code for it, once a programmer masters it, it provides a huge feature set for producing some very powerful software. This style of coding has grown out fashion, possibly because it was difficult to master. Microsoft later came out with tools to make it easier, like MFC (Microsoft Foundation Classes), ATL, etc. Later managed languages literally took over Windows development.

So what does an old timer programmer like myself think of the two styles of programming, managed languages compared to native coding using the WIN32 API ? I was actually put into a situation where I gained a unique perspective on this, few programmers may have. When I moved to Windows programming I was using Visual Basic (classic). I had versions 1.0, 2.0 and later 5.0 professional. Visual Basic was a masterpiece when it comes to fast software development. Visual Basic, despite its amazing speed for designing the front end of software, also lacked in areas where I needed a bit more, so I left Visual Basic behind and then tried my hand at coding using Powerbasic (the closest thing as far as language syntax). Back then when I first started programming using PowerBasic, many programmers using it, used it as an addon to Visual basic for writing high performance DLLs. The language was capable of being used to write EXE’s too, but Powerbasic has no GUI command set at the time and so it was best suited for writing backend code (non-GUI) which is why it was marketed as an addon for Visual Basic. Develop your front end in Visual Basic, but use PowerBasic to write your number crunching code for the backend. But I wanted to be able to write a full blow application using PowerBasic alone. But Why ?

PowerBasic had two things Visual Basic lacked. One was that it was designed for better performance. It had many low level features which Visual Basic lacked such as pointers, very fast string engine with extensive command set, inline assembler and it was better suited for accessing the Windows API. Yes, Visual Basic programmers for years were extending Visual Basic by accessing the Windows API, but PowerBasic was designed specificly for this, so it was better suited. One nice example is how easy it was in Powerbasic to work with pointers, even code pointers. One could use the LoadLibrary API to load a DLL and then pool it for the address of an API function and then make a call to the function using the CALL DWORD command which is for calling a function using a pointer. PowerBasic also had a richer data type set, better suited for working with the Windows API.

So for a few years I was on a new adventure. I started to learn how to code using the native Windows API (WIN32). While some may laugh at the idea of using BASIC for any professional programming, what I was learning to do was more akin to learning how to code using pure C with the Windows API. Now mind you, I said C, not C++. Why ? Because working with the Windows API was more procedural in nature than object oriented, whether one did it in C or Powerbasic. To be able to learn how to work with the Windows API, I needed some kind of training and since there were literally no books available about using the Windows API with PowerBasic I had to use books written for C (not C++). Since coding with C using the Windows API went out of fashion in a short time after Windows became a 32 bit operating system, with Microsoft first pushing MFC and then later managed languages took over, when I would search out good books to read, I could only find used books from many years ago which I would look for on Amazon. I searched for the best books I could find on coding with C using the Windows API. I did find a few (the same was with OpenGL too). When I wanted to learn how to write custom controls, I could not find anything useful for 32 bit Windows and the only book I could find was for 16 bit Windows, but amazingly the techniques taught are still viable today even with Windows 8. So with an extensive library in hand, I proceeded to teach myself WIN32 programming. Fortunately, PowerBasic syntax is much easier to deal with than C, so coding the WIN32 with PowerBasic was much easier than coding using C, so maybe this is why it was possible to deal with it better. But learn I did.

What native coding has taught me!

What makes this story so interesting (at least for me) is what I learned from this effort to learn low level WIN32 coding. I have spent a decade and a half as a native coder and it is what one can accomplish with native coding that really amazes me. The Windows API (WIN32) is an amazing thing. It is actually very efficient and designed for performance. The many features designed in Windows for low level customization is just astounding to me. The DLL (dynamic link library) is ingenious. I work with things like writing custom control classes, threads, ownerdraw, customdraw, subclassing, superclassing, window hooks, custom dialog classes, DIBs (device independent bitmaps). But if the powerful features of the Windows API don’t excite a programmer, that maybe this will. Native coding allows a programmer to write software which will put most modern software to shame when it comes to performance and minimal hardware requirements. Native coding produces software which is so small, that it is simply amazing, really.

But there is more to this. Native coding is not object oriented ! Yes, native coding is more procedural in nature. True, later versions of Windows added a layer of new features using COM classes, but the majority of the WIN32 API is a flat API. Even when GDIplus was added, while Microsoft promoted using the C classes provided to work with it, they did create a flat API, which a few PowerBasic programmers were able to leverage so they could use much of the GDIplus using a more procedural style of coding and this benefited performance. Do you find this hard to believe ? Here is an example of how a native coder can leverage multiple graphic engines in Windows to work together and all in a tiny package using native coding.  ZapSolution, a french company, developed a number of excellent graphic libraries using native coding. One is a skin engine, for skinning Windows ( WinLift ) applications and the other is a graphic engine which allows you to combine the GDI, GDIplus and OpenGL together seamlessly ( GDImage ). But what you will find amazing about both of the libraries is not only the performance, but the amazingly the tine size of the libraries. They were originally written in PowerBasic, but the developer switched over to C and is porting them to C. The two languages are very similar when doing native coding. It is not whether the libraries were created in PowerBasic or C, which really matters, but the point that they were developing using native coding using a purely flat API using a procedural style of coding.

Native coding produces some of the smallest executables you likely will ever see and the performance is as good as it gets. About the only way I could see one get better performance would be to use native coding but use assembler instead. I doubt most programmers could handle that, working with both native coding and assembler, but amazingly there are some who have. One of my favorite examples and a very nice toolbar painting utility called ToolBar Paint . It was written using native coding and assembler its tiny size shows it. The app even supports plugins.

Procedural coding style improves upon Native coding

While everything today seems to be all about OOP (object oriented programming), few appreciate the power of good old procedural style coding. What makes native coding so powerful is that it also uses a more procedural style of coding which is easier to debug and which produces much smaller applications with less overhead. Actually, I have found the good old dynamic link library (DLL) to be far more efficient and less resource hungry than modern day components (COM based OCX, dot.net components). DLL’s can be very efficient and can do some amazing things. The so called problems some faced with DLLs can be easily overcome by some simple practices. For example, if I plan on a DLL being upgraded but the filename needs to be the same, I design it from the beginning to pass the application a version number so the application can know what version of the DLL it actually loaded. This way the app can compensate or even provide information to the user that a different version of the library was found than expected, in the rare case it does. Second, in the old days hard drive space was limited so often libraries like DLL’s were installed in the System folder (or System32) to decrease disk space usage. But today, disk drives are so huge that this is no longer an issue, so DLL’s can simply be installed in the same folder as the application, which prevents problems with version conflicts. Native coded DLLs are so small in size, that the extra space used even on tablets is insignificant. Lastly, the practice of writing an API using a prefix for all function calls, decreases the problems with name conflicts (which name spaces was designed to solve in the managed world). For example I developed a GUI engine (DLL’s) which has a command set of nearly 900 commands (subroutine and function calls) and in the entire API I use a prefix for every API and even the constants used in the include file (similar to a C header). I uses the first letters of the products name as the prefix, so every API call starts with EZ_ . Other library developers have found this useful, to use a common prefix for an API they create. While this won’t solve every possible conflict between libraries, it does decrease them significantly, so one need not use namespaces anymore, but simply one can use a flat API library. I should also point out that the use of DLL’s and native coding, can allow one to create transportable software, which only needs to be copied and run. Much of the software today can only be run if it is properly installed by an installer program which handles any registrations with the operating system. Most applications could not simply just be copied from drive to another and then expected to run. Transportable software is purely standalone software which does not require any access to the registry, has no components to register and can simply be copied and run. It can easily be installed onto a flash drive, micro SD card or even be copied and run from the cloud drive, like SkyDrive.

Smaller, Faster

Programmers are always looking for ways to developer smaller and faster software. Some compiler makers have even considered that smaller and faster should be a major goal of their programming languages. Old time programmers know what it means to be able to build smaller and faster software. They had little choice when computers had so little power and memory. But today, programmers can benefit from that experience. Find that old time C programmer working in a corner somewhere in your shop and ask him (or her) how you can learn to build small, faster software. Maybe you might even have native windows coder in your shop or company somewhere. Surely they can teach todays programmers a thing or two about building smaller, faster software.  So with the coming “Internet of Things” are you looking for ways to produce the next great software package which can run on even the smallest Windows device possible ? Why not learn more about native coding. Why not learn how the “old fashioned” procedural style of coding, often used with such native coding, can provide some benefits that even OOP can not. Now remember, I warned you a couple times in this article that you probably don’t want to hear this, so if you have read this article all the way to its end then maybe you have that itching inside to be the next native coder. Just be careful to not tell your friends you are one (no one wants to be laughed at). Instead just let your tiny, high performance apps that you create using native coding speak for themselves. Then you truly do get the last laugh. Maybe even a raise when you show the boss what you can do. So happy coding ! Maybe you too can be a native coder !

 

 


Comments Off

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:

blog01

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:

$COMPILE EXE
$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&)

GLOBAL hMenu1&
GLOBAL hSubMenu1&
GLOBAL hSubMenu2&
GLOBAL hSubMenu3&
GLOBAL hSubMenu4&
GLOBAL hSubMenu5&
GLOBAL hSubMenu6&
‘ ——————–
$INCLUDE “ezwmain.inc”                          ‘ 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”
END SUB

SUB EZ_DesignWindow(FormName$)
SELECT CASE FormName$
    CASE “MAIN”
      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”
    CASE “FLOAT1″
      EZ_Toolbar 100, EZ_LoadPicture(“toolbar2.bmp”), “BBBBBBBBBB”, “24X24O”
    CASE “FLOAT2″
      EZ_Toolbar 200, “#LargeSTD”, “BBB BBBBBB BB BBB B|0123456789ABCDE”, “FB”
    CASE ELSE
END SELECT

END SUB

SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
LOCAL X&, CP$, D$
SELECT CASE FormName$
    CASE “MAIN”
        SELECT CASE CID&
            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″
        SELECT CASE CID&
            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 “FLOAT1″
        SELECT CASE CID&
            CASE 101 TO 112
               IF CMsg&=%EZ_ToolTip THEN SetTips1(CID&-100)
            CASE ELSE
        END SELECT
    CASE “FLOAT2″
        SELECT CASE CID&
            CASE 201 TO 215
               IF CMsg&=%EZ_ToolTip THEN SetTips2(CID&-200)
            CASE ELSE
        END SELECT
    CASE ELSE
END SELECT
END SUB

SUB SetTips1(N&)
    LOCAL D$
    SELECT CASE N&
       CASE 1
          D$=”Button”
       CASE 2
          D$=”Text”
       CASE 3
          D$=”CheckBox”
       CASE 4
          D$=”Radio”
       CASE 5
          D$=”ListBox”
       CASE 6
          D$=”Progress Bar”
       CASE 7
          D$=”Tab Control”
       CASE ELSE
          D$=”Nothing”
    END SELECT
    EZ_SetToolTip D$
END SUB

SUB SetTips2(N&)
    LOCAL D$
    SELECT CASE N&
       CASE 1
          D$=”Cut”
       CASE 2
          D$=”Copy”
       CASE 3
          D$=”Paste”
       CASE 4
          D$=”Undo”
       CASE 5
          D$=”Redo”
       CASE 6
          D$=”Delete”
       CASE 7
          D$=”New”
       CASE 8
          D$=”Open”
       CASE 9
          D$=”Save”
       CASE 10
          D$=”Preview”
       CASE 11
          D$=”Properties”
       CASE 12
          D$=”Help”
       CASE 13
          D$=”Find”
       CASE 14
          D$=”Replace”
       CASE 15
          D$=”Print”
       CASE ELSE
          D$=”Nothing”
    END SELECT
    EZ_SetToolTip D$
END SUB

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:

      CASE  %FORM1_LISTVIEW1
            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 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:

http://www.youtube.com/watch?v=D9fvdfE59_Y

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.

http://www.youtube.com/watch?v=FC3UH1wBcL0

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 chrisboss@centurlink.net or support@cwsof.com

Want to learn more about EZGUI 5.0 Professional, check out the rest of my web site at http://cwsof.com

 

 

 


Comments Off