BASIC is not dead! Neither is the WIN32! Time to end the myth. (Part 3)

This is a continuation of two other articles about BASIC, but with a twist, the addition of the WIN32 into the equation.

The short version of my story is that I am a long time BASIC programmer and never regretted it. First experience with BASIC was back in 1975. After all those years it makes sense to explain not only why use BASIC, but to expose some of the myths about it. The first is that BASIC is a bad language and its history as an interpreter makes it a poor tool for software development today (which is false).

BASIC has been and has always been an advanced language. Doubt that ? When Dartmouth created BASIC is was a miracle for its time. The idea of a mainframe time sharing, so hundreds of students could code on it at the same time was astounding to say the least. No other language could do that at the time. Why BASIC ? Easy to code and easy to interpret. You see, interpreting a programming language at runtime is a very difficult thing to do. You think your old C compiler was slow and took forever to compile an app (aka. the coffee break syndrome), imagine interpreting BASIC dynamically at runtime and producing a decent performance (albeit not as fast as compiled languages of course). Not an easy task to accomplish. Yet, BASIC was allowing students to code in real time (rather than type out cards for FORTRAN and waiting for the computer department to run your card batch days later).

In the 1980’s came the generation of the home computer. Remember the Commodore 64, Atari 400/800, TI99/4A, etc ? The Commodore had 64 KB of memory and 1 mhz CPU. At least half of the memory addresses were allocated for ROM, so not much left for your own programs. Imagine if you had to squeeze Windows into that. You couldn’t even squeeze the core console API engine (text only) of the WIN32 into that. You couldn’t even squeeze Windows 95 into that. Yet, those home computers allowed programmers to write code and get immediate results. You would be amazed at what some people used Commodore 64’s for back then. Now some may point to the fact that BASIC was an interpreted language then and a poor substitute for a real language like C. Myth #2, BASIC was not solely an interpreted language. Back in the 1980’s I was using the ABACUS BASIC compiler to convert my BASIC programs into pure machine language and what a performance boost. I even wrote my own compiler (BASIC like with subset of BASIC) using the ABACUS compiler. It took a awhile to compile an app, but the final results was amazing. To add to that I learned 6502 machine language to allow me to enhance my programs.

Then came the Windows days and Visual BASIC. No matter what people say, Visual BASIC was a game changer. It introduced visual design to programming, which not even C supported at the time. No wonder it was a hit. Now the “citizen programmer” , as some have coined it, came into being and people who were engineers, tradesmen or the like could write software for their specific job tasks. They actually became better software developers than the so called “real” programmers trained in college. Why ?

Being a programmer and proficient with a programming language is not all it takes to be a good programmer. If you have to write an application for say a bank, what does a programmer know about banking ? If you have to write an application for a civil engineer, what does a programmer know about civil engineering ? Nothing ! The citizen programmer was someone who knew their own trade, but also learned how to program in BASIC (an easy, natural language a citizen could understand) and so they had the advantage. They knew their trade better than any programmer did, so they often wrote software which others in their trade would appreciate better. This is why Visual Basic became the hit it was. True, so called “real” programmers laughed at it , but the citizen programmers were knocking out app after app faster than the C programmers could take a couple dozen extended coffee breaks.

The first generation of Visual BASIC did have a weakness though. It was a PCode compiler and not a native code (machine code) compiler. Performance took a hit. So did those citizen programmers sit back and ignore this because of their ignorance ? No, they clamored for more and more. Better features, better performance. Eventually Microsoft caught on and made later versions of Visual Basic a real native code compiler. Visual Basic now put C to shame. It became the heart and soul of the citizen programmer.

The problem with Visual Basic was that it was not designed from the ground up to be a full blown programming language. Microsoft bought the rights to a third party developed tool (see: https://en.wikipedia.org/wiki/Alan_Cooper ) and molded it into Visual Basic. It worked and was a success ! But one flaw. Visual Basic was not built from the ground up with the WIN32 API in mind and how Windows really worked under the hood. It lacked the raw power of pure C.

Visual Design has its place in the Windows world, but nothing replaces pure hard core coding. Visual Basic had captured the visual design market, but it was lacking when it came to pure hard core coding. Books were written about how to leverage the WIN32 API in Visual Basic, but there is a real learning curve when it comes to the WIN32 API. Even C programmers felt that challenge and Microsoft felt the need to make their life easier with the likes of MFC (Microsoft Foundation Classes) and later C++ became the rage. To make things worse, cross platform development became the panacea of software development and everybody wanted to develop for the web. Microsoft had to come up with a solution and dot.net was born and the slow death of Visual Basic began. First when VB.NET replaced Visual Basic. In time C# became the favorite for dot.net and even VB.NET is in a slow death spiral.

A few key lessons have been lost over time. First, BASIC was not the problem. The creation of the dot.net craze was not because of the failings of languages like Visual Basic, but because of the desire for cross platform development. Cross platform development , while it does work, also has failed because of one key false premise. The idea that a perfect cross platform development tool is the panacea to reach for is wrong, plain and simple. Why ? Because to achieve cross platform, compromises are required, plain and simple. Anyone who says otherwise is not telling you the whole truth. GUI frameworks like QT were necessary to accomplish this, because different platforms have different GUI API’s which are not 100% compatible with each other. Compromises had to be made so that one source code would compile to multiple platforms. This is why at times one’s favorite app does not seem like other apps on the platform. They are ‘fudges” to make it work on the platform you use, but it does not look quite native. Cross platform design is the problem. Yes, there is a time and place for cross platform design. But their are also times when a pure native experience is desired and preferred. Windows is the most popular desktop platform today and it makes sense to write apps which take advantage of all that platform offers.

The second lesson is that on the Windows platform, the WIN32 API is the core of the operating system and always will be. All the fancy stuff added in later years is simply glued on top of the WIN32 API. If you want the best performance possible on Windows, then the closer you get to the core WIN32 API, the better. Sadly, todays development tools give the impression one is a great programmer, since they can plug and play all sorts of prewritten libraries and components. True they are necessary, but the moment that favorite component is no longer supported, then ones app is in crisis because you may not be able to update the app because a new version of the component is no longer available. Or you want to go beyond what that component does, but it is a fixed “black box” and you can’t modify it. You are locked in. Or maybe there is no existing library or component available for the task you desire, so where do you start in building your own.

Well, you could always fall back and learn pure C (not C++) and write the components from scratch using the WIN32 API. Classic Visual Basic programmers often found themselves falling back to the WIN32 API and writing the code themselves and there is a lesson in this for us today. The need for low level control has always existed in computer programming. That old fashioned Commodore 64 came with a manual that gave you all you needed to know about the inner workings of the computer. A programmer, even using BASIC, was never limited by the programming language. You could add machine code whenever you needed it. There were low level hooks even into the BASIC interpreter so one could extend the language. One company even pushed the limits of the Commodore 64 and created a full blown GUI for it called GEOS (see: https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system) ). Imagine that ! A Windows like experience on the lowly Commodore 64.

Getting back to BASIC. Could a BASIC programmer actually write code just like a pure C programmer could on Windows ? The answer is yes. There are a number of BASIC programming languages around today for Windows such as:

Some target cross platform (albeit with compromises), some target OpenGL, some are interpreted and a few actually allow one to write code similar to a pure C programmer using the WIN32 API. I personally have licenses for PureBasic, GLBasic and have played around with Freebasic and ThinBasic.

There are more advanced BASIC (or BASIC like) development tools which offer a more Visual Basic like experience such as:

XOJO https://www.xojo.com/

WINDEV https://windev.com/

RADBASIC https://www.radbasic.dev/

TWINBASIC https://twinbasic.com/

Lastly, I would like to mention Powerbasic which is what I use. The reason for this is that Powerbasic, IMO, is more akin to old fashioned C. It is the closest one can get to the WIN32 API. Having been working with the WIN32 for about 20 years now, I can attest to the fact that a BASIC compiler can produce the same performance and have the same raw power as the C language can. The WIN32 API is not easy to learn, but it is worthwhile to learn it. No matter what language you code in, you have the option of taking advantage of the raw power of the WIN32 API. True, one may need the help of a GUI command set provided in the language of choice to make it easier to work with. Each of the BASIC’s above take a different approach to this. But as far as raw power and performance, the lower level the GUI framework used the better. Does it make a difference ?

In my experience Powerbasic originally did not have a GUI command set, so one had to resort to coding directly to the WIN32 API. While Powerbasic in later years added a simple wrapper command set over the WIN32 API’s Dialog engine, called DDT (Dynamic Dialog Tools) which many have become productive with, since I started before that was available I needed to build my own GUI framework which accessed the WIN32 API. Since this framework became more powerful over time I stuck with that. Yes, it does make sense to provide a slightly higher level GUI command set which is easier than the WIN32 API, but this does not mean that one should be shielded from it completely, nor should the framework be so top heavy that it significantly degrades performance. Also this allows me to develop on a very minimal PC and does not require the latest PC hardware just to be able to compile without taking a long coffee break. So what does your development PC look like ? Latest core I7 (or I9) ? 32 GB ram ? Fastest SSD on the market ?

My current development PC is an ancient remanufactured desktop PC I purchased for less than $100. I upgraded it from the Celeron CPU to an Intel Core2 Q8200 cpu running at 2.33 ghz and to 4 Gb ram. The harddrive is 145 GB and I later added a second 500 GB hard drive. It is running the latest version of Windows 10. While it takes forever for even an older Visual Studio to load up, I can start the Powerbasic IDE in a few seconds and then compile my GUI framework which is over 50,000 lines of WIN32 code in about 1 or 2 seconds. The Powerbasic compiler was written in assembler so it is fast as lightning. The results is what matters and this is where not only Powerbasic, but also using the WIN32 API as the basis of a GUI framework really shines. My GUI framework (I call it EZGUI 5.0 Professional) is only about 1 megabyte in size. Yes, it can fit on an old fashioned floppy disk. A number of my customers who use it are using it in commercial software. (see video: https://www.youtube.com/watch?v=1rp2NtuxACg&t=272s and pause at about 4 minutes and 32 seconds and notice laptop running the deep water robot. This app was written by my customer using my GUI framework). The GUI framework has a command set of over 1000 GUI commands. Why software needs to be bloated today is shame. Why Windows even needs more than 2 GB memory is shame also.

The point is that the WIN32 API is an amazingly powerful framework. It supports so many systems for customization that one can do almost anything with it. I use things like Ownerdraw, Customdraw, subclassing, superclassing, threads, DIB sections (device independent bitmaps) and even OpenGL (which most Windows PC’s provide access to). Not only can I access the built in system controls, but I can create new controls of my own design. I have created custom controls such as Files Listbox, Property Listbox, MCI control, Splitterbar control, Shape/Hotspot control, Canvas control, OpenGL Canvas control and more. One of the challenges in making my own GUI framework was how to build a visual designer for it. The WIN32 API has no built in drag and drop engine for building Form designers. So designed my own custom Drag Handle control and a subclassing engine which had a visual design mode to create a simple to use drag and drop engine. One of the hardest things I had to accomplish with this was how to draw multiple controls, even hundreds at one time and do it smoothly without flicker. Again, using the WIN32 I was able to build my own solution.

The drag handle controls had to work together to define a series of rectangles and then using a memory buffer to draw the rectangles on top of the form (BitBlt as one image) and move them smoothly was a challange, but doable with the WIN32 API.

One of the lessons I learned early on was that any library or component which was a closed black box would have limitations. So I added to my GUI framework “hooks” into key engines in it, so one could open up that black box and modify how it works. I added hooks into the core message loop, the framework window procedure, etc. I provided mechanisms to make it easy to work directly with the WIN32 so one was never left in the lurch. Even classic Visual Basic did not allow you to access everything the WIN32 provided (or at least not easily). Some things were challenges like subclassing controls. I built into my GUI framework an event engine and one event is the subclass event. One can easily subclass any control (even third party ones) and then get an event where every window message processed one could preprocess it in your own event routine. Since the WIN32 provided hooks into its own engines, why not do this in a GUI framework on top.

The lesson is this is simple. BASIC is not and never has been the problem. BASIC is an advanced language which has grown over the years. I can do almost anything one can do in C, using Powerbasic. I can work with complex structures, pointers, direct memory access, threads, etc. I can even use inline assembler. Also a BASIC written from the ground up, similar to C and with all the advanced features can allow one to build small and fast Windows apps. Making a BASIC which works in concert with the WIN32 API and allowing it low level access (API functions, memory, etc.) can allow one to build apps only rivalled by pure C. Yes, you can add object oriented coding styles if you like. Powerbasic provides this, but it is not required. One can write apps using a procedural design or an OOP based design. The choice is up to the programmer. For your information, the WIN32 is not object oriented at its core. True some OOP has been built on top it, but the core WIN32 is procedurally based. This is why non-OOP based WIN32 apps perform so well. Much less overhead. If you want to build the fastest possible Windows app then procedural WIN32 design is the way to go.

BASIC is not a dead language. New generations of BASIC keep coming. The syntax of BASIC has always been a draw for programmers, especially the citizen programmer. Currently I have to work with a customer (writing an app in BASIC) and I have to do a lot of examining of code written in C (in firmware for a microprocessor) on the project. While I am not able to write C, I am quite capable of reading pure C (procedural style). All the books I read to learn how to program with the WIN32 API were written for C programmers, not BASIC programmers. With all the wading into C I have done over the years, I keep coming back to the same conclusion. Why is the C language so terse ? While doesn’t it have a more natural syntax. It just can not compare to BASIC. One simple question. Why hasn’t C gotten past the curly bracket yet ? Couldn’t they make a C syntax which simply uses the end of line or carriage return as part of the syntax, like BASIC, like Python. I may be wrong about this, but my impression is that the curly bracket is an old fashioned limitation imposed by the slow compilers from the old days where it took hours to compile an app. Not easy to make a compiler run fast on a 25 mhz computer. The curly bracket simply makes it easier on the compiler, not the programmer. With such powerful computers today, surely someone could design a C compiler which no longer requires the curly bracket. The WIN32 code I write with BASIC is so much easier to understand than the same C code. Also C is still stuck in the old null terminated method for handling strings. Some BASIC’s are too. It is not so hard to define a string data type which tracks the string length rather than impose the use of a null termination. The WIN32 already has this feature. In C it is called a BSTR, but few programmers use it since it seems relegated to use only in COM in C apps. The Powerbasic compiler uses the BSTR as its main string data type, rather than null terminated (it also supports null terminated if you need it which it calls ASCIIZ). Variable length strings in Powerbasic are BSTR’s (uses OLE API’s in WIN32) and one can even embed true binary data in it, since character zero is allowed in a string. IMO Powerbasic has the most powerful string engines of any language today. So why does a BASIC provide a more advanced mechanism that does C (yes, C supports BSTR’s but that is not a C native data type but is simply a WIN32 data type). I can create a huge variable length string in Powerbasic like this:

 MSGBOX "start"
 LOCAL MyVar AS STRING
 MyVar = STRING$(1000000000, " ")
 MSGBOX "length="+STR$(LEN(MyVar))

Yes, a simple string variable with the length of 1 billion characters. I can store any binary data in it I like. it takes a second or two to work, but it is 1 GB remember. I can even use that memory and using a pointer using the DIM AT command and define an array structures/numbers inside of it. Powerbasic even puts a null terminator at the end of the string (not part of it, but one byte after it) so one can easily use the STRPTR function and pass the string to a WIN32 API as if it were a null terminated string (of course the string can not contain a zero character in it when used this way, but that is what the WIN32 expects, not a limitation of Powerbasic).

Yes, a BASIC compiler can rival a C compiler. Particularly when it targets a single platform such as Windows (C compilers do have an important place when targeting different platforms, but some BASICs can do so similarly). Especially when it comes to writing extremely small and fast apps BASIC is also up to the task.

Feel free to download this simple test app which is written 100% in Powerbasic (my GUI framework is also 100% written in Powerbasic).

Test app which demos GUI framework written using WIN32: http://cwsof.com/download/testwin8.zip

This one sample app demonstrates things like Ownerdraw, Customdraw, 2D sprite animation, Visual Design engine, OpenGL 3D animation, complex window regions (non-rectangular forms), custom controls and MCI. The entire app is only 1.2 megabytes (would fit on a floppy disk) (also not including graphics).

The conclusion is that BASIC is not a dead language, nor should it be allowed to die. Being over 60 years old myself, I may be near the end of my programming career and not up to date with the latest new fangled programming language, but I do know one thing. Like many other BASIC programmers out there, I made a living using BASIC over decades and have pushed it to its limits. I have customers using the GUI framework I developed which are able to build complex commercial apps which are being used all over the world, some in mission critical environments. If I had one hope for the programming world, it would be to take a second look at BASIC and see why it has stayed the course of time. With all the resources of the big tech companies out there, surely someone could see the value in putting resources into the next generation of BASIC, rather than leave it up to small tech companies and independent developers. C programmers try your hand at recreating my sample app above in C using just the WIN32 API (or say MFC). Other programmers feel free to recreate the app using whatever you use, but with one restriction, the entire app (not counting graphics or media) must be less than 2 megabytes in size and run on any version of Windows from Windows XP to Windows 11.

Lastly, please the messages posted to those who actually use BASIC and have made a living using it. No need for the nay-sayers , C programmers and the like to post. We BASIC programmers already know the story quite well by now. Any BASIC programmer worth his salt who has been programming in it for years already knows what the rest of the programming world thinks of BASIC. No need to rehash it over again.

tagged with , , , ,