Slashdot Mirror
Competitive Cross-Platform Development?
Avalonia asks: "I work for a software company in the oil and gas exploration industry with a software development team of seven. Our software and development environment is cross-platform on Solaris, Irix, Linux and Windows. Most of our customers are on Solaris and Irix 64-bit systems, but Linux and Windows are increasingly important. Our environment is based around an elaborate command-line system of Makefiles controlling four different compilers (gcc 3.1, Sun Forte, Irix MIPSpro and Visual C++ 7). Needless to say, maintaining this system and producing modern multi-threaded C++ that will go through the four build systems is time-consuming in the extreme. A large proportion of our time is spent finding C++ code that just works rather than being creative and competitive with new functionality. What tools and strategies can we use to increase our productivity and regain our competitive advantage, without going for Windows only?"
"Our recent single-platform competitors (Windows only) can seriously outrun us in terms of productivity by using a single modern IDE development environment - such as C++ builder or Visual Studio - although we can scale onto larger multiprocessor Unix systems. With Windows 64-bit imminent we may lose our 'big-iron' scalability advantage. Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications."
Perl? :)
Platform independent, it's highly creative, and damn if you can't prototype stuff quickly.
www.eclipse.org
I think it runs on several of the environments you mention. And I think there are C++ plugins for it.
BC
why all the different compilers?
.. but can't gcc cross compile? At least then you could dump alot of the compiler-specific scripting in your build procedures.
Hrm, this seems too simple an answer, there must be something wrong with it
"Old man yells at systemd"
Why not just use gcc for all four platforms? The sticking point would likely be Windows, but even if you elect to stay with MFC++ for Windows, you've reduced the incompatibilities from four to two different compilers.
Trust the Computer. The Computer is your friend.
Why not do what a great many other people do (though I have a feeling that you may be doing this already), and target a specific platform for initial release, and then release on the others afterward? This allows you to focus on the platform that gives you the most bang for the buck, but still keep your scaling advantage. If you already have an established product/development environment, then you should already know enough to keep from doing any of the "big mistakes" when it comes to writing portable code. Plus this allows you to divvie up your engineers into functionality vs porting.
Another thing would be to standardize on say, gcc. since the source is available, you can do whatever tweaks you need to to get around any performance issues (I know, easier said than done). Then standardize on things like configure.
this topic (if you haven't read it already). The basic idea is to break out all parts that don't work across the different platforms into their own sections of code (classes/interfaces) assuming you aren't doing that already. Then when you do updates (that will hopefully work platform independantly) you can just right those sections once. Pretty obvious but I have seen so many places with this same issue who actually have completely seperate code bases rather then breaking parts out.
.NET CLR's for all those platforms.
Unfortunately if you are already doing this then you are probably screwed unless someone releases
controlling four different compilers (gcc 3.1, Sun Forte, Irix MIPSpro and Visual C++ 7)
Couldn't you just use gcc across all systems? There are also plenty of opensource IDEs around. We use
Eclipse along with ClearCase. Very good for cross platform.
-- main(s){printf(s="main(s){printf(s=%c%s%c,34,s,34
...why you think you can't use Java.For all the bad press Java gets about being "slow", it is mostly old, outdated FUD. Newer virtual machines are often faster than C/C++ applications, especially in the number crunching arena. Intensive graphics are no big issue since Java now has a fullscreen API (page flipping, double buffering, and all that), a very fast implementation of Java3D, and (if you prefer) OpenGL wrappers.
Even if you feel that Java doesn't cut it for everything, apply the 80/20 rule. 80% of your non-performance critical code in Java, and the later 10& in C/C++. This solution would at least *reduce* your multi-platform woes. You might try posting this on JavaGaming. The guys over there are wizards at making Java perform with intensive graphics. (No surprise considering that some of the industries greatest performance experts hang out there.) They can also help you find the APIs you need. I'd really take a second look before you toss Java out as an option.
Javascript + Nintendo DSi = DSiCade
Java isn't an all or nothing deal. You could write your app in Java and then convert the parts that really need performance into C and call it via JNI. Then you only have to deal with keeping a much smaller C library portable.
-----
Free P2P Backup, Windows & Linux
Here we have to develop a big tool for multiple platforms (lukily all Unix). It would be possible for us to use only gcc, but we decided to use two different compilers (gcc, IRIX) so that we can find compiler specific errors more easily.
We found that this is a good policy to decrease complexity (even though it may look counter intuitive)
Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications.
So what you're saying is:
You've coded it in Java, used native methods where applicable, optimized it, ran it, and it was too slow on every single hardware configuration known to man.
Or are you just guessing?
If you posted on Slashdot hoping we'd help you, give us the details. How "not an option" is it?
-... ---
Step 1. Go to http://java.sun.com and download the JRE 1.4.1.
Step 2. Visit http://www.datadino.com and click on "Webstart Now!".
Step 3. Right click and save Meat Fighter. Find where you saved the JAR file and double click.
Step 4. Right click and save Duke Nukes Stuff. Double click on the JAR.
Step 5. Visit jGoodies and try their wide variety of products.
If you are under Linux, I'm afraid the games probably won't perform well. (Little issue with getting X to be configured to handle high speed direct-framebuffer graphics). However, DataDino should work, although you may need to get the installer instead of using the super-cool WebStart link (Mozilla problem only!). If you don't have a database to use, visit the "Supported Databases" page and download the test HSQLDB database.
The plain and simple fact is that Java is fighting two issues:
1. Poorly written apps that give all Java apps a bad name. (For example, "genius" A decides to load a table before releasing the event thread. Table takes 5 minutes to load and user gets annoyed. The solution would have been to load the table in a separate thread so that the user can see and interact with the table items as they are being loaded.)
2. Perceived performance vs. actual performance. People see Swing and the default look and feel and instantly "feel" that the app is slower than windows. Nothing could be farther from the truth. In all reality, it is probably running faster than the Windows app, it just doesn't seem right. This is caused by the Java L&F being way too "flat". Your brain doesn't quite connect the buttons and other objects as being solid objects to be manipulated.
Javascript + Nintendo DSi = DSiCade
Hi. I'm not usually much of a poster to this site, but since I spent the last
three years of my life doing exactly what the original poster asked
about, I'm going to make an exception.
First my credentials. What we do is write design software for
engineers. Much of the code is intensive numerics, where performance
is critical. There is also a fair bit of Gui work where we don't care
nearly so much. Our target platforms are Windows, Linux and five
flavours of Unix. We had no restrictions as to language, except that
it had to be something we had a reasonable change of finding
developers to work in, (so no Prolog or Haskell). The project is
question was intended to go to a big installed user base.
First, PERL. We investigated PERL and ended up using it extensively
for scripting, but frankly it won't do the job for intensive
numerics, when there are a million dot products to calculate.
Second Java. We initially thought Java was our best bet for UI, and
possibly the rst. Unfortunately it turned out that Java's performance
is not up to it either. It may look fine on Windows and Sun, but some
platforms were ten times as slow as the Windows implementation. That
was the sort of performance hit we could not take. Admittedly this was
three or so years ago. It took us only a fews hours to run a simple
numeric Java program on all platforms, and there were several where it
couldn't cut it. (Are you listening IBM?).
We toyed with a split between Java and C++ for the numerics, but it
would have taken a lot of work. A class can practically be only one
language, and the application didn't split nicely into 'numeric' and
'non-numeric' classes.
We finally settled on C++ and like several posters went for GCC in
order to get maximum portability. Obviously this is not possible on
Windows, and we went with VC6 on that. In practice the number of times
we found code that would run on one but not the other was very rare,
with a big exception I'll come to later. This has worked pretty well,
but GCC is not built for speed. We recently tried porting to the HP
native compiler, and got a better than double speedup. However that is
the sort of hit can can afford to take if it gives us full portability.
There are some restrictions on GCC. Using shared libraries with C++ is
very tough on some Unix platforms. And the native STL on VC6 has some
incompatibilities with the GNU STL, which we fixed by going to STLPort
on Windows.
When we discarded Java, we picked up on Qt as an alternative GUI kit, and have
never looked back. It's powerful, truly portable and very cheap. We
have a few issues, and we don't use the really cutting edge features,
but on the whole it probably saved us man years of effort. In my
opinion its easier to use then Swing, but that's just an opinion.
We also considered writing two separate versions, one for
Windows and one for Unix. Unfortunately that would have essentially
doubled the amount for work necessary, and have done it for ever,
since we were pretty certain the codes would never have converged. We
needed to have exactly the same look and feel across all platforms,
and no-one wanted to settle the hundreds of disputes over whether the
'Windows' or the 'Unix' way was the right UI.
I mentioned a big exception a while back. Early on in the project we
took a strategic decision not to permit multi-threading. We did split
the GUI and the numerics into separate processes, so effectively this
gives us two threads. We've never had a problem doing this, and it
simplifies the code a lot. If you can do this too I'd recommend it.
I suspect that it reduces the differences between GCC and VC6
enormously. We wrote our own classes to isolate the differences in
socket programming between GCC and VC6.
Makefiles? Don't know. We have a hulking great set of Makefiles, hand
coded, driven by hand coded Perl scripts, and both are a nightmare to
maintain. Anyone with better ideas, please let us know.
If you need to reply, call me "Engineer".
Think about Point #2 in this context. How many programs have you tried that you are surprised to learn are Java? If you said none, you probably aren't looking hard enough. (Hint: Look for the java.exe file in the installation directory.) You tend to recognize Java apps by their distinctive look. The distinctive look has problems with perceived performance. As such, many good programmers change it to use a non-standard look.
After you visit jGoodies, you should understand more of what I mean.
As for Point #1. I don't know enough about MFC to be 100% sure, but I believe that Windows automatically handles repainting when you are populating complex objects such as tables. (e.g. You'll tend to notice large tables in SQL Server Enterprise Manager paint nothing in the table as you scroll. Instead, you can watch the text filled in after the fact.) Swing (the Java GUI toolkit) requires the programmer to make these optimizations. Why? Because that's who *should* be doing it.
What if for some reason, I want to design a scrollable table that is fast enough when pulling data over dial-up connections? Under Java, I might design it so that the data doesn't display until the user stops scrolling, or I might display partial data. Under MFC, do I have much choice? Not without jumping through a great deal of hoops.
Notice how Microsoft writes new components every time they have a new piece of software (e.g. Office toolbars, Outlook shortcut bar, etc.). They do this to improve performance in their programs. Java programmers shouldn't have to rewrite GUI components, just data models. However, few and far between is the programmer who actually does this.
BTW, another spot you might want to visit is
Swing Sightings. You can find links to all kinds of well written Java programs.
If you'd like to try a Java program that uses native components instead of Java Swing, try Eclipse. While I personally don't like it, it should help you understand the perceived problem a little more.
Javascript + Nintendo DSi = DSiCade
On portable programming: remember the adage "only the paranoid survive". Assume that language-defined libraries will pobably not behave exactly the same on different platforms (e.g., threading). Rather than using such a library directly, write your own library around it, and code your application in terms of your library. Then, when you port it to the next platform, the only platform-specific changes should be in your library, not everywhere you used the library.
On choice of language: C is probably the ultimate in terms of portability. You might code difficult sections in C. C++ can probably be written just as portably, but I would suggest that you restrict developers to a known-portable subset of the language features, especially with regards to class inhertitance and the "standard" library (whatever the old STL is called now). If one of your programmers creates something that "surprisingly works", expect it not to work on any other platform.
As for RAD: that is a tough one. I've had good success with wxPython (Python is fantastically easy and powerful, and wxWindows provides a very nice set of widgets). There is also a wxDesigner tool for creating dialog boxes (and interestingly, it emits perl, python or C++, your choice). I haven't used it, but I would expect it to be well worth it (it's non-free). The rest of the common GUI development stuff (connecting buttons and menus to action functions) is trivial to code by hand in wxPython.
You might use Java for the interface and use JNI (Java Native Interface) to attach computation and rendering modules onto the VM.
I know of several games that use Java interfaces and then run a real time simulation written in C++.
Maybe you could build on a third-party threading lib?
I work work for an oil and gas exploration company. We are starting on a project to take all of the windows geophysical systems off of windows and go with a Linux solution. Even last year we were trying to move all of our applications off of unix to Windows. Now were are considering the opposite.