Fog Creek Software
Discussion Board




Cross Platform development

My company has an accounting package. It's made up of a client, developed with C++/MFC and an database engine, running on Linux.

Recently we began to hear from several customers who said they were deploying Linux desktops with OpenOffice. These aren't enough to justify a full migration, but since their number keeps increasing, we're looking for alternatives.

We know all about wxWindows for the UI, but we're looking for more. We're looking for cross platform network and IO libraries, memory management, the lot.

I began to look at NSPR, Netscape's Portable Runtime, but I don't know if it's still active and up to date. I also know that Qt has an excelet cross platform package that covers just about everything, but the price tag is a bit too much for us.
And, last but obviously least, I know all about Java/Swing/SWT, but we're simply not going that way.

So, does anyone have any idea? Any cross platform libraries that might allows us to create an write once, compile everywhere app?

Some Random Guy
Thursday, August 26, 2004

I thought you said your customers are using OpenOffice.

Derek
Thursday, August 26, 2004

Our Linux customers are. What's your point?

Some Random Guy
Thursday, August 26, 2004

Sorry, I got OpenOffice confused with Crossover Office. Anyway, you could use that.

Derek
Thursday, August 26, 2004

For non-gui stuff, you can try commoncpp: http://www.gnu.org/software/commoncpp/

There is also boost: http://www.boost.org/

Although I don't think they have networking yet, they have a lot of other really useful features.

Combining one or both of these with wxWindows may do it.

Oren Miller
Thursday, August 26, 2004

since your app requires a central server anyways... would it be feasible to create a web interface in html? that way your linux users can access the app and as an added bonus so can anybody else.

johnson
Thursday, August 26, 2004

A web interface is out of the question. We do all processing on the client and use the server only for the database. This is and always will be a fat application.

Some Random Guy
Thursday, August 26, 2004

Check out wxPython.

From the website

"wxPython is a GUI toolkit for the Python programming language. It allows Python programmers to create programs with a robust, highly functional graphical user interface, simply and easily. It is implemented as a Python extension module (native code) that wraps the popular wxWidgets cross platform GUI library, which is written in C++."

Additionally using python would solve your need for cross platform memory management,  networking, and other IO.

http://www.wxpython.org/index.php

lumberjack
Thursday, August 26, 2004

To the OP:

It's a little unclear what your looking for. On the one hand, you can't to a full migration. On the other hand, you're running a thick client.

Basically, what sort of development are you looking to do? What does a partial migration mean in your situation?

I'd second the vote for Qt, but it's at the very least overkill if you're not rewriting the GUI with it, and you've implied that you don't intend that.

Mike Swieton
Thursday, August 26, 2004

Java.  IT was meant exactly for this.

hoser
Thursday, August 26, 2004

Depending on what kind of program you want to develop, RealBasic might fit the bill, if just for front-ends.

Then you can easily compile GUIs for Linux, MacOS and Windows.

Wayne
Thursday, August 26, 2004

Indeed, you could try building a prototype in Python and the wxPython wrapper to the cross-platform wxWidgets (ex-wxWindows) widgets set, and it turns out that some parts are too slow, extract this into DLL's compiled to native code.

Fred
Thursday, August 26, 2004

There's also APR - Apache Portable Runtime.

But basically, if you want something that will completely replace MFC, including database and network support, Qt doesn't really have any contender.

If you can accept a composite solution, then APR / NSPR + FLTK / FOX / wxWindows might be a good solution for you.

And you might avoid the problem altogether by making sure your app works well under Wine; Minor changes are needed, if any - anything that isn't bleeding-edge should more-or-less just work.

Ori Berger
Thursday, August 26, 2004

NSPR and Necko are alive and well working hard every day in Mozilla/Firefox and Sun/Netscape servers.

http://www.mozilla.org/projects/netlib/

http://www.mozilla.org/projects/xpcom/

fool for python
Friday, August 27, 2004

For XP development I wrote LGI:
http://www.memecode.com/lgi.php

Might be what you looking for:
- gui (windows look&feel on everything)
- network sockets
- processes + threads
- Linux/X11 & Win32 ports
- date & time stuff
- multi-linguage dialogs/strings/menus stored in XML (graphical editor)

Anyway check out the site for more... plus there is a reasonable amount of doxygen documentation as well.

Matthew Allen
Friday, August 27, 2004

wxWidgets (formerly wxWindows) actually has a pretty good connectivity library and all kinds of other libraries, and threads and stuff.  It is not just a GUI framework, although it might have started as that and is best known for that..

i like i
Friday, August 27, 2004

> We know all about wxWindows for the UI, but we're looking for more. We're looking for cross platform network and IO libraries, memory management, the lot.

Look into http://www.cs.wustl.edu/~schmidt/ACE.html for cross-platform network/IO/memory management for C++.

Christopher Wells
Friday, August 27, 2004

Python SUCKS.

Mr. Fancypants
Friday, August 27, 2004

wxWindows/wxWidgets DOES have networkin, I/O, ODBC, etc.

wxPython is probably out of the question if you're not planning to change your language too.

Catalin (www.rotaru.com)
Friday, August 27, 2004

If it is MFC, have you tried running it on crossover office?

Karel
Friday, August 27, 2004



Yeah, I'd start going with Java.  It will have all the abilities you need and you can "skin" the GUI for whatever OS you're running on... even OSX.

KC
Friday, August 27, 2004

My problem isn't the look and feel, it's the plumbing. From what I've read it's not that hard to turn a GUI from MFC to wxWindows - there's even an IBM article on how to do that. The plumbing is the tricky part. This is definitely what scares me. I need to have write once, compile anywhere for C++.

Some Random Guy
Friday, August 27, 2004

Mr Fancy says "Python SUCKS."
I'm genuinely interested in how you reached that conclusion, provided of course that it's based on some real experience and not just "I read about it and hate the indentation blah blah".

_
Friday, August 27, 2004

You above: you're not muppet, right?

Some Random Guy
Friday, August 27, 2004

Ouch! that was below the belt.

_
Friday, August 27, 2004

Some Random Guy:

I have a bit of porting experience. About the only advice I can give you is this: decide exactly on your tools (compilers, etc), platforms, and libraries. It seems like the major platforms all have different STL implementations, so you may want to try STLPort, which is fairly compatible.

If you haven't, go read Scott Meyer's Effective C++ line of books. Much of it centers around what the standard actually says, what most compilers implement, and how to deal with the disparity.

I know that that is extremely general advice, but I'm expecting that you mean plumbing as very specific, mostly platform-agnostic already pure logic libraries.

Mike Swieton
Friday, August 27, 2004

STLPort is fantastic!  I used it for porting my giganto library to the Pocket PC (http://kalanithielen.com/portfolio/ktlib/).  Microsoft's "eMbedded Visual C++" program comes with a very stripped down version of the STL that doesn't have any of the streams classes.  I heard that Dinkumware had a good implementation of the STL for the Pocket PC, but when I emailed them about it they said it'd be $600 to license it.  Then I found STLPort.  It's free, it's well-made, and it works on Windows, Mac, Linux, Pocket PC, etc.

Kalani
Saturday, August 28, 2004

I've generally found wxWidgets to be a solid write once, compile everywhere option.  I haven't used the networking components, but it does have a pretty advanced set of them and shouldn't be too bad.  Additionally, Windows network programming and UNIX network programming are nearly identical.  There's an extra step to take when using Windows (you have to initialize the winsock libraries), but otherwise it's identical.  If you export your icons and bitmaps from the resource file to xbm format files, you even get universal icons for the program.

I'd rule out the wxPython just on the basis of language hopping is bad.  Java is off the list for the same reasons.

Clay Dowling
Monday, August 30, 2004

*  Recent Topics

*  Fog Creek Home