Slashdot Mirror
Cross-Platform Development Tools?
Amphigory asks: "I am currently preparing to develop a product. It will have to run in Windows (market realities being what they are) but I really would prefer to develop in Linux. What options are available for this? Some more details: I would prefer something similar to C++ Builder, but I can't wait for Kylix. I am comfortable in C++, Java, Delphi. So far, JBuilder is the leading option. However, I am concerned that the support burden of making sure that all my end users have a Java 2 virtual machine may be too great. Any suggestions? Does anyone have experience distributing a JVM with their package? How easy is it?"
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?
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.
I've been using an application at work called ProactiveNet (http://www.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.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
--sam
--sam
Any technology distinguishable from magic is insufficiently advanced.
Especially the available Add-ons are very important! Mainsoft created a layer for the Stingray Objective Tools. With additional native ... 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
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.
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 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.
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
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.
GCS/MU d- s+: a- C++$ USH++$ P- L+> E W++$ N o-- K- W++@ O-- M- !V PS Y+ PGP- t+ 5(+) X- R tv? b++++ y++(+++)
You missed a scripting lanuage: Tcl/Tk. It doesn't have the "write only" property that perl has.
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).
-- Don't Tase me, bro!
Yes, and no thanks. I'll go back to using 'fragmented' OS's as my platform of choice.
-BrentIf 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?
-BrentI 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 ;)
-BrentIf 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:
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.
My journal has hot
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
My journal has hot
I think you are obviously humour-impaired.
:) (Ok, not really, but close enough)
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.
My journal has hot
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..
cpeterso
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.
A Government Is a Body of People, Usually Notably Ungoverned
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.
--JRZ
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!!!
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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
Adam
IBM has a free evaluation version of VisualAge for Java available. Both Linux and Windows versions.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
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.
--The basis of all love is respect
"Boxen". Plural of box (computer). Sort of like Vaxen (multiple VAX machines) or oxen. See the Jargon File.
--The basis of all love is respect
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.
It's 10 PM. Do you know if you're un-American?
I havn't done a whole lot of cross platform development.
... just do a ...
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.
> 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++
Cheers
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.
Sigged!
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 http://www.guardbot.com).
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.
====
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
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?)
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.
Fight Spammers!
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.
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.
Sailing over the event horizon
Might I suggest MetaCard? www.metacard.com 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!)
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 http://www.metacard.com/
or our site:
http://www.xworlds.com/
Kevin
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).
I've used Xlib, motif, MFC(yuck), Visual Cafe, Jbuilder, tcl/tk, VB, Delphi and more...
Unlike most of the posters, I've actually done what you're talking about.
The best solution I've ever seen is FLTK.
Qt is second best, and is easier to get started
with than FLTK, but Qt is not LGPL & doesn't allow quite as much low level control.
Jbuilder is problematic, it's better to use java directly (emacs/vi + make files), but implementation of swing is terrible.
http://www.fltk.org/
I spent two years developing with java & 3 months accomplishing far more with fltk (on a different, harder project). The app is used exclusively on NT, but I developed under Linux because I prefer the environment.
Your main options are:
FLTK: Fast, flexible, reliable, small, simple
Java: Slow, limiting, buggy, bloated, complicated
QT: Good, attractive, larger widget set than FLTK, but FLTK is better in the long run.
Use emacs/vi & DDD & fluid (FLTK gui builder)
http://rareformnewmedia.com/
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!
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?
A Government Is a Body of People, Usually Notably Ungoverned
One of my personal favorites would have to be QT by Troll Tech. This is a cross-platform C++ toolset that cross-compiles into Windows and X code. There are no royalties or runtime costs charged, on any platform.
The popular UNIX desktop KDE is written using the free version of the QT/UNIX development package. If you've used it, you'll probably agree that its fast, comfortable and very solid -- all very important considerations when coding a real product.
This is a very good, clean, serious package. If you're interested in UNIX/Windows cross-platform development I strongly suggest that you check it out.
You're special forces then? That's great! I just love your olympics!
It is a cross-platform dev environment. It allows you to use Windows 9x, Windows CE, Windows NT, and Windows 2000!
cpeterso
Qt is an excellent crossplatform library for C and C++. One caveat (before everyone else mentions it) is that it is not free for Windows. Run time libraries are freely redistributable. If your project is already commercial, then this should not be a big hassle. The qt-interest@trolltech.com mailing list is quite active with a good mix of both Unix and Windows developers.
There is a free evaluation copy that you can download to try it out on Windows, or just try out the free X version that's probably already on your distro.
The embedded Qt is right around the corner, and a Mac version is being planned.
The Qt classes blow away those jokes offered up by MFC and make OWL look puny. From what I understand, Qt will be the GUI component of Kylix.
Yes, it's unfortunate that Trolltech charges for the Windows version regardless of whether your project is open or closed source. I wish they had the X pricing structure for all platforms (free for free software, closed for closed source).
A Government Is a Body of People, Usually Notably Ungoverned
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.
/x modifier.
;)
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.
Something worth considering, if it's practical, is to have your product use JavaScript and a web browser as its GUI. We have a cross-platform product that supports six different platforms, and rather than dealing with proprietary GUIs and GUI translator tools, we have an HTTP server that handles some special CGI commands, and serves the GUI as JavaScript. Since the GUI is the bulk of the platform-dependent code in many systems, this reduced the amount of platform dependent code that we needed significantly. On the other hand, our product has all sorts of other platform dependencies that have their own difficulties, so this approach clearly doesn't handle all of these problems.
* mild mannered physics grad student by day *
* mild mannered physics grad student by day *
* daring code hacker by night *
http://www.silent-tristero.com
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.
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.
.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.
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...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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
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."
We're on the road to Tycho.
There are also cross-platform GUI environments like WxWindows, V, etc. See the MinGW FAQ for more information as well!
JimD