Monday, 21 of April of 2014

After 50 years, BASIC still misunderstood !

It appears that the BASIC programming language has been around a lot longer than most of us have realized. It had its beginnings back in 1964 at Dartmouth College. BASIC has a long and rich history as a programming language, but often today it is viewed as a beginners language or childs language. What few may appreciate is how great an impact BASIC has had on programming and how it has grown over time. When programmers hear the name BASIC today, they often think about a slow interpreted language with little use for real world programming. This is the furthest thing from the truth though.


Having experienced writing a FORTRAN program using punch cards back in the 1970′s, I can attest to how amazing it was to use BASIC on a video terminal in real time. You could get immediate results when writing code. Write a few lines of code and then RUN it and you had immediate results. Coding became something the average person could do. But what made BASIC so well received ?

Aside from the immediate results one got from using an interpreted language, the real key to BASIC was its more natural syntax. If one had any experience with basic algebra in school, picking up the BASIC language was not very difficult. The idea of variables to store numbers, basic mathematical expressions along with a simple, easy to use command language for adding logic made BASIC just make sense. It was coding using language we are used to. Some have referred to it as a more “natural”programming language. Compared to languages of today, like C++, it is obvious why a language like BASIC would be appealing.

But could you get real work done with BASIC ?

Absolutely !  As quickly as people started learning BASIC, they also started finding ways to get some real work done with it.  The reason for programming languages is to be able to get real work done with a computer. As long as this is accomplished, then a programming language is valuable. So, did a lot of programmers get some real work done with BASIC ? More than many may imagine. Actually BASIC created a different breed of programmer. Rather than simply leaving programming in the hands of a select few highly trained professionals, BASIC brought programming to the average person. A engineer could write programs to solve daily problems on his job. An accountant could write programs to make the daily drudgery of working with lots of numbers faster and more accurate. The first tasks these budding programmers solved likely were simple, but as one task was solved, they often would tackle something even more complex next. Before long, people were learning on their own how to write some very complex software, even turning what started as a hobby into a real business.  They took their knowledge of their specific trade and used programming as a way to create new ways to solve all sorts of problems. They got real work done and did it well.

BASIC, the language, grew in ways few would have expected.

The interesting thing about BASIC is that the creators of the different BASIC flavors (brands) often did not expect the results they got. What may have been viewed as a training or hobby programming language, was often used to accomplish real work in the business world and was quite successfully. One of the best examples of this was Visual Basic. Visual Basic, for all practical purpose, was not intended to replace so called higher level languages like C. But something amazing happened with Visual Basic. People who were not professional programmers or even trained in college in computer science, were creating commercial software to solve all sorts of problems in business. The number of commercial applications written in Visual Basic by so called “hobby” programmers is likely astounding if one were to actually calculate the actual numbers. Some very good software was written by such “hobby” programmers too.

What some may not appreciate is that those who learned how to program in BASIC were (and are today) just as interested in finding ways to push the boundaries of software development as any college trained C (or C++) programmer is. This has been going on for a long time, whether the mainstream programming world has noticed. Let’s go back a few years and see.

BASIC on every computer !

Back in the 1980′s, BASIC found its way onto nearly every desktop and home computer. GWBasic came with early MSDOS and later another version called QBasic shipped with Microsoft DOS. I was using BASIC back before DOS on CPM computers to write business applications. When the hobby home computer became popular, with the TI-99/4A computer by Texas Instruments, the Atari computers and the famous Commodore 64, they all came with a version of BASIC burned into ROM. While slow in execution speed, the languages made up for that in ease of use and accessability. BASIC was everywhere !

BASIC programmers are more than hobby programmers !

But BASIC programmers quickly learned to want more. Did they all switch to C ? No, they loved BASIC, so instead they found ways to expand the language, to improve it. Programmers using ROM based Basics learned machine language so they could extend the language. I once wrote such an extension to Commodore ROM basic which added sprite and graphic commands to the language. Now despite the misconception that all BASIC’s were (or are) interpretors, I started using a real BASIC language compiler on my Commodore 64 back in the 1980′s.  Abacus had a very nice compiler which produced programs nearly as fast as those hand coded in assembler and it was BASIC. I used the Abacus compiler to write my own subset BASIC compiler specifically for producing programs which were even closer to those written in assembler, in speed.

BASIC programmers have long appreciated the value of an optimized compiler. They stopped using line numbers and interpreted languages a long time ago. BASIC over the years picked up some of the best features from other languages, like Pascal and C. But BASIC though was about ease of coding. New features were not added to BASIC simply to make it the same as other languages, but simply to gain the best feature sets possible while maintaining the naturalness of BASIC. They wanted the best of both worlds, power and ease of use. What BASIC programmers didn’t want was added complexity to programming. Many different flavors of BASIC over the years came along and tried to maintain that goal of ease of programming. In the DOS days, BASIC programmers would use tools like screen layout designers, code generators and the like. In the Windows years, different versions of BASIC came along which provided drag and drop visual designers. If the BASIC language some used didn’t have a visual designer, its community of users often built their own. In the early Windows years there were a number of commercial BASIC’s created, some by some very big companies. Aside from Visual Basic 1.0, there was GFA Basic, CA Realizer and a number of independent BASIC’s (indie developers who created shareware Basic languages or freeware). Early versions of Visual Basic were PCode compilers and in time users demanded more power and speed and Visual Basic 5.0 introduced a real compiler backend which was nearly as good as many a C compiler. In the DOS days some very powerful BASIC compilers were commercially sold, QuickBasic (and PDS 7.1) from Microsoft and TurboBasic from Borland (which still exists today as Powerbasic). Those BASIC compilers produced very high quality applications. Back when I was using Microsoft’s PDS 7.1 Basic compiler, I was writing some extension libraries in assembler to add even more power to the language. The way I compiled the applications was so complex, I couldn’t do it from the IDE and had to write batch files which would compile my applications just the right way so I could get the most out of the compiler.

Yes, BASIC programmers were (and still are) a unique breed. They want to be able to produce the best and the fastest software possible and were willing to push the limits of the compilers they used. As a long time BASIC programmer myself, I often found myself looking for something better. I wanted to program faster. I wanted to produce smaller and faster applications. I wanted more powerful features. But like many other BASIC programmers, it was not a matter of switching to a different language, like C++, but in finding ways to make BASIC better. There is something about BASIC which just makes it feel right for many programmers. Personally, I think it has a lot to do with the more natural syntax of the language. While many modern BASICs support object oriented syntax when wanted, many long time BASIC programmers find a more procedural style of coding preferable, since it can make coding simpler while producing smaller and faster applications. But what ever the reasons for sticking with BASIC and even the style of coding each BASIC programmer uses, BASIC is a language that just won’t go away.


Leave a comment

Code Minimalism ! What is it ?

If there was one complaint I have with a lot of code today it is the lack of easy readability. True, programming language code by its nature can’t always be easy to read. But shouldn’t it be the goal of programmers to write code which is more readable ?

Some to learn from BASIC

It is interesting that the name BASIC is an acronym for “Beginners All-purpose Symbolic Instruction Code”. Consider one part of that acronym, “Beginners”. Why for beginners ? The idea is that it would be easier for a novice to be able to code with it. How would that be accomplished ? The only way to make a programming language easier for a novice is to remove complexity and terseness. One term coined by some BASIC users is a more “natural” language or syntax. In essense it means, more readable or closer to natural languages we use. But isn’t better readability something that a professional programmer should strive for ? Absolutely ! Why ?

If a programmer writes code for a business and then he leaves the company, someone else will have to come along and read his/her code. If the code is easily readable, then the transition to a different programmer is much faster and more reliable. If it is not, then all sorts of nightmares occur for the next programmer, trying to make sense of someone elses code. And even more important than this, code readability determines how easy it will be to debug the software. Programmers often want to automate debugging, as if somehow the computer can figure out your code and find your mistakes for you. True a software debugger is useful, but often it works best in concert with the programmer, not by itself. Debugging often comes down to just reading the code back and examining it with a careful eye. Now the more readabile the code is, the easier it is for the programmer to do this.

It is interesting that the very thing BASIC was designed to do, is often considered a negative by most main stream programmers. “Oh, BASIC is for beginners only”, “Basic is hobby language and not for serious programmers” or “BASIC teaches all the wrong things” may be often be heard from main stream professional programmers. But yet, is not the idea of a more natural programming language a good thing and something for a professional to strive for ?

The BASIC language compilers of today have come a long way from the early BASIC interpreters of old. While maintaining much of the core simplicity of the original language, they have added more complex and powerful features. But the idea of a simpler and easier code syntax still remains.

Modular Design

Over the years I have dealt with a good number of other programmers. My company designs tools for programmers, so I often see the code from many different programmers who use my companies tools. When doing research for development I browse programming forums often trying to learn as much as possible from others code. The one thing I notice often is the lack of modular design in code to make code more readable. Modular design is often used to break up the code into smaller workable pieces, but modular design often is not used for the sake of making code more readable. In the same way a programming language can be designed for better code readability, so too can our own code accomplish this. Let me dem0nstrate. The WIN32 API function CreateFont has 14 different parameters which need to be passed. The height of the font must be precalculated based on the calculation of:

nHeight = -MulDiv(PointSize, GetDeviceCaps(hDC, LOGPIXELSY), 72)

The API returns a font handle, which needs to be stored in a variable to be used later, which requires even more code (ie. Global variables when writing procedural style code). Personally I found this a lot of code, when I often do the exact same thing when creating a font. The fonts I use are used on normal window DC’s. Rarely if ever do I need a font using anything but pixels for logical coordinates. The fonts need to be defined using a standard point size, rather than pixels. Why would I want to use CreateFont every time I need a new font ?

Since I was writing a GUI framework designed to make things easier, I used some of the same principles which make the BASIC language so easy to read. First, a trick I learned from old fashioned DOS basic was to create a font pool using an index system. In DOS basic, colors are handled this way. Each RGB color has an index. Index zero is Black, and then from there the colors are Dark Blue (1), Dark Green (2) and so on. So why not use something similar with fonts ?

Windows provides some predefined system fonts using the GetStockObject so I load those fonts into the beginning of the font pool (static internal array) for indexes 0 to 5. From index 6 on and can define custom fonts and the subroutine I wrote to create new fonts (which calls CreateFont) has very simple parameters like this:

EZ_DefFont  MyFontIndex, MyFontFace, MyFontPointSize , MyFontAttributes

MyFontIndex is simple an integer number which defines the fonts index in the font pool.

MyFontface is a string which defines the fonts name.

MyFontPointSize is an integer which defines the fonts point size.

MyFontAttributes is a simple string which defines the general attributes (or properties) of the font using a single character for each attribute.

Now in use it is even easier. Let’s see some examples:

EZ_DefFont 7, “Arial”, 10, “VIBQ”

This defines font number 7 as Arial, 10 point and with the attributes Variable pitch (V), Italic (I), Bold face (B) and Letter Quality (Q).

Now I can use this font anywhere in my program simply by refering to it by its index (number 7).

The subroutine EZ_DefFont internally uses about 150 lines of code in it and it calls APIs like MulDiv, CreateFont, GetDeviceCaps, GetMapMode, GetDC and ReleaseDC. The GUI framework was designed as a state machine so this subroutine can define fonts for normal windows (controls), DC drawing, Drawing in the frameworks Canvas control and even the Printer. By simply using the C attribute the subroutine defaults to the current Canvas. By simply using the P attribute it defaults to the current printer. So the command is well rounded. It can add weight to the fonts in increments of 100 units with the + attribute and can even define rotated fonts using a macro string like “{90}” in the attributes. By using a simple string to pass the attributes and using a single character for each attribute it makes it easier to code and easier to read. True the execution speed is slower than if I simply called CreateFont, but in most cases the ease of coding outweights the extra overhead of the subroutine.

The key is simplicity

The point of all of this is simplicity. The less characters used in code, the easier it is to read. The simpler command statements are the easier the code is to read.  When one prewritten modular subroutine can accomplish what would have taken dozens of lines of code, then code is easier to read. I found this technique decreases code size significantly and makes code readability significantly better. For example, when I first learned how to create a ToolBar control using the WIN32 API, it was a bit complex. So much code for such a simple control ! When writing a GUI framework I had the goal making it as simple as possible. Here is an example of how the framework creates a complete toolbar control using one line of code:

EZ_Toolbar 50, “#LargeSTD”, “BBBBBBBBBBBB”, “ON32X32{4}VT”

The command defines a toolbar in this case, with an ID of 50, using the standard built in Large bitmap (“#LargeSTD”) , defining 12 buttons (the BBB‘s) with the attributes of Open edge (O), No divider line (N), 32 x 32 pixel images (32X32), Vertical toolbar (V) and Tabstop (T).

The idea is code condensing. Accomplishing as much as possible with as little code as possible. The EZ_ToolBar command in the GUI framework likely calls over 500 lines of code, maybe more. The subroutine has over 400 lines of code in it, but it calls a number of other routines in the GUI framework internally, so it is hard to calculate how many lines of code actually get used by this one routine in total.

The benefits of Procedural Design

While Object Oriented Program is all the rage today, the techniques noted above about code simplification, in my opinion, work best with a more procedural style of coding. Whether you use Basic like me or use a language like C (rather than C++), procedural style coding lends itself to this kind of code minimalism. In my case, rather that use objects and classes I use a state machine for handling a lot of the GUI features. Threading is only used for non-GUI tasks, so all the code will be executed in a linear fashion so a state machine works well in my case. Even with an event based GUI framework this still works well (my GUI engine is event based). Procedural style code using a state machine can produce a much smaller (and with less code) application than its OOP counterpart.

Here is application example you can download:  Windows 8 Compatibility Test App

This app I created for testing my GUI framework and its features to make sure it worked on Windows 8 and that the WIN32 still supported the features. Make sure your PC has the proper OpenGL drivers for the 3D part (only requires OpenGL 2.0 or less).

The executable is only 169 Kilobytes in size, which is small for what it does. Most of the work is being done by the GUI framework which are DLLs (dynamic link libraries). This means the code that created the EXE was minimal, compared to if I wrote it entirely using the WIN32 API. The GUI framework only calls the WIN32 API and thing else, so no other frameworks are being used (no MFC, no ATL, no Dot.Net). Let me show you a little of the source code for this demo app.

If you select the CustomDraw option from the list of features, you will see a Listview control which is drawn using customdraw. It is a standard WIN32 Listview control, but you will notice that the columns use different colors and different fonts to produce a very nice effect which makes the control more meaningful to the end user. Using the WIN32 API, it requires a bit of code, using a GUI framework designed for minimalism the code used in this app is this:

SUB DMAIN_CDLISTVIEW_Events( MyID&, CMsg&, CVal&, Cancel&)
          CASE %EZ_Selected
          CASE %EZ_NoCustomDraw
               Cancel&=1      ‘ force custom draw
          CASE %EZ_CustomDraw
               LOCAL I&, SI&, T$
               I&=EZ_GetCDrawItem(CVal&, SI&)
               SELECT CASE SI&
                   CASE 0
                       EZ_SetCDrawItem CVal&, 90, 0,15
                   CASE 1
                       EZ_SetCDrawItem CVal&, 91, 2,26
                   CASE 2
                       T$=EZ_GetLVItemText(“DMain”, MyID&, I&,SI&)
                       IF T$=”In Stock” THEN
                            EZ_SetCDrawItem CVal&, 92, 1,15
                            EZ_SetCDrawItem CVal&, 93, 4,28
                       END IF
                   CASE ELSE
                       EZ_SetCDrawItem CVal&, 90, 0,-1
               END SELECT
          CASE ELSE

The command EZ_SetCDrawItem in the framework can define the foreground, background colors and the font for each individual item in the listview control. The control will look like this:



















It is not the framework that is important, but the idea of code minimalism. The less code you use to define a task, the more readable it is and the easier it is to code and debug. One of the reasons I use this technique (code minimalism) is that rather than use a lot of “canned” objects, I need to be able to have an almost endless set of choices for customization. To do this using objects and classes would increase the code base, rather than decrease it. Using a more procedural style of coding with a state machine, it allows me to provide more choices with less code.

To sum it up

The idea discussed in this artile is about code minimalism, using as little code as possible to accomplish a task. If programmers today did not have the benefit of a visual environment for designing their applications and a code editor with intellisense, they likely would appreciate how much work it really involved in coding an application. When I designed a GUI framework, while I did build a drag and drop Visual Designer/Code Generator for it, it was also designed so it could be used to hand code an entire application using a simple code editor (no designer/no intellisense). There are actually a number of programmers who use this GUI framework this way, with just a code editor. This could not be done without the benefit of code minimalism. Even when using a higher level visual design environment, code minimalism makes the life of the visual designer much easier and it makes tracking code flow of generated code much easier to follow. So maybe this is something we cal learn from BASIC ! If code was easier to code and easier to read and it required much less code to accomplish tasks (aka. code minimalism) wouldn’t than make our life as programmers much easier ? Wouldn’t it make it easier to debug our applications ?



Comments Off

The $99 Windows Tablet ! Is it possible ?

Maybe this is only possible in my imagination, but I really do think it could be possible and if so it could bring Windows to a totally different use than ever imagined before.

Let’s start with the Desktop !

What does this have to do with the ultimate Windows tablet ? A lot, but be patient and I will get to the point. While some may think the desktop PC is obsolete, I for one really doubt that. The PC is for getting real work done. For some this may mean a laptop running Windows, but for many it means a real desktop PC, with a large monitor, a quality keyboard and a real mouse. Laptops are great for those on the go, but some just need a large display and once you start making the display large enough, it really does not make sense to make it mobile anymore. Both my wife and I use desktop PC’s, with primary 22 inch monitors (1920 x 1080 pixels)  plus a second monitor along side (which can be a bit smaller in size). She uses hers for working with graphics and animation software and I for programming. Dual monitors just make sense for many applications. The point is, no laptop and definitely no tablet will can replace the desktop PC for many tasks. But tablets need not be PC replacements either. They only need to  be useful within their own context (light weight and mobile).

Now add to this the keyboard. If anyone thinks that a touch keyboard or even a light weight external tablet keyboard can replace a quality desktop keyboard, then I really wonder how much typing they really do. I am so picky about my desktop keyboard, that I am still using an over 20 year old IBM model M keyboard with real mechanical keys. The speed at which I can type on this keyboard is so fast compared to any laptop keyboard, that it irreplaceable to me. A tablet could never even comes close in usability for typing in comparison. Real work requires a computer designed for the task at hand and desktop PC’s likely will always have a place, especially in business. It is important to use the right device for the right task.

Laptops are middle of the road devices

The laptop is very valuable as well. Laptops give you a more middle of the road solution. They have the power of a desktop PC, but they have the benefit of being mobile. For me the biggest weakness of a laptop is the keyboard and the touch pad. True, some get very good at using a laptop, but for some a laptop keyboard keyboard just can’t replace a quality desktop keyboard and a touchpad just can’t come close to the good old mouse. That said, many make do and they find the laptop still very useful. For example, my latest laptop I purchased, I opted for a Lenovo brand because of the reviews about their keyboards (they make very good laptop keyboards) and I purchased an external Microsoft Arc Touch mouse which I am very pleased with. Between the Lenovo quality keyboard and the Microsoft Arc Touch mouse, my laptop comes close to being nearly as useful to me as my desktop PC. Still, a 15 inch screen laptop at over 5 lbs, the extra mouse and the laptop messenger bag are not what I would call a total light weight package.

So now we come to tablets

So now we come to tablets. Tablets serve a purpose and are great mobile devices. True, most tablets are likely used by consumers, but my concerns are about using tablets for business purposes. Despite being a computer programmer, I don’t have a fancy smart phone and I am not wasting my time playing hours and hours of the latest mobile game. While I do have both a Windows tablet and two Android tablets, I didn’t get them for the typical consumer consumption tasks most people may use them for. When I browse the web (usually for research for work or for reading the latest news) I typically have my PC browser open with 5, 10 or even 15 tabs open, each with a different web page on them. I will browse one page (to see if the information is useful to my research) while another is downloading. I may watch a podcast once in awhile about something dealing with programming or other tech subjects on my second monitor, while browsing the web on the other. It is all a matter of speed and efficiency. This is all done on my desktop PC and not the tablets. My tablets, while I do have some personal uses for them, are primarily so I can experience how a mobile device works and for testing any software I may create for tablets. I haven’t done much with Android yet, so that is more of a hobby right now, but the Windows tablet was purchased specifically for testing Windows applications I may develop for tablets. But the more I use my tablets, the more I realize the limitations they have and also the key differences between software written for the desktop and software written for tablets (and there is a difference). The idea of a tablet being used as if it were the same thing as a desktop PC is not realistic. Software for tablets need to be written specifically for a tablet in mind.

Now I am coming from the perspective of using tablets for business use, not for the typical consumer use. For years I wrote custom software for a variety of local businesses (from CPM, DOS and then Windows). I know what it means to get work done using technology. Back in the DOS days a typical PC cost $2000 to $3000 each. That was a lot of money back then, so I had to learn how to help my clients make the most out of the technology they purchased.  One of the important lessons I learned was to use the right equipment for the right task, but also to keep the costs to an absolute minimum. I never encouraged a customer to upgrade to the latest computer, simple because it was fashionable. Some of my customers used their computers and software far beyond the typical lifespans most businesses allocate for them. I wrote some DOS applications which amazingly are still in use today. For a business, technology is great, but only if it pays for itself and it does valuable work. So why is this important and what does it have to do with Windows tablets ?

Use the right device for the right job

If a business mistakenly views a tablet as if it is was a full blown PC, then they may end up paying too much money up front for the devices, get less work done with them and may end up wasting a lot of money. Why ? Some software, simply put was meant to be run on a desktop PC with the hardware to support it and not on a tablet.  For the price of a high end Windows tablet a business could buy two inexpensive, but decent laptops or even desktop computers. So, if a high end tablet is going to be used by a business, they surely need to evaluate whether it really is up to the job and worth the investment. Maybe a laptop would be better suited to the task. Maybe the task is well suited to the tablet, but will the benefits outweight the costs. There is a use for high end tablets, but only when the returns make the cost worth it.

But tablets have limitations. By time you start adding things like a fancy case (or cover) for the tablet, accessories like digitizer pens and external keyboards, the costs can get pretty high and the low weight factor may be lost and what makes the tablet any better than a comparable laptop now ? Maybe a business could have purchased two decent laptops for the price of the one tablet and all its accessories. So does this mean that tablets have no value to a business ? No, but one needs to weigh the costs versus benefits. But imagine if very low cost Windows tablets were available, so one could afford to buy a laptop or desktop for the heavy work loads and then add an inexpensive Windows tablet to the mix for when a very light weight, limited mobile device would suffice or even better better suited !

A lesson from Android

I am not an expert on tablets by any means, but I do follow the news about what is happening in the mobile world very carefully. As a programmer I need to know what people are doing with mobile devices. One thing for sure is that tablets seem to be more popular among consumers, more apps in app stores seem to be for consumers (ie. games) and the current model for much of the tablet world for software is free software where developers find alternate ways  to monetize the software, such as in app purchases. The free model for software may work for consumers, but for businesses software costs money and the right software for tablets may even cost more. The software is what makes the device useful to a business, not the hardware. A fancy retina capable display (high resolution) may sound great, but it doesn’t usually make a tablet any more productive for a business.  Only two things matter for a business when it comes to using mobile devices. One is the cost of the device and the other is software which makes the device a useful tool. One lesson we can learn from Android is that lower cost tablets make a difference. Likely the popularity of Android has as much to do with the many different choices of hardware it runs on. Some may opt for the $300 tablet (or more), but more and more people are looking for the under $100 tablet. True the experience with a $100 tablet may not be as good as the higher quality tablet, but for many it suffices and they are happier because they did not waste money which could be better spent on more important things. The low cost tablet is here to stay and it plays an important role. So what about Windows tablets ?

Bay Trail and smaller form factor breaks some barriers

Not only has the performance of Windows tablets gotten better with Intels Bay Trail systems (Atom system on a chip), but this has brought the price levels down significantly. The new minimum system requirements for Windows 8 has also brought us the smaller 8 inch form factor, which gives us smaller, lighter and less expensive Windows tablets. Just this week Best Buy was selling the Lenovo Miix 2 , 8 inch, tablet for only $199. The Microsoft Store was selling the similar Dell Venue 8 Pro for only $229. The price is getting more and more reasonable now and this makes Windows tablets worth considering for a business.

But as a programmer, I think we could go further. How ?

Rethink how tablets are used in business

Maybe I am too thrifty by nature, but I find it makes sense to spend money on technology in a way where you get the most out of your investment. For example, unlike many who just have to have the latest smart phone with the most expensive data plan possible, I only have a cheap TracFone which only costs me about $7 a month with just enough minutes so I have a mobile phone when I really need it, like calling home to see what my wife wants me to pick up at the store when I am out or being able to call for help in an emergency when maybe my car breaks down. Just enough technology for the task at hand and at a price that does not break the bank.

For a business, mobile devices, such as tablets, are the same. Maybe a business wants to hand out a tablet to hundreds of employees. The cost can get very high in this case. But will the tablet accomplish enough work to make the investment worthwhile ? This will only be the case if the tablet is affordable enough and if the tablet is used correctly. Having written custom software for many years for businesses, I realize that the cost versus benefits factor must be carefully weighted out. From my experience, often the software is more important than the hardware. A $500 tablet with only minimal software (meaning it only accomplishes so much work) is far less valuable to a business than a $100 tablet with well written software which does some real work. The real investment should be in the software.  The freemium model of selling software for consumers in some app stores may give a false sense of security to some business owners making them think that if they just buy the really expensive tablet, then the software will be there waiting for them and it won’t cost much. Quality software, which does valuable work, simply put costs money. Now if the tablets cost too much money and the right software costs a lot more, then the total long term expense may make the investment a poor one.

Don’t be fooled by the bring your own device model

The current idea of bring your own device sounds like a great idea doesn’t it. Let the employees bring their own devices and the company saves money, right ? Maybe. But this creates the problem with cross platform development. How many different devices will the company have to support ? Can the software be written so it works just as well on all the devices ? What if you want the software available for desktop PC’s as well as the tablets ? In the long run the expense for writing custom software for so many different devices can far outweigh the savings of the bring your own device policy. Remember, it is not how many different devices you support which matters, but how much work those devices accomplish. The software is what mattters and quality software is not easy to develop, no matter what platform you support. Cross platform development, no matter how much it is promoted by tech companies, comes with compromises. Programmers, if they are honest will admit this. How many times will one platform support a feature while another may not have the exact same thing ? If you think the difference between different web browsers is a problem (ie. web site shows well on one browser but not on another), then consider multiple operating systems along with dozens of different form factors. What works well on a laptop may not work well on a 10 inch tablet. What works well on Windows may not work well on IOS or Android. Cross platform means compromise. Now at times cross platform makes sense and it is worth the cost. But is it possible that developing software for only one major platform and even one specific device format could produce better results if the software is written properly ? I think this is so.

It takes years for a programmer to learn how to get the most out of a specific platform

As a WIN32 programmer, I can honestly admit that it can take years for a programmer to learn how to get the most out of a single platform. I have spent nearly a decade and a half in learning the Windows API (WIN32) and how to get the most out of it and I still have only tapped into a small portion of it. Changing technologies every few years only slows down software development, rather than improve it. Just when a programmer feels they are getting really productive with a technology, all of sudden there comes a new one which the IT world now embraces and it is back to the drawing board again for many programmers. What a waste of experience this is !  Since software is the important thing for mobile devices for business use, then core technologies which change little over time have a far longer lifespan and may produce better and more productive software over time. As programmers learn how to tap into the deeper features of a technology, they can do more with it and accomplish more with less changes in the hardware. This has been true ever since the beginning of the home computer. Back in the days of the Commodore 64, a group of programmers created an operating system called GEOS, which accomplished more than the creators of the computer ever imagined possible. They turned a home computer with only a 1 mhz CPU and 64 KB RAM into a minature Macintosh, just by pushing the hardware limits through well written software.

If there is a platform today which has this same potential, I would say it is Windows and not the new WINRT Windows, but the good old fashioned real Windows. There probably aren’t many programmers left today with the experience with the core WIN32 API’s to know how to accomplish the same kind of thing the developers of GEOS did for the Commodore 64, but there are some and the technology is so well documented that it would not be difficult to train new programmers.. What many businesses may not realize is that good old fashioned native coding for Windows is capable of producing software which can not only perform well on todays Windows tablets, but it is capable of performing well even on a tablet with one quarter the power of todays tablets (maybe even less). I know, because I am a native Windows coder and I know it is possible. I also realize that there are programmers are capable of writing software for Windows which can run on far less powerful hardware and that if if efforts were made to develop more software this way, then manufacturers could build Windows tablets which can run such software which cost half the price of what they cost today. By matching the right software which less expensive hardware, the $99 Windows tablet could be possible. Rather than keeping Windows tablets high priced and making then more and more powerful, it is within reason to build even lighter Windows tablets, which are thinner with even longer battery lives, but which have less powerful hardware so they would be far less expensive. Software developers could concentrate on learning how to push the hardware to its maximum limit, so the tablet can do real work effectively, but with a low overhead for expenses for the hardware. Software needs to be designed for a specific platform and even a specific device format. Imagine a large corporation buying thousands of low cost Windows tablets for as low as $99, equipped with software that does an important job and effectively. One would not need any more hardware than the task requires. Some tasks could require a little as 1 ghz or less CPU, 1 gigabyte or less of RAM and an SSD no larger than 16 gigabytes. The displays need not be super high resolution either, but just enough to make the device effective.

Windows is actually far more capable for such devices than you may imagine. Companies who have used embedded versions of Windows in their equipment know that the minimum requirements of the hardware can be brought down to a pretty low level as long as the software they write can work with it. Imagine if the concepts of embedded Windows were applied to tablet development. The $99 Windows tablet could be a reality. Also imagine Windows tablet like devices which are so light and thin that they could be used for so called “wearable” devices. As costs drop, even flexible displays could be used for wearable devices. Imagine Windows devices so small and thin and inexpensive that they could be used for all sorts of embedded purposes, so they could be used almost anywhere. It is possible. But it all comes back to the software. I have been programming long enough to know they we don’t need more and more powerful hardware. We passed the point of “powerful enough” many years ago. Windows already has the core technologies so that high performance software can be written for it and require minimal hardware. The core WIN32 API’s , native coders use, are just as viable today as they were over a decade (or two) ago. If manufacturers were to concentrate on building less expensive, thinner and lighter Windows tablets, programmers will find ways to push them to their limits. It may require programmers to work a little harder, but as I said before the software is what matters now, not the hardware. If businesses could buy Windows tablets which are so thin and light (which is possible if they don’t need to be as powerful) that they are as easy to carry around as a cell phone and for a price as low or cheaper than many Android tablets, but still get a lot of work out of them, would that not make a lot of business sense ?

The ultimate $99 Windows tablet

The ultimate Windows tablet for me (and I expect others might be interested) is not the next generation tablet with twice the power or with the latest retina display. It would be a tablet which is inexpensive ($99 is possible), half the thickness of todays 8 inch tablets, but only requiring a decent resolution display, half the memory, half the CPU power and half the disk space of the typical Windows tablet today. Now imagine that because it needs less memory, a smaller SSD, less screen resolution and a much less powerful CPU it can be built not only more cheaply, but is can be half as thick, half the weight and have twice the battery life of todays tablets and be running real Windows ! Businesses would find more ways to use them. Probably buy more of them. And by putting the expense into the right software, still get a lot of useful work done with them. This is one native coder, already capable of writing such software today ! Yes, I mean today. The software is already possible.

Do you doubt this is possible ? Can native coding really produce high performance software capable of running on such a limited Windows tablet ?

Even though I am not a C++ programmer, I greatly appreciated Microsoft’s C++ expert , Herb Sutter, in his talk “Why C++ ?” where he discusses writing software with performance in mind. Watch this video (on Microsofts Channel 9) and see why native coding for a specific platform makes a difference.

As a native coder, I don’t currently write many full applications because I am a developer of tools for programmers and my main work has been in developing tools (ie. a GUI framework), but I do have some examples of what native coding can do which you can download. As a test to appreciate what native coding can do, why not download the following example applications and try them on as many different Windows PC’s as you can. I would recommend at least a resolution of 1024 x 768 for testing (at the default 96 DPI). Some of the apps are scalable based on the DPI, so I can’t guarantee that on some devices they may not scale beyond your devices screen resolution, but they should fit on most Windows PC’s and tablets. I have not optimized any of the apps for Touch yet, but they should still be useable even on a tablet.

What I would like you to try, is to see little hardware is required to run the applications. Run them not only on a modern Windows 8 PC, but also on Windows 7, Windows XP or even an earlier version of Windows. For example try them on any legacy PC with as little memory as possible and see if they still run reasonably well. Native coding can produce applications which are tiny in size and yet have very good performance.

App #1:   Windows 8 compatiblity Test

This app I created for testing my GUI framework and its features to make sure it worked on Windows 8 and that the WIN32 still supported the features. Make sure your PC has the proper OpenGL drivers for the 3D part (only requires OpenGL 2.0 or less).

App #2:  3D Model viewer

This app I wrote to test my GUI frameworks 3D engine. The app is for working with the STL file format (used in 3D printing). It can handle huge 3D models with as much as a million or more polygons in them. Now there is a quirk in some STL binary model files, where the header of the file is encoded as if it were an ascii (text) file, which may confuse the model viewer. If that occurs in a file you use and the model does not display, simply change the file extension from .STL to .STLB so the viewer forces it to be viewed as a binary STL model file. (I fixed this in a later version).

App #3:  3D Sandbox demo app for Intel 2013 App Innovation contest

This app was written for the Intel contest and it still has much work left to finish it, but it does demonstrate some nice features already such as scalability, better design for touch on tablets, etc. I should point out that the actual app (EXE file) may seem a little larger in size than the other apps above, but the actual code in it is minimal and most of the size is because of embedded bitmaps for texture maps.

All of the above apps are written using native coding (the GUI framework they use is 100% native coded) and they are designed to work on minimal hardware. So why not try to see how minimal machine you can get them to run on effectively. About the only feature in the apps which may have a limit  as far as hardware capability is the 3D stuff which requires OpenGL. For example with the 3D model viewer, maybe use models with a lot less polygons in them on a very limited Windows device. Now on my Windows Vista desktop PC, with a simple Pentium D (dual core) CPU , 2 gig of memory and a minimal graphic card, the 3D model viewer does a pretty good job with even 3D models with over a million polygons in them. So if you try the app with say a Windows XP computer with only 256 meg RAM and minimal OpenGL support, why not try much smaller models like with only a few thousand polygons.

The above demos should at least demonstrate the native coded applications can work on very minimal hardware, so a low cost Windows tablet would still be viable to run some very powerful software.




Comments Off