Fog Creek Software
Discussion Board

Unix neophyte seeks advice

I've written a program for Windows. It uses wxWindows for the UI and this little Win32/DirectX layer I wrote to provide graphics, sound, input and timer. Now I'm idly contemplating porting this to Linux, as it would fill what you might describe as a "market hole". (I use the phrase advisedly, as it's not clear that anyone wants this hole filling, but since it is a free project this is totally irrelevant :)

None of the libraries I found look very good (long story), so I'm thinking of taking the route I took on Windows, which I took for exactly the same reason, and using the system stuff directly. But now I've got a problem... where do I get started with this kind of thing? Are there any books I should be reading? I did a search for stuff about XFree86 DGA (which I'd heard was where it's at), but it seems that's now deprecated. Erm... in favour of what? And does it and/or whatever replaces it work within a window?

I'm less interested in specific answers than any suggestions about where to look! I have just been spoilt by and got far too used to Windows, I suspect, and I'm not sure where to go first. So if anyone has any suggestions for this IDE-loving auto-complete-requiring pointing-and-clicking windows weenie, perhaps after having been through this themselves, they would be gratefully received.

Thursday, July 15, 2004

have you taken a look at REALbasic?

depending on what you want it might work pretty compiles standalone apps for Linux, Windows and Mac and provides autocomplete and all the other benefits of an IDE.

Thursday, July 15, 2004

Having a cursory interest in wxWindows, I had thought it was portable between platforms.

So I suppose you are concerned about the DirectX/Win32 platform specific bits of your app?

Are you making maximum use of the platform independent aspects of wxWindows?

Thursday, July 15, 2004

My feeling is you are going to be disappointed with a lot of the IDEs on Linux.  Maybe other's have had better experiences than me, but everytime I try to use an IDE on Linux I find myself running back to Emacs. 

You might be surprised what emacs can do.  I am using a variant of Jan Borsodi's configuration which can be had here:

One thing you have to understand about X is it has a really strange and twisted history which might not be obvious at first glance.  X was developed to work across a network where the application and the display are on different machines.  It is a classic example of Unix over engineering, or solving problems that don't exist. 

The architecture might not seem like a big deal until you get into configuration or performance issues.  All the performance hacks are pretty much work arounds for what is often an inheriently broken design.

If I was you, I'd try to find a small portion of your code that doesn't rely on a lot of specific functionality and port that first.  Just to get comfortable working in a Unix like environment.  Say like a utility library.

The good news is if you are working in C++ both msvc and g++ are much more conformant compilers than a fews years back.  So language issues are as big of a deal as 5 years ago. 

christopher (
Thursday, July 15, 2004

That's a pretty biased view of X--why do you say it was solving problems that do not exist?

All the time I used X as my main user interface, I was running apps on machines remote from the display, sometimes on different continents.

It took ages for the equivalent missing functionality in Windows to be filled in by Citrix, Netmeeting, NT Terminal Server, VNC and so forth.

And even today, when there is a big but underutilized dual CPU, 2 GB killer machine on the other side of the office, we see people getting up and physically walking over to sit in front of it when they want to use it. How primitive!

Thursday, July 15, 2004

The wxWindows toolkit is indeed quite crossplatform. I've had fairly good experiences with it, myself.

I'm not too sure what exactly you're asking. If you're looking for an IDE, I don't have much good suggestions. If your app is relatively small, the quickest way to get something running, with the lowest learning curve, would be a shell script that calls g++ ;) But then again, I grew up with command line dev, and never feel comfortable in an IDE, so your mileage may vary. I hear Eclipse is very good, and the same about KDevelop.

If you're looking for specific advice about porting, I can't really say anything without more specifics.

If it's a free project, why not post the source? Even if no one wants to take on the task, you'll get better feedback, I think.

Good luck!

Mike Swieton
Thursday, July 15, 2004

There is a multi-platform game library called 'Allegro' that might cover the stuff you want.  I know it handles things like times, input and graphics (but stays away from 3D stuff).  I know it has been used for more than just games.  It has been ported to Linux, Windows, DOS and maybe Mac.  Do a google search if you are interested.

Aussie Mick
Thursday, July 15, 2004

I second the Eclipse IDE + CDT 2.0 (make sure you've got at least a midrange system though).
Also you'll definitely want to take a look at the SDL library (


Eyrak Paen
Thursday, July 15, 2004

I already discussed my thoughts on X here:

There are so many problems with X that I could on for days.  I'll spare you most of the details, but here are a couple of the worst:

XResources (or how backspace deletes and delete backspaces?)
No stardard window manager
Two process model requires all calls to the renderer be serialized.
No standard widget set....

I still wish we could drop X and start over with a frame buffer model like both Windows and Mac OSX have. 

My feeling is that the complexity of X is the biggest reason Unix lost on the desktop.

Remember CDE?  How about Motif?  OpenView? Xlib anybody?  Talk about a mess. 

If the Gnome and KDE folks would work together then that would solve a couple of the problems.  That's still a big if.

christopher (
Friday, July 16, 2004

If your graphics / input has a real-time / game-like nature, use SDL. If it's more of an application and less of a game, FLTK or Fox might fit the bill better.

For 3D graphics, you want OpenGL.

As others noted, WxWindows itself works perfectly well on Unixes.

Or, you could link against WineLib (a Win32 / DirectX library for  x86 and non x86 unix). It's not perfect and missing some functionality, but not much - many programs can run out of the box (using the original .EXE, without even compiling on Linux). You can either work around the missing functionality, or -- better -- help implement it.

Most complaints against X are unmerited. X is not slow. Xlib is somewhat more complicated than it should be, but that's also true of Win32 and almost any general-purpose-enough toolkit.

CDE, Motif, Athena, Xt and the rest are dumb and ugly not because of any X deficiency, but rather because whoever developed them did a less-than-spectacular job (Xt and Motif are overengineered to the extreme).

KDE and Gnome did a good job. FLTK, WxWindows (now WxWidgets, and Microsoft's request), Fox and others also do a good job.

X is inherently networked, but if you need the extra speed, you can use the XShm extension, and get performance that is on par with Windows on the same machine. If you don't use XShm, you can use X remotely - and, as it was pointed out, Citrix and Terminal Server are still far from giving capabilities that X gave nearly 20 years ago.

Ori Berger
Friday, July 16, 2004

s/and Microsoft's request/at Microsoft's request/

Ori Berger
Friday, July 16, 2004

For sound, input, timer: SDL ( )
For graphics: SDL and/org OpenGL

Friday, July 16, 2004

The network abstraction is in the wrong place in X.  IMHO putting graphic primitives on the wire is a bad idea.  I feel the abstraction should be at a higher application level like say HTML or XAML maybe.  If that isn't good enough (say for games), it should be run 100% local.

I stand behind what I say.  I used to think that X was the ultimate in network computing, but I feel differently now.  I am now convinced it is the primary reason Unix failed on the desktop.

To program for X you really need to study the history to understand why things are the way they are.  The fact that there is xlib, CDE, Motif, Gnome, GTK, FVWM, KDE, Lesstif, TWM, etc, etc, etc.  is all part of the problem.  If a consistent, usable, UI had been the focus instead of remoting an application's display, I feel Unix would have been far better off. The fact that the shared memory extension even exists points to the problems with the core architecture.

I recommend this book for anybody that plans on doing X programming:

It at least gives you an idea of what was going through the designers heads at the time.  I don't blame them for their work.  It was certainly an interesting idea.  I just don't think it is a good design for todays general purpose desktops.

Yes with X you can run Firefox on a machine in the next state, to browse Joel on Software in NY, but by doing so you increase the network traffic and the CPU cycles required to read this post, with the side benefit of it taking twice as along.  BTW, I'm not a fan of citrix, et al, either.  I feel these architectures provide all the drawbacks of network computing (latency, partial failure, high server load, etc.), with out the advantages.

I'm off the subject here, and I'm pretty opinionated on this topic, so I'll shut up now.

christopher (
Friday, July 16, 2004

I wrote my first X program 13 years ago. I've watched X evolve. I disagree about the uniform, consistent UI - such a thing has to be very well designed, and have inherent up/down compatibility problems. On almost every Win32 and Mac program you have non-standard controls (Even owner-draw, which is "standard", requires xlib-style capabilities from remote).

X would have died miserably like the various competitors of the time if it worked like HTML. So would Win32 and Mac if they didn't support lower-level primitives. Instead, you can run a perfectly modern UI (with Win2k/Mac look, courtesy of e.g. KDE or FLTK or Gnome) on an X terminal manufactured in 1990 and not updated since. And if your program isn't doing too much graphics, you get decent performance. You wouldn't have been able to achieve that any other way (Except, perhaps, VNC-style, which is much higher bandwidth and essentially just a different set of primitives) -- see, for example, HTML 1.0

Like every legacy system, X has a lot of useless baggage that gets carried around - all the resource management, much of the old color management, the old font management, etc. But it was built to last, and -- while it would have been better designed in hindsight -- it is not a bad design at all. Some implementations are good too.

Avalon requires a complete re-implementation of the Win32 API, and it's probable that some old features won't mix with some new features. On the other hand, Keith Packard has an X server that does most (or all?) of what Avalon promises. It's perfectly backward compatible, and works today.

X has good future extensibility and backward compatibility, and always had.

Ori Berger
Friday, July 16, 2004

There definately needs to be a low level, hardware independant 2D abstraction layer in any modern desktop system.  But that abstraction need not be serializable over the wire as it is in X. 

christopher (
Friday, July 16, 2004

*  Recent Topics

*  Fog Creek Home