The Software Developer

Do you remember Windows 95 ? Yes, Windows was no longer a 16 bit operating system. Now with a 32 bit operating system, more would be possible with software. How much memory did Windows 95 require ? My first Windows 95 computer was one which I upgraded from DOS/Windows 3.1 which only had 8 megabytes of RAM. So how did an operating system like Windows run so well on so little memory ? The average CPU back then was likely a 386 or 486 class CPU which was in the 25 to 32 mhz range. From todays perspective, such a thing would almost seem impossible. The official system requirements were a 386 CPU, 4 megabytes of RAM and 55 megabytes of diskspace. Most computers today have CPU’s in the 1 to 2 ghz range with 2 to 4 gigabytes of ram. So much power is now in our hands. But is it really ?

So how was Windows 95 possible with so little hardware ?

The operating system was designed around a set of flat API’s (basically function calls). Often refered to as the WIN32 API, the operating system provided a set of low level features which could be used to build applications. The efficiency of that operating system to run on such minimal hardware says a lot. But what many may not appreciate today is that how software which ran on Windows 95 was written is far different than how software is written today. While MFC (Microsoft Foundation Classes) was already being used by some developers at that time, many applications were still written using the pure Windows API’s alone. Doing this created applications with less dependencies. If you examine the Windows programming books available at that time, while some discussed using MFC, there were a number which taught programming using the pure WIN32 API’s alone. Having been exposed to WIN32 programming much later, nearly 15 years after Windows 95, I can appreciate why some programmers chose MFC over the the pure WIN32 API’s, since working with the WIN32 was not an easy task. But the WIN32 API’s though do have one real advantage. Working closer to the core operating system allows one to build applications which are smaller, faster and which requires a minimal footprint (less memory and disk space).

So what happened to Windows development ?

I am sure many programmers have a different perspective on this, but my own experience is quite unique and offers a different perspective on this. My programming started back on the days of CPM, before even DOS. When the IBM compatible PC came along, I started programming in Microsoft QuickBasic, then PDS 7.1 (professional version of QuickBasic). I even wrote some libraries for the compiler using assembler. There were three criteria for my development needs, (1) Fast development (2) Easy to read syntax and (3) Performance. Using a quality BASIC compiler along with a little bit of assembler provided me with all three.

When it came time to move to Windows, like many Basic programmers I quickly latched onto Visual Basic 1.0 (for 16 bit, and later 5.0 for 32 bit). I dabbled with a number of Basic programming languages such as GFA Basic and CA Realizer, but Visual Basic provided the easiest transition for me. But something happened to my programming experience which would change things drastically. I switched to a different Basic language compiler which was more akin to programming in C in Windows, which forced me to start learning how to work with the WIN32 API’s. There were no RAD tools for me to use at the time. Everything had to be coded manually in a code editor without a RAD front end. It was very difficult at first, not so much because the WIN32 API’s were too complex to work with, but because all the documentation about the Windows API were written for C (or C++) programmers. I had to port a lot of C code to Basic, which wasn’t easy because I was not a C programmer. To make things even more difficult, in the C world programmers had quickly adopted MFC, so many of the programming books dealt with MFC, rather than the WIN32 API’s directly. Over the years I would scan online looking for old copies of programming books which dated back to the early to mid 1990′s. For example I just could not find a book which explained how to write custom window classes using the WIN32. The only (and best) one I could find dated back to Windows 3.1, but it was amazing how little had changed since then.

It was interesting to see the direction that Visual Basic followed during these and later years. In the 16 bit days of Windows 3.1, Visual Basic added the VBX custom control format which was a real benefit to Visual Basic programmers back then. It was later replaced by the OCX (COM based) custom control format. While there were many advantages to these component models, the OCX would, in my opinion, introduce a downhill slide in the Windows programming model. I first experienced this when I wrote an application which could be used as a utility for a multimedia development tool. I was a beta tester for a product called MediaForge, a powerful multimedia development tool. The developer of that software was an amazing C programmer with an extensive knowledge of the Windows API. When I sent him my Visual Basic application (an HTML generator utility), the first thing he commented on was whether I could get rid of the OCX’s that had to be distributed with my app. I was forced to use OCX’s for simple things like the common dialogs. It would not be until some years later when I started digging into the WIN32 API’s myself, that I would come to appreciate how bloated some software became because of overuse of the OCX component model. The code needed to impliment a common dialog via the API was minimal compared to the size of the Visual Basic OCX. So what was the problem here ?

Object Oriented Programming changes things.

The real cause for the software bloat was, in my opinion, the overuse of the COM component model and the overuse of object oriented programming model. While they both have their value, their overuse has added a significant amount of extra overhead to Windows programming, far more than most programmers would like to admit. How do I know this ?

(For some more info about the weaknesses of OOP consider these articles:)

• http://www.csjournals.com/IJCSC/PDF1-2/9..pdf
• http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/
• http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf

When I started learning how to program using the pure WIN32 API’s, I had a few advantages that the early Windows programmers may not have had. First, I had a chance to see how the WIN32 API remained basically intact over multiple generations of Windows. The few changes made, were easy to work with since Windows from the days of Windows 95 has had a few very important features which have remained steadfast in every generation. One is the trusty DLL (dynamic link library). The DLL design, in my opinion, was simply ingenious. DLL’s are truly dynamic, produce reusable code and they tend to have a much smaller footprint than their OCX counterparts , plus they normally don’t need to be registered with the operating system, meaning the registry need not be involved. You can simply copy and run. The second important feature, associated with DLL’s again, is the ability to dynamically load DLL’s (via the LoadLibrary API), rather than staticly link them at compile time (the DLL is still separate, but the EXE header tells Windows to load the DLL automatically). Dynamic loading allows you to poll the DLL to see if an API exists or not, so you can take adantage of features in later versions of Windows if you like.

The second advantage I had was that I used a BASIC language compiler rather than C. The amazing thing about this was that working with the pure WIN32 API’s was so much easier using Basic, than it would have been using C. The language syntax made code more readable, the powerful memory management built in made coding easier, the compilers built in support for variable lengths strings (using the Windows OLE engine) made things much easier as well. For once, WIN32 code made sense and was readable. I didn’t need to use MFC. I could write applications using the WIN32 API alone.

Interesting results !

Of course to be able to write software faster it only made sense to design RAD tools, but once again the power of the WIN32 API’s proved an advantage. As I went from just a beginner API programmer to an experienced one, I began to solve more and more problems using the pure WIN32 API’s. Of course, every programmer needs some kind of higher level libraries, so I began to build my own. Because I used a Basic language compiler, I had no MFC to fall back on. I had to build my own libraries.

So while building a reusable GUI library was important, I had some basic rules. The library must be in DLL format. API’s which didn’t exist on some earlier versions of Windows, had to be polled for and then loaded dynamically, so the library would be compatible with all versions of Windows from 95 to Windows 8. If possible when an API was not available on an earlier version of Windows alternate code was added to support similar features if possible. At the minimum, the library must support all of its features on at least Windows XP forward.

Since I didn’t even have the benefit of a drag and drop visual designer to help me, I decided that I needed to learn how to build that from scratch using the WIN32 API’s. Any complex task using the WIN32 API’s which took some time to develop, I decided should be put into library code so it can be reused. Code reusability is not dependent upon the object oriented programming model as some may think. Procedural, flat API, programming models can also benefit from high level reusable code libraries. The key to working with the WIN32 API’s is to build such reusable libraries.

So the final results have been interesting. First, I found there are some very powerful low level features in Windows which have been there since Windows 95 and are still fully supported in Windows 8. For example the DIB (device independent bitmap) API’s are very useful and very powerful. The WIN32 API’s offer so many different ways of customizing user interface elements (controls). Such things as subclassing and superclassing are powerful tools. Fortunately I found one of the few books written about how to write custom window classes (controls) using the WIN32 API’s (and the term class does not mean it is object oriented in this case). I have written a number of custom window classes using the WIN32′s, such as my own Canvas control with a low level DIB engine and 2D sprite engine, an OpenGL based 3D Canvas control with a 3D scripting language, a Turtle Graphics control and a Property Listbox control. For me, as a WIN32 programmer, the possibilities seem endless.

But the most amazing thing about all of this was the size and footprint of the GUI libraries I was able to build using the WIN32 API’s. The entire GUI library can fit on an old fashioned floppy disk with room to spare. When I realized that I could write complex GUI libraries and applications which can run on most versions of Windows in use today with a minimal amount of memory (easily 64 meg or less), which are truly transportable (just copy and run, even from a flash drive) and can easily be run on the most minimal of computer hardware (ie. 233 mhz or less CPU), it is very exciting. While most programmers may be stifled by the minimal hardware on some Windows tablets today, for a WIN32 programmer the average Atom based Tablet is far more than adequate, but is a powerhouse.

So if you are looking for an alternative way of writing software which has a minimal footprint, then seriously consider what has been around since the days of Windows 95, the WIN32 API’s.

Why do some programmers, even today, still desire to see classic Visual Basic brought back ?

I can’t answer the question for others, but I can offer a perspective which I feel is often overlooked. The move from Visual Basic to VB.NET was so drastic for some that they just could not, or would not, make the transition. A number who moved to VB.NET quickly switched to C# and left Basic in the dust. So what was really going on here ? Was Visual Basic so poorly designed it just had to be left behind ? Was the managed language approach so superior that Visual Basic was just obsolete ?

One programmers perspective of Visual Basic.

I liked Visual Basic for a number of reasons, but the key reason was the ability to prototype an application very fast. The interaction of the development environment made building GUI’s extremely fast. The second reason was that it was BASIC. I had been programming in some form of Basic for years, before Visual Basic came along. I had some exposure to languages like Fortran, Lisp, dabbled with C, but none of them had the appeal of Basic. Coding was easy in basic and as one compiler developer commented, that Basic is a natural language. It is not cryptic, like C. So combining a natural language, which had a long history, with an easy to use drag and drop development environment (RAD), it was no surprise that Visual Basic was a big hit. The strange thing about Visual Basic though, was that it was a hit with a unique sector of software developers. Independent programmers, hobby programmers and the like just took to Visual Basic, like a duck in water. People who you never thought of as being programmer material, started picking up Visual Basic in their spare time so they could build their own software for use at home as well as at work.  They started creating applications for a specific need which they knew very well. Maybe they needed some software which just didn’t exist, so they created it themselves. Small businesses began to flurish from the flood of Visual Basic developers who literally were coming out of the woodworks, as they say.

The interesting thing about Visual Basic programmers though, was that even though they preferred Basic because it was an easy language to learn, they still had high expectations for themselves. If Visual Basic couldn’t do something, they often searched for ways to push the language beyond was it was designed for. So began the crop of books about how to integrate pure WIN32 API calls into Visual Basic. They were starting to tap into the deeper things of Windows.

So what happened ?

I can’t speak for Microsoft and their reasons for leaving Visual Basic behind. Likely they had good reasons in their own mind, but I believe they failed to appreciate what Visual Basic had become. I have the impression they did not expect Visual Basic to become so popular and didn’t know what to do with it. For example, initially Visual Basic only generated Pcode based applications so they were slow compared to their C++ counterparts. Visual Basic programmers wanted more though. My first version of Visual Basic which had a real compiler backend which generated decent machine code was VB 5.0 Professional. The interesting thing about this though, was that I have the impression that Microsoft didn’t plan this result initially. VB programmers were excited to have the ability to produce applications which were as fast as their C counterparts, but few may realize that to be able to get such a compiler required a little trick, which I one day read about. Now please correct me, if I am wrong about this, but I had read that Visual Basic used a C compiler backend. It was not actually a pure Basic to machine code compiler. Whether this is true or not, the point is that Visual Basic, one way or another had to become a true compiler. VB programmers wanted speed, performance. It wasn’t enough that they had one of the easiest to use GUI based programming languages, but they wanted the same performance as C programmers had and they got it, or at least pretty close.

So Visual Basic versions 5.0 and 6.0 were reaching a truly professional level, so why wasn’t there a Visual Basic 7.0 ? I can’t answer this question, but I did walk away with a very deep impression. This I say from years of hindsight. The problem was not with Visual Basic. The problem was with just BASIC ! You see, C and then later C++ was what was considered the true professional programming languages. Windows as build upon C and C++. BASIC was never intended to become the professional language it became. The shear growth of Basic and then Visual Basic, I do not believe was expected. It was that language to satisfy the hobby programmers and the kids. It was not intended to become a professional language. But with QuickBasic, then PDS 7.1 and then in the Windows world Visual Basic, it took on a new life. All sorts of people were writing commercial grade software and it worked great. RAD tools with Basic at their core, were able to produce software at an amazing rate.

So again, what happened ? Visual Basic was brought to its end (of life cycle as they might say). Now the programming world embraced managed languages like VB.NET and C#.  But something more was happenning here. The transition from Visual Basic to VB.NET also was weeding out two sets of programmers with a divergent style of programming. Why did some VB programmers make the transition, while others did not ? Were they simply just bad programmers, not willing to learn something new ? I don’t think so, and while this is my opinion I do feel there is a good reason to consider this other possibility. There is a clue in one of the reasons many managed language programmers say is why Visual Basic was a poor language. I have often read comments by programmers mentioning how Visual Basic was not truly object oriented. Key OOP features were missing in VB, so it needed to be left behind (or they say). I would like to offer a different perspective on this.

OOP versus Procedural based programming.

It was about this time (the shift to managed languages) that OOP (Object Oriented Programming) began to push procedural styles of programming into the background. This can be seen not only with Visual Basic compared to VB.NET, but also in the shift from C to C++ and then later to C#. I never realized how much managed languages effected the software industry until I watched the video of a talk by Herb Sutter (a Microsoft C++ expert) entitled:

“Why C++ ?”

http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C

He touches on how managed languages took over for awhile and even left C and C+ behind only to find in the long run one of the vital aspects of software was being lost and that was performance. Now I would like to go a step further. The transition to managed languages was much more than this. It was also the transition from procedural coding styles to OOP, trying to leave procedural behind too. This can be seen with Visual Basic. Those who made the transition to VB.NET likely also preferred OOP over procedural style coding. Those who did not, possibly had nothing to do with being poor programmers, but instead maybe they just simply preferred a more procedural style of coding. Visual Basic was quite unique. Where OOP succeeded the most, was in designing the interface (GUI). But the rest of the coding could be done using purely procedural style coding, much like we used in the DOS days. It was beautiful blend of the two.

So the desire of many to see a true Visual Basic programming language brought back is very understandable. But the real question before that could be possible is whether a more procedural style of programming has an advantages over using pure OOP ? Also, can the BASIC language maintain its syntax and still be used as a professional language, yet grow and advanced in a way more natural to Basic ? The answer to both questions is an absolute yes !

One step back and two steps forward.

The last Microsoft programmign language I used in my business was Visual Basic 5.0 Professional. For me, my experience was quite strange in that I had to take one step back first and then take two steps forward. I switched to PowerBasic which in those days had not GUI features at all. I still was a Basic programmer, still wrote code in a purely procedural style, but I had to write applications in the same way as the old time C (not C++) programmers had to using the pure Windows WIN32 API’s. Whereas Visual Basic programmers were extending Visual Basic by learning how to tap into the Windows API, I was writing software using the Windows API alone. From everything I read, one of the reasons C programmers began to leave behind using the pure WIN32 API’s was it was suppose to be too difficult to write any application. So along came things like MFC (Microsoft Foundation Classes) and ATL. As a Basic programmer though I had to dig into all that old C code to see how they wrote applications and they translate it into Basic. An interesting thing happenned though. The Basic version was more readable than the C version. Also the C code was purely procedural in nature, so it was a perfect fit for translating into Basic. MFC code often would confuse me more than the pure C code.  The point is that by being forced to learn how to code Windows software using what most would have considered old fashion techniques, I realized the advantage of Basic and procedural style coding, plus why Visual Basic programmers often pushed it to the limit by tapping into the Windows API, which is where the real power was.

Now imagine the power of say a Visual Basic 7, with its ease of development, combined with tools to extend it (other Basic language compilers) which simply allowed long time Visual Basic (and any Basic) programmers to be able to once again push the limits of Windows software development ? The huge existing codebase of VB code could be put to work.

Two steps forward.

Because I learned how to write Basic code using the pure Windows API, I realized something. Visual Basic never fully tapped into what is possible with Windows. The power that exists in Windows would boggle your mind if you really knew what is there. The Windows DIB engine is amazingly powerful and it has been there since Windows 95.  Threading in Windows would have been easy to impliment in Visual Basic if they only followed a simple rule, which I learned from an excellent book about Windows multitasking and threading. Threads are not needed for foreground GUI tasks. Threads are better suited to background tasks (non-GUI or preparing stuff for the GUI, but not drawing it).  I learned how to tap into using threads, even with a purely procedural style of coding. Visual Basic programmers often found themselves being forced to use third party (some even from Microsoft) OCX controls just to add features which should have been built into Visual Basic natively or could have been accomplished with a few lines of API code. Visual Basic should have exposed more of the underlying features of Windows and natively if possible. Things like subclassing and superclassing should have been introduced into the language. Things like ownerdraw and customdraw should have been introduced into the language. Visual Basic if done right, could have become one of the most powerful programming languages around, capable of producing small, fast and transportable (no installation required, just copy and run) applications.

Procedural style coding, as used in Visual Basic, has many advantages. One thing it can produce smaller, faster applications with a tiny footprint. Basic is a more natural language which allows you to use huge stocks of existing code and more easily maintain it (because it is more readable).

The key to future versions of BASIC is to first view them as a professional language. Second don’t force OOP on users. OOP has its place as an addition to the language, but one should be able to write an application with purely procedural style coding it they prefer. Third, maintain the language at its core, don’t try to make it like C or C#, but respect the long history of the language and its core syntax. Just maybe then, bringing back classic Visual Basic, would not be a step backward, but two steps forward.

Tech journalists are talking about what Windows Blue will mean for the future of Windows. Actually, no matter what anyone suggests, only Microsoft really knows what it has planned for future versions of Windows. What really is important though is how changes in Windows will affect software developers, plus businesses, and why considering this may be far more important in the long run.

Windows means more than browsing the web, watching videos and visiting facebook.

In recent years we have seen the over consumerization of computers, in particular the shift from desktop PCs to tablets and other portable devices. Everything seems to be all about mobile today. But is mobile and touch the future of computers ?

What we are seeing is not the shift from desktop computers to mobile, but a significant split between business and consumers. When I started programming in the late 80′s and early 90′s, computers were business tools, not consumer products. A computer with a 20 meg harddrive, RGB monitor and 640 KB of memory could cost you $2,000 to $3,000. A computer was a business investment and productivity was vital to make it worth the investment. In time the prices of computers dropped significantly, so much so that consumers (average people) began to buy computers. The strange thing about this though was the consumers didn’t know what to do with their computers, they looked for software which provided some kind of entertainment value. Consumers played games. They listened to music. With the coming of the internet, they browsed the web, did their shopping online, emailed friends and family. A powerful tool had become a toy, an entertainment device. Many of these same consumers who were watching videos online, buying stuff at Amazon, didn’t have the slightest idea of key functionality built into their computer. Many didn’t know how to create folders, copy files, delete files, etc. Many consumers never realized that they needed to purchase a new subscription to the antivirus software which came with their computer, after 90 days. It became obvious that consumers were using a tool which they barely knew anything about. Having been a computer consultant and programmer for a number of years, time after time I found myself again and again suggesting to consumers I dealt with that maybe they should buy a book about Windows and learn a little more about it and what it can do.

I had come to the conclusion that the average person (consumer) was being sold more than they really needed. Then along came MP3 players, smart phones and tablets. Consumers didn’t need a keyboard, they simply touched the device. They didn’t have to learn all the complexities of a full blown computer. They finally were purchasing what they wanted all along. Something which did a specific task and that is it. So now we see computer sales slowing down significantly. Manufacturers should have seen this coming. The computer market has made the shift that all should have expected. But there is a problem here. Windows means more than browsing the web, watching videos and visiting facebook. Windows is part of another key market and that is the business computer market, not just consumer devices. Computers started out as tools, not toys. They still are tools and very important ones. So where does Windows 8 come in ?

Windows 8 is not the end of the desktop but it bridges the gap between consumer devices and business tools.

The Metro (or Modern UI or Windows Store) side of Windows 8 is all about two things. Consumerization of electronic devices and touch. These two aspects are not necessarily the same thing. Touch has a big value in consumerization, but it can also be a useful tool in the right situation. Touch though is more meaningful for consumer devices because that is what consumers want and need. Touch is useful for business, but it is not the end all. It has a place, but is also has its limits and why many don’t see this is confusing. Businesses can’t make their decisions about tools by watching fancy TV commercials with everybody dancing around and touching their computer screens. Businesses can ill afford to waste their money on mobile devices if they don’t have a real purpose to their business. A tablet PC is only valuable if it really increases productivity for a business. There are some cases where it will and there are many cases where it simply won’t. Just putting a tablet PC in an employees hand won’t automatically improve a business. Put a tablet PC into the right employees hand and with the right software and for the right reason and then it may make a difference. Computers cost money and like any business tool they must be used in the right way and the right situation, otherwise they are a waste of money.

Having written software for a variety of businesses from local mom and pop stores to manufacturing environments, I can appreciate how important computers are, but only when they are used effectively. Journalists like to talk about software like Office suites and how once Microsoft Office is ported to Metro, the desktop is no longer needed. The real question is though, how much do they really know about how computers are really being used today in business ? Many people may not appreciate that a significant portion of business software is custom designed for a specific task or for a specific vertical market. Large corporations likely spend millions, if not billions of dollars in development costs of custom software specific to their business alone. Every time there is a change in how an operating system works and rewrites of their software become necessary, huge sums of money have to be spent just to keep up. The less a company has to redo things which currently work fine, the more money they save (and that is important today). Why do you think so many companies are still using Windows XP ? The old adage “if it is not broke, don’t fix it” means saving money in the long run.

So, as far as the consumer side of things, maybe Windows could do away with the desktop. But as far as businesses are concerned, to do away with the desktop could mean the loss of millions, if not billions of dollars. But wouldn’t Microsoft recognize this ? I can’t speak for them, but I would have to venture a guess that they do. So how does one create a totally new operating system which solves the needs of the consumer, while satisfying the needs of businesses ? The answer, merge a new operating system into the existing one and have the best of both worlds. That is what Windows 8 does.

If the desktop were not important, it would have been broken already in Windows 8.

If the desktop had no value, I would venture to say that Microsoft would already have broken a lot of it already in Windows 8. Guess what ? They didn’t. Actually they did a really good job in making sure they didn’t break it. One of the first things I had to do when I first got my hands on the build version of Windows 8 was to test it to see how well it supported the core WIN32 API’s which have been around since Windows 95/98. I was expecting a lot of things to possibly be broken, since Windows 8 was so different, but amazingly it all worked and very well. Now I was not testing just some simple user interface stuff which one would expect to work. I was testing quite a lot of lower level stuff. I was testing things like the Windows DIB engine, OpenGL, subclassing, superclassing, ownerdraw, customdraw, GDI drawing, MDI, MCI, complex window regions, custom window classes, drag and drop and more. I wanted to know right at the start, was Windows 8 going to break a lot of my code ? But it didn’t. I had only one little problem and even that was fixed in a later preview version of Windows 8.

Now if Microsoft has taken the same care with things like dot.net as it has with the core WIN32 API’s, then developers should feel confident that the desktop is well and alive in Windows 8. So why all this effort to maintain what some may refer to as legacy technology ? Because it is important, no vital, to businesses. I can understand Microsofts need to promote the new UI stuff in Windows 8. It is important to the consumerization of computers and to mobile. But the desktop surely is not dead yet and hopefully it will be with us for a good time longer.

Touch and the Modern UI don’t fit all business needs.

Another reason the desktop needs to stick around for some time is that touch is not the solution to everything. Touch is great in the right situations. It may even be preferred by consumers. But touch is not going to replace the mouse anytime soon. Productivity is vital in business and remember, for a business, a computer is a tool. No touch screen can replace a real keyboard for fast character input. This is so obvious I can not see how anyone could even suggest otherwise. As a programmer the speed of typing is so critical to me that I still use a 20 year old IBM keyboard because few modern keyboards come even close to the quality of my old IBM keyboard. IBM learned how to make some of the best keyboards ever and mine is key to my own productivity. The mouse is far superior to touch for fine tuned accuracy in pointing. Actually a mouse can do some things touch can not (trust me its true). Not even a touchpad on a laptop comes close to the accuracy of a real mouse and that is surely better than touch alone. The beauty of the mouse comes from its ability to separate movement from a touch action (a click for a mouse), plus its accuracy. Many business applications require a real keyboard, a real mouse and yes a real desktop environment (aka. the Windows Desktop).

A lot of software is boring.

Most consumers get excited about the latest fad in software. It has to look pretty. It has to be exciting (ie. touch). It has to be new ! Not so with business. Actually a lot of business software is quite boring and that is a good thing. The so called modern UI look of Metro is meaningless for some software. It doesn’t matter whether the look is flat or 3D. What matters is the job the software does. Many tasks a computer is used for are simply boring. It is the work they do which is important. Does it solve a problem ? Does it make critical calculations a business may depend upon ? Does it interface with some machine ? Does it do the job it was intended to do ? The whole reason many started using computers was that computers don’t mind doing boring jobs, unlike people who do mind. For many businesses software is just a tool and the tool has to do its job and do it right. Some companies spend a lot of money developing such boring software, because it does the job and does it right. What businesses need to know though is that all the efforts to create such software is not in vain. A lot of money is lost by companies trying to “build a better mousetrap” as they say, only to find that the originally application worked fine and it wasn’t worth the effort to recreate it as something new. What businesses need is backward compatibility in the operating systems they use. They don’t want to have to rewrite every application they use just because they bought some new computers. That is not cost effective. To them the computer is a tool and they don’t need a new tool which can’t do what the old did.

Do we need the desktop anymore ?

Absolutely ! How long it will stay with us, I can not say and won’t even try guessing. But for now, there is a good reason why Windows 8 provides all the necessary desktop features we require. If it wasn’t necessary, it wouldn’t be there in Windows 8.