Slashdot Mirror
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?"
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...
I personally agree that if you're going to release something command-line based, it shouldn't matter at all. I myself am a software developer, and while my applications are not cross-platform, I certainly appreciate those utilities that are. In my case, what I'm doing is not simple and highly specialized, so cross-platform doesn't do anything for me except make more work for no reason. My applications are not things that anybody else would find useful aside from the people I am making it for.
Most people, when they run an application on Windows, expect it to react in the same old Windows way. Many of cross-platform libraries do a poor job of doing that. I personally don't use GAIM because I can't stand the way it looks. Even though complaining about the ugliness of the GUI might seem stupid to some, it is a genuine problem with people. Clearly, it makes some form of different, as evidenced by the ever increasing "beautification" of window managers like KDE and Gnome.
It may be that this bugs me more than most precisely because I am a developer. It may be that it bugs ordinary people even more. I have no idea. But I think that increasingly the transparency of external libraries would probably help gain them acceptance. The problem is made even worse by libraries that clutter up your system by popping up and asking you to update, or add entries in your menus that you'll never need, as a user.
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.
Blasphemy is a human right. Blasphemophobia kills.
Well, using Qt obviously makes a huge difference. Not only is it an excellent toolkit, but they do a tremendous amount of work to make things portable, so writing cross-platform code becomes a piece of cake. That's also why KDE 4 (which will hopefully end up as the first, "real" Linux gui) will run on Windows.
There are too many things you give up when writing portable GUI code, Qt is ok, wxWidgets is ok, Swing is ok, AWT sucks; using native GUI elements is by far superior. For example, to write a windows app that uses dockable floating toolbars that are easily customizable and contain custom controls within them is relatively trivial with windows and extremely painful if not impossible with ohers because such behavior is not native on other OSs. While you can get portable GUI apps to be very functional, it requires more work to extend the lowest-common-denominator tools.
In the end it is not a question whether it can be done but rather how much work will it take to make it very usable and portable at the same time. I did it for a small app that ran on Windows, OSX and KDE as expected, looked a bit off on Gnome, then after getting Gnome right, OSX controls would not align, and so on. Eventually I just gave up with having to maintain 4 different VMs just to validate things work and now I just stick to WinXP/200x and work more on developing and less on making things portable. It's a matter of preference.
I wrote some complex GUI code with Qt, and found it much easier than any APIs I saw for Windows. From what I've seen, it requires less work to use Qt.
Overall I see Win32 API is just complex. I once was reading up on MSDN about how one would go about processing stdout from a child application. They presented like a 50 lines solution using many tricky looking calls. I ended up writing functionily identical code using POSIX functions like dup2() and fileno() (which Windows in fact does support right out of the box), in a dozen simple lines, and it was portable to boot.
You can be an insane coder too, read: Insane Coding
Also, portability tends to ecourage modularity, which helps isolate bugs and make them less likely in the first place, since the modules are smaller and easier to reason about than large chunks of code.
PHEM - party like it's 1997-2003!
yes, you said fork() and fork() NEVER EVER worked as you describe.
I supposed you were just mixing up vague recollections about vfork()
and its limitations (sharing address space until execve(), etc) with
vague recollections about copy-on-write pages in the child & stuff,
and you were just confused by the whole thing.
But no, you're deliberately spreading misinformation and don't
care about that --
Is it so humiliating to admit you're wrong ?