Friday, 24 of October of 2014

IOT and Windows – what is needed, a lesson from the past

The exciting Internet of Things is the next frontier for programmers. Most interesting is the possiblity of Windows running such devices. But what is need to make this possible ? Is a shift in mindset needed to make this possible ?

A lesson from the past

Programmers who got their start back in the 1970’s and 80’s remember what it was like to write software for computers with very little raw power.  It amazes me how the current mini-devices like the Raspberry PI and in the Windows world the existing x86 mini-PC devices seem so underpowered and it is a wonder why they don’t perform better. In considering this, an old time programmer may come to a number of conclusions.

In the old days, the key to performance in computers was the software and even the operating systems (past home some computers didn’t have a full operating system in the same way they do today, but simply supported basic input and output via direct hardware access). Let’s consider one example that demonstrates how powerful even limited hardware can be with the right software.

How any computer device today with a CPU (or SOC , System on a Chip) running at 1 gigahertz or better can have a problem with performance boggles the mind. Consider a home computer from the past, the Commodore 64 (C64). The C64 was a powerful little computer back in the day. Its CPU ran a blistering 1 megahertz (that is megahertz, not gigahertz). Ok, I am using some humor here. By todays standard one would not refer to 1 megahertz as blistering (fast). Yet back in the old days, some programmers felt that such a computer was capable of much more than most would think. C64 users likely remember how slow interprted BASIC was on those machines. It was “turtle slow” be correct. But programmers back then found that when they learned how to write software using a real native code compiler or even by using machine language they could make that turtle slow computer do some amazing things. Personally, I started using the Abacus BASIC 64 compiler which was a huge improvement. One could actually write software with some decent performance. Using that compiler, I then wrote my own mini-compiler with a limited command set so I could write code which would perform closer to assembly language speeds. My mini-BASIC compiler generated machine code directly (no assembler in the middle). I quickly found out that how you write software makes a big difference. Using my mini-compiler I wrote a family friendly video game and sold it to Compute Gazette magazine, earning myself $1500 for just a few weeks work, which was not bad for a self taught hobby programmer back in the late 1980’s.

Some amazing programmers, likely using assembler to code, built an amazing operating system for the Commodore 64, called Geos. Geos turned the Commodore 64 into a Macintosh (Apple) like computer (which cost 4 times as much and has 8 times the speed as the C64). Berkeley Softworks, which created Geos pushed the limits of the C64 far beyond what even its manufacturer (Commodore) ever considered. All of this on a computer with a 1 megahertz CPU, 64 kilobytes of ram and an external disk drive with only 170 kilobytes of disk space.

The lesson learned ? Software written using native code compilers and which are closer to the hardware can perform at amazing speeds. How you write software makes a difference.

The Windows world

In the early years of 32 bit Windows (Windows 95), a typical PC likely was only using a CPU which ran at 100 megahertz or better, likely with less than 24 megabytes of ram. Compared to todays PC’s (ie. 1.5 ghz CPU, 2 gig ram) this would be nothing. Most current software for Windows likely could not run on hardware with so little power. Now consider some of the mini-PC, hobby prototyping devices which are now coming out which are x86 based. In the ARM world the Raspberry PI has been a big successful among hobbiests. In the x86 world devices like the Intel Galileo, MinnowBoard and SharksCove are being offered, but at prices still a bit too high for the typical hobbiest. While I do think they need to get the prices down for such devices to the $50 range and add in the free version of Windows 8.1 now being offered OEMs building tablets to make a complete package, the real challenge will be writing software for these devices which push them to their limits.

As a programmer I have been looking at such devices with excitement, but two barriers still exist which I feel need to be addressed. First, is as mentioned, price. To be compariable to the Raspberry PI and to be affordable so they can be the basis of the coming “Internet of Things” devices the price needs to come way down, even if it means less raw power (CPU, memory, etc.) in the hardware. Manufacturers of such devices are still thinking with the Windows PC mindset so the hardware specs are probably too high, which may explain the higher costs than ARM devices. With the next generation of small Windows tablets (7 inch) coming out selling at $100, surely a prototyping, hobby mini computer device could be built for much less. Second, Windows needs to be sheared down a bit to make it more practical for smaller devices, yet with full user interface features. Now some may think that will be difficult. The typical Windows PC is so over powered today, yet most don’t realize it. Why ? Because of how software is written today. So how could Windows be pared down to make it more friendly to the coming Internet of Things ?

Get rid of all managed language engines in the operating system. Get rid of dot.net. Get rid of WINRT. Leave just the core WIN32 API. This would decrease the overhead needed hardware wise. This would make Windows better suited to use on “tiny, tiny” devices. Target smaller screen sizes with resolutions as low as 1024 x 600 (even if you have to fake it like the Toshiba mini tablet does, making Windows think the display is larger than it is). The Windows API is a very, very lean and fast API. The core API likely requires a lot less memory and CPU speed than does the full blown operating system today.

Now at first glance, one might think this would seriously limit Windows development, but I would be more inclined to think that like the Commodore 64 and Geos, developers would learn how to tap into the raw power of Windows and they would find ways to push the limits of even minimal hardware. If Microsoft wants to put Windows everywhere (meaning devices in all areas of life), then the mindset towards Windows needs to be changed.

Not possible, some would say

Some might say, nice ideas but it simply is not possible , nor practical. I would beg to differ though and I have good reason. Unlike most Windows developers today, using managed languages via Visual Studio, for the last 15 years my company has been primarily using simple native code compilers and the raw WIN32 API. Likely because of my past experience in the “old days” of computing, back in the 1980’s, I purposely worked with older, legacy, computers for actual everyday software development so as to force myself to get used to minimal hardware. For example, back when Windows XP was the current Windows, I instead did most of my development on a 233 mhz computer running Windows 95, instead of Windows XP. I did supe it up a bit with 256 meg ram (a lot for Win95) , but it was still only a 233 mhz CPU. I would develop my software on this PC and then test it on a more current PC. By forcing myself to get use to less hardware resources, it helped me learn how to write software which performed well no matter the hardware. Amazingly the raw WIN32 API was well suited to this and it was designed for raw performance.

Also I found that software developed with the WIN32 API required little memory and the executables were so small it was amazing. It felt like the old days, writing software which could fit on a floppy disk ( less than 1.4 megabytes). Now some may think, with the WIN32 API programmers would not have a higher level GUI framework to work with, like dot.net. While initially true, I am sure in time that developers with the right mindset would start building GUI frameworks (which only required the WIN32 API) which would be small in size and fast, like they did for the Commodore 64 with Geos. Not possible you may say ! Well, actually it is and my own company has been for the last 15 years following in the footsteps of those Geos developers, building a GUI framework designed for minimal hardware. I know it is possible, because it is already being done. Other companies should consider this approach as well, if they would like to build the next generation of software for Windows based Internet of Things devices. I am still amazed at powerful the WIN32 API is and what can be done with it. Having built a GUI framework with nearly 1000 commands in it which still can fit on a floppy disk (with room to spare at only about 1 megabyte) tells me that tiny, IOT (Internet of Thing) devices should not pose a problem.

WIN32 programming, a lost art

WIN32 programming appears to have become a lost art, but it need not be. There are plenty of resources available for companies interested in adding this to their software development methods. You can still develop software using managed languages for PC’s and some Windows tablets, but for the coming Internet of Things, why not consider adding WIN32 programming. Maybe you are wondering, most programming sites cator to managed languages, so where can I find information about WIN32 programming ? A quick search on Amazon.com can help you find plenty of older books on WIN32 programming (sadly there are none that I know of which are current). Some of the best resources can be found on support forums provided by companies which make native code Windows compilers . Microsofts web site, while not teaching WIN32 programming, does have extensive documentation about the WIN32 flat API’s. While some may refer to these as legacy API’s, they are actually at the core of Windows. What do you think dot.net runs on ? You can skip the “middleman” and go to the core of the operating system.

Not convinced ?

Let me provide an example of a company which has leveraged the WIN32 APIs so you can better appreciate what it is capable of (note: this company is not associated with mine). The point is to demonstrate what is possible when programmers write software using the core WIN32 API, rather than with managed languages, for Windows. This company is one of the best Graphic engine developers I have personally come across in a long time. One tool they write is called GDImage, a graphic engine, which can leverage multiple low level graphic APIs and merge them together, including the GDI, GDIplus and OpenGL. The original version was written using the PowerBasic 32 bit native code compiler, but the developer has ported it over to Microsoft C to get the benefit of 64 bit compilation. The developer also shares his knowledge of WIN32 programming on a number of programming forums.  The point here is that the graphic library (DLL) is feature rich, performs very well (speed), was designed to only use the core WIN32 API and the entire runtime library is only 315 KB (kilobytes) in size. Now that is the size developers want to reach for the coming Internet of Things devices. That is 1/5th the size of an old fashioned floppy disk. Download this developers demo to better appreciate this. This developer even avoids using the C++ classes for GDIplus, but used the Flat GDIplus API’s provided in Windows.  There are developers out there who are currently leveraging the raw WIN32 API (and OpenGL, etc.). There are still sources available for programmers to learn WIN32 programming.

 


Leave a comment

Keep it simple. Keep it fast. Code it so you can read it.

Having been programming since the 1980’s, I often wonder what has happened to programming. When learning something new from a technology book I would often gauge the books quality on how simply the topic was explained and how quickly I could grasp the subject. Complexity may seem impressive, but how often do we question whether there may be a simpler way ?

A lesson from woodworking

One of the interesting things about woodworking over the centuries is that many seemingly complex tasks can be done using very simple techniques. To the novice though, they may wonder “how did they do that ?”. But to the expert, it may actually be quite simple. You simply just have to know how to do it.  Often the more simple techniques are the most powerful, since they tend to be easier, faster and safer. It is just knowing how to use them to handle a more complex task which is the real trick.

Programming is similiar. Sadly though, I have seen programming become more complex rather than become easier. High level programming languages are suppose to make coding easier, not more complex. Back in the old days many a novice learned how to program using BASIC. Actually BASIC was harder than it needed to be, since on Computers like the Commodore 64 many tasks needed to be done by “peeking and poking” bytes into memory addresses to make the hardware do something. Still, despite those challenges, many a young person learned how to write real computer code to make the computer do some amazing things. Despite the mistaken views of many new programmers today, BASIC back then (and today) wasn’t simply a childish interpreted language. For example, programmers back then were using real compilers. I used the Abacus BASIC compiler which provided significant performance increases.  There were many programming language choices back then (see: Programming Languages uses on C64 ). It was not uncommon for BASIC programmers to learn machine language or assembler language. I chose to learn machine language rather than assembler, so I could write my own compiler. I used the Abacus BASIC compiler to write my own compiler which generated machine language directly. Rather than try to create a very high level language, I chose to create something which was very low level with few commands, which was similiar to BASIC in syntax, but was closer to the machine. I used my compiler instead of using an assembler. It would generate machine code with nearly as good performance as something written in assembler. I used it to write a family friendly video game which I sold to the Compute Gazette magazine.

Despite the need to learn machine language, I still apreciated the importance of keeping it simple. The language syntax of my compiler was kept very simple, borrowing from BASIC while being much easier to code than assembler. One thing I learned was the importance of keeping code simple and clean.  6502 (CPU in Commodore 64) machine language is actually quite simple compared to many modern CPU architectures.  One would think that learning pure machine language (not simply assembler) would be difficult. The book I used to learn it was:

“Machine Language for Beginners”

by Richard Mansfield (dated 1987)

How this author was able to write a book about something like machine language for the 6502 CPU and yet make it so simple that it was easy to learn is amazing. Like the old time woodworkers of old, sometimes it is a matter of knowing how to keep things simple, even when the task seems complex. This is something todays programmers could benefit from, making programming simple and clear, even if the task seems complex.

BASIC – why ?

In a world where everything seems to be about C++ and programming languages with a syntax similiar to C++, like Javascript, some may wonder why does anyone even care about BASIC anymore ?

The principle of “keep it simple” comes to mind. The easier it is to teach a language the faster one can learn to program. Even professionals still like BASIC. For example, one of the more difficult tasks today is pure WIN32 programming. Back in the early 1990’s, WIN32 programming was how all Windows software was written. One usually would use something like C (later C++) to write a WIN32 program. It went out of fashion because it was too difficult to do for many (that is my take on it anyway). Things like MFC and OWL came along to supposedly make it easier, but in time dot.net became the standard and WIN32 programming lost its luster.

While WIN32 programming is quite difficult to learm especially if you want to do something very complex, I had a very interesting experience few programmers get. I came to WIN32 programming about 15 years ago and for me it wasn’t easy to learn, especially the more complex stuff. But despite WIN32 programming being naturally difficult, I personally feel I had one advantage which many programmers back in the 1990’s didn’t have. I started learning WIN32 programming, not using a C compiler but a BASIC language compiler. I was using the PowerBasic 5.0 compiler (todays version is 10). There is something interesting about the history of BASIC between the transition between DOS to Windows. BASIC was a popular programming language back in the DOS days. A lot of commercial software likely was written using BASIC. Microsofts QuickBasic 4 and later PDS 7.1 became the standard for BASIC language compilers. Borlands TurboBasic also was a very powerful programming language. BASIC had proven it could be both an easy to learn language, as well as a language which could offer many of the modern contructs a programming language required. Like my earlier years, I even learned how to code in assembler so I could write high performance modules which I compiled into my PDS 7.1 applications (BASIC).

BASIC though would have a problem. The transition from DOS to Windows would prove very challenging at first. Microsoft was fortunate to come across the original developer of Visual Basic, Alan Cooper . Visual Basic it appears didn’t start out as a compiler for BASIC for Windows. It was something totally different and it was all about scripting and drag and drop. I still have a copy of Visual Basic 2.0 and to be frank about it, the visual designer back then was very rudimentary by todays standard. But for back then it was amazing. Real drag and drop. Microsoft tweaked Alan Coopers software into what became Visual Basic. But it differed greatly from how software was developed back then using the WIN32 API and C. I doubt Microsoft fully expected what would happen with Visual Basic and how popular it would become. From what I gather, it wasn’t planned, it just happened. This explains a lot about Visual Basic and its core weakness, performance. Visual Basic was not a real compiler, but a Pcode compiler with a runtime engine. It was not until version 4.0 that Microsoft finally appreciated the need to turn it into a real compiler and even there, from what I have read, they had to use a C backend for the real compiler part. It is no wonder that Visual Basic was both loved and hated by programmers. For many it shined as easy to use and it used BASIC as the core language. For others, it wasn’t a real compiler and it took many iterations before it would have the performance of a real compiler. So BASIC programmers gravitated to Visual Basic and so called “real” programmers stuck with C and in time C had to find its way, with C++ and later all the dot.net stuff with C#.

BASIC though as a language nearly died during this time. Why ? In the DOS days, BASIC was a high performance compiler on par with C. “Real” programmers wrote a lot of commercial software with BASIC.  In the Windows world, one had to consider how to talk to the operating system and Windows was written in C, so naturally “real” Windows development was done in C. Visual Basic changed much of this, but it was inherently weak because it is was PCode compiler and while it had ease of use, it lacked the power of the WIN32 and a native code compiler. In time Visual Basic programmers benefited from books on how to use the WIN32 in Visual Basic and later a real compiler backend, but much of this was a “hack” to add what should of been there from the start.

What is really interesting is to consider the other BASIC’s that came along trying to make the jump to Windows. I tried many of them myself and I was rarely satisfied. They jumped on the VBX bandwagon and the concept of components and object oriented programming, but none of them could come close to Visual Basic. Visual Basic actually was a significant departure from the WIN32 API itself, so learning how to integrate WIN32 techniques with object oriented techniques would prove challenging for many. It was like two different worlds trying to merge together. Many a DOS BASIC programmer found Visual Basic confusing, despite its easy drag and drop environment. Likely the reason has to do with code flow. No matter how software is written, understanding code flow is critical. Object Oriented programming actually gets in the way at times and can make understanding code flow confusing. There were a number of DOS Basic programmers who could not make the transition from DOS to Windows, even with Visual Basic.

There were attempts with other BASIC languages for Windows like CA Realizer (see also:  Ad about CA Realizer) by Computer Associates and GFA Basic . I bought both of them, but found them too confusing. The transition from DOS to Windows caused confusion for DOS Basic programmers, not because they were poor programmers, but because many concepts were very different and more complex. Visual Basic, despite it not being a real compiler was the most successful but it was more because of the ease of drag and drop, rather than it being a superior programming language. As a long time BASIC programmer I got caught up with change and I gravitated to Visual Basic, but while I liked the easy drag and drop environment, I missed the power of a real compiler with high performance. Despite the misnomer that BASIC programmers didn’t know how to code, but simply were beginners, many BASIC programmers were very advanced and were often looking for ways to improve software and get better performance and to create more complex user interfaces.

Learning the WIN32

So back to my story. About 15 years ago, I had stopped using Visual Basic. There were too many limitations, not because of BASIC, but because of how Visual Basic was designed from the start.  I didn’t mind a runtime library (DLL) for Visual Basic, but its dependency upon OCX controls for so many core features of the language was disappointing.  Things like the common controls and the common dialogs requiring OCX controls which added complexity to distributing ones application.  I had to find something that was more familiar to me. I found the PowerBasic compiler, which was a big change for me. I got started with it with version 5.0 and at that time PowerBasic too was floundering, trying to make the transition from DOS to Windows.  The compiler was like a good old fashioned C compiler, but had no MFC to make coding easier and no drag and drop front end like Visual Basic. So what was it good for ?

PowerBasic advertised their compiler as an addon to Visual Basic for writing real DLL’s which could be accessed by any language. It had all the features of a real compiler and was on par for performance with any C compiler of the time. But they marketed the compiler as an addon for Visual Basic to do all the non-GUI stuff Visual Basic was poor at. But I wanted to build real applications with it and while one could do that, they would have to learn how to code using the WIN32 API just like old time C programmers did. I had a choice and so I started to learn how to work with the WIN32 API. I had to learn about window messages, window classes (not same thing as object classes), DC’s, message loops and so on. Simply put, learning the WIN32 API is difficult and I now understand why in the past C programmers got away from it and why things like MFC were developed. But something else happened which I did not expect.

BASIC shined for WIN32 programming

One of the big problems I had when I started learning WIN32 programming was there was absolutely no books on WIN32 programming for PowerBasic. Most API books for Visual Basic, were not for writing an application using the WIN32 API, but simply how to integrate a few key APIs into a Visual Basic program. So most Visual Basic books, if not all, were useless for a Basic programmer who wanted to learn how to code completely using the WIN32 API. Actually even today, there are still few (if any) well known books about programming the WIN32 API using BASIC. They are all primarily about C. I also had the problem of many Windows programming books dealing with MFC or ATL, so I had to search for old books, many out of print, which were about programming Windows using simply C.

Now I am not a C programmer. I don’t even like C, even though I have had a few C compilers over the years but they never caught my attention. Surprisingly though, there were a few Windows books which were so well written, even though about C, that I could learn many of the things I needed to know. I started on my path to learn the Windows WIN32 API. It took time, but with the right books, written simply, I began to grasp it. The interesting thing for me though, was that I found that the BASIC versions of what I wrote compared to a C version were much easier to code and much easier to read.  Windows was written in C, so it took me time to grasp many of its concepts, functions, structures and so forth. Personally, I feel that the Windows API is actually very well written and has many advantages. The problem is that it was written in C, so it carries the terse syntax and complexity of C which made it harder to learn than it needed to be. Seeing WIN32 code, but in BASIC made me more easily make sense of what was going on. If only Windows has been written in BASIC, rather than C, maybe WIN32 programming would still be in fashion today.

Actually, a well written BASIC compiler can have many advantages. One thing I appreciated about PowerBasic was its strong string command set. PowerBasic, unlike C and many indie BASICs on the web which borrow heavily from C, uses the Windows OLE APIs for the variable length string data type. OLE strings don’t require a zero character for an end of string. They can contain 100% binary data (from byte 0 to 255) of any length. Working with the Windows API does not require C, but there are BASIC language compilers today which can do much of what C does. Languages like PureBasic and FreeBasic  are examples.

WIN32 code written in BASIC, I found to be easier to read than C. Also WIN32 coding, while not easy, lends itself to a programmer seeing the need to write modular code much like old time BASIC programmers did. Building quality libraries, especially for user interface code was quite common for old time BASIC programmers. The old saying “don’t reinvent the wheel” is fitting. If code was complex, why not build a reusable routine so the next time you simply call your library. Unlike todays programmers who get bogged down with object oriented programming, old time BASIC programmers became very adept at building reusable libraries using simple functions and procedures. Modular design makes sense, but it need not be overly complex for it to work.

The “Internet of Things”

The coming “Internet of Things” means there is a need for smaller, faster software. Tiny devices won’t run at optimial speeds if the software is overly bloated.  BASIC programmers have a history of writing small and fast software, despite the stories todays programmers have been told. Yes, we have been using compilers, working directly with machine language and working with simple API’s for a very long time. If there was one thing this old time programmer would like to see in the software world, it would be a resurgence in BASIC. If a company wants to build the next generation of “Internet of Things” devices, why not develop operating systems which lend themselves to being simple? Why not write API’s which are simple in design from the ground up? Why not build the next generation of not C, but BASIC compilers, capable of being used by the average person ?  Why not build BASIC compilers capable of being used to write those next generation compilers ?

BASIC code leans towards simplicity. BASIC tends to be more readable. BASIC and the “Internet of Things” would go like a hand in a glove, a perfect fit.

 

 


Comments Off

They have done it !!! The $99 Windows tablet.

Did I have it right or what ?  Yes, in one of my blog articles I discussed how it should be possible to get Windows tablets down to $99.

Well, here it is! Hewlett Packard has done it. Yes, the HP Stream 7 tablet is the first $99 Windows tablet and it is about time.

Now the challenge for the coming new generation of low cost Windows tablets will be writing software which can push the limits of the hardware.

Writing software using the raw WIN32 API is the way to go. Compared to dot.net, such software should be leaner and faster.

EZGUI 5.0 Professional (along with PowerBasic ) is powerful combination for developing software for this coming generation of Windows tablets.

 


Comments Off