Saturday, 23 of August of 2014

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 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 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 (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 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 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 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 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 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

Windows and The Internet of Things !

Having just read an interesting article by Paul Thurott, about Microsofts Internet of Things SDK built upon 32 bit x86 Windows and using Intels Galileo device (an x86 device the size of the Raspberry PI device) which uses Intels tiny system on a chip CPU (Quark), I found very interesting one of the core development methods which will be required. The WIN32 (or at least a subset of it) will be making a comeback. So why does this interest me ?

A decade and a half of WIN32 development

Because I have spent the last decade and a half not only learning the WIN32 API, but also learning how to build tiny sized software which require minimal hardware. How many programmers today can write software which not only runs on the latest computers, but also can run on something with only the power of what we would call a legacy PC ?  If Windows 8 could run on a PC with only a 500 mhz CPU or less and with only 256 megabytes of RAM and only minimal disk space available for applications, say 50 megabytes or less, could your software run on that ?

Well designed WIN32 software can !

No, really ! Why do I say that ?

The proof is in the pudding!

You have to be a WIN32 programmer to appreciate this. You also have to know how to design software without all the object oriented fluff most software has today. The core WIN32 is actually very procedural in nature. It is basically a flat API and the most efficient WIN32 software is that which is written using the flat API directly, without something like MFC (Microsoft Foundation Classes). Just plain pure WIN32. Now there is no reason that well designed GUI libraries could be written to make things easier, but such would best be written using the WIN32 as a flat API. No OOP stuff to get in the way.

As a long time developer of programming tools and GUI libraries based on the WIN32, I know how “lean” WIN32 applications can be. Maybe because of my going back to the old DOS days, I can appreciate the importance of writing software which requires minimal hardware (Once wrote a complete point of sale system for a video rental store, which ran on a CPM computer with only a 2.5 mhz CPU,  64 KB memory and two floppy disk drives). Old time programmers knew how to squeeze every byte and CPU cycle out of a computer in those days.

Would you like to see what can be done using the pure WIN32 API ?

Download this application I wrote for testing WIN32 backward compatibility on Windows 8: Win8 Test app

The app uses a GUI library which is 100% pure WIN32 based. The real test of any WIN32 app is how well it runs on minimal hardware. First try the app on your current PC and see what it does. It demonstrates WIN32 features like Forms (windows) and standard controls and the common controls, complex window regions, ownerdraw, customdraw, custom controls (written in pure WIN32),  WYSIWYG similar to what Visual Designers do (based on low level GDI), MCI multimedia, GDI drawing, DIB based drawing, OpenGL 3D.

Now feel free to try the app on the slowest Windows PC you have. Try it even with legacy PC’s such as Windows XP (ie. with only 256 meg RAM or less), Windows ME, even Windows 95/98.  Try to imagine how little hardware an Internet of Things device may have. Try it with a PC with less than a 500 mhz CPU and less than 256 meg ram.

Back when Windows XP was the current operating system, I purposely developed WIN32 software on a Windows 95 PC which I boosted to 256 meg RAM. The purpose was to see how well the software ran on minimum hardware. WIN32 software can be designed to run on very minimal hardware and you may be surprised how little you really need.

Native coding for Windows can produce high performance software. Learning how to leverage the low level WIN32 API using a native code compiler like C++ or others can produce even smaller, faster software. Is there is a need for this today ? Yes there is. Watch Herb Sutters talk “Why C++?” and see why and how. Native coding produces smaller, faster, software. The WIN32 coding produces even smaller, faster software. Just what we need for the coming “Internet of Things”.

Now if Microsoft can just learn how to squeeze a complete embeded GUI version of Windows 8 (no Metro or needed) into a small enough size to run on Intels Galileo device, then we would have something worth coding for. WIN32 programmers may then be in high demand. Whether you code in C, C++ or other languages (I code in Powerbasic, which is a BASIC compiler on par with many C compilers) doesn’t matter. They key will be learning how to leverage the WIN32 API so you can write tiny, tiny, tiny software which can perform even on the most minimal hardware. Combined with embeded Windows 8 designed for such small devices, then the internet of things just could become a reality.


Comments Off