The problem with software
Developing my own socket abstraction library has revealed a number of interesting issues with typical software platforms.
Specifically software compatibility and the incremental release systems used by companies like Microsoft for their Windows operating system.
I decided to make my socket library IPv6 compatible. Windows XP SP2 has support for IPv6. However, this support is lacking some functions that are accepted as standard calls for IPv6 in the BSD socket library. Most of these functions only exist on Vista. This means that anyone wanting to create IPv4 / 6 compatible applications must ensure that any code path they take, doesn’t expose them selves to Vista only functionality. This usually means using legacy functions or calling a larger number of functions in place of a single one that isn’t backward compatible.
Another issue is the fact that functionality is rarely back ported by companies like Microsoft. Vista has a redesigned IP stack with support for IPv4 / 6 and dual-stack, meaning a single socket can support connections from both IPv4 and IPv6 addresses. But if you want to be able to run your own piece of software on a decent number of machines, you can’t use this functionality as it does not exist in XP. Meaning that all software must cater to the lowest common denominator.
Microsoft seem to refuse to back port many of their updates in hopes of forcing people to upgrade to the poorly received Windows Vista. This can be seen in the blatant attempts of locking Halo 2 and Shadow Run to Vista only when the code itself ran fine on XP. This was exposed when a cracking group later removed the Vista only check from a DLL.
Not only is this bad for users, but it’s bad for developers. Having to maintain multiple code paths or reduce code to legacy functions to try and maintain a decent amount of compatibility with users is frustrating at best and a security risk at worst.
The same can be said for applications. No one wants to support an application for ever, but there need to be migration paths available. Software that is no longer commercially viable or maintained needs to be released to the community, or at least under contract to the users, so they have a hope of either continuing to maintain the software in-house or develop a migration strategy when they it is feasible to do so.
This is all too often seen in games that don’t work on Vista of which at least half of my recent game library is included (StarForce, Safedisc and Securom I’m looking at you!) and even on Linux with closed binary games released for 2.2 Kernels which require strange work arounds and antiquated glibc shared objects to run.
Linux suffers from the reverse problem, it is in constant flux. But the open nature of Linux and it’s applications mitigate this as maintainers quickly update their code to work. Closed source binaries like the Nvidia graphics drivers tend to break frequently with X.Org and kernel changes requiring users to hold back until Nvidia go through their release process for updated drivers. This is not a fault of Linux, but the closed nature of most commercial software development models which are not designed to work in this way.
One solution for maintaining compatibility without changing business models or releasing code publically, is something along the lines of GNU HURD which is unfortunately not going to be in a usable state any time soon. GNU HURD lies ontop of a basic micro kernel and runs “services”. In this model, previous compatibility layers, such as Windows 98, Windows XP, etc, could be run as another “service” instead of a library that emulates previous behavior which cannot be guaranteed to provide all the quirks needed to run the software that used the original functions. This effectively means that you could have multiple Windows versions running in parallel, all working together without issue (hopefully). Things such as file system operations, networking, etc. are exposed as other services, mitigating any issue of compatibility being lost without having to maintain older “services”.
Unfortunately, GNU HURD’s development has been going on for 20 odd years and the last I looked they were wanting to move to another micro-kernel and even consider another re-write. It looks like it won’t see the light of day any time soon which I find very sad for such a promising piece of software.
Software developers cannot forget what they are doing. Not only are they running a business, but they are providing a service. If they can no longer provide that service efficiently, then they need give the ability to some one else. The simplest way to do that is to release software as open source once it is no longer commercially viable.