Saturday, 20 of December of 2014

Tag » Windows

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

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