The Old Joel on Software Forum: Part 3 (of 5) - Actual Cross-Platform GUI development

Actual Cross-Platform GUI development

Back in September the occasional topic of cross-platform GUI development came up. For a project I'm working on currently I had a need to build a GUI application that was write-once, compile anywhere. The strong recommendation for wxWindows made in several discussions swayed me, and I looked into the product.

As part of the earlier discussions, it was mentioned that nobody here has actually tested the cross-platform capabilities of wxWindows. I can now not only say that I have tested them, but that it worked perfectly. I needed no source code changes to move between Windows and OpenBSD, and the program looks great on both platforms.

I posted a more detailed story on my blog: http://www.lazarusid.com/notes/

Clay Dowling
Thursday, January 1, 2004

Clay,

I too use wxWindows, but primarily for Win32 development instead of MFC. I use the MinGW version of GCC for my compiler.

Your comment that the library is huge is correct, but I manage to create static executibles (no DLL required) that are around 400K.

Firstly, I edit the setup.h in wxWindows to disable any components/features that my app doesn't use. Then I recompile the library. Then I recompile the app.

After running strip to remove debugging symbols, and running UPX on the final .exe, I am able to get some fairly large apps to be 400-600K in size without the use of a DLL.

I'm currently porting one of my apps to Mac OS X, and it seems to be as easy as you pointed out.

Chip
Thursday, January 1, 2004

This is pretty good to hear. Borland is "officially" supporting wxWindows with their new multi-platform C++ IDE known as "CBuilderX".

Mitch & Murray (from downtown)
Thursday, January 1, 2004

Chip,

I'll have to give your static linking trick a try. If that proves to be a pain I was thinking of something in my setup exe that will only download the DLL if needed. For the app in my screenshots, the user typically has a pretty fat, always-on data pipe, so that's not unreasonable. So far it's just one application written with this library, so we aren't seeing the DLL benefit. I have some other projects though where the DLL will pay off huge dividends. Little apps were coming in at 2 MB staticly linked, so a single 3 MB DLL shared among half a dozen little apps makes for a huge space savings.

Of course, I'm out of luck on the UNIX front, where distributing system libraries can make you very unpopular. I'll have to link staticly there.

Clay Dowling
Thursday, January 1, 2004

Clay,

I too was getting 2MB statically-linked Hello World GUI apps when I started out. But trimming the library by uncommenting items in setup.h shrunk that down to around 600K.

Stripping and UPX'ing further shrunk down a Hello World down to a 250K statically-linked executable.

My larger apps were only 100-200K above the Hello World baseline.

My trimming of setup.h was conservative, and left in all of the standard GUI components and only removed the obvious bloat (Unicode, jpeg libraries, etc...).

The comments in setup.h tell you what is safe to remove and what is not. It is quite helpful.

Chip
Thursday, January 1, 2004

Just a comment re- UPXing executables:

That's fine when you have many resources to spare. However, it may be problematic if you have many instances running at the same time (e.g., on a Terminal Services / Citrix machine), and/or constrained by physical memory.

Each UPX program instance allocates memory and expands itself to that memory. If you have 20 copies running, you'll need 20 times as much memory for the code segments (which may mean 200MB, if your unpacked executable is 10MB). Furthermore, when swapping out, that memory will have to be written to the page file.

If you use a "standard" EXE, instances share the same physical memory for the code pages - and if a code page ever needs to swap out, it won't be written out - instead, it will be re-read from the EXE file when needed.

For most programs, at most one copy is running, and physical memory is available in great abundance. However, the UPX-unfavorable conditions are becoming more likely with Windows Server 2003 and Terminal Server popularity.

Ori Berger
Friday, January 2, 2004

That's very good to know. I'm not doing anything with Terminal Services at the moment, but it's been suggested in the past, and I would have fallen into that trap.

Clay Dowling
Friday, January 2, 2004

FWIW, I read somewhere about certain cases where UPXing a program is not safe, but it was too technical to remember :-)

You might want to browse through the archives to know more:

http://upx.sourceforge.net/phpBB/

Frederic Faure
Friday, January 2, 2004

But what if your app already exists with MFC and rewriting with wxWin is not an option?

I've tried Windu but the platforms it supports are very limitted and even obsolete. (i.e. IBM AIX 4.3.3 which IBM has discontinued support on, and versions of compilers which are no longer for sale.) I looked at MainWin too but it's so expensive that it becomes unprofitable.

old_timer
Friday, January 2, 2004

> But what if your app already exists with MFC and rewriting with wxWin is not an option?

The wxWin API is a clone of MFC in many ways. In about 90% of the functions you can port simply by replacing the C at the front of the function name with a wx.

Here's an article explaining how to do it:

http://www-106.ibm.com/developerworks/linux/library/l-mfc/?open&l=920,t=gr

Chip
Friday, January 2, 2004

I'd just like to say that I've started to explore a little further into the capabilities of wxWindows. The features that I could get through subclassing were pretty impressive. Less than half an hour's work got me a grid on a par with the data entry grids in Access. New rows automatically added at the bottom, and columns resize to fit the window. Such things are probably also available to the MFC developer, but it's really nice to find in a cross-platform library.

Clay Dowling
Sunday, January 4, 2004