Wednesday, 17 of September of 2014

Cheaper Windows 8.1 tablets coming ! How to develop for minimal hardware.

Yes, cheaper (lower cost) Windows 8.1 tablets are coming. Just read about Archos coming out with a 8 inch, Windows 8.1 (not WINRT) tablet for only about $150. I had suggested in the past that Windows tablets could eventually reach the $99 price range and things are obviously going in the right direction. The free version of Windows 8.1 Microsoft is offering obviously will make a big difference. This version is only for smaller than 8 inch devices under $200. But it is real Windows.

Designing software for minimal hardware

Obviously these low cost tablets will have minimal hardware. Likely the SDD (solid state drive) or whatever they use for a disk drive, will be small, like 32 gigabytes or less. Memory likely with be 2 gigabytes or less (possibly 1 gigabyte). They will likely be based on the Intel Atom SOC’s (system on a chip). So how does one write desktop software for such hardware ?

EZGUI 5.0 Professional offers developers a way to build powerful desktop applications which only require minimal hardware. Combined with the PowerBasic compiler, it allows one to build complex user interfaces using a tiny Graphic User Interface framework.  I am looking into porting the framework for use with other compilers, but for now it only works with PowerBasic.

When I say “tiny”, I mean tiny ! While modern dot.net frameworks are in the many megabytes in size and require more and more horsepower (CPU power), the EZGUI 5.0 Professional framework is tiny in comparison and can work on PC’s with 1/3 of the power of a typical mass market PC (can you say Walmart?). So what does the EZGUI framework support and how big is it ?

Compared even to the old classic Visual Basic (5.0) runtimes, EZGUI is still tiny.

Consider Visual Basic 5.0 Professional’s runtimes:

msvbvm50.dll – 1324 KB
comdlg32.ocx – 150 KB
comctl32.ocx – 595 KB
comct232.ocx – 161 KB
mscomct2.ocx – 633 KB
richtx32.ocx – 208 KB

Totol – 3071 KB

Let’s list a feature set of the EZGUI 5.0 Profssional framework and you tell me how large a runtime would be required.

  • Forms (including MDI)
  • All standard controls
  • Most common controls (Animation, Calendar,DateTime,Listview,Pager,Progressbar,Rebar,StatusBar,ToolTips,Tab control, Toolbar,Trackbar,UpDown)
  • RichEdit (supports versions 1.0 to 4.0)
  • Print engine (print to printers)
  • Common Dialogs (open/save, colors, fonts,print, page setup, find/replace)
  • Tray Icons
  • Form Menus and Popup menus
  • Clipboard (text,RTF text,bitmaps)
  • Registry
  • Control Search Functions
  • Timers
  • Display HLP and HTML Help files
  • MessageBoxes

So far a decent number of features, so if we can stay below Visual Basics 3 meg runtime (core runtime and typical OCX’s necessary) size we are doing good, right ?

Well let’s add some more advanced features such as:

  • Shape/Hotspot/SplitterBar custom control
  • Turtle Graphics (vector based images) custom control
  • Files Listbox custom control
  • Properties Listbox custom control (yes a real property list control)
  • MCI custom control with simple scripting language

Not bad, but let’s add some more features to our GUI framework (definitely going to be a bigger runtime than Visual basic, right ?)

  • Thread engine for non-GUI worker threads
  • Subclassing engine for low level access to controls window procedures
  • Superclassing engine to make building new controls from existing classes easier
  • Support for multi-monitors

We need Graphics, so what about that ?

  • Canvas custom control with low level drawing engine and low level DIB (device indepent bitmap) engine for accessing pixels directly
  • 2D Sprite engine for Canvas with frame animation, alphablending, antialiasing
  • 22 Image filters for drawing bitmaps
  • OpenGL based glCanvas custom control with 3D scripting language
  • STL 3D model support for drawing high polygon count models

If we have graphics, how about customizing controls ?

  • OwnerDraw engine with graphic commands for customizing Menus, Tab control, Listbox, Combobox,Button, Label and Listview controls
  • Customdraw for customing fonts and colors per item/cell for Listview and treeview controls
  • support for drawing some Theme aspects for ownerdraw
  • direct access to window DC’s for drawing or reading

Some more features thrown in like:

  • copy contents of forms and controls to a bitmap
  • complex window region generation for forms and some controls (non-rectangular windows)

And lastly, since RAD is so important wouldn’t a GUI framework need some way to make building a visual designer (like Visual Basic) easy ?

  • Visual Designer drag and drop engine with drag handle custom control
  • Snap To Grid
  • Rubberbanding engine (for drawing controls)
  • subclassing engine to make controls capable of drag and drop visual design

Ok, how big a runtime do you think we will need ? If classic Visual Basic was about 3 megabytes, then likely all of the above would require at least twice as much, right ?

Wrong. The entire runtime for the GUI framework is only about 1 megabyte in size and I haven’t even mentioned all the features in it (it has a command set which is close to 1000 commands).

So with the coming low cost Windows 8.1 tablets, developers can also build powerful software which will run very well on them too.


Comments Off

Windows 8 and IOT, could a new take on classic Visual Basic create new generation of programmers ?

Programmers are always on the look out for new ideas for a programming language. So as a software developer with many years behind me, here is my take on an idea which could make a big difference for software development for Windows 8 and the coming “Internet of Things”, if it were to be implimented. This story will take some twists and turns, so don’t get caught up too quickly with the idea of bring classic Visual Basic back.

Classic Visual Basic, a starting point

First, I would start with everything I thought was good about classic Visual Basic. Classic Visual Basic was a very simple development system when it came to user interface design. It was clean, simple and easy to use, even for beginning programmers. Key reasons why it became one of the most popular programming languages around, was how quickly you could prototype an application, it had a simple IDE without too much clutter, it didn’t require a leading edge PC to develop on and the language was based on one of the easiest languages to learn, BASIC. BASIC has a very long history behind it and it has demonstrated over and over again that it is a language worth using. The easy and more natural language syntax makes it a great language for both beginners and professionals. A lot of usable legacy code (non-user interface) is still around from the DOS (BASIC) days and early Windows (Visual Basic). Microsoft set the standard for BASIC back with Quick Basic (and later PDS 7.1). So Visual Basic is a good starting point for building a new programming language. Also I think that some may not realize that one of Visual Basics biggest strengths is something that most consider a weakness today, at least from my experience it is.  Classic Visual Basic allowed a programmer to write code in a more procedural style. Some viewed Visual Basic as not going far enough when it came to Object Oriented Programming, but its strength was how easy it was to code using a procedural style of coding, but still offering a RAD development environment. From my own experience, I find that procedural coding can not only be as modular and reusable as OOP, but it allows one to build software with a much smaller footprint, is easier to debug (much easier to follow code flow) and a good approach for building the next generation of tiny applications for the coming “Internet of Things”. Herb Sutter in his talk “Why C++?”  discusses important aspects about the importance of building software which performs better and requires less resources. But I would go further. I would suggest, “Why not BASIC ?” and I mean a more procedural style of BASIC with the power of C (not C++), but with the ease of classic Visual Basic.

Lessons learned from experience. Something different.

Visual Basic though, failed in a number of areas. It wasn’t because it was designed poorly, but because the original goals were different. Ease of use and component reuse were key aspects of classic Visual Basic. I don’t think many realized how popular this language would become and how many “hobby” programmers, as well as professionals, would build commercially viable software with it. But its initial strengths would also later be part of its weaknesses. First let me discuss component reuse. COM based components (aka. OCX controls) created a huge market for third party development and Visual basic programmers often solved problems with such addons. One problem though, was that this created a dependency upon COM based components, which were much more bloated (size and resources used) than its simple DLL based counterparts.  Applications were not as easily installed. You couldn’t just “copy and run” an app in some instances.  Classic Visual Basic wasn’t originally a native compiler (native machine code), but was a PCode compiler instead which slowed things down a good bit. Later a real compiler was added, but from what I have read it was not a native BASIC compiler, but instead a C compiler backend tha was added to provide this functionality. You can better appreciate the difference between a real native code BASIC compiler and using a C backend, when you realize that companies who built addons for Visual Basic (OCX controls, libraries) often had to write them in C, rather than Visual Basic. Visual Basic was limited in what you could write with it. This is why years ago, another Basic compiler maker, Powerbasic, marketed their product as an addon to Visual Basic for writing fast DLL’s which could be used by any language. Visual Basic was not originally designed as a true compiler, like other languages were. This affected how it was developed and later on it showed.

A new Basic programming language, similar in design to Visual Basic, would need to be able to compile directly to machine code well enough so the language could be written in itself. Any runtime GUI library which it would support, should be built using the language itself. This means the core functionality of the compiler must only depend upon the WIN32 API and no runtimes and higher level libraries (static or DLL) would be compilable using the core compiler. When smart devices start getting smaller and smaller, machine code performance is a must.  A new Basic language should have the same ease of use as classic Visual Basic, but it should be designed from the ground up to work more closely with the native WIN32 API. Instead of overuse of Object Oriented syntaxes, instead it should reflect the core WIN32 API better. Of course, one shouldn’t have to write window procedures and message loops with it, but it should allow you to if you want to. It should be just as natural to write pure WIN32 code with it as it is to write more high level code with it. The GUI feature set of the language, rather than be built upon OCX controls should be built upon both a runtime engine (DLL) or a static library counterpart. One of the things I disliked about classic Visual Basic was that the common controls and common dialogs were in separate OCX controls. The size of those libraries were far too big for the functionality they provided too.

Classic Visual Basic was too far away from the WIN32 API. For example, its native controls were actually superclasses of the operating system native controls (which is why their class names started with the word THUNDER if you took a peek at them). Maybe this was done to better impliment the Object Oriented aspects of the language, but they were fixed in stone, rather than being flexible like native Windows control classes. Native window classes allow you to easily build upon them using subclassing and superclassing. A new Visual Basic should make such things natural and part of the language, rather than an after thought. A new Classic Visual Basic should be as powerful as C, but with the ease of BASIC. There is already a BASIC compiler available with this kind of power , PowerBasic, with the raw power of C (and full access to the WIN32 API), but it lacks the ease of use of Visual Basic and also it lacks higher level GUI features which are important for faster development. As a WIN32 programmer myself, PowerBasic is about everything I would want in a compiler, but when it comes to RAD development it can’t even compare to classic Visual Basic. Even as a WIN32 programmer, I don’t want to spend all my time at that low level. At times I just want to be able to build an application as fast as possible.

Unlike classic Visual Basic though, I would prefer to see us go back to simpler modular design techniques via dynamic link libraries and static libraries. They are better suited for building the tiny applications which will be needed for the coming “Internet of Things” devices. If designed correctly, a compiler of this sort could be capable of building applications which perform well even on the lowly Intel Quark SOC (System on a Chip). A programming language with the ease of classic Visual Basic, but the power of a raw C compiler would provide for faster software development and would also appeal to a greater number of hobby programmers interested in just building software easily.

Is this possible ?

Actually, not only would such a programming language be possible, but it could speed up development for future “tiny” Windows devices at a pace similar to when the original classic Visual Basic was introduced. But with a big difference. It should be developed from scratch with totally different goals. I would like to see it patterned after the PowerBasic compiler which allows a programmer to write very fast and tiny applications as well as any C programmer. But PowerBasic is too low level, so the next step would be to build upon it higher level layers (in both static and DLL format) for the Graphic User Interface features as addon libraries rather than simply built into the core language itself. Since being able to use a lot of legacy code is important, different GUI engines could be buiod for different purposes. A GUI engine could be built specifically for backward compatibility with classic Visual Basic source code. This way developers could bring legacy applications back to life. But other GUI engines could be built for different purposes such as a leaner, smaller, engine closer to the WIN32 API capable of running on the most minimal hardware possible. Classic Visual Basics GUI engine was too dependent upon the COM model and is bloated in comparison to coding a GUI library specifically to tap into the WIN32 API at its lowest levels using a more procedural style of coding. Most of the core WIN32 API is a flat API, rather than object oriented. Even GDIplus comes in a flat API, besides its C classes. New GUI libraries could be built which require one tenth the typical hardware horsepower which most software require today. This is not theory or just wishful thinking. If my company is already building such GUI libraries, well suited to the “Internet of Things”, which is only about 1 megabyte in size (can fit on a floppy if you remember what that was), surely other companies can do the same. But such tiny GUI libraries require compilers with the raw power of C (not C++, but C), but programming languages like Powerbasic demonstrate that it can also be done using BASIC, rather than C.

Just imagine

Just imagine something like this, when Microsofts new Shark Cove device becomes available. Imagine if one could start up something similar to classic Visual Basic, right on the Shark Cove itself ? No special iCore powerhouse computer needed, like you need for Visual Studio.  Nothing would spur on development for the Shark Cove better than it coming with a classic Visual Basic like programming language already installed on it. Yes, develop software for the device right on the device. That means no dot.net required. That means fast performance which can only come from the low level WIN32 API. PowerBasic programmers already should be capable of this, if the device is running a full blown version of Windows (no dot.net needed), but imagine if one had the ease of use of classic Visual Basic as well.  Now that would make the Shark Cove a lot more valuable as a prototyping device than even the Raspberry PI, in my opinion. Actually, if such a compiler was built correctly it might even be capable of running on even less hardware than what the Shark Cove has. Again this is not simply an impossible dream. My current development system only takes about 20 megabytes of disk space, which includes a fast native code compiler, an inhouse drag and drop designer (not up to Visual Basics level though) and code generator and a complete GUI engine running without about 1 megabyte in size.  Still don’t believe this is possible ? Why not download this simple application I wrote for testing backward WIN32 compatibility of Windows 8 with previous versions of Windows:

Download Windows 8 backward compatibility App.

The application executable (EXE) is only 166 KB in size and the GUI framework libraries are only about 1 megabyte total in size. The framework only uses the WIN32 API and no Dot.Net, no MFC, no C libraries. It also uses the standard OpenGL libraries ones video driver installs for its OpenGL 3D support. So basically it only uses core operating system libraries. It uses many WIN32 features such as the GDI, Ownerdraw, CustomDraw, Standard and Common Controls, Common Dialogs, Timers, MCI plus it also uses three unique high level engines for 2D Sprite animation, 3D OpenGL animation and Visual Design drag and drop (what visual designers like Visual Basic require for a drag and drop form designer). All the code (proprietary, so sorry no source code here) was written in BASIC (not C or C++).

 

 

 


Comments Off

WIN32, 32 bit Atom SOC’s and Windows ! A powerful combination.

I just have to say that I am getting very excited about some of the things both Intel and Microsoft are working on. Why ?

Old time programmer feeling lost

I have been programming since the 1980′s professionally (anyone remember the Commodore 64, TI-99, CPM ?) and like most programmers change is not easy. How far things have come and development tools have changed drastically. I am a coder. For you new generation programmers, that means rather than spending a lot of time in a drag and drop, intellisense based, IDE I prefer to to code in a simple code editor without a lot of fancy stuff getting in the way. Now I appreciate the importance of RAD (rapid application development), even building my own RAD tools, but it is when I get down to just plain old writing code where I feel most comfortable.

I have been a long time Microsoft BASIC programmer, first with QBasic, then Quick Basic 4.0, Microsoft PDS 7.1 and then later classic Visual Basic 1.0, 2.0 and finally 5.0 Professional. But I am also a low level coder, having worked with 6502 machine language (Commodore 64 days) and some x86 assembler. I wrote my own simple compiler back in the Commodore 64 days just so I could write a family friendly video game which was published in the Compute Gazette magazine.

One of the things that I have maintained over the years as a long time programmer, was an appreciation of building high performance applications which work with minimal hardware. I remember once building a complete point of sale system for a Kaypro II (CPM) computer using interpreted BASIC on machine with only 2 floppy disk drives and 64 KB ram (that is Kilobytes, not megabytes) and a 2.5 mhz CPU. Now imagine that (and programmers today complain about the Intel Atom SOC’s with over 400 times more power). So working with minimal hardware is nothing new to me.

It is easy for a programmer like me to feel lost today with all the different development tools being used today. C++, JAVA, C# and more. But amazingly some of my old time tricks may now come back into fashion because of computer devices getting smaller and smaller and the interest in the so called “Internet of Things”.

What is an old time programmer to do when classic Visual Basic meets the end of its life cycle ?

I had two choices when classic Visual Basic came to an end. Either jump on the dot.net (managed languages) bandwagon or learn something many prefer not to do anymore, the low level WIN32 API. I chose the latter, the WIN32 API. Fortunately for this old time BASIC programmer, I found a programming language well suited to the task called Powerbasic. In short, PowerBasic is what I felt C should have been. The ease of BASIC, but with the power of C and of course the WIN32 API.  The history of Powerbasic is important here because of where it came from. Powerbasic dates back to the old DOS days, but under a different name. Back then it was called TurboBasic, sold by Borland International, well known for their powerful programming languages. Borland eventually sold back the rights to TurboBasic to its original developer Bob Zale, who renamed it Powerbasic. Powerbasic now works with Windows and to get the most out of it requires a good knowledge of the Windows API (WIN32). The point of all of this is the history of the programming language and how it dates back to when compilers produced very small and fast executables capable of running on computer hardware which most programmers today could not even imagine developing software for. It is this kind of mindset which allows todays WIN32 programmers (which are likely a small number) to be able to write software which runs on very minimal computer hardware with ease.

15 years learning the WIN32 API

For the last 15 years I have been learning the deeper things of the WIN32 API. I still use BASIC, but for those of you not familiar with PowerBasic, just think of it like an old time C (not C++) compiler, but BASIC instead. Yes, I work with things like code and data pointers, threads and of course the low level WIN32 API. Since there were no books written about learning the WIN32 API for PowerBasic programmers, I had to read books written for C (not C++). Because so much has changed over the years with software development, the only usable books for me dated back before even MFC (Microsoft Foundation Classes). Fortunately with places like Amazon.com one can find such rare books. So research I did and amazingly even books written for good old C (not C++) were easy to port to PowerBasic code. So what were the best books I found for learning the WIN32 API ?

WIN32 Books ?

While most will likely suggest the Charles Petzold books, I found others which I felt were more clear and easy to understand.  For those of you interested in learning the WIN32 API the following are good reads:

Windows 95 – A Developers Guide
by Jeffrey Ricter and Jonathan Locke
copyright 1995
published by M&T Books

Windows 98 Programming from the ground up
by Herbert Schildt
copyright 1998
published by Osborne McGraw Hill

Threading is an important subject and I strongly recommend an entire book dedicated to the subject:
Multithreading Applications in WIN32
(the complete guide to threads)
by Jim Beveridge and Robert Wiener
copyright 1998
published by Addison-Wesley Developers Press

It was very difficult to find a good book which explained writing custom controls (true WIN32 controls) and I finally found this one:

Windows Custom Controls
By William Smith and Robert Ward
Published by R&D Technical Books
Copyright 1993

That one may be difficult to find but is worth getting if you can. Amazingly, even though it was written for 16 bit Windows the core concepts have not changed in 32 bit Windows.

I also learned basic OpenGL technigues and found this book invaluable:

OpenGL SuperBible

by Richard Wright

Copyright 1999

While I used the 2nd edition, there are a number of later editions worth reading. Early editions though may be a good start since they have less material to deal with.

 

Old skills have new uses

So what does this all have to do with today ? There is a big interest in the “Internet of Things” (translated means very small devices which connect to the internet in all sorts of everyday uses). There is also interest in tiny computers which could be the basis for developing such devices. While I, like other tech users, have an interest in Arduino, Intel Galileo and the Raspberry PI the latest addition is what really interested me. It is called the Sharks Cove and it sounds very exciting indeed. It also appears my aging programming skills now may have a new life in such a device.

The Sharks Cove

Microsoft, Intel and CircuitCo are working closely together to bring to life this amazing new device. While the price is a bit steep (intially $299), it does open up possibilities for developers who are interested in the coming generation of devices. What I find most interesting is that this device, unlike Galileo, appears to be a full blow mini PC capable of running real 32 bit Windows with GUI capabilities (it has HDMI output). You can read about the Sharks Cove here and here. So what is the Sharks Cove ?

It appears to be a real computer, capable of running 32 bit Windows 8.1. It uses the Intel Atom system on a chip (SOC), has a 16 gig EMMC drive (just enough to hold windows) and 1 gig memory. Now most programmers today don’t feel comfortable with anything less than an ICore CPU and 4 or 8 gig memory on a PC, so those of you interested in writing software for a device like this might want to consider learning either plain C or PowerBasic along with the WIN32 API. The WIN32 API is very low level and is more procedural in nature (using a flat API) so I would recommend skipping the object oriented style of coding to get the maximum power (performance and minimal resourses) out of your software if you want to write software for the Sharks Cove. Why is such low level programming important ? Watch Herb Sutters talk “Why C++ ?” to better appreciate why native coding is so important today. Whether you use C, C++ or PowerBasic (or any other language well suited to WIN32 programming), native coding can produce amazingly small and fast executables, well suited to devices like the Sharks Cove.

The power of the Windows WIN32 API

Normally in my blog when I write an article which will also be posted here on Code Project, I try to avoid mentioning the software I develop or at least keep it to a minimum. But for this article I will, because it demonstrates the raw power of the WIN32 API and what is possible if programmers started working with the WIN32 API again. I will try to keep what I say to useful generalities, but forgive me if I find it difficult.

There are two key issues when developing software for a device like the Sharks Cove. The first is the size of the executables themselves, since disk space will be at a premium. The second is the ability to run with minimal CPU power and minimal memory. Remember that Windows itself will already be using a significant portion of the available resources, so what is left for your applications won’t be anything like you may be use to. Managed programming languages do have a reputation of requiring a good bit of resources, so coding using the WIN32 API does have its benefits.

For the last 15 years my company has been developing its own GUI framework based on the WIN32 API. Currently it only supports the PowerBasic compiler, so most of you likely couldn’t use it anyway (if you program in C++). But it does demonstrate how WIN32 programming can be used to build much smaller, faster, lean GUI frameworks for devices like the Sharks Cove.

Classic Visual Basic programmers will appreciate the value of a GUI framework or runtime, since Visual Basic applications required a core runtime (DLL). That DLL though only was 1.4 megabytes in size so it was not much overhead. Visual basic applications themselves are actually quite small because they use a runtime, so they are well suited to running on computers with minimal memory and disk space. One downside to classic Visual Basic was that much of the more advanced functionality was left to secondary runtimes (or OCX controls), so when using the common controls, common dialogs, etc an application quickly grew in size up to 3 or 4 megabytes and if you used third party OCX controls some times the app could grow significantly larger. When Visual Basic was originally created it was kind of a fluke, really. Microsoft didn’t create it, but it was created by Alan Cooper (original developer of Visual Basic) and was not initially intended to be a full blown programming language. This explains why it started out as a Pcode language and only after years of development did it finally get a real compiler backend (which I have read was actually a C compiler). It was not designed from the ground up to be a GUI framework, like the dot.net framework was. It also concentrated more on component resuse and the drag and drop experience, rather than on being a lean, fast GUI framework. The concept was good, but flawed in that it did not concentrate on performance and tapping into the raw power of Windows and the WIN32 API. Ease of use was the priority and even in later years, experienced Visual Basic programmers had to resort to calling the WIN32 API directly to tap into that raw power of the Windows API. So books about the WIN32 API and how to use it with Visual Basic became a staple for many an experienced Visual Basic programmer. But what if developers back then had built GUI frameworks which tappped into the raw power of the WIN32 without all the weaknesses of early versions of Visual Basic ? There were attempts like MFC and OWL but they were simply object oriented wrappers on top of the WIN32 API, which did solve some problems, but were not the lean framework which programmers would have desired.

Building my own GUI framework using the raw WIN32 API

My company for the last 15 years has been developing a GUI framework which does demonstrate how possible it is to build small, fast, lean GUI frameworks based on the WIN32 API. Now while I developed my framework for the Powerbasic compiler, it is very reasonable to conclude that other programmers could do something similar for C and C++. Especially would this be useful for developing software for future devices based on the Shark Cove device running real 32 bit Windows (x86). But how small, how lean, could such GUI frameworks be ?

Now some of the features I mention here, may not sound very exciting to many programmers who are using the latest dot.net languages, so please don’t start with the “I can do that easily with Visual Studio”. The point is that imagine writing software for a device where even the dot.net runtimes might be considered bloated for the device and you definitelly won’t be installing Visual Studio on any such devices. Imagine for a moment, you don’t have dot.net. Imagine only being able to code using C++ and the WIN32 API because of restraints in software size and system requirements. Now consider the features I mention below and see how developers can create new GUI frameworks specifically for these new devices.

Let’s use the classic Visual Basic runtimes as a basis of comparison.

Consider Visual Basic 5.0 Professional’s runtimes:

msvbvm50.dll – 1324 KB
comdlg32.ocx – 150 KB
comctl32.ocx – 595 KB
comct232.ocx – 161 KB
mscomct2.ocx – 633 KB
richtx32.ocx – 208 KB

Totol – 3071 KB

Because many of the more needed features of Visual Basic,  such as the common controls, richedit control and common dialogs required additional OCX libraries, the above runtime list well enumerates what the typical Visual Basic application required. So for all practical purpose the Visual Basic runtimes (or GUI framework) were about 3 megabytes in size. That is still not bad though. But remember, that Visual Basic was not designed for leaness, but for ease of use and component use. But the above runtimes didn’t include any animation engines, customizing features like owndraw, OpenGL graphics, threading, subclassing or superclassing. Actually they were pretty lean in features really.

But what if Visual Basic had been designed from the beginning for leaner size, better performance and tapping into some of the raw power of the WIN32 API ?

Now consider, simply for comparison sakes a more recent GUI framework which my company developed which was designed to tap into the raw power of the Windows API while maintaining ease of use. Let’s simply list a feature set of the framework and you tell me how large a runtime would be required.

  • Forms (including MDI)
  • All standard controls
  • Most common controls (Animation, Calendar,DateTime,Listview,Pager,Progressbar,Rebar,StatusBar,ToolTips,Tab control, Toolbar,Trackbar,UpDown)
  • RichEdit (supports versions 1.0 to 4.0)
  • Print engine (print to printers)
  • Common Dialogs (open/save, colors, fonts,print, page setup, find/replace)
  • Tray Icons
  • Form Menus and Popup menus
  • Clipboard (text,RTF text,bitmaps)
  • Registry
  • Control Search Functions
  • Timers
  • Display HLP and HTML Help files
  • MessageBoxes

So far a decent number of features, so if we can stay below Visual Basics 3 meg runtime size we are doing good, right ?

Well let’s add some more advanced features such as:

  • Shape/Hotspot/SplitterBar custom control
  • Turtle Graphics (vector based images) custom control
  • Files Listbox custom control
  • Properties Listbox custom control (yes a real property list control)
  • MCI custom control with simple scripting language

Not bad, but let’s add some more features to our GUI framework (definitely going to be a bigger runtime than Visual basic, right ?)

  • Thread engine for non-GUI worker threads
  • Subclassing engine for low level access to controls window procedures
  • Superclassing engine to make building new controls from existing classes easier
  • Support for multi-monitors

We need Graphics, so what about that ?

  • Canvas custom control with low level drawing engine and low level DIB (device indepent bitmap) engine for accessing pixels directly
  • 2D Sprite engine for Canvas with frame animation, alphablending, antialiasing
  • 22 Image filters for drawing bitmaps
  • OpenGL based glCanvas custom control with 3D scripting language
  • STL 3D model support for drawing high polygon count models

If we have graphics, how about customizing controls ?

  • OwnerDraw engine with graphic commands for customizing Menus, Tab control, Listbox, Combobox,Button, Label and Listview controls
  • Customdraw for customing fonts and colors per item/cell for Listview and treeview controls
  • support for drawing some Theme aspects for ownerdraw
  • direct access to window DC’s for drawing or reading

Some more features thrown in like:

  • copy contents of forms and controls to a bitmap
  • complex window region generation for forms and some controls (non-rectangular windows)

And lastly, since RAD is so important wouldn’t a GUI framework need some way to make building a visual designer (like Visual Basic) easy ?

  • Visual Designer drag and drop engine with drag handle custom control
  • Snap To Grid
  • Rubberbanding engine (for drawing controls)
  • subclassing engine to make controls capable of drag and drop visual design

Ok, how big a runtime do you think we will need ? If classic Visual Basic was about 3 megabytes, then likely all of the above would require at least twice as much, right ?

Wrong. The entire runtime for the GUI framework is only about 1 megabyte in size and I haven’t even mentioned all the features in it (it has a command set which is close to 1000 commands).

So how does one do it, if they want to build their own GUI framework ?

First, this demonstrates the power of writing directly to the WIN32 API. You will need a programming language well suited to working with the Windows API as a flat API, such as C, C++, Powerbasic, PureBasic or others. Next, it is best to write the code in a more procedural style avoiding all the extra overhead of object oriented coding styles. Even something like GDIplus (which I don’t currently use yet) can be accessed using the flat API versions rather than the C++ classes most programmers use. Here is an example of a programmer who uses the GDIplus API’s via the flat API’s rather than C++ classes, along with OpenGL and other advanced graphic API’s using only flat API’s to develop powerful skinning and graphic engines. His GDImage library, originally written in PowerBasic but now ported to C, is an example of a very lean graphic engine built using only the flat API’s in Windows without all the extra OOP overhead. It demonstrates how powerful low level WIN32 (and OpenGL) programming can be, while maintaining a very, very lean framework.

Some of you are likely old time C programmers (rather than C++), so using the WIN32 API directly along with C makes you a very valuable asset to companies interested in building software for devices based on the Shark Cove initiative. By honing down your WIN32 skills you have a resource not easily found today in the programming world. WIN32 programming used to be considered old fashioned, but maybe not anymore.

While what my company has done is only for use with Powerbasic development tools, I would venture to say maybe this article will spur on some of you C programmers to start building new GUI frameworks specifically for C which are just as lean. Old time procedural style coding has some advantages, such as producing very small executables with minimal resources required. WIN32 programming can produce the next generation of small, fast software which could turn the “Internet of Things” into a practical reality.

Wondering if old fashioned WIN32 programming is viable for the Windows 8.1 desktop ?

The WIN32 amazingly has stayed very intact and well written WIN32 code works very well on Windows 8.1 Why not download my sample, “backward compatiblity”, application which I wrote just for testing many of the features in my GUI framework on Windows 8 to make sure they work as expected.

Download: WIN32 backward compatibility test app

So, I hope this little article will spur on more development of GUI frameworks, especially for the coming “Internet of Things” devices. So start programming now and see what you can create. Keep it small. Keep it lean. Keep is fast. Use only minimal hardware. Why not check out the Sharks Cove device and see what you can do with it, using the WIN32 API. Please post your experiences with this device here, since we all would like to see what others can do with it.

 


Comments Off