Slashdot Mirror


Cross-Platform Development Tools?

Amphigory asks: "I am currently preparing to develop a product. It will have to run in Windows (market realities being what they are) but I really would prefer to develop in Linux. What options are available for this? Some more details: I would prefer something similar to C++ Builder, but I can't wait for Kylix. I am comfortable in C++, Java, Delphi. So far, JBuilder is the leading option. However, I am concerned that the support burden of making sure that all my end users have a Java 2 virtual machine may be too great. Any suggestions? Does anyone have experience distributing a JVM with their package? How easy is it?"

16 of 240 comments (clear)

  1. GTK/Win32 - Real-World Experience by cduffy · · Score: 3

    I've written a few apps on *nix with Glib/GTK and ported them over to Win32. For the most part, I'm very happy -- the porting step took little more than a few hours to get something running (though there was some additional debugging needed to boot).

    Perhaps more of a concern is that GTK/Win32 apps just don't blend in quite as well as pure win32 or Qt ones. The dialog boxes they use are nice, but not the common ones, and the matter of opening a console window for error/warning output is confusing to some users.

    I'm still maintaining a GTK app developed in this manner which has its primary userbase on Unix and a smaller one on Win32 (it's being used for teaching in a primarily *nix-based campus), and am very happy with it. However, were I starting a new project aimed towards Win32 users, I'd probably go a different route (perhaps Python -- easy to train folks in, ridiculously readable -- with its wxWindows bindings).

  2. I've done this - FLTK is the way to go by joss · · Score: 3

    I've used Xlib, motif, MFC(yuck), Visual Cafe, Jbuilder, tcl/tk, VB, Delphi and more...

    Unlike most of the posters, I've actually done what you're talking about.

    The best solution I've ever seen is FLTK.
    Qt is second best, and is easier to get started
    with than FLTK, but Qt is not LGPL & doesn't allow quite as much low level control.

    Jbuilder is problematic, it's better to use java directly (emacs/vi + make files), but implementation of swing is terrible.

    http://www.fltk.org/

    I spent two years developing with java & 3 months accomplishing far more with fltk (on a different, harder project). The app is used exclusively on NT, but I developed under Linux because I prefer the environment.

    Your main options are:

    FLTK: Fast, flexible, reliable, small, simple
    Java: Slow, limiting, buggy, bloated, complicated
    QT: Good, attractive, larger widget set than FLTK, but FLTK is better in the long run.

    Use emacs/vi & DDD & fluid (FLTK gui builder)

    --
    http://rareformnewmedia.com/
  3. Java & JBuilder by Malc · · Score: 3

    Just because you're using JBuilder 3 doesn't mean that you have to use Java 2. I'm currently using it with the JDK 1.1.8. JBuilder is as buggy as hell and it stopped allowing me to debug my Java 1.1 application.

    The problem with JBuilder (most modern developer machines should have enough resources now) is the bugs. Inprise don't release enough patches. Instead they seem to release new versions (at your expense) with new features instead. I use JBuilder to create UI's, create JAR files and compile. I spend most of the rest of the time in Emacs with it's JDE. Of course, windows development could occur under J++ (everybody who uses it seems very happy, people who don't are usually just biased, load-mouthed Microsoft haters)

    You didn't specifiy what your target is. If it's a web-based applet, do not use the Sun plugin and do not use Java 1.2. The plug-in causes problems: I don't think you can use both plug-in 1.1 and 1.2, so your users better not have to use a different version for something else. Plug-in 1.1 doesn't seem to fully enforce the browser's sand box. Until Netscape 6, there are no major browsers that support Java 1.2 or above.

    If you're deploying on the web, you can't really use Swing 1.1.1 with Java 1.1 as the JAR files will make the download too large. Deploying this way on an intranet might be acceptable.

    If you're developing for Windows, make sure you have some savvy UI people. You might not want to try and imitate the look and feel of Windows. This is because no matter how you try, you will never get it quite the same and people like will get irritated! Ever seen that Java bug where a model dialog ends up behind it's parent window? Pain in the arse!

  4. Visual Cafe is nice. by kevlar · · Score: 3

    Lets you code in Java that'll run on any platform, and you can make a .exe for windows as well. I believe it embeds the actual interpretor into the .exe itself (I could be wrong about this though). The version I use is a couple years old, so Sun may have gone ape-sh1t about how it makes those .exe's. Its definately worth looking into though, since you can have the power of Java without the limitations of installing JDK.

  5. Re:C++ sucks. Lotsa added on crap nobody needed. by Arandir · · Score: 3

    There's a beautiful streamlined, compact language within C++, and it's called C.

    True. It's another way of saying "the heart of C++ is beauty".

    C++ is just layers of bureaucracy to wade through

    Huh? You're right. Stuff like function prototypes have to go! Disorganization is the only way to create code.

    God only knows what some new class will inherit in a really big project.

    Well, if you looked at the class definition, you would know. Are you arguing against inheritance here? I know which side I would bet on.

    There's nothing C++ can do that C cannot.

    BFD. There's nothing in C that you can't do in assembly. Why aren't you using assembly?

    No language should require a multi-hundred paged book to explain.

    "C A Reference Manual", Harbison and Steele, 392 pages. I guess it depends upon what you want in a book. The K&R book is pretty short, but that's because it only tells you, but does not explain, about C. Stroustrup's book does a lot of explaining.

    He should've started anew when creating his OO dream rather than trying to maintain backward compatibility.

    He could have done that, but he would have lost the backward compatibility, which was a very important goal. If you don't like C++, try Eiffel or Python instead. Oh wait! You don't like OO to begin with. Too bad.

    Look at the K&R book. A good language needs little explanation.

    If you *already* know C, the K&R is adequate. But if you don't know it, K&R is a serious roadblock.

    New C code will still be being written 20 years from now. Can you say the same for C++

    Yes I can say the same. Why shouldn't it?

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  6. QT by rjstanford · · Score: 3

    One of my personal favorites would have to be QT by Troll Tech. This is a cross-platform C++ toolset that cross-compiles into Windows and X code. There are no royalties or runtime costs charged, on any platform.

    The popular UNIX desktop KDE is written using the free version of the QT/UNIX development package. If you've used it, you'll probably agree that its fast, comfortable and very solid -- all very important considerations when coding a real product.

    This is a very good, clean, serious package. If you're interested in UNIX/Windows cross-platform development I strongly suggest that you check it out.

    --
    You're special forces then? That's great! I just love your olympics!
  7. Try Microsoft Visual Studio by cpeterso · · Score: 4

    It is a cross-platform dev environment. It allows you to use Windows 9x, Windows CE, Windows NT, and Windows 2000!

  8. Qt by Arandir · · Score: 4

    Qt is an excellent crossplatform library for C and C++. One caveat (before everyone else mentions it) is that it is not free for Windows. Run time libraries are freely redistributable. If your project is already commercial, then this should not be a big hassle. The qt-interest@trolltech.com mailing list is quite active with a good mix of both Unix and Windows developers.

    There is a free evaluation copy that you can download to try it out on Windows, or just try out the free X version that's probably already on your distro.

    The embedded Qt is right around the corner, and a Mac version is being planned.

    The Qt classes blow away those jokes offered up by MFC and make OWL look puny. From what I understand, Qt will be the GUI component of Kylix.

    Yes, it's unfortunate that Trolltech charges for the Windows version regardless of whether your project is open or closed source. I wish they had the X pricing structure for all platforms (free for free software, closed for closed source).

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  9. Wrong. Badly wrong. by chazR · · Score: 4

    Given the GUI nature of Windows I'd assume that C++ is out of the question - after all under Linux you've only got gcc - which works well enough for simple Linux apps but would fail miserably under the burden of a full-sized Windows app

    Ever heard of the Linux kernel? Or Gnome? or KDE? Or Gnumeric? These are all large projects which gcc compiles fine. g++ scales just as well. And they are both a *lot* closer to the standards than VC++.

    ...and you can't use the logical structure of MFC with it either.

    Logical structure? MFC barely has *any* structure. It is a poorly designed, unstructured, non-standards complying disgrace. Often, you are forced to use the raw API because MFC can't cut it. As a framework, it's a disgrace.

    Java is a lot slower than C++, and can be a lot more difficult to use for a large project, what with keeping track of finals, absracts and the like.

    A decent, modern JIT (Symantec, Borland and even MS have *very* good ones) will run Java with a similar, or even better, performance than C++. And if you have trouble keeping track of finals, abstracts etc. then you have completely missed the point. These are tools which make large-scale development considerably easier in Java than in C/C++. Develop a couple of large (100,000+ lines) projects before dismissing useful language features.

    Python is a marvellous language with some great features but it is fairly rigid, and its indentation rules leave a lot to be desired

    Umm. These rules are a critical part of the language. They are intended to make it easier to maintain, for one thing. A bit B&D for some tastes, but they are there for a purpose.

    And Perl? Well, for anything other than a simple CGI script, forget it. You won't be able to understand the code five minutes later, let alone after a couple of release cycles.

    Any competent programmer will be aware of the facility perl gives you to shoot yourself in the foot, and don't make use of it. Well-written perl is no worse than any other powerful scripting language. If you have trouble understanding regexps, do some learning. Practice a bit, and use the /x modifier.

    Any other scripting languages aren't even worth considering.

    Why not? Do you have extensive experience of them? Or do you just find it hard to name another 5? What about REXX, for example? Just because it's not as popular as perl shouldn't be a reason to write it off. How about REBOL, Tcl/Tk, Scheme, Guile, Snobol, even ;)

    The Windows platform will continue to lose mindshare. One day you will have to port. A port from Visual Studio is not a thing I would wish to be involved with again. Been there, got the scars.

    I apologise.

    Share and Enjoy.

  10. Browser GUI by AlphaHelix · · Score: 4

    Something worth considering, if it's practical, is to have your product use JavaScript and a web browser as its GUI. We have a cross-platform product that supports six different platforms, and rather than dealing with proprietary GUIs and GUI translator tools, we have an HTTP server that handles some special CGI commands, and serves the GUI as JavaScript. Since the GUI is the bulk of the platform-dependent code in many systems, this reduced the amount of platform dependent code that we needed significantly. On the other hand, our product has all sorts of other platform dependencies that have their own difficulties, so this approach clearly doesn't handle all of these problems.
    * mild mannered physics grad student by day *

    --
    * mild mannered physics grad student by day *
    * daring code hacker by night *
    http://www.silent-tristero.com
  11. cross platform toolkits by jetson123 · · Score: 5
    I looked into this recently, and here are a bunch of suggestions/evaluations:
    • Java 1.2. Technically, I think this is by far the best choice: easy to program, robust, extensive built-in APIs, etc. But you need to somehow get a Java 1.2 runtime onto your clients machines, and it still isn't efficient enough for number crunching (if that's part of your application).
    • FLTK Small, cross-platform (Linux, Windows, ...), straightforward C++ GUI toolkit. You can link your applications statically and they are still small enough to distribute. It includes a GUI builder. Good OpenGL support. Has its on look-and-feel. Versions 1.x still lack drag-and-drop and dynamic widget layout support.
    • wxWindows Very complete C++ GUI toolkit, cross platform between Linux, Windows, MacOS. Lots of widgets. Drag-and-drop support and dynamic layout. Uses platform look-and-feel. Very MFC-like, including the use of event tables for event routing. Steeper learning curve. GUI builder doesn't seem to be quite ready yet.
    • Qt Commercial toolkit. Pretty good quality. But you need an expensive, per-developer license unless you do open source. I don't think it's worth the money or hassle compared to wxWindows.
    • Willows Supoprts genuine Windows programming on Linux, in an open source environment. (I haven't looked much into how complete it is because I don't actually like genuine Windows programming :-)
    • GTK There is a Windows port as well as C++ bindings. I don't think the Windows port is far enough along yet for deployment, though.
    • Tcl/Tk The Tk toolkit comes with a scripting language you may not want, and, out of the box, it has a fairly limited widget set by modern standards. No drag-and-drop support. Multiple GUI builders. Great canvas class. Exceptionally easy to get started with, great for prototyping.
    • Fox Toolkit In may ways like FLTK. Has drag-and-drop support, but cross platform is still a promise.

    Altogether, if you can deploy Java 1.2 and it's efficient enough for your needs (for most applications, it is), I'd go with that. If you need something in C++, I'd stick with wxWindows, FLTK, or Tcl/Tk, depending on your specific needs and preferences. I think you may also want to reconsider whether you really want an IDE and GUI builder; I find writing GUIs by hand in toolkits that are set up for it is ultimately faster and easier.

  12. On distributing a VM... by SuperKendall · · Score: 5

    About a year ago I worked on a project that distributed the Java2 plugin, where the problems are similar - in our case we also had to run as an application so we supported standalone VM installation as well.

    There are a few good options I can think of:

    1) Get an installer like InstallAnywhere that supports detection and installation of VM's. With InstallAnywhere, you can build a .exe installer with the VM bundled in and it will install it if it's not installed already - this is also a nice option as it can set up desktop icons or start menu items for you in a cross platform manner (should you want to be able to install to other platforms). InstallShield for Java is supposed to be nice, but I have not used it for a long time so I couldn't really speak to it's strengths.

    2) Along with the Java2 plugin, you can get a helpful tool that generates html code to wrap around a normal applet - this code will auto-detect if the plugin is installed on IE or Netscape, and install the plugin if it's not already in place. You could create a VM install page and have the plugin installed by the browser, which installs the Java2 runtime and your app will be able to run that way.

    One thing you will run into is that Swing apps can use a fair amount of memory - I use two regularily right now, "Forte For Java CE" and "TogetherJ" (which is really amazingly useful now!).

    One thing that would be really nice is if you could run more than one Java app in a VM, but right now you pretty much have to load one VM per application. It wouldn't be very hard to work up a solution to that problem, but no-one has done so yet...

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  13. Qt and C++ is great for this by kjeldahl · · Score: 5

    I've developed several applications using linux, gcc and qt and recompiling under windows (using Microsoft Visual C++) right before final delivery, and this works mostly great.

    Be aware to do some ifdefs if you use "advanced C++" though. The libraries provided with Microsoft Visual C++ really suck (iostreams and STL), and be prepared if your clients try to work with your source code. Microsoft has a tendency to call different releases of the various "6.0" compilers the same (even after different servicepacks have been applied), and this will lead to some really wierd error messages when you use things like iostreams and STL and will cost you and your clients quite a few hours of work unless you are able to make sure that everybody is using the EXACT same version of VC++.

    I have been able to compile the Qt examples under windows using the excellent mingw32 ("complete gcc development environment under windows"), but mingw32 is not as far as I know a supported platform from Troll (the developers of Qt) which means you will need to do some tweaking yourself.

    But all in all, using Qt, gcc, and Microsoft Visual C++ I am able to develop and test under linux and then reboot and recompile (with some tweaks for iostreams and possibly STL) for Windows.

    Assuming ming32/gcc becomes a supported platform from Troll Tech, cross development should be REALLY REALLY easy, and give you access to a more complete iostreams library and STL.

    Good luck,

    Marius Kjeldahl

  14. Contrary to popular belief, I am not a Java zealot by DaveWood · · Score: 5
    Over the past few years I've written hundreds of thousands of lines of Java code, from 1.0 to 1.2 in just about every JVM under the sun (not a pun, I swear).

    Yes, my friends have been fearing for my sanity. Yes, I have reimplemented almost every part of the API at one time or another. Yes, I do still love writing things in Java, and no, I am not a masochist. The ordinary, common-sense benefits in the language and the process are just that important to me.

    Until I saw 1.2, I would agree with my (ahem) colleagues in saying that Java "isn't ready for prime time" (oh, I hate that expression). Between the memory leaks and the various bugs in the foundations of the vertical APIs, and the "not-quite-thin-but-not-quite-fat" state of the APIs themselves, 1.0 was a toy, and 1.1 was interesting - it had a lot of the ingredients, but it wasn't ready.

    1.2, I believe, is finally "OK," as near as I can tell. I have beaten the heck out of it, and I have these things to say:

    • It no longer leaks memory (!)
    • It is reasonably robust - crashes are now rare
    • The Hotspot performance gains are real and, actually, significant
    • Lo and behold, the Linux port is actually stable and feature-complete
    Netbeans, which I have always loved, suffered terribly and unjustly under 1.1's bug load - so much so that you had to be crazy to use it. Under 1.2, Forte (Netbeans sequel) screams, kicks flaming ass, and is quite frankly the best Java IDE I've used - and coming up on the best IDE in any language.

    So write it in Java 1.2. It will be a lot less painful: avoiding the pointer/allocation/array-stomping headaches alone makes it worth it, let alone the other improvements in compile time sanity and language clarity. The API is stacked, and will save you tons of time.

    Distributing the VM itself is quite easy with the proper windows tools; there are several common ones on the market that all work very well, and ultimately disting the VM with your stuff is trivial. Forte itself is actually a great example of how easy this is to do.

    Finally, despite words from people who I have a psychic intuition have never actually benchmarked a native vs. Hotspot VM implementations of a real application, its speed is acceptable - perhaps even good, on Win32 using the latest VM. You can also consider Java-to-native compilation options...

    Notwithstanding the fact that by design, Java will be around long after the Win32 APIs have gone the way of the dodo, and you can merge native and Java object code without destroying the OO design of your system... Use Java, dude!

    The only person all this good news doesn't help is me, since I'm in the business of writing applets these days, not applications... Doh!

    --
    Say it with me, people: "Fuck the header files."

  15. GCC cross-compiler by jnd3 · · Score: 5
    There is a way to use GCC as a cross-compiler in Linux (i.e. use the compiler in Linux to produce Windows binaries). There's a link from the SDL page that describes Linux cross-compiling for Win32.

    There are also cross-platform GUI environments like WxWindows, V, etc. See the MinGW FAQ for more information as well!

    JimD

  16. Re:gcc! (duh!) and Qt, Winelib or WXWindows. by VaporX · · Score: 5

    > As many people undoubtedly will point
    > out, "real programmers" don't use IDEs.
    "Real" programmers don't make bonehead statements like this. "Real" programmers use whatever it takes to get the job done with the best quality in the shortest amount of time. If you're going to develop exclusively for Windows, you'll find that using the Visual tools (or possibly CodeWarrior for Win) is far superior to cross-developing from Unix. I've done both. It's okay to be anti-Microsoft, but don't let anti-Microsoft politics/feelings impede your business... Get your job done first.