The problem with cross platform development

Everybody wants cross platform choices, but few appreciate the problems with this and the disadavantages.

As a software developer, I have struggled with the decision of whether to stick with a single platform or to look for better ways to write software which can be run on multiple platforms. For this discussion let’s consider Windows 95 to Windows 7 as one platform, the Windows platform. Then you have the Mac platform and then Linux. Windows 8 will introduce a new platform with Windows for ARM, which I consider a different platform than normal Windows.

So what is the big deal you may say ?

There are two key issues for multiplatform development:

(1) The operating system

(2) The CPU family the operating supports.

Lets first look at the operating system. Different operating systems have different API’s programmers (or compilers) which often are significantly different than each other. It is not easy (or even practical some times) to try to make an application run identical on two different platforms. It can be done, but often it is done at the expense of key features unique to each operating system. Such applications are hybrids which only use what is common between the operating systems and often they have to use work arounds in areas not common to both operating systems. This puts more pressure on the developers because they can’t take advantage of some fetaures because one operating doesn’t support it. Have companies successfully developed and marketed cross platform applications. Yes and No. I will use one example to explain what I mean. Corel for years made CorelDraw (its flagship product) available for both Mac and Windows. When you ran Coreldraw on Windows it was obvious it was a hybrid. You can tell the developers had to make sacrifices to make it run on both Mac and Windows. The interesting thing about Corel is that while it successfully developed and marketed both a Mac and Windows version for years, they finally reached a point when they decided on developing for Windows only. Why ? Well I can’t speak for Corel and I doubt it was because Mac was not a valuable platform to develop for, but consider this. They chose the platform with the larger user base (obviously Windows) and the Windows only version didn’t have that hybrid look and feel any more. It was a true 100% Windows application which used all the features available to the Windows operating system.

Why would a software developer feel they needed to target a single operating system ?

Its because operating systems are so uniquely different from each other, especially under the hood, that trying to develop hybrid applications forces a developer to make too many sacrifices. You just can not get the best of both worlds as they say. I happen to agree that this is a problem and also this is why too many operating system choices can actually decrease software quality rather than increase it because of the desire of many for cross platform development. I personally like the idea of learning to become an expert on just one operating system, rather than trying to be a “jack of all trades, but master of none” with multiple operating systems.

Now I should point out that some consider Windows to be multiplatform because of all the different versions (95 to Windows 7), but as an experienced Windows API programmer I can tell you that Windows provides a number of mechanisms to allow one to develop applications which can run on all versions of Windows (albeit early versions may not support a feature, but the app can be designed to test for this and use an alternate solution). My own EZGUI 5.0 was designed to it can run on Windows 95, which the runtime supports with nearly 90% or more of its feature set, but still can be run on Windows Vista, 7 (and 8) and use the new features they support by dynamically loading them at runtime.

Yet I do not consider Windows 8 for ARM (CPU’s) the same as Windows in general. Why ?

Because of the second problem and that is the CPU family an operating system was designed for. Interestingly, the x86 (Intel , AMD) family of CPU’s has an amazing advantage over others in that it has a long history of growth and improvement, but yet maintaining an amazing amount of backward compatiblity. For example the latest x86 CPUs’ could be used to run the ancient DOS operating system, even today and a programmer can write inline assembler to access some of the new features of the CPU. 64 bit x86 CPU’s can run 32 bit operating systems if you want to. Now add to this the Windows operating system, which too provides significant backward compatibility. To appreciate this, consider my own EZGUI GUI engine. I designed it specifically to use long time API’s which have been in Windows since Windows 95 but are still perfectly supported in Windows 8. True Microsoft has added a lot of stuff on top of the core API, but it is amazing how little the core of Windows has changed. With the renewed interest in native coding at Microsoft, one can use code which has been around for a very long time. But there is a hitch ?

What will happen when Windows is put on ARM devices ?

I don’t see a problem with Metro applications, since they are not native code but use cross platform methods of programming, which interestly is the product of the most cross platform operating system there is, which is not really an operating actually, which is the Internet (the Web). HTML, HTML5, Javascript, etc are the new cross platform languages and personally I think it works and works well. All the years of coding for the internet has matured these languages. But what I am talking about hear are true, 100%, native applications for an operating system.

To have apps run on Windows, both x86 and ARM, depends upon having compilers which can target multiple CPU families. Microsoft compilers can do this and possibly some others, but there is a catch. What is that ?

Similar problems can result when trying to create a compiler for multiple CPU families, such as x86 and ARM. You see, while CPU’s within a family are similar, CPUs in different platforms can be a different as night and day. Now I have not worked with ARM at all and I am not an expert on this family of CPU’s, but this much I can say. CPU families have a unique core designer which may significantly differ. For example ARM is designed for a smaller instruction set (RISC) while x86 is designed for a more extensive isntruction set (CISC). There is a big difference between these CPU families. It is not the high level languages used for programming that matters, but the underlying generation of machine code by these compilers. What may work well on one CPU family may not work as well on another.

Why is this important ?

I can only speak from my own experience on this, but this is what matters to me. I learned a little about 6502 machine language in my early years programming, enough to write a simple compiler. I liked the RISC (reduces instruction set) of the 6502 CPU family and it was easy to learn. But today computers (and CPU’s) are far more complex with greater requirements. You want a CPU which can handle that complexity, but you also want a compiler which is optimized for that CPU. Most software today is bloated, likely because compiler/language developers don’t seem to care as much about the low level CPU as they did in the past. In the old days, compiler makers became experts on a specific CPU and counted CPU cycles and benchmarked their compilers. It doesn’t seem to be that way as much any more. Now I have been using the PowerBasic compiler (see:  http://www.powerbasic.com  ) for nearly 10 years now and what excites me about their compilers is they still are experts on their target CPU (x86 Intel/AMD) and they still count CPU cycles and they still benchmark the execution speed of their compiler and its generated executables. This provides two advantages. Software created using a compiler which is optimized for a specific CPU, created by experts on that CPU is more likely to run faster and be more efficient. Also the software is more likely to be more reliable (less buggy) at least from the perspective of bugs generated by the machine code generated by the compiler. Don’t think it is easy to write machine code generation for a task for two uniquely different CPU families. It is literally twice the work, which means one should expect the compiler maker to be expert on both CPU’s to the same degree. I personally find it better to be a master of one trade rather than try to be a “jack of all trades, but master of none”. Thats why I stick with one programming language (Basic) and one compiler (PowerBasic) and one CPU family (x86) and one operating system (Windows or x86). I think my choice does provide some advantages which is best indicated by the quality and reliability of the software tools I create.

While I hope Windows 8 on ARM does well , I plan on sticking with the x86 CPU family (for now anyway).

Windows on x86 has a long, long history and it has the largest user base of any CPU/Operating system pair. Look at how hard Linux has tried to overtake Windows and it still has a small user base in comparison. For me, for now, I plan on being a one CPU (family) and one operating system programmer. If I do delve into cross platform it will likely be HTML5, since it too has a long history (HTML) and track record. But as far as native coding , PowerBasic is my compiler choice, x86 is my CPU choice and Windows is my operating system choice.

Note: If you are curious what version of Windows I use, my primary development PC is running Windows XP, but I also use Windows 95 (can you believe that), Windows Vista Home Basic and Windows 7 (32 bit and 64 bit) and I am experimenting with the Windows 8 Preview. How many programmers do you know who even still have a Windows 95 PC ? I do because I strongly believe in the value of backward compatibility and only by testing on all the full range of Windows can one appreciate how amazing this is. Just another note, because of this method of development, my software even runs well on Linux using Wine (nows thats backward compatibility).