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?"
Amulet GUI toolkit (Score:1)
Steve Huntley
blacksqr@usa.net
http://www.win.net/~blacksqr
Re:JVM (Score:1)
We actually have shortcuts that point to the
Then your tree looks something like this:
These are the programs/scripts your users actually run (or a shortcut for Windows).
Windows/start.bat
Unix/start.sh
Their classpath's point to the same place:
shared/lib/rt.jar
shared/lib/myapp.jar
But the java executable is different:
Windows/java2/jre/bin/jre.exe
Unix/java2/jre/bin/jre
Windows start.bat:
@echo off
set CLASSPATH=..\shared\lib\myapp.jar;..\shared\lib\r
java2\bin\java.exe com.company.myclass
Unix start.sh
#!/bin/sh
CLASSPATH=../shared/lib/myapp.jar;../shared/lib
export CLASSPATH
./java2/bin/java com.company.myclass
Re:C++ sucks. Lotsa added on crap nobody needed. (Score:1)
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?
Thom
Re:Why bother with cross-platform? (Score:1)
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....
Perl/TK (Score:1)
Re:Try Microsoft Visual Studio (Score:1)
Re:JVM's are dandy, its Java I can't stand (Score:1)
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.
IBM JDK 1.2.2 is out, though hiding (Score:1)
Re:JVM's are dandy, its Java I can't stand (Score:1)
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.
Re:JVM's are dandy, its Java I can't stand (Score:1)
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".
Try the GUI Toolkit, Framework Page (Score:1)
Re:cross platform toolkits (Score:1)
Since you mention Tcl/Tk, it's also worth considering Perl/Tk. See the Perl/Tk FAQ [cornell.edu], or just all the Perl/Tk links at perl.com [perl.com].
Java is fast enough but Swing is a pig (Score:1)
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 [sun.com] 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.
Proof is in the pudding (Score:1)
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 [borland.com]
JBuilder dev.Team
Try the QT toolkit (Score:1)
- Sam
Squeak Smalltalk (Score:1)
Though Squeak Smalltalk [squeak.org] is the best cross-platform development system I know, it has some problems which may (or may not) make you not consider it:
This last "problem" also means that the other problems might soon be solved...
Re:Linux is a lame development environment (Score:1)
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
development.
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
quality.
Re:MainWin (Score:1)
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!
Re:KDE libs on Windows (Score:1)
Re:Why bother with cross-platform? (Score:1)
??? 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.
Re:Try Microsoft Visual Studio (Score:1)
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 (Score:1)
Emacs and Java (Score:1)
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 [squeak.org], the most cross-platform language ever.
--Ivan, weenie NT4 user: bite me!
Re:C++ sucks. Lotsa added on crap nobody needed. (Score:1)
because C++ rehab doesn't take that long. the world will probably be cured by then.
Re:I'd like to thank apple and NeXT (Score:1)
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.
--
Re:Amusing MFC anecdote (Score:1)
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
Re:Try Microsoft Visual Studio (Score:1)
QT, vi and make..... (Score:1)
Why bother with cross-platform? (Score:2)
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?
Java - the ideal option (Score:2)
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.
Re:gcc! (duh!) and Qt, Winelib or WXWindows. (Score:2)
_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.
Bundling JVM, etc w/ software packages (Score:2)
I've been using an application at work called ProactiveNet (http://www.proactivenet.com/ [proactivenet.com]). 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.
Beware the IDEs of March! (Score:2)
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.
Use the web server model of SATAN/SAINT (Score:2)
--sam
Re:MainWin (Score:2)
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
anything else might also be a nightmare for really
large projects.
Re:JVM's are dandy, its Java I can't stand (Score:2)
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.
Re:JVM's are dandy, its Java I can't stand (Score:2)
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.
Re:JVM's are dandy, its Java I can't stand (Score:2)
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.
Re:JVM's are dandy, its Java I can't stand (Score:2)
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.
Re:JVM's are dandy, its Java I can't stand (Score:2)
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.
Re:JVM's are dandy, its Java I can't stand (Score:2)
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 ?
Re:Try Microsoft Visual Studio (Score:2)
CodeWarrior (Score:2)
Re:Why bother with cross-platform? (Score:2)
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.
Re:QT (Score:2)
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 [trolltech.com] has all the details.
Not java (Score:2)
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.
Tcl/Tk (Score:2)
See www.scriptics.com 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).
Re:Try Microsoft Visual Studio (Score:2)
Yes, and no thanks. I'll go back to using 'fragmented' OS's as my platform of choice.
-BrentRe:Try Microsoft Visual Studio (Score:2)
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?
-BrentRe:Try Microsoft Visual Studio (Score:2)
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 ;)
-BrentQt license (Score:2)
If you want to use Qt, be sure to read the license [trolltech.com] and the Troll Tech FAQ [trolltech.com] carefully.
As I interpret these, there are two important restrictions:
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! (duh!) and Qt, Winelib or WXWindows. (Score:2)
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.
Re:gcc! (duh!) and Qt, Winelib or WXWindows. (Score:2)
Re:Qt (what about GTK?) (Score:2)
One of the guys who ported the GIMP to Win32 also ported GTK... I'm normally a big Qt fan, but GTK is free
Re:Try Microsoft Visual Studio (Score:2)
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.
Sorry, I was just joking! gosh.. (Score:2)
BTW, take a chill pill and relax..
Re:Why bother with cross-platform? (Score:2)
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.
Re:Qt (Score:2)
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.
Amusing MFC anecdote (Score:2)
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.
--JRZ
I'd like to thank apple and NeXT (Score:2)
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).
THANK YOU APPLE ONCE AGAIN!!!
Re:On distributing a VM... (Score:2)
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.
Re:Wrong. Badly wrong. (Score:2)
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.
Re:On distributing a VM... (Score:2)
The tool that actually does this conversion is called, not surprisingly, HTMLConverter. It can be gotten from Sun's page [sun.com].
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
Adam
Try VisualAge (Score:2)
Re:Forte is really good... (Score:2)
Re:Forte is really good... (Score:2)
Re:Why bother with cross-platform? (Score:2)
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.
Re:JVM's are dandy, its Java I can't stand (Score:2)
What you need depends on what you're implementing (Score:2)
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
#if _windowstag
#define myfunc(a) MyfuncWindoze(a)
#define
#endif
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.
Re:Why bother with cross-platform? (Score:2)
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
Re:C++ sucks. Lotsa added on crap nobody needed. (Score:2)
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++ [amazon.com]
Cheers
Re:Check out Omnis Studio (Score:2)
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.
Re:CodeWarrior (Score:2)
My experience (Score:2)
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.
====
Re:Contrary to popular belief, I am not a Java zea (Score:2)
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).
How about Python TK/Wx (Score:2)
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
All the options suck (Score:2)
Metrowerks [metrowerks.com] 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 not available (Score:2)
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.
Not Willows - Codeweavers (Score:2)
Re:Why bother with cross-platform? (Score:2)
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.
Re:UUGGGHH!! Java (Score:2)
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.
MetaCard, anyone? (Score:2)
Re:MetaCard, anyone? (Score:2)
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.
Re: Cross-Platform Development Tools? (Score:2)
Check out http://www.metacard.com/
or our site:
http://www.xworlds.com/
Kevin
GTK/Win32 - Real-World Experience (Score:3)
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).
I've done this - FLTK is the way to go (Score:3)
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)
Java & JBuilder (Score:3)
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!
Visual Cafe is nice. (Score:3)
Re:C++ sucks. Lotsa added on crap nobody needed. (Score:3)
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?
QT (Score:3)
One of my personal favorites would have to be QT [trolltech.com] by Troll Tech [trolltech.com]. 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.
Try Microsoft Visual Studio (Score:4)
Qt (Score:4)
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).
Wrong. Badly wrong. (Score:4)
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++.
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
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.
Browser GUI (Score:4)
* mild mannered physics grad student by day *
cross platform toolkits (Score:5)
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.
On distributing a VM... (Score:5)
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
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...
Qt and C++ is great for this (Score:5)
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
Contrary to popular belief, I am not a Java zealot (Score:5)
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."
GCC cross-compiler (Score:5)
There are also cross-platform GUI environments like WxWindows [wxwindows.org], V [objectcentral.com], etc. See the MinGW FAQ [mingw.org] for more information as well!
JimD
Re:gcc! (duh!) and Qt, Winelib or WXWindows. (Score:5)
> 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.