I have repeatedly read how Windows 7 is not well-suited to touch, which is the reason some people are waiting for Windows 8 before buying a tablet. Microsoft’s solution is Metro — the next generation touch interface for Windows. Yes, Metro is touch friendly, but is it really the answer to the enterprise when it comes to Windows tablets?

Windows 7 is not any less suited to touch and a tablet PC than Windows 8. Sure Windows 8 does offer a few perks that make touch better as far as the operating system is concerned, such a better on-screen keyboard. But as far as applications a business may want to design themselves specific to tablets, I don’t see any advantage Windows 8 has over Windows 7.

Actually Windows 7 already has the key features necessary to impliment quality touch applications. It supports the WM_TOUCH and WM_GESTURE messages (which is how WIN32 handles touch). Two-point touch is sufficient for most touch applications, so today’s Windows 7 tablets are completely viable for business use right now.

Metro and Touch Targets Consumers

Maybe I am biased, but I find the Windows desktop better suited to business applications than Metro. Yes, Metro does have some exciting features, such as Contracts (a way of sharing between applications), but this does not mean it is significantly better than the desktop for business apps.

Metro has its origins, not from computers, but from a phone user interface. Yes, the world is saturated with smartphones today, so some people think that a Windows tablet should act more like a smartphone than a computer. But for a moment, consider this: Windows 8 Consumer Preview has a number of apps you can download from the Microsoft app store, such as games, entertainment, weather apps, etc. Have you seen any serious business apps included in the Windows Store?

I think Microsoft could make a big impression on its business customers by including just one serious business program as a Metro app. The next generation of Office will still be a desktop style application. What an impression they could have made it they had included just one part of Office as a Metro app, but it hasn’t happened yet. Office 15 will come with Windows on ARM devices. Microsoft has insinuated for free but hasn’t explicitly said so.

My impression right now is that Metro targets consumers. Consumers want simple and easy touch UIs that let them browse the web, send email, read books and so forth. Businesses though are different. A tablet needs to be a tool, not a toy or a distraction. This does not mean that Metro can’t handle a real world business application. But what makes Metro any better suited to business applications than the Windows desktop?

The Problem Is With Software

(This is where I will diverge from the mainstream viewpoint, so maybe you ought to sit down (if not already) before you read further.)

I have been working with the Windows API (WIN32) for nearly 10 years now, so I think that I can reasonably grasp how Windows works under the hood. I design tools for programmers and not for consumers and understand the challenges developers face in writing software. I am not your typical “bleeding edge” style programmer, who is always designing for the next generation computers, but rather one who recognizes the need to write software that runs well even on the typical low-cost, mass-market computer and even older legacy computers.

Maybe because my experience dates back to the old days when computers were very limited in power (can you say “floppy disk”?) and a programmer had to find ways to get the most out of minimal hardware, my viewpoints are different; I am not alone.

No matter the reasons why, more of the problem with Windows tablets and touch has to do with how software is developed, rather than it being a problem with the current Windows tablets running Windows 7. I don’t feel that Windows 8 deals with this problem any better than does Windows 7, so things won’t get any better when Windows 8 is available. The UI (Metro) may be different, but the root cause will still be there.

To start with, the majority of our software today is developed using Microsoft’s own programming tools. I won’t say they are bad; lots of quality software is built using them. But as a programmer who works with non-Microsoft programming tools, I can honestly say this: One of the terms common programmers, especially those who don’t use MS development tools, is “bloated”. What does a programmer mean when he or she says that? It means the software uses too much of a computer’s resources, such as the CPU, GPU, memory and disk drive space.

If you can write an application that is half the size, uses half the memory and runs twices as fast, won’t you get a more “fast and fluid” experience from it?

Rather than deal with this inherent problem, Microsoft programmming languages in recent years have added a feature they feel will compensate, called “asynchronous” to many of its languages; so when an application makes a call to an objects method that is asynchronous, it returns immediately no matter how long it takes for the code to execute. Metro applications will use this technique even more.

I hate to burst anyone’s bubble, but asynchronous code does not speed things up on a computer, but actually slows it down. Why? Because, at its core this simply means you are using threads to have multiple blocks of code run at the same time. Guess what? Threads have overhead (called a “context switch”), which actually puts a greater load on a CPU and not less. This is why long-time WIN32 programmers have learned to use threads very carefully and only when they really would make a difference (ie. reading external data input).

If you doubt this then read a book written by somebody who knows: Multithreading Applications in Win32: The complete guide to threads by Jim Beveridge and Robert Wiener and published by Addison Wesley Developers Press.

Root Cause — How Software Is Developed?

Another reason for bloated software today is likely something most programmers don’t want to admit: Over-reliance on OOP (Objected Oriented Programming). This is something the majority of programmers would disagree with me on, but there is good reason to believe that Object Oriented Programming has not only increased the bloat in software today, but it may even decrease productivity in software development.

Metro and WinRT are highly dependent upon OOP, particularly COM (which is really a form of OOP when you think about). Microsoft programming languages are so object oriented today that I doubt many Windows programmers would even know how to write a Windows application without using any OOP at all.

The core Windows API, on the other hand, is basically a flat API (some more recent additions though do use COM). Now as far as 3D graphics are concerned, one of the reasons I chose OpenGL over DirectX is because it too is a flat API requiring less dependence upon COM and OOP.

Richard Mansfield wrote an excellent white paper about why OOP is not the panacea many think it is. He had some valid points. If you don’t know who Richard Mansfield is, then you likely are a lot younger than me. He was the editor of Compute magazine back in the `80s, and anyone who ever learned how to program the Commodore 64 definitely knows who he is. His book on 6502 machine language was so well-written it taught me well enough so I could write my own compiler for the C64. Obviously then, there are some experienced programmers who feel that a more procedural style of coding can have benefits over OOP, so it’s not just me who feels this way.

If the principles of writing efficient software we learned years ago were implimented when writing software for today’s Windows tablet computers, I think “fast and fluid” would definitely be the norm. One of the things us old-time programmers may appreciate is the importance of using compilers that generate fast, small and efficient machine code.

Today, surprisingly, many programming languages are going the route of being interpreted rather than producing pure machine code. Sure pure machine code is not cross platform, but if you are writing software only for x86 Windows, that is not an issue. If you want “fast and fluid” nothing beats fast machine code. Even compiled languages are so bloated today, that you really don’t get the full benefit from them.

Today, Intel Atom CPU’s are regularly criticised as being too slow, lacking power. Windows tablets (the reasonably priced ones) usually come with an Atom CPU. But it is programmers who are most likely to make this criticism. Why? Because their software runs too slow on these CPUs. But the problem is not the CPUs, but the software. A well-written WIN32 application can run very fast even on the Atom CPU.

Is WIN32 Really That Powerful For Tablet Software Development?

Despite those who like to refer to the Windows API (WIN32) as ancient, and lacking power, and those who would be lost without so called modern OOP, there are those who can (and do) write Windows software using non-Microsoft languages, without OOP and using the pure Windows API. Guess what? The software they write is much smaller, faster and less bloated than most software today.

Don’t appreciate this? Check out this developer’s website and download his amazing program called Toolbar Paint. Its a great toolbar bitmap editor, which was surprisingly written using assembler.

Toolbar Paint is only 56 KB (yes, kilobytes) in size! When was the last time you used a Windows application which is only 56 KB?

The programming circles I deal with most use a much higher level language than assembler, but yet they too are building applications that size in the kilobytes, rather than in megabytes. Such small-size applications are what Windows tablets need today. All one has to do is add touch to such applications and design the user interface with slightly larger UI elements — and now you have well-written, resource light, application that will run great on today’s generation of Windows 7 tablet PCs and even tomorrow’s Windows 8 PCs (on the desktop).

Maybe it is how we write software that needs to change, if we want to use tablet computers in the enterprise.

Chris Boss is an advanced Windows API programmer and developer of 10 year-old EZGUI, which is now version 5. He owns The Computer Workshop, which opened for businesses in the late 1980s. He originally developed custom software for local businesses. Now he develops programming tools for use with the PowerBasic compiler.