Applications and the Difficulties of Portability?

insane_coder asks: "I'm a software developer who writes a lot of freeware utilities in C/C++ which are all cross platform and work well. Lately some of my users have been pestering me to stop wasting precious development time supporting minority OSs like Linux, and get more work done for the majority — the Windows users. Now all of my utilities are simple tools that perform various operations on files such as compression or rearranging. I've also made a few frontends for them using the excellent Qt library to allow the user to select a file and process using a simple GUI. In the dozens of applications I wrote, most of them several thousand lines long, I haven't written a single conditional for any particular OS. When I release, I just compile each app for all the OSs I have access to and post them on my website. I barely expend any effort at all to achieve portability. So the question I have to ask is: Why do the masses perceive portability as something that requires effort and a waste of time?" "Most applications don't do anything fancy or need to talk to devices and therefor there is no need to do anything special other than compile them on a particular OS to run on that OS. So why are there so many simple apps using native APIs to do simple things like file reading instead of the standard ones? Why are we projecting an image that one must go out of their way or switch to a different language in order to achieve portability?"

Comments

It's Windows development tools

[Todd Knarr]

It's the Windows development tools. By default they generate code that uses tons of Windows-specific APIs that aren't portable to anything but another version of Windows (and sometimes not even then). If you start with OS-specific code, then yes supporting other OSes looks difficult. Combine this with Microsoft's business need to make portability look as difficult as possible to discourage developers from aiming for it and the results are predictable.

Re:It's Windows development tools

[borfast]

Exactly. Add to that some ignorance from those people who say it's difficult to write portable code (perhaps because they have only ever been exposed to that confusion of code generated by MS tools) and you get a mass of people who are willing to sacrifice the minorities for... well, for nothing, really, because they won't get anything more than they already do - but they don't know this. They think that dropping support for other platforms will allow the developer to focus more on the functionality or stability of the software.

And these people are not necessarily your average fresh-out-of-school programmer. Sometimes even people with several years of experience fall into this category and refuse to work on cross-platform code because they say "it consumes more resources". An example I have dealt with recently is Garage Games and their Torque line of products.

Garage Games makes game engines and they used to announce on their website that their game engines run on Windows, OS X and Linux. Long story short, the Linux version is far from the quality of the Windows and OS X counterparts (when it runs at all) and the company dropped Linux as a supported platform, "because it consumes too many of their resources". Instead, the Linux version is now supported by the community - but it bears the same price tag, nonetheless...

Re:It's Windows development tools

[radtea]

It's the Windows development tools...Combine this with Microsoft's business need to make portability look as difficult as possible to discourage developers from aiming for it and the results are predictable.

Amen.

I write only portable code (currently very happy with wxWidgets, and have used Qt in the past) but MS fud is so thick that I have at times had to convince clients that using platform-neutral code would be faster than an "all Microsoft solution."

I've also encountered an amazing number of developers who have no real interest in writing good software. They simply want to do things the easiest way possible that requires the least thought, and MS caters to those people and always has.

There is a delightlful ancedote told in a book by one of the guys who was deeply involved in the first Visual C++ release (the old C7.) At the time Borland owned the C++ compiler market on Windows, and MS was playing catch-up big time. The marketing people realized that the technical goodness and standards-conformance of the Borland compiler was only of interest to a small core of die-hard techies. The much larger market was C programmers who wanted to be able to call themselves C++ programmers. Thus were the Visual C wizards born. They made it easy for people who had no clue to create "classes" and pretend to get it (while putting everything into a single procedural method.) I wish I could recall the name of the book--it was one of the most unselfconsiously arrogant memoirs I have ever read.

One response to the false belief that cross-platform code is not cheaper than single-platform code is to make the point that writing cross-platform code is quite different from porting code from one platform to another. Another is to remind people that we are dealing with Turing complete machines, so all functionality is always available on all platforms. This isn't actually relevant, but it will shut people up who don't know what they're taking about, and if we have anything to learn from MS it is that substance and quality mean nothing when put alongside a catchy argument.

Portability Isn't Hard

[RAMMS EIN]

For the most part, portability isn't hard. You can write pretty much all the functionality of your software without getting into platform-specific issues. Generally, the higher the level of abstraction a languages is at (assembly C Python), the easier it gets. Of course, you do have to use standard APIs and avoid platform-specific ones (win32, GNU extensions, etc.) Things that have caused trouble for me in the past:

  - Sockets (BSD sockets vs. Winsock's almost-compatible variant); this is not a problem in most higher level languages
  - GUIs (there isn't really a standard; perhaps wxWidgets?)
  - Threads (POSIX threads vs. whatever Windows has)
  - Processes (fork, AFAIK, really doesn't exist on Windows)

If I need any functionality that isn't readily portable, I usually target POSIX or BSD, which makes my code portable to many *nix variants, and Windows using Cygwin.

Of course, there are also a whole bunch of cross-platform libraries out there, like glib, the APR, SDL, Qt, ...

Re:Portability Isn't Hard

[Twylite]

I think you've identified on most of the major areas that cause portability problems, with the possible exception of endianness. Since I actively maintain software under Windows, Linux and Solaris, let me add some comments:

If you're developing a GUI application then a decent GUI library will handle most of your problems. Libraries like wxWidgets and QT provide cross-platform GUI widgets as well as thread creation and synchronization primitives. They usually also provide socket abstractions, or you can use another cross-platform library like ACE.

Things get more hairy when you enter the realm of server applications and high performance. Software written for *nix is pretty much straightforwardly portable to Windows, but not the reverse.

The difference is in the schedulers, which affects processes, threads, synchronization, and blocking and non-blocking IO. In a nutshell the Windows scheduler deals with threads and not processes, is a fair scheduler, and a thread can block on multiple conditions simultaneously.

That should be a lot to digest, so let me try to explain that statement and its implications:

First a disclaimer: I am going to talk about *nix in generalisations, because both Linux and Solaris support a variety of schedulers and the default scheduler can change between versions, and userland and kernel threading libraries behave very differently.

ONE: The Windows scheduler schedules threads. Processes are merely containers for threads and their address space, access tokens, etc. Processes are not scheduled. This means that a multithreaded process on Windows has fundamentally different time sharing characteristics to a *nix application. The characteristics would be most similar to a multiprocess application in the *nix world. Most *nix schedulers I have encountered schedule processes first, then schedule threads within the process.

TWO: The Windows scheduler is "fair" -- it is a multilevel queue with round-robin at each level. Threads with a higher priority will always preempt those of a lower priority, and priority elevation is used to prevent starvation.

A number of *nix schedulers use a n adaptive algorithm that favours historically busy processes. This means that a producer-consumer approach may work well on a Windows system, but experience high latency on *nix (note: not reduced throughput under load, but increased latency). Such an approach can work on *nix, but must be implemented differently.

Both Linux and Solaris can be set to use round-robin schedulers (e.g. Solaris's real-time class process), but this can degrade overall system performance.

THREE: A thread can block on multiple objects simultaneously. I said "conditions" before, but I'd prefer to get more specific. A Windows thread can wait for the end of another thread or process, a mutex, and event (like a condition in *nix), an IO operation, a semaphore, a timer, and a couple of others. The thread can also block under any one, or all, of a number of objects are in the signalled state.

Compare that to *nix where you can wait on one of anything except for IO, where you can use select (or poll or dev/poll or kqueue) to wait on multiple non-blocking file descriptors. kqueue is a little more functional, but to my knowledge still doesn't support synchronization objects. If you are using SysV semaphores you can wait for multiple semaphores to be signalled.

This has huge implications for application design. On Windows you can have a consumer thread wait on multiple producer threads using one mutex per consumer to control synchronization. All threads can be awoken from any wait state by a global event to inform them of reconfiguration, shutdown, etc. This is quite trivial, and is a straightforward and easily understood design.

Move the same design to a *nix platform and you have problems. First your consumer thread can't wait on multiple producers without some radical changes (use could pipes rather tha

It depends.

[Shados]

From the sound of the article/question, with their setup, it really doesn't seem like it is that big a deal to support multiple platforms. Plus, the knowledge is there, and they seem to enjoy it, its simple tools, etc. Why the hell not.

Other environments (usualy very customer centric ones, let say consulting firms, with strict deadlines, marketing getting in the way, etc) and more complex applications with very specific needs, it becomes trickier. These are the environments where your job is hard even if you're only supporting one platform, and even using every single last specialised API the platform offers still let you wish for more. In those cases it becomes a bit more annoying to have to go with the lowest common denominator.

Then add to that that users of different platforms -expect- different things. It isn't the end of the world to make something that works on both OSX and Windows, for example. But users of both platforms expect certain different things. I don't know the status right now ,but I remember even in Java a few years back, one had to add some specific arguments when running java apps so that the menu bar would be at the right place in OSX, otherwise it would end up more like KDE/WIndows/Gnome/etc, with everything inside the window by default.

And last, but the most important one, testing, QA, etc. Doing cross platform, no matter what you do (unless you only do HTML and target Firefox only or something) means testing on those platforms, if only to look. That means moving the files, booting up the virtual machine, or something, to check it out. If the app is remotly complex, that IS time consuming like hell.

So in the end, it really depends. If you release your app to the general public, then the advantages of cross platform often outweight the "cost", and its only a matter of time before we are -expected- to do it. When your audience is more limited though, you often benifit more from targeting one particular platform and optimising your workflow like crazy for it, the time saving is significant.