Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Programming IT Technology

Cross-Platform Development Tools? 240

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?"
This discussion has been archived. No new comments can be posted.

Cross-Platform Development Tools?

Comments Filter:
  • by Anonymous Coward
    Amulet ( claims to be a mature free cross-platform GUI development environment for Linux, Win95/NT and Mac. I haven't investigated it personally, but it seems worth checking out.

    Steve Huntley
  • by Anonymous Coward
    You can distribute the Java Runtime Environment with your app. This just has the necessary components to execute programs, no compilers, no debugger, etc. The only bit you need to write natively are the program wrappers. I use .bat and .sh scripts, but some people like native executables for each platform.

    We actually have shortcuts that point to the .bat files so that we can change the shortcut's icon.

    Then your tree looks something like this:

    These are the programs/scripts your users actually run (or a shortcut for Windows).


    Their classpath's point to the same place:


    But the java executable is different:


    Windows start.bat:

    @echo off
    set CLASSPATH=..\shared\lib\myapp.jar;..\shared\lib\rt .jar

    CLASSPATH=../shared/lib/myapp.jar;../shared/lib/ rt.jar
    export CLASSPATH
  • This is not flamebait.
    Saying it doesn't make it so.

    There's a beautiful streamlined, compact language within C++, and it's called C.
    I would agree that C is a incredible language. One can hardly imagine Unix without it BUT it is not the "be-all, end-all" language; nothing is or likely ever will be. IMNSHO languages are tools; nothing more. If I am coding in isolation and targeting Unix and Unix-like operating systems, I choose C. If I am crossing over to the Windows side of the world, I tend to stick to C++/QT or dip my toes in Java. If it's commerical work I just use what they tell me; although I do have input, I am not the decision maker. If you want to be effective, use the best tool for the job. Hell, I'll even use PERL. *ducks flying regexes*

    Look at the K&R book.
    Incredible book. Mine is dog eared and one of my favorites. I could not recommend it more highly.

    New C code will still be being written 20 years from now. Can you say the same for C++ and Java?
    Of course you can say they will be around. I don't think this industry ever throws things away. Think about all those COBOL programs running around. Why is anyone going to throw away anything that works? <:

    I don't mean this as a put down or anything but have been getting tortured by some old C++ guys on a nightmare project or something?


  • Apparently you haven't asked Loki what they've done with g++. Of course, they did have to patch it for Heavy Gear II... but even their other stuff is pretty impressive!

    And g++ will soon be much better. Wait for version 3 and the new libstdc++. Then we should have about everything we need for C++ on LInux. Well, and a debugger that can step over STL crap automatically....
  • by Micah ( 278 )
    No one's mentioned this yet. Perl/TK is actually quite nice, for some things. Now, I wouldn't recommend it for a large program of any kind, or anything involving CPU-intensive calculations. But it has a fine GUI that's powerful and relatively easy to learn. And the canvas rocks! Check out the demo widget program. You'll be impressed.
  • Bell's Second Law [] strikes again...
  • On the contrary, few programmers are actually versed enough with how to _handle_ the power of a multi-paradigm language that they often wind up being more productive in a more constrained environment.

    This notion has its roots in philosophy where "true freedom" is actually a misnomer: we require some constraints in order to make sense of the world and to be productive in it.

    So yes, there are situations where OO is not the ideal paradigm. Functional languages are a great alternative and are very expressive.

    I think it's wrong to conclude that because OO is not a panacea it will be laughed out of the office. It is certainly an improvement upon top-down, procedural design in terms of flexibility and maintainability.

    OO doesn't replace the need for good programmers. Shoddy programmers will ALWAYS make shoddy programs, no matter the paradigm.

    HOWEVER, I would say that the constraints imposed on an OO language like Java or Smalltalk would result in a program that is less shoddy in the area of memory leaks and segmentation faults.

    This, at the very least, is an quantitative improvement, by enforcing a paradigm of dynamic memory allocation (the "new" operator) and removing raw pointers from the language.

    OO is not the perfect paradigm, nor should it be, or we might as well stop all software engineering research right now. It would be hard to argue that there is any ONE TRUE paradigm at all. I don't think anyone is claiming that it is the end of all software paradigms. It is, however, a useful and productive paradigm, and is worthy of widespread use. Which, as a matter of fact, is the case.
  • Go to Alphaworks and download "DirectDOM". It's there. And it kicks ass.
  • Paradigms per se have zilch to do with memory mangement. A fully garbage-collecting, memory-safe environment can be implemented beneath any language.

    That's debatable. OO is a model that promotes a very simple dynamic memory allocation mechanism: the 'new' operator. This operator was designed to be combined with an automatic garbage collector. [This is based on observing Smalltalk - I'm not sure if Simula used "new"/had a garbage collector]

    That C++ doesn't do this is somewhat irrelevant as C++ is clearly a "multi-paradigm" language, not a strictly OO one.

    It is certainly an improvement upon top-down, procedural design in terms of flexibility and maintainability.

    The jury is out on that.

    Perhaps... I think that empirical evidence shows that software productivity and quality has been modestly improving over the last 20 years. [Given that the whole economy's productivity has been improving around 3% per year, mainly caused by information technology, according to Alan Greenspan]. The improvement in programmer productivity may not be caused by OO... but there certainly would be a correlation, just as there would be a correletion among other "paradigm waves", such as the structured programming movement in the 70's.

  • The keywords "new" and "delete" could just as simply draw you a slice of memory in a completely different
    way on different computing platforms. You're tying syntax to implementation.

    In a way I am, and yes you're right here. I think the point I'm making is that OO systems change memory allocation into "allocating objects".

    A procedural language such as C has no such model. It's a "blob of malloc'ed memory".

  • For cross-platform development, remember to check out the GUI Toolkit, Framework Page []. It lists almost all cross-platform GUI libraries and many other types of toolkits out there, an essential resource for developers.

  • Since you mention Tcl/Tk, it's also worth considering Perl/Tk. See the Perl/Tk FAQ [], or just all the Perl/Tk links at [].

  • 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++

    True enough for Java but Swing is another story. Swing is a very nice, full featured, well structured, flexible GUI API but its performance is still abysmal. I mean sure, it is passable under Windows if you have a late model box with enough RAM but even the tiniest real application under Swing has a memory footprint of at least 15Mb. Even if you have enough memory to keep it from paging to disk it still has to slogging all that stuff around on the heap. It is noticeably slower than a native app.

    But don't take my word for it. Go download Sun's Forte for Java [] IDE, which is itself written in Java, and see for yourself. Running on Windows under JDK 1.2.2 it uses over 50Mb before you even open a file.
  • JBuilder is nmore than a cross-development tool. It's the proof that WORA works. JBuilder itself is writtn in 100% Java and the same exact bytecode is distributed on all supported platforms (Linux,Solaris and Windows).
    This by itself should be encouraging since JBuilder is a big application.

    The distribution of a JVM should not be aproblem since the JRE, not the JDK, is redistributable by license. In other wordss, you can bundle your app with a JR, you don't have to bundle te JDK.

    Paolo Ciccone []
    JBuilder dev.Team
  • The QT toolkit will allow you to use the same toolkit for the graphical elements in both the Linux and the Windows environment. This will make porting between Windows and Linux much easier.

    - Sam

  • Though Squeak Smalltalk [] is the best cross-platform development system I know, it has some problems which may (or may not) make you not consider it:

    • it has its own GUI which runs inside a single window in the host system
    • like most Smalltalks, it is hard to separate the application from the development environment for shipping it to customers
    • it is being actively developed, with the side effect that there are a lot of rough edges and things change a lot with each version

    This last "problem" also means that the other problems might soon be solved...

  • You obviously have never use Linux to make sure
    ridiculous comments.
    I work all day with winblows and when I work
    at home it's Linux and is indeed the dream
    environment. It's fast and doesn't crash.
    If you want IDE graphic there is Gnome and KDE
    Check Caldera's KDE version someday and you will
    have quite a surprise. Also once the new XWindow
    is out most distributions will also have great
    looking graphic that will exceed winblows in
  • Mainwin is crap!

    Mainwin combines the horror of MFC with the horror of Motif! How much worse can you get?

    Mainwin is a short path to a large headache. Steer clear at all costs!

  • I'd imagine that the KDE widgets should be pretty portable -- the code is clean and high level. On the other hand, anything that involves networking code probably will not port easily since it'd most likely use sockets.

  • 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,

    ??? The entire KDE package compiles with g++. I'd hardly call it a "simple Linux app". What features is g++ missing ? It seems to include the basics, including things like STL. The main problem is probably going to be coding something that will compile on MS's brain damaged compilers, which don't always accept ansi-standard code. As for MFC, well yeah, you can't use it, you use some other API instead ( such as QT ). It's not like MFC is the world's only API for Windows.

    I agree that Java is slow. I don't agree with your comments about python and perl though. Both can be quite useful, and it is possible to write comprehensible code in perl, even if you can't.

    Why switch to Linux to develop a Windows app ? Maybe he wants it to run on more than one platform.

  • I have programmed for the Win32 API since 1994 (yes, even Win32s on Windows 3.1) and this assertion is only about 5% true -- and even then, it's mostly driver writers who have to worry about such issues.

    Compared to my experiences with Java AWT, OS/2, and what I've heard about shared C libraries under Linux, Win32 is consistent between all the various versions of Windows.

  • wxStudio ( [])also seems to be coming along fairly well.
  • Emacs and Java, the two tastes that go great together.

    Seriously, as far as development "tools", Emacs is the way to go. I hate to start a new job and being forced to use some development environment. Give me Emacs with its keybindings and its full glory anyday.

    If you are developing cross-platform and do not need a GUI, go for C++. If you need a GUI, go for Java. If you are really courageous, go for Squeak [], the most cross-platform language ever.

    --Ivan, weenie NT4 user: bite me!

  • Why shoudln't it?

    because C++ rehab doesn't take that long. the world will probably be cured by then.

  • The rumor seems to be that Apple has axed OpenStep/Cocoa on all platforms except for MacOSX. (I haven't actually seen an Apple statement on the topic, but the old Next folks seem pretty pissed.)

    On the face of it, this seems bizarre. For one, NeXT was actually kinda profitable before Apple bought them. For another, OpenStep/Cocoa for Windows and Unix would only help to increase the software base for MacOS X.
  • And if you happen to have a boat load of money for support then QT is what you want... <sarcasm>

    Really though I do like wxWindows or GTK with the C++ wrappers. Use that with CodeFusion from Cygnus and you have a pretty good environment
  • Why does a simple humorous comment always have to turn into a discussion about propaganda and cross-platform development tools?
  • Fancy IDE's are for wimps....If you need cross platform, QT is not too expensive for Windows development and then you can use your favorite editor. If you really MUST have an IDE, KDevelop is pretty darn awesome and, if you stick to the QT libraries (rather than the KDE), you'll still be portable. I believe that KDevelop can generate makefiles (or at least configure scripts) so it would probably not be terribly difficult to get the project to work on Windows. Elvis has for ever spoiled me for other editors. I leave trails of ":wq"'s every time I use something else. BTW, it may even be possible to get some of the KDE libraries to compile on windows although I don't know if anyone has ever tried....
  • by Anonymous Coward

    Now I now this may sound like flamebait to the fanatical /. Linux zealots, but wait for a second. I am a Linux user myself, and I've contributed a few patches to various projects in the last couple of years. What I'm wondering is why are you bothering to develop it under Linux is you are going to be running it under Linux?

    For a start, doing this will require you to be in possession of a cross-platform language. Currently your real choices are C++, Java and the various scripting languages (Python etc.). I'll discuss each.

    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, and you can't use the logical structure of MFC with it either.

    Java - well it's cross platform, but for a real application it's not really all it cracked up to be is it? There's performance to consider for a start - 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.

    And then we come to scripting languages - Python is a marvellous language with some great features but it is fairly rigid, and its indentation rules leave a lot to be desired. 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 other scripting languages aren't even worth considering.

    Your best option IMHO is to stick with Windows - if it's a Windows app you're developing then use MS Developer Studio. It's a very easy to use, logical product with built in support for the MFC, which will make your development much quicker. After all, why switch to Linux to develop a Windows app? You wouldn't write the Linux kernel in Dev Studio would you?

  • by Anonymous Coward
    Go with Java. It is incredible to find the same applications that you wrote in Windows run in Linux with the drive being mounted. Javasoft will sell you the rest of the hype, but luckily this one is worth it - as you already know it.

    As far as development tools -

    1. If you got the bucks go with VisualAge and WebSphere. Nothing to beat IBM in any platform.

    2. If not go with Forte (or Netbeans) and a Sybase backend. Forte is absolutely worth the salt. It is a classic "Linux" case where a free tool is better than many of its costly contemporaries.

    2a. Zope good enough - if not high volume.

    3. Oracle solutions - not everything is available cross platform. Somethings are best kept in windows NT.

    4. Sun - Hmm not much of Cross platform commitments beyond Sun and NT.

    5. Sybase - eventually you will use NT.

    6. The rest they all run properly on NT. Support for other platforms range from fully commited to namesake. But just as you said they all care for their bottom line.

    So Ignore that bottom line idea. Do something radically different. You might get noticed or thrown out. You wont be yet another Chair occupant in the room.
  • No- he's right. Real programmers don't use IDEs. There hasn't been an IDE yet that did string handling right in FORTRAN.

    _Intelligent_ programmers use IDEs- but only because they're convient. They understand the code the IDEs produce, and could write it themselves if they took the time. In that sense, IDEs are no different than any other code generators- lex and yacc, for example.

    But an IDE is no replacement for skill and understanding.
  • Just to comment on the question about bundling JVM environment -

    I've been using an application at work called ProactiveNet ( []). It bundles a full JVM, Perl and Apache (with mod_jserv installed) - specifically configured the way those apps need it. Putting the package together appears to have been fairly straightforward. Just specify an application-specific installation path (in this case, under /usr/pw/ ) and you have your own compartmentalized runtime environment. Much easier from the support standpoint than telling the customer they need to set up brand x of package y, version z.20 with modules foo, bar and baz installed.

  • There aren't many IDEs for Linux - Code Warrior is probably one of the better ones, though there's always Emacs. :)

    However, I can offer a few thoughts, for your perusal. First, graphics. Qt is nice, but not terribly portable and the licence is nasty. Allegro or SDL are probably much better bets, if there's an API in a suitable language.

    (Swing, for Java, is the only way to go, although there are still more bugs in it than lines of code.)

    If portable is the name of the game, then code in a very modular style. Anything that may need to be ripped out sould be rippable-out without disturbing the rest of the program. That way, you can glue on just about any library for any machine and not have to touch your main code at all.

  • For all small simple GUIs, I'm seriously sold on the SATAN/SAINT model. Basically, you just write a webserver (http 1.0 is trivial to implement) and a front end that fork()s and spawns a web browser and the server and connects the two. If your GUI is large and complex, than this approach starts to break down. But if you just need some simple user input (buttons, imagemaps, and text boxes), then don't hack up a GUI for that. They are a pain in the ass to code, and it's a lot easier to just use an existing browser. I've coded stuff up to 15k lines with the browser approach, but usually only about 2-3k are the front end, and most of the rest is the guts of the application.

  • Especially the available Add-ons are very important! Mainsoft created a layer for the Stingray Objective Tools. With additional native
    Toolkits which are available both for Win32 and Linux this really seams to be an interesting migration path for companies which have to port there existing code within a short time. A nice
    virtual print engine (Idealsoft?) would be a valuable addition ... If you already have spent a lot of time and money on your code, which has to be supported further, it isn't easy to go for GTK/Win32, Qt or wxWindows. Changing from COM to
    anything else might also be a nightmare for really
    large projects.
  • I agree that OO and Java are not the be all and end all of anything. However, I definitely don't agree that a 'multi-paradigm' language like C++ is the right way to go. Nor do I agree that 'dumb' programmers use Java and 'smart' programmers want choice. I must admit to not having read "Patterns in Software", but I'm not aware of anyone in the design patterns movement having 'lambasted' OO languages. The classic "Design Patterns" certainly emphasises patterns as a guiding concept in OO design, not as an opposed philosophy, though of course they do criticise certain OO approaches.

    OO languages do not constrain programmers to write good programs or produce good designs, but they do encourage OO design, which is beneficial when done well. Of course, the languages introduce new possibilities for error by introducing powerful new features in the form of encapsulation (you have to choose what to encapsulate), subtype polymorphism (it is not always obvious what the type hierarchy should be), and implementation inheritance ('natural' type hierarchies rarely correspond well to reusable implementation).

    Nonetheless, OO does fulfill the important requirement of being better than any other method for designing software (and after all, what is the competition ? you can take out implementation inheritance, or add generics, but essentially you still have an object based language). The important thing is to encourage high module coherence and low coupling between modules. This enables developers to think in terms of natural abstractions and make changes with a good understanding of what they're doing. You're more likely to get reusable, maintainable code that way.

    Java encourages (you can't force) object orriented design by making it easer, in essence, to do the right thing than the wrong thing. Its much harder - in Java - to write classes with long stretches of procedural code or complicated and messy interdependencies than it is to write clean and simple abstractions. Of course, you still have to be able to design natural and reusable components, or no language can help you. Java does indeed constrain you (and the rest of your development team, which may be an advantage), but it constrains you to do things you probably really wanted to do anyway. I don't know about OO, but productivity gains from Java are real (I'd cite the studies, but I don't have the URL, look at Sun's website).

    The designers of C++ claim that the langauge is 'paradigm neutral' and does not force you to program in any particular style. This is not, IMHO, entirely true. Everything about C++ that is not also in C makes the language more object orriented (typical OO languages either have generics or weak typing, BTW, its Java and not C++ which is exceptional in forcing people to cast). It is unusual among OO languages really only in trying to maintain compatibility with C (hence a lot of the complexity - eg. pass by value). It is also hard to design good software for implementation in C++ - to leverage the language well, relatively high coupling between modules is necessary. To pick two random examples: C++ classes actually have to be designed to be subclassed, and the developer must guess which methods and features the client will need to use of override. Also, if I have two type hierarchies and I want to implement a conversion between the two in the 'natural' C++ way (using implicit constructors or cast operators) I *must* contaminate one hierarchy or the other with knowledge of the other's existence. This is not to mention the problems caused as ANSI C++ actually begins to be used in anger - eg. code that throws exceptions and code that uses pointers don't get on at all well.
  • Do you think you could try to be a little more abrasive ? I'm not quite getting the message here. More seriously - I was disappointed with you reply. I hoped you would try to give your reasons for your beliefs about OO.

    There's only really one major point in the previous message: You believe that the OO assumption that abstraction is beneficial is incorrect, or at least too strong. Unfortunately you've failed to back this up yourself, so its completely impossible to answer the point. I will of course read Gabriel's book, now I know of its existence, but thats not going to help for the purposes of this conversation. Its really pointless in a forum like this to wave around "authoratitive" references without at least summarising their arguments. *Of course* abstractions that are too general will break software that tries to use them. *Shrug* noone ever claimed all OO programs were good - bad programmers will do the wrong thing in any paradigm. High coherence and low coupling are good because they let the developer think about the system one module at a time (though of course the modules should have been chosen to make up a coherent 'big picture') - this is what OO is meant to facilitate, and you haven't answered this point.

    As to generics, Mr Stapanov can say what he pleases, but *you* failed to answer my point. Most OO languages either have generics or weak typing. Its Java, not C++, which is exceptional here. The STL components are *classes* with *virtual functions* some of which are designed to be extended through inheritance. STL did stop people from writing half-arsed collection implementations that required client classes to extend particular superclasses, but that was always just a consequence of C++'s unrooted type hierarchy. Oh look, another example of coupling (albeit one that's now thankfully fixed).

    Oh, and the examples of C++ weaknesses I gave are examples of things that encourage high coupling between modules and thus reduce reuse. Your answers were both irrelevant. I don't care about the cost of virtual function tables, because 32 bits per object and a few K per class is not important for most applications, and I was talking about conversions, not dynamic casts. I do care about language features that encourage people to write non-reusable code without good reasons.

  • It has in fact been done for C, by Boehm (sic?) I think, though it is in theory not safe and may sometimes miss garbage. It uses some simple heuristics to guess which data items are pointers and traces references that way. Some tricks (like XORing pointers) upset it quite badly, but it can help with programs whose memory management is irredeemable (like XFree86). Works for C++ too. Might even work for assembler.

    Its quite true that OO does not depend on GC or vice versa, however OO languages without GC have an extra obstacle to overcome - something has to keep track of which instance are and are not in use without making unwarranted assumptions about the behaviour of other modules.

  • Strong typing has nothing to do with OO. As the previous poster was using it, strong typing refers to variables having definite types that cannot be violated declared at compile time - thus C++ is strongly typed and Java somewhat more so. Technically this is static typing, but who am I to argue with common usage ? Strictly strong typing refers to objects having a single definitive type that they retain for their entire life - you have a slighty better case using this definition if you can impose a concept of type on languages that have none of their own.

    Weakly typed OO languages exist - Self and Smalltalk being the best examples. Smalltalk's classes are treated simply as predefined (and under the hood somewhat priveleged) objects. There is no recognisable concept of type that appears in the syntax or semantics of the language. Self is an even better example as it has no special priveleged class objects at all - object creation and definition is done by copying already existing prototype objects.
  • Well its clearly not the definition the person you replied to was using, because what they said made no sense under that defition but did if substitue 'static' for 'strong'. This is not an unusual error and is one many people who ought to know better fall into.

    To treat Smalltalk as strongly typed you need to decide what you consider to be a type. Is it a class ? an interface ? the latter makes more sense, but has no explicit representation in the language, so its hard to claim the *language* is strongly typed (also, you can call become: or addMessage: which really screws up any claims along these lines). If you can do it for Self, I'll give you a prize.

    Incidentally, the problem with OO and static typing is that the static types make it harder to reuse code for purposes not imagined by its original author. For instance if I have a smalltalk class Foo that manipulates object of class Bar but only ever calls two of their methods, I can reuse it to manipulate objects of class Baz by just implementing those two methods.

    To do the same thing in Java or C++ the author of Foo would need to have forseen my requirement and provided an interface of pure virtual class that I could extend to declare the fact that I implement those two functions. Coupling inhibiting reuse again.
  • Of course encapsulation existed before OO, as did some kinds of polymorphism. Its only really inheritance that was a unique contribution.

    I was hoping you would do something to back up you arguments besides quoting references. You've said nothing to actually justify your assertion that OO languages are less useful than 'multi-paradigm' languages or that anyone really needs to get away from the OO paradigm for some given application. Specifically, I suppose, you would have to show that OO does not achieve its aim of facilitatin low coupling and high coherence leading to better levels of reuse, or that there was some other fatal problem that negated these presumed advantages.

    Unless you can do this - or give some idea of how to do this - claiming that OO is "not good enough" is pointless. What is it not good enough for ? Where does it fail ? How slipping into another paradigm actually help ?
  • Absolutely - this is like the mainframe programmer a while back who said he always wrote portable code: 'it can run on any IBM-compatible mainframes'...
  • Does anyone have any good experience with CodeWarrior for cross-platform development (ie, actually developing both *on* and *for* multiple platforms)? What do you do for source control across multiple platforms: just CVS? I hear that Codewarrior is going to support CVS soon, any word?
  • I ran into a lot of issues porting from G++ to MSVC++, but upon closer inspection, I think many of them actually seem to be the result of G++ being too permisive, rather than MSVC++ being non-standard.

    You're partly right. G++ is permissive, but you can force it to be strict. I just tried this example:

    int foo ( int j = 0 );
    int main ( int argc, char** argv ) { exit (0); }
    int foo ( int j = 0 ){ return 0; }
    Now try compiling this with
    g++ test.C
    OK, that went through without a hitch. Now try this:
    g++ -Wall -pedantic-errors test.C
    -- it catches this one. So no, g++ most probably isn't "outvoted" -- it agrees with the other guys on what the ansi standard is, but you need to tell it to enforce the standard.

  • by panda ( 10044 )

    I agree pretty much with everything the above poster said, except that there will be a fee if you intend to distribute your Qt application for money. Qt is only free if you are. If you charge money for a product developed with Qt, then you need to pay the license fee to Troll Tech. This page [] has all the details.

  • I've been developing in Java for some time now. I hate it, but it pays well. Give me Delphi on windows and give me emacs on 'nix.

    Point? Programs written in Java are easy to develop, but hard to deploy. Even a 1.1 machine is too much to ask. Also, you can't establish parent/child realations between windows, and copy/paste doesn't work, threading doesn't work as documented, and its slow, and you can't even fucking ask how much memory is available...

    Java was developed by Sun to make MS look bad. So they try to avoid anything that windows supports.

    Go for Borland C++. Your program will run everywhere, will be easy to deploy, and be easy to debug.
  • You missed a scripting lanuage: Tcl/Tk. It doesn't have the "write only" property that perl has.

    See for more info. Tcl/Tk is free (speech, BSD-style), but scriptics also sells a debugger and a wrapper. The wrapper will hide your source code and allow you to distribute a stand-alone application so your customers won't need Tcl/Tk installed on their systems.

    Tcl was designed as a glue language and if you find that some of your code runs too slow on Tcl, you can recode those modules in C and load them as an extension (you're C code will be most portable if you use Cygwin).
  • Have you ever actually coded using Win32?

    Yes, and no thanks. I'll go back to using 'fragmented' OS's as my platform of choice.

  • I have programmed for the Win32 API since 1994 (yes, even Win32s on Windows 3.1) and this assertion is only about 5% true

    If that's so true, then email me an example program written in C++ that takes full advantage of Windows 2000, but also runs on Windows 98, Windows 3.1, Windows NT 4.0, and Windows CE. Without #ifdefs. Sure, NT 4.0, 98, and 2000 are relatively similar, but Windows CE isn't. Neither is Windows 3.1.

    Anyways, that's what I'm talking about. I mean sure, program written for Windows 2000 will run fine on all copies of Windows 2000, just like programs written for Solaris will run fine on all copies of Solaris. But is it easier to port the Solaris program to a HPC running Linux, or a Windows 2000 program to Solaris?

  • In reality, Win32 is Win32 is Win32.

    I guess someones been listening to too much Microsoft propoganda. In reality, it's easy to get one source base to compile on all the OS's from other vendors, (Solaris, Linux, Mac OS X, BeOS) then it is to get on source base to compile on all the OS's that Microsoft currently markets. (Windows 98, Windows NT, Windows 2000, Windows CE).

    However, it's true that Microsoft would consider MS Visual Studio all the 'cross-platform' development tools that you'd need. Even though that refuse to acknowledge that their OS line is fragmented ;)

  • Note that the free Qt license (QPL) only applies to the Linux version, not the Windows version, and only if you develop free software.

    If you want to use Qt, be sure to read the license [] and the Troll Tech FAQ [] carefully.

    As I interpret these, there are two important restrictions:

    • You must pay for licenses to the commercial version of Qt even if you only distribute your application internally inside your company.
    • You must pay for licenses to the commercial version of Qt before you start your project; if you start developing under the QPL, your software is automatically free software when distributed. (This is perhaps hard for Troll Tech to enforce, but then so are per-developer licenses.)

    There are several other, good cross-platform C++ libraries out there, many of the cheaper than Qt, some free (see my other post). I recommend giving them serious consideration before investing much time and money in Qt.

  • gcc is totally portable and you make cross-compilers on any of the various platforms. (i.e., it is not difficult to compile a cross-compiler for Win32 on Linux).

    The Qt libraries are portable across Windows and Linux and aren't very expensive if you need a nice widget set.

    As many people undoubtedly will point out, "real programmers" don't use IDEs. But if you insist on using one, I'll bet KDevelop would work if you use only Qt stuff and not KDE stuff. (I don't have any practical experience in using KDevelop to write cross-platform Qt-applications, though).

    Then there is winelib, which Corel is using to make its WordPerfect Suite and CorelDraw cross-platform. I don't know how mature it is, but if Corel is using what they open-sourced, then I'm guessing that it probably stable enough for serious development work.

    WXWindows is another cross-platform library, like winelib. I have no experience with it, but I think its referenced on the LDP Web site somewhere. I'd check there, because there exists lots libraries similar to WXWindows and winelib.

  • Oh yeah, and one of the guys who ported the GIMP ported GTK+ to Win32...
  • 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).

    One of the guys who ported the GIMP to Win32 also ported GTK... I'm normally a big Qt fan, but GTK is free ...

  • I think you are obviously humour-impaired.

    If I have to explain its not funny but, Microsoft Visual Studio is cross-platform only if you consider all of the Windows platforms to be different platforms. In reality, Win32 is Win32 is Win32. :) (Ok, not really, but close enough)
  • I almost left out the exclamation point after "Windows 2000!", but I knew some people wouldn't get the joke then. I'm sorry that some people didn't get the joke even as-is.

    BTW, take a chill pill and relax..
  • Given the GUI nature of Windows I'd assume that C++ is out of the question

    You assume wrong. OO languages shine when the problem set involve objects. GUIs have objects. Windows, controls, events, etc. Pushbuttons are derived from buttons which derive from windows. Windows have parents and children.
  • even for linux, it's $1550 up front, no gui builder, just a set of libraries.

    Just a set of libraries? Of course it "just a set of libraries"!

    Troll Tech doesn't need to sell a gui builder, as there are already several excellent ones already available, either for a price or for free. Qt is Troll's product, and it's a good product. It would be absurd to relegate it to the level of a loss leader for yet another gui builder.

    As for the matter of pricing, the price they chose reflects the value they place on their own product. They consider it a high end cross platform tool for professional firms and developers. Apparently, the market agrees with them, as they haven't lowered their price yet. This is NOT a library for shareware authors who want to write closed source crap. It's for real world programmers who make their living off of cross platform development. And the license is per developer, not per site, so you don't have to pay extra to take your work home at night, like you do with MS stuff.
  • Well, I'm one of the many who has worked with both Qt and MFC, and, like virtually everybody in that boat, I vastly prefer Qt. All the reasons have been said before, so I don't want to beat them to death.
    I did, however, just see a lecture by Bjarne Stroustrup in which he was talking about good vs. bad object oriented design. He used MFC as his example of how to write a really, really bad OO library. I don't really know anybody who would disagree.
    Really, Qt was invented for people like the author of this question: excellent, fast, cross-platform C++ GUIs.

  • Yes, thank you Mr Jobs for not open sourcing OpenStep long ago and for not supporting the free software community to make a free implementation. Yes, thank you apple for depriving developers of an awesome cross platform framework for building applications! Thank you for forcing us to use inferior and memory hogging Java if we want to easily implement something on more than one OS! Thank you for only making the current implementation available on MacOSX even though it already runs on Windows, and Solaris (and thus probably other unix based systems).

  • That's good until one of your apps calls System.exit(), or you run two apps that need different classpaths...

    To make it robust, I think you'd also want to provide a classloader for each app you run to provide for custom classpaths and class unloading (to conserve memory). Also, it would be good to use the security manager ot trap a few things like System.exit() so that one app couldn't bother the others running in the same VM.

    But overall it does seem pretty simple, which is why I'm surprised something like that is not shipped with any VM.
  • And they are both a *lot* closer to the standards than VC++.

    Actually, no. VC++ encourages stupidity by having some non-standard features, but it is in fact a lot closer to the C++ standard than g++.

    g++ is still using an obselete iostreams library, and namespaces don't really work, and there are a lot of problems with the STL implementation that comes with it (at least on my Mandrake 6.1 machine), probably because there are bugs in compiler dealing with templates.

    Though on the whole I agree with you. That AC is a dufus. MFC as a reason to stick to windows, LOL on that one. And Visual Studio... using it after coming from a unix environment is about as frustrating as typing with mittens on.
  • InstallAnywhere is a difficult initial setup, but after the first one, it's pretty easy to just copy/paste the first configuration files into a new project and make a new application. You can bundle all the applications together into one install, so you can install more than one application at one time.

    The tool that actually does this conversion is called, not surprisingly, HTMLConverter. It can be gotten from Sun's page [].

    It turns out that a lot of the actual library space is shared between VM's, so while the initial memory requirement is pretty steep, every additional VM is not much more expensive. If you turn on native threads under linux and do a 'top', it will appear as though there are at least 4 java programs running that are using 8M a piece, but they are actually using a lot of the same space.

    Hope this helps a little
  • IBM has a free evaluation version of VisualAge for Java available. Both Linux and Windows versions.
  • I just installed Forte (Community Edition 1.0) over here on both my boxen (I have an NT and a SPARC). The problem that I have is that it has a Godzilla footprint. According to my Solaris "top" monitor, booting up Forte takes up 107MB. When you only have 128MB, this can leave you feeling a bit cramped.
  • "Boxen". Plural of box (computer). Sort of like Vaxen (multiple VAX machines) or oxen. See the Jargon File [].
  • ummmm...where to begin....
    Given the GUI nature of Windows I'd assume that C++ is out of the question
    Excuse me? There are multiple c++ libraries that allow for cross-platform development. Qt, wxWindows, gtk, just to name a few.

    Java - well it's cross platform, but for a real application it's not really all it cracked up to be is it?
    Yes, it is. Quite simply, Java is MORE object oriented than c++, (or more exclusively so). Object orientation allows large projects to be arranged and managed in a logical manner. Java is a wonderful choice for cross platform development. There are performance issues, however. But using Java for a front-end, and c++ for the back-end can result in a quick application, with cross-platform, consistant UI.

    As for your argument against scripting languages...Well, your best bet would probably be TCL for the front-end of an app. It has a nice toolkit, and works on just about all major platforms. Scripting languages being what they are, performance is an issue, so writing an entire app in it doesn't seem too efficient.

    But the bigger point here is that linux/unix users SHOULD strive to write cross-platform code, whenever possible. When you write applications this way, you meet you PHB's requirement that it work under windows. The application can be sold, the company can make money. More importantly to the linux/unix community, however, the application can be re-compiled, re-tested, then released for other platforms. PHB's love this because they can make more money, and the community loves this because more applications are now available for their non-windows OS.

    Also, I understand the desire to develop under Linux. I develop at work mostly under Solaris, and love it. When I have to develop under Windows, I spend long, frustrating days where mis-handling of a pointer causes BSOD, not a core dump.

  • But who said Java /has/ to be the best for everything? I mean that's why we /have/ different languages in the first place! One of the deficits of C++ is that it really IS so flexible that it allows you room to do anything under the sun in any way you want. Sometimes you don't want to have a tool you have to define yourself to use. Sometimes you want something that already has a well defined paradigm. So OO doesn't float your boat - go ahead, DON'T use Java! Nobody is forcing you. I would personally /hate/ to see a Java that is the be all and end all monster of programming languages that allows me to program in any haphazard way I want. If you don't like the tool don't use it. But don't complain that it's hard to bang nails in with a screwdriver.
  • I havn't done a whole lot of cross platform development.

    However, what I have done mainly is to get a project for school to run on both windows and linux (windows for the ease of debugging using visual studio, linux so it will run on the sun boxes at school).

    I have found that for most non-gui applications, there is a 1:1 function correlation between windows "stuff" and linux "stuff" (posix threads and windows threads come to mind here). There are other places where the functions are identical, but require another function call at the beginning of the program to set things up (sockets). Then there are functions that behave similarly but different enough to be a pain (too many to list...:).

    1:1 correlations are easy to deal with ... just do a
    #if _windowstag
    #define myfunc(a) MyfuncWindoze(a)
    #define ...

    For things that require extra startup, just #if in the correct code where appropriate (looks kinda nasty though).

    For larger projects where "native" code is required (ie: java is too slow, or you want the app to look like it was written for it's respective os) creating a framework class structure could be handy. In other words, figure out all of the operating system dependent functions and write an extra layer that your application will call, which will then call those dependent functions. That way the porting required is down to a minimum...

    My inexperienced 2c.

  • The main problem is probably going to be coding something that will compile on MS's brain damaged compilers, which don't always accept ansi-standard code

    I ran into a lot of issues porting from G++ to MSVC++, but upon closer inspection, I think many of them actually seem to be the result of G++ being too permisive, rather than MSVC++ being non-standard.

    For instance, G++ allows you to define default parameter values in BOTH the declaration AND definition. I believe that this is not supposed to be allowed. G++ does not bat an eye at non-static const class members either. MSVC++ likes neither of these. And if you check out the info pages, a number of extensions are documented. (They do not consider my examples to be language extensions).

    I first thought "Man, MSVC++ sucks, when it comes to standards GNU is the way to go", but I've since fed the same code to other compilers (Metroworks, Borland*) they agree with Microsoft. I haven't actually read the standard (since I don't want to spend $30 just to find out whether what I nned to do to get things working is right), so I cannot say for sure which is nonstandard, but .. G++ is outvoted 3:1.

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

    I disagree. OO{P/D} is not some silver bullet that will solve all your design issues, and Stroustrup knows that: He left the programming paradigm to the PROGRAMMER. (Functional/Procedural programming DOES have it's place, as does OO.)

    If you want detailed info., check out this book:

    Multi-Paradigm Design for C++ []

  • Omnis studio is expensive. Plus, when I was in contact with them I had the impression their channel in scandinavia is managed by very un-motivated people. I don't know in other parts of the world.
    But again, Omnis studio is expensive, some sort of Powerbuilder imitation. Too bad Sybase doesn't have PB for Linux. They do have a version for HP-UX, though.

  • I've used Codewarrior Pro 4 and Pro 5 extensively to do cross platform development (MacOS & Windows). The cross compilation works well, and the cross debugging is even better. This is the best way, IMHO, to get ANSI C++ compliance on Windows (Visual C++ certainly doesn't cut it). It also does Java and Pascal within the same IDE. However, while I've installed and admired the IDE on Linux, I've never tried to cross compile with it. Be aware that CW on Linux is still on version Pro 4, whereas Pro 5 is the most recent version on Mac and PC. Solaris support is also at Pro 4. Another caveat is that the Linux version uses gcc as the compiler, so you will have to deal with the differences between gcc and the Codewarrior compiler if you recompile under the Windows version. At the moment, the Codewarrior Pro 5 compiler appears to be more ANSI C++ compliant than gcc, but the differences are fairly minor.
  • I've been developing a cross platform application using Java (Plug: try it at []).

    We use JBuilder 3 for development. However, we actually plugged in the libraries from JBuilder 1 because JBuilder 3 requires Swing (while JBuilder 1 uses the AWT), but we felt that we couldn't require that our users have Java 2. We also wrote an exe wrapper which searches for an installed JVM and executes our software, so that Windows users can start up our software just by double clicking on the exe.

    I'm not too sure whether Java is really the best way to proceed. If your users don't have the necessary JVMs, you're limiting your user base, and there are compatibility problems with older JVMs which may cause more problems.

  • You make several good points. Possibly the best reason I can think of to use Java is the language features and improvements over C++. I am simply much more productive using Java than C++, and it is nice not to have to deal with porting issues.

    However, there still are some drawbacks to Java:

    Although Java has the potential to be (mostly) platform independent, Sun has a strong bias towards Windows. The latest Java implementation (1.3 RC2) is only available for Windows. Sun does not even support their own OS yet! Java 1.2 was out for well over a year before Sun released a Linux implementation. Even if we go back to v1.2, you will see that Sun supports versions of Windows back to win95, but support for Sun's OS is limited to very recent versions of Solaris. v1.2 is still not supported on some fairly popular platforms, such as MacOS. Sun's attitude appears to be: Provide up-to-date and solid Java implementations for Windows, and support other platforms when/if we get around to it.

    Java is not yet suitable for the following application areas: Hard real-time systems (due to threading/GC issues), fast 3D graphics, high-end (96 KHz, 24 bit, > 2 channel) audio apps (Java is limited to 16 bit stereo @44.1 KHz, and only for Java 1.3).

  • Something I have found to be exceedingly useful is the Python language. It exhibits many of the traits of Java ( such as it's generate of bytecode files which can then distributed sans source ).

    I find development time in Python is very quick compared with Java and the code is exceptionally easy to maintain ( I find Perl apps very difficult to read after I write them but maybe that's just me). Seems to me that Java's big selling point is being cross platform except I quite frequently have problems moving java apps between Platforms. A well written Python app works anywhere you can find an Interpreter.

    There are also some very good GUI toolkits for Python which are cross platform (ie. WxPython and TkInter).

    Python applications tend to be very small and extremely quick ( definitatly faster than a similar VB app ).

    And of course learning python was very easy.

    Jeff Clement
  • Of course, all the alternatives suck, which is why you asked the question in the first place.

    Metrowerks [] is the vendor most serious about cross-platform development. Their IDE is mature, and quite nice, although the Java layout editor needs work.

    The usual Java problems continue. Java 2 is an improvement, but deployment has been slow. Some areas are still in flux (audio, in particular) with different versions of the API. Unless you ship a JVM, a JIT compiler, and Swing with the application, along with an installer that gets it all right without messing up existing Java installations, there will be problems.

    I haven't looked at the portable C++ GUI libraries in years, so I can't comment on that one. (Anybody remember Bedrock?)

  • Java 2 is not available under all platforms.

    Why are you requiring Java 2 as opposed to 1.1.8?

    You might look at doing alot of layering, so you can abstact to OS as much as you can.

    Install anywhere might solve your problem, or at least to some extent. I think it is more a design problem. You can do it in C or C++ if you abstract sufficiently. Then abuse your precompiler for lots of it.

    You have to give more detail to get more than just guesses.

  • The guy who wrote TWIN is no longer with Willows (which is actually a subsidiary of Caldera) because they decided they didn't want to pay to maintain the thing anymore. He's moved to CodeWeavers [], and has merged the code with WINE to create Twine [].
  • Java - well it's cross platform, but for a real application it's not really all it cracked up to be is it? There's performance to consider for a start - 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.

    I suspect you haven't tried out Java for a few years...

    Java with a modern JITC is approaching the speed of natively compiled code. With the latest compiler technologies, such as Hotspot, I've seen Java running faster than the equivalent C++ code. The reason this is possible is the same reason technologies like TransMeta's code warping are so good - code is optimized globally at runtime rather than class-by-class at compile-time.

    As for scaleability, there are a number of very large Java applications out there - for example the Oracle suite. I wouldn't hesitate to use Java on a large project. If keeping track of "finals, abstracts and the like" is really too burdensome, then I'd suggest you shouldn't even be attempting large projects yet.

    One area where Java (actually AWT and Swing) does have a problem is memory footprint. Java programs typically need a lot of memory to run in. Again, there are some compiler advances that are starting to address this too.

    As always, Java is not a silver bullet, and its not for everyone. But don't dismiss it out of hand - it has a lot going for it too.

  • Why does everyone love Java? It's so ungodly pathetic. Yeah, it works for cross platform crap, but it's an awful solution.

    Oh come on, that's just trolling. If you have a point to make, make it, justify it, show at least some glimmering of evidence for it. Dumb name calling is just that: dumb. If this is your best argument against Java then you loose.

    If you have a hammer, everything looks like a nail. Java developers far too often fall into this category. Just because you can write in Java, doesn't mean you have to. ANSI C seems to be a much more ideal solution.

    And the same can be said for ANSI C or any other language. Why don't you tell us why you think Java is a poor solution. Then there might be a productive exchange of ideas to be had. Sigh.

    Requiring people to have java on their machines is an uncessary burden. Before they can even install your software, they have to go out and find yet another piece of software. Or you have to bundle it with your program, which increases your distribution costs and makes you dependent on a third party product that you can't exercise much control over. Why do this to people?

    So you'd be against using any library or similar extension that wasn't included with the base operating system? This seems like an onerous restriction to put on the developers. Part of the art of programming is to pick and choose between technologies. I guess this is why you like ANSI C so much. Still, shame you can't use those fancy-shmancy GUIs that users like so much. Don't worry they'll grow to love your curses-based UI.

  • Might I suggest MetaCard? [] It's cross-platform, (Solaris SPARC, Solaris x86, DEC Alpha, SGI IRIS, HP-9000/700, IBM RS/6000, SCO ODT, BSD UNIX, Linux Intel, LinuxPPC, Mac, Windows 3.1, 95, 98, NT [dunno about 2000 yet] ) , it's darn fast for a scripting program, and it's quite easy to use. Of course, it is scripting... and in my opinion, with the speed that MC has, that's good. I'm working on quite a few programs myself in it (games, actually) , and find it to be great for many utilities and such. For a cross-platform project, it's a dream. So... what do we all think of that? (this is my first post, too. Yay!)
  • It gets better...

    FIRST: Metacard has an IDE (aka GUI, aka interactive development environment) where you can build complete GUI apps. MC has a set of canned interface objects (buttons, fields, vector & raster graphics, scrollbars, progress bars, platform-specific look-and-feel settings, hierarchical menus, media players, etc). You draw the interface objects on a "card" (form/window/frame/whatever) by dragging them into existence; script them as needed so they each do their little jobs; and pretty soon gestault happens - you have a "stack" (MC app file) that can be moved around from Linux to Win32 to MacOS to Unix to Kingdom Come... (actually I don't think the Kingdom Come version is even in beta yet)... the point is, your creation is binary compatible across all dozen-plus supported platforms. You can write it on your platform of choice, even if your clients/friends/owners want to use it on an inferior platform.

    SECOND: Metacard's command/function/property set is *vast*. Anything that can be done in Perl can be done in MetaTalk (MC's scripting language), but with about 835% less difficulty/more pleasure. One example: the Metacard GUI dev environment was created with Metacard and scripted with MetaTalk. (Metacard also has some functionality specific to each platform. For instance, you can mess with the registry on Win32; you can mess with the resource fork on MacOS; you can mess with the world on Unix).

    THIRD: It does all those normal things you forget to ask about - read and write data, start and stop processes, figure out which OS it's running on, what time it is, etc.

    FOURTH: It handles UDP and TCP socket connections. You can create internet-enabled apps. A sample HTTP server stack is part of the install, and some other things are available on MC's FTP site - an FTP client and a mail client, and I don't know what else.

    I better stop. There's more, but I have a day job to sleep for.

  • You might want to try MetaCard. Its a cross platform development tool that runs on MacOS, Windows, Linux, and various versions of UNIX. Its a scripting language, very easy to pick up, very efficient to work with. One license covers use on all platforms.

    Check out

    or our site:

  • by cduffy ( 652 ) <> on Tuesday April 04, 2000 @11:11AM (#1151454)
    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).
  • by joss ( 1346 ) on Wednesday April 05, 2000 @12:22AM (#1151455) Homepage
    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.

    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)
  • by Malc ( 1751 ) on Tuesday April 04, 2000 @12:02PM (#1151456)
    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!
  • by kevlar ( 13509 ) on Tuesday April 04, 2000 @01:48PM (#1151457)
    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.

  • 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?
  • by rjstanford ( 69735 ) on Tuesday April 04, 2000 @09:30AM (#1151459) Homepage Journal

    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.

  • by cpeterso ( 19082 ) on Tuesday April 04, 2000 @09:26AM (#1151460) Homepage
    It is a cross-platform dev environment. It allows you to use Windows 9x, Windows CE, Windows NT, and Windows 2000!

  • by Arandir ( 19206 ) on Tuesday April 04, 2000 @09:34AM (#1151461) Homepage Journal
    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 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).
  • by chazR ( 41002 ) on Tuesday April 04, 2000 @10:14AM (#1151462) Homepage
    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.
  • by AlphaHelix ( 117420 ) on Tuesday April 04, 2000 @10:10AM (#1151463) Homepage
    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 *
  • by jetson123 ( 13128 ) on Tuesday April 04, 2000 @01:05PM (#1151464)
    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.

  • by SuperKendall ( 25149 ) on Tuesday April 04, 2000 @09:42AM (#1151465)
    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...
  • by kjeldahl ( 65177 ) on Tuesday April 04, 2000 @09:42AM (#1151466) Homepage
    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
  • 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."

  • by jnd3 ( 116181 ) on Tuesday April 04, 2000 @10:05AM (#1151468) Homepage
    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!


  • by VaporX ( 171185 ) on Tuesday April 04, 2000 @10:59AM (#1151469)
    > 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.

Can't open /usr/fortunes. Lid stuck on cookie jar.