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?"
Amulet (http://www.cs.cmu.edu/~amulet/) claims to be a mature free cross-platform GUI development environment for Linux, Win95/NT and Mac. I haven't investigated it personally, but it seems worth checking out.
Steve Huntley
blacksqr@usa.net
http://www.win.net/~blacksqr
You can distribute the Java Runtime Environment with your app. This just has the necessary components to execute programs, no compilers, no debugger, etc. The only bit you need to write natively are the program wrappers. I use .bat and .sh scripts, but some people like native executables for each platform.
.bat files so that we can change the shortcut's icon.
t .jar
/ rt.jar
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
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
Apparently you haven't asked Loki what they've done with g++. Of course, they did have to patch it for Heavy Gear II... but even their other stuff is pretty impressive!
And g++ will soon be much better. Wait for version 3 and the new libstdc++. Then we should have about everything we need for C++ on LInux. Well, and a debugger that can step over STL crap automatically....
No one's mentioned this yet. Perl/TK is actually quite nice, for some things. Now, I wouldn't recommend it for a large program of any kind, or anything involving CPU-intensive calculations. But it has a fine GUI that's powerful and relatively easy to learn. And the canvas rocks! Check out the demo widget program. You'll be impressed.
Bell's Second Law strikes again...
Ooh, a sarcasm detector. Oh, that's a real useful invention.
On the contrary, few programmers are actually versed enough with how to _handle_ the power of a multi-paradigm language that they often wind up being more productive in a more constrained environment.
This notion has its roots in philosophy where "true freedom" is actually a misnomer: we require some constraints in order to make sense of the world and to be productive in it.
So yes, there are situations where OO is not the ideal paradigm. Functional languages are a great alternative and are very expressive.
I think it's wrong to conclude that because OO is not a panacea it will be laughed out of the office. It is certainly an improvement upon top-down, procedural design in terms of flexibility and maintainability.
OO doesn't replace the need for good programmers. Shoddy programmers will ALWAYS make shoddy programs, no matter the paradigm.
HOWEVER, I would say that the constraints imposed on an OO language like Java or Smalltalk would result in a program that is less shoddy in the area of memory leaks and segmentation faults.
This, at the very least, is an quantitative improvement, by enforcing a paradigm of dynamic memory allocation (the "new" operator) and removing raw pointers from the language.
OO is not the perfect paradigm, nor should it be, or we might as well stop all software engineering research right now. It would be hard to argue that there is any ONE TRUE paradigm at all. I don't think anyone is claiming that it is the end of all software paradigms. It is, however, a useful and productive paradigm, and is worthy of widespread use. Which, as a matter of fact, is the case.
-Stu
Go to Alphaworks and download "DirectDOM". It's there. And it kicks ass.
-Stu
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.
-Stu
The keywords "new" and "delete" could just as simply draw you a slice of memory in a completely different
way on different computing platforms. You're tying syntax to implementation.
In a way I am, and yes you're right here. I think the point I'm making is that OO systems change memory allocation into "allocating objects".
A procedural language such as C has no such model. It's a "blob of malloc'ed memory".
-Stu
For cross-platform development, remember to check out the GUI Toolkit, Framework Page. It lists almost all cross-platform GUI libraries and many other types of toolkits out there, an essential resource for developers.
Free Software: the software by the people, of the people and for the people. Develop! Share! Enhance! Enjoy!
Since you mention Tcl/Tk, it's also worth considering Perl/Tk. See the Perl/Tk FAQ, or just all the Perl/Tk links at perl.com.
A decent, modern JIT (Symantec, Borland and even MS have *very* good ones) will run Java with a similar, or even better, performance than C++
True enough for Java but Swing is another story. Swing is a very nice, full featured, well structured, flexible GUI API but its performance is still abysmal. I mean sure, it is passable under Windows if you have a late model box with enough RAM but even the tiniest real application under Swing has a memory footprint of at least 15Mb. Even if you have enough memory to keep it from paging to disk it still has to slogging all that stuff around on the heap. It is noticeably slower than a native app.
But don't take my word for it. Go download Sun's Forte for Java IDE, which is itself written in Java, and see for yourself. Running on Windows under JDK 1.2.2 it uses over 50Mb before you even open a file.
JBuilder is nmore than a cross-development tool. It's the proof that WORA works. JBuilder itself is writtn in 100% Java and the same exact bytecode is distributed on all supported platforms (Linux,Solaris and Windows).
This by itself should be encouraging since JBuilder is a big application.
The distribution of a JVM should not be aproblem since the JRE, not the JDK, is redistributable by license. In other wordss, you can bundle your app with a JR, you don't have to bundle te JDK.
--
Paolo Ciccone
JBuilder dev.Team
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Though Squeak Smalltalk is the best cross-platform development system I know, it has some problems which may (or may not) make you not consider it:
This last "problem" also means that the other problems might soon be solved...
You obviously have never use Linux to make sure
ridiculous comments.
I work all day with winblows and when I work
at home it's Linux and is indeed the dream
environment. It's fast and doesn't crash.
If you want IDE graphic there is Gnome and KDE
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.
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!
-josh
??? 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.
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 (http://wxstudio.linuxbox.com/)also seems to be coming along fairly well.
-rozzin.
Seriously, as far as development "tools", Emacs is the way to go. I hate to start a new job and being forced to use some development environment. Give me Emacs with its keybindings and its full glory anyday.
If you are developing cross-platform and do not need a GUI, go for C++. If you need a GUI, go for Java. If you are really courageous, go for Squeak, the most cross-platform language ever.
--Ivan, weenie NT4 user: bite me!
--weenie NT4 user: bite me!
"Computers are nothing but a perfect illusion of order" -- Iggy Pop
because C++ rehab doesn't take that long. the world will probably be cured by then.
The rumor seems to be that Apple has axed OpenStep/Cocoa on all platforms except for MacOSX. (I haven't actually seen an Apple statement on the topic, but the old Next folks seem pretty pissed.)
On the face of it, this seems bizarre. For one, NeXT was actually kinda profitable before Apple bought them. For another, OpenStep/Cocoa for Windows and Unix would only help to increase the software base for MacOS X.
--
Business. Numbers. Money. People. Computer World.
And if you happen to have a boat load of money for support then QT is what you want...
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
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
Why does a simple humorous comment always have to turn into a discussion about propaganda and cross-platform development tools?
Fancy IDE's are for wimps....If you need cross platform, QT is not too expensive for Windows development and then you can use your favorite editor. If you really MUST have an IDE, KDevelop is pretty darn awesome and, if you stick to the QT libraries (rather than the KDE), you'll still be portable. I believe that KDevelop can generate makefiles (or at least configure scripts) so it would probably not be terribly difficult to get the project to work on Windows. Elvis has for ever spoiled me for other editors. I leave trails of ":wq"'s every time I use something else. BTW, it may even be possible to get some of the KDE libraries to compile on windows although I don't know if anyone has ever tried....
In Soviet Russia, hot grits put YOU down THEIR pants.
-- Word of the day: Percussive maintenance is the fine art of whacking the crap out of an electronic device to get it wo
Something you should check out are ACE and TAO. ACE is essentially middleware for C++ programming that will allow you to write code which will compile almost anywhere (all flavors of Unix, Windows CE/NT/9x/2k, various real-time OSs). TAO is a CORBA compliant ORB with the same properties. Basically, if you write your code using ACE (and TAO if you want), it will compile cleanly anywhere without you needing to account for cross-platform weirdness. Oh, and if I recall, ACE & TAO are LGPL'd.
-- "I am disrespectful to dirt. Can you not see that I am serious!"
This is very easy, I could write a class that would do this in about 10 minutes.
You need a Launcher class, something that spawns a new thread for each application you want to run, and simply calls the main method of the specified Java class in it's run method. It could be as simple as a little AWT text field and a "launch" button.
-Snoot
What about cross-platform Smalltalk tools (e.g. ST/X, IBM?)?
'nuf said.
Have you thought about building a web application with something like Silver Stream or Apache-Jserv?
Recently we built a sales responce tool for a client that allowed users to send information, manage contacts, and generate sales reports for managers. It worked out rather nicly and was completed in the time it would've taken to build a Win32 or Java application.
Justen Stepka
http://www.omnis.net
t ml
http://www.omnis.net/linux/index.html
Omnis Software won an award at LinuxWorldExpo last August in the Development Tools category.
It will soon be shipping with dome of the full-price Linux distributions.
http://www.omnis.net/whatsnew/press/caldera24.h
Omnis Studio supports native DAMs against Oracle, DB2, Informix, ODBC, etc. data sources.
It supports the use of JavaBeans and ActiveX components. It already has a large international developer base.
But its not Open Source.
Paul
.
...and are you hiring? I'll be looking for a job this summer and searches on the major job web sites turn up only about a dozen jobs which make even the slightest mention of Qt. I like Qt, and I'd love to use it on the job. Unfortunately, the vast majority of interest I get from employers seek VC++/MFC expertise. I also use C++ Builder/VCL on Windows, but it too is scarce on the job sites. Am I looking in the wrong places (Monster.com, dice.dom, and computerjobs.com)?
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'd like to see this lecture.
I agree with you about Forte - it's free (currently), it works really well (much better than JBuilder), and I use it all the time as my IDE (when I'm not using TogetherJ or writing in XEmacs).
One thing I really like about it is how you "mount" directories/jar files for a project - no longer to you have to add/remove files from a project, you just mount the project source directory and then add/subtract files at your leisure.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
There are a few minor bugs with the JRE; check out Sun's bug parade section in the Java Developer Connection site for more info. (Like the NY Times, it's free, but you have to register.)
I would imagine using something like InstallShield's Java edition would make things even easier, but I've not tried it.
--Milton L. Hankins
Smart programmers want choice. C++ may shoot you in the foot and blow your brains out at the first chance, but at least it gives you freedom. Don't like objects? Don't use them. Don't want a vtable? Don't cause one to be created. Ultimately I see paradigm-agnostic languages as being the winners, once programmers start thinking.
Excuse me, but I work w/a development team in and we use Java. I believe that the strictness of the java language keeps us all on track for doing things consistant. Also, I don't think that it's impossible to write procedural code in Java, it's not that bound. Actually I would say that Python forces more code-style standards than Java. And might I ask WHY having a C backward compatibility in C++ is a "Good Thing"?
I agree that Choice is good, I don't believe that having a team of STYLE-creative programmers trying to SPEED through projects and figure out what the other person(s) are doing is the most efficient thing.
This is actually a compelling argument for using Python for something such as a large internet based project where a lot of different people tend to touch the same code.
Oh wow, they are really moving on template support. I'm so hopelessly out of date.
For the curious, here's SGI's iostreams library:
http://www.sgi.com/Technolo gy/STL/standard_library.html
Now I gotta find some egcs rpms...
What are Koenig lookups?
Where the compiler searches the namespaces of a function's arguments to find the function if it isn't found in the current namespace.
I remember reading awhile back that CodeWarrior had a java to native compile option. It would seem to me that such an idea would give you the best of all worlds. Native performance on nativly supported machines, VM support on non-supported machines.
Does anybody have any Java to native experience?
Anyone who cannot cope with mathematics is not fully human.
There's nothing in C that you can't do in assembly.
:)
Yes there is: Finishing the project before dropping dead or going insane.
Save the whales. Feed the hungry. Free the mallocs.
Beyond that, you might consider the following approach to development, which I have found to work quite well:
- Use Python. If you don't know the language, you can pick it up very quickly. It scales well to large projects. And since it's interactive, you save a lot of development time by skipping the compile and link steps.
- Use a cross-platform GUI library. wxWindows is a good one. There are others that have Python bindings -- see this list for a few.
- Once you get something working, you can optimize the hot spots, and then rewrite the performance critical parts in C, C++, or Java, all of which interface nicely with Python.
This way you can retain cross-platform portability and reduce your development effort considerably.Run very far away from the dated MS-provided STL libraries (from Dinkumware). They are horrendously out of date, buggy, and poorly documented. Use one of the standard implementations, either from SGI or the great STLPort (based on the SGI STL). SGI even has a decent implementation of iostreams which outperform native iostream libraries on almost any platform.
mx
I would check out WxWindows if you haven't already. I have had a good bit of luck developing software under it. It allows you to write once, then re-compile for each platform. The resulting programs use graphics native to the system (gtk/motif for unixes), and so seem to fit nicely with the other applications on the system.
The distribution comes with a bunch of examples, so learning the classes isn't terribly difficult. The only downside I have seen is that I haven't found a nice IDE that uses it...But since I like emacs and vi, it doesn't much matter to me. =)
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.
Actually, this is not the fault of g++. This is the libstdc++ library you're talking about. They seem to be redoing the whole thing, so we'll see how that turns out. g++, however, has pretty good support for everything, including namespaces, which are just broken in most versions of libstdc++.
All floating point?! Just great... (BTW: The fact that java lacks quite considerably *even* on fp test is quite telling)
... uhm... visual on control repainting no matter how fast your cpu is. And that GUI is disgusting.
Now would you try smth closer to GUI/DB stuff at least.
In my experience java is (alas) a memory gobbling, slow loading abomination with GUI that is
I blame implementations... Idea per se is quite neat.
To original poster of question in topic:
Did you try JBuilder yourself? Maybe I don't understand smth or whatever - but it's completely non-useable, IMHO. Personally I'm awaiting for Kylix thing.
Java 2 is ... interesting. While Swing is a nice API, it is 10x slower than AWT, on the whole. This is because it is 100% java, rather than native. If you don't need speed, Java 2 is OK. If you do, wxWindows is a crossw-platform widget set for C++ and Python (maybe others?).
Become a FSF associate member before the low #s are used
Check out this posting on creating Windows EXE's using SmallEiffel on Linux.
We created a large app at our company, all developed in windows, however we used weblogic's Zero Administration Client. There is a cross platform package that works pretty well that can package up a JRE with your app. It also allows for dynamic updates. Weblogic also handled all our database connections. It is still kinda new, and has some bugs to be worked out, but for the most part, its fine.
-
How about some real numbers? A java vs. C/C++ benchmark page is here
We just went through these exact discussions prior to deciding to shift our "strategic language direction" to Java from C/C++. I think we hit most of the arguments made here, as well as a few others:
- We predicted (and are realizing) a considerably shorter development cycle in Java.
- We anticipate that writing in a "portable" language will bring us to market MONTHS faster on multiple platforms, versus the time it would take to port our GUI/EUI components.
- Performance: Do you design your applications to scream on today's hardware, or to run on today's and scream on tomorrows? We voted for the latter. (And new, high-quality JITs (referenced earlier) helped support this decision)
Is SWING a pig? Yeah, but if you design that to run only on the client, you've overcome some of your potential architectural/scalability issues with design decisions up front.The major drawback we're finding is that ANY of the GUI-builder environments that we've worked with generate enough superfluous code (or worse yet, platform/environment-specific code!) that we've resorted to vi. As an aside, vi rocks, but it doesn't do drag-n-drop GUI development as well as it could...;-)
Enough rambling, back to the Revolution!
You can't, of course - but then, there are some fairly basic assumptions, like a Von Neumann architecture, that nearly all computers have followed for decades.
Most existing OS's are bagged down with platform-specific assumptions - Win2000 is thus a real huge pain to port, even for MS with millions to throw away - they had great difficulty getting it out the door on time, let alone porting it! By contrast, Java is specifically designed to abstract away lots of platform-specific features - even down to the representation of strings and pointers. Thus, although the Java Linux ports are non-trivial, it's a case of port one program (the runtime environment) and hey presto, everything else runs without changing a line (in theory).
Furthermore, because MS makes loads of money off Windows licensing, they tend to plan obselecence to force users to upgrade. By stark contrast, Java Runtime Environments are generally free, and they promise rock-solid compatibility, so there is little incentive for Sun to go around breaking old code. (They do, of course - but only by accident - and, unlike Microsoft, they don't tend to call such incompatibilities "features", on the whole.)
Female Prison Rape in NY
Not true. If you use C and malloc rather than Java and "new", you have more memory management work to do. More possibility for mistakes - for something which, in many applications, just isn't worth manually coding.
If you used some weird OO-style memory management in C, that would be a change of paradigm (in my book).
A fully garbage-collecting, memory-safe environment can be implemented beneath any language.
Hahahaha! Really? Show me one case where this has ever been done successfully for C, without implementing a full-blown virtual machine. And if it's so good, why aren't more people using it?
Female Prison Rape in NY
"The STL components are *classes* with *virtual functions* some of which are designed to be extended through inheritance."
Not true.
The STL is a collection of container classes, algorithms (free functions), and iterators to connect the two. There are no virtual functions in the STL. The STL is not designed to be extended via inheritence (although you can do this if you want to), and the STL uses no inheritience.* You extend the STL by writing a new container that provides iterators for use with the algorithms, or you write a new algorithm that uses iterators. No inheritence or virtual functions necessary.
The STL does use elements of object-based programming, since it has classes. But it can't really be called object-oriented, since it doesn't use vtable based polymorphism or inheritance. Also, the algorithms are free functions, which are a no-no in strict OO. The STL represents a genuinely different paradigm.
Notes--
* Actually, this is not techically correct. The ISO commitee added a few classes, like std::iterator, to the STL that are designed to be inherited. However, this is more of a convenience thing, since the std::iterator class only contains a few bookkeeping typedefs. It has no methods. You don't inherit any method signatures or implementations, or data. It's not true inheritence.
Stephen Molitor steve_molitor@yahoo.com
Just to be clear --
By the "STL" I mean the part of the Standard C++ Library designed by Stepnov -- the container classes, algorithms, iterators and function objects. Other parts of the Standard Library are truly object-oriented, like iostreams. The STL is most definitely not object-oriented, although it does borrow the class concept.
Personally, I think generic programming and OO complement each other. Unlike Stepanov, I really like OO. But I love the STL. I wouldn't want to do without either one.
Stephen Molitor steve_molitor@yahoo.com
>>>Do you have some good reason for wanting to develop on Linux? /crashes/ man!
>>Well, would you want to reboot a dozen times a day if you didn't have to?
>The point is; you don't want to lose your code when your machine accidentally reboots because you close internet explorer. Seriously; I develop under Linux but
>had to do some porting sometime ago and decided to use VC++ for it and lost my changes twice because the platform just
I'm not normally a Microsoft apologist -- far from it. But I will defend them here. I use Linux quite a bit, and it definitely crashes less than NT. But an NT development machine running VC++ (I use 4.x still) is not an unstable environment. I have not crashed the OS itself in weeks, months even.
I _do_ crash Visual C++. Moderately often. But I crash a lot of software often, Linux and NT. The difference between crashing an app and the OS is significant, and I really don't find NT _that_ fragile.
Now don't get me started about how horrible the Win32 APIs are. I too am looking for a good cross-platform development toolset. More in a later message.
-- There is no truth. There is only Perception. To Percieve is to Exist.
>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.
I want to know more about this. I've been considering this strategy for a while. I need portability to Windows and Mac right now, and I want to port to Linux and BeOS and anything else fun that comes down the pike. I already have a tested core of C++ code, and I hate our current portable GUI technique. I use GL now for all of my 2D/3D graphics, and I need something to make good portable GUI/widget stuff. I have already written a number of Win32 custom widgets (controls, they call them) that I'd need to port to a new UI system. Where do I start? How do I bind a C++ back end to a Java front-end? What products already use this? Does this involve CORBA or COM or how do I resolve the fact that no two C++ compilers link/mangle the same way?
Does anyone know anyting about Netscape/Mozilla's XPCOM/XPWidgets system? It looks like a great (though complex) design. Could it be used to make component software and UIs outside of Mozilla?
-- There is no truth. There is only Perception. To Percieve is to Exist.
*cough*mingw32*cough*
>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. Untrue, untrue, and untrue. Yes, they *were* true of gcc/g++ (They are really the same compiler) with gcc 2.*8*x, but 2.95.2 is one of the most standards-conforming compilers in existance, as shown by this page comparing various compilers. Note that gcc 2.95.x is the same as egcs. Oh, btw, namespaces work fine in gcc/egcs. The STL, which is actually SGI's, is almost as good as VC++'s, and can be replaced by future versions of SGI's library. The std:: namespace is, by default, ignored, but it can be turned on with the -fhonor-std option. Unfortunately, this somewhat breaks its own iostream headers. Luckily, SGI has an experimental iostream library one can download as well. This is the only area where g++ lacks compared to VC++, but it's sufficiently close as to be useable by the vast majority of programs that rely upon the STL. Oh, do I love SGI. In gcc 2.95.2, I have found no bugs relating to templates (or, heck, at all). Even partial specialization works! Oh, btw, I develop on Win32. I still prefer bash/Unix command-line tools from cygwin/mingw32 gcc 2.95.2, and makefiles to VC++. Now, KDevelop for Win32 would be nice. Btw... What are Koenig lookups?
Hmm...sounds like something I've heard of before...oh yeah: MFC. You're right, no one should need anything more then good ol' ANSI C and the Windows API.
Heh.
Install a unix toolset in windows NT (eg. Interix, Cygnus, MKS), copy over your desktop background, and pretend you're in linux :)
If you're doing nothing but development within C++Builder, and cli shells, you won't notice a lot of difference.
Or, to go a step further, you could reside your files on the linux machine, work on them via telnet, and have your C++Builder project access those files via SMB.
Our first brush with Java 1.3 is that its even *better* than 1.2. In particular, Swing and 2D rendering (e.g. Grids) is much better in 1.3.
The netomat browser does this - packages the JRE 1.2.1 with it, I think. You can see how it works at http://www.netomat.net. Course, if everyone starts doing it like this there'll be a million different JVMs running all over the place on your PC. Brave new world, huh?
Have you ever actually coded using Win32? It doesn't sound like it. What you sound like is a FUD spreader.
No offense...
- Its been (successfully, imo) superceded by Icon (cf http://www.cs.arizona.edu/icon)
- While Icon and Snobol are both good tools for text processing (and GUI facilities have been added to Icon), neither has any kind of a built-in interface to the operating system (there is, eg, no direct way to open a socket in Icon)
Icon has been ported to a number of platforms (tho the graphics facilities are only available under MS Windows, Unix (X), and VAX/VMS)-y
150 Opening BINARY mode data connection for slashdot.sig (129323052 bytes).
You should try Zinc Applications Framwork
http://www.zinc.com
The current Dinkumware library is excellent, but it doesn't ship with MSVC++ because of the time delay involved in the legal battle for the code. (Side note, P.J. Plauger, founder of Dinkumware, is a Senior Editor at C/C++ Users Journal, an excellent magazing--he knows his stuff!) You can purchase it, and I hope it will be included in future releases of MSVC++. But don't knock the libraries simply because you're looking at very old versions of the libraries.
If Java is an idiot language then the poster of all people should immediately use it! OO is a much better way generally of writing code. The encapsulation and thinking in terms of entities closer to the real world that have sets of behaviors is a great improvement of the old days where you hand some raw function some data structure that the function then knows how to chew on and all the rest of the old C hackery. Sure OO is not good for every single problem. But it is an improvement of many.
Now I will agree that OO as it is commonly practiced with inheritance of implementation as well as interface and with protocols based almost exclusively on type/class is unnecessarily dim-witted. Adding stong typing just makes the problem of productively using the language worse for many OO languages. Java gets out of some of this, but not quite enough imho, with interfaces. I also want a language with a real full strength interpreter which Java could of been but somehow isn't. Oh, and true first class methods would be real useful. For that matter I would rather do something similar to Lisp where I could roll my own language/environment for the problem at hand.
I won't argue that Java keeps you from writing really tight data structure type components.
But OO is not going to be laughed out of the office or anywhere else any time soon.
Have you looked at wxwindows
I use wxpython, and I like it
The options (with Java) are:
1. Java 2 application and redistribute the JRE using a suitable installer program.
2. Java 2 applet with Java Plugin.
I have successfully deployed largish Java systems using the second technique - and strongly recommend it. More information about the plugin is at http://java.sun.com/products/plugin/index.html.
I ported a giant Mac app to Windows using (ouchouchouch) Quicktime 4 as a porting layer. CodeWarrior was absolutely necessary (allowing us to compile Mac programs on Windows) and it rocked. Except the resource editor sucked (maybe it got better?) which made us use MS Studio for that side. There were bugs for sure, particularly things that made everything go BOOM when you clicked on a button I called the crash button.. in the IDE. Much has to do with how much memory you got (I really pushed it). Didn't test Java which also was available. Linux came out after that, didn't test it. You might have to purchase different platform IDEs separately now, but one of the most valuable parts of it was a very cool side by side window comparison utility, shades of Ediff. It seems possible that you might be able to compile Win on Lin and Lin on Win if the trend holds, maybe you should ask CW.
The standard JDK 1.2.2 for Linux doesn't contain a JIT,
which may explain the performance difference. I'm
not sure if the Sun Hotspot JIT is available as a
separate package for Linux, although there are
others.
Wouldn't it be possible to develop it in Java (on prefered platform), get a native compiler for Win32 and compile it there. You lose the platform independance of the final distribution - but that never seemed to have been the point from the beginning so it's not a problem, is it?
May we live long and die out
If you are going to develop under Linux there are a couple of IDEs out there. None as nice as M$ developer, but in truth what they provide is mostly glitz. When I first switched I desperately wanted something equivalent.. I tried CodeCrusader, the KIDE, etc. When it came down to it, XEmacs/Emacs ended up being the most robust, easiest to use, all around good editor. This is not meant to try to say Emacs is better than VI, or that perhaps you may not perfer KIDE or Code Crusader. But rather, I think one might end up realizing that the glitz and controls one is used to M$ stuff, isn't as necessary/useful as the tools you can get with a more functional editor. I will say, however, things like a window with all your project files in it is something I miss.. Emacs has something called speedbar, but its nowhere near as useful.
Except for KIDE, none of these editors will provide you with an instant-application-creator (i.e. RAD). The closest you may come is glade (there is another one around with similiar functionality) that is damn close to a RAD.. maybe it even is a RAD, that allows you to quickly and easily build up GTK/GNOME applications.. I played with it for half an hour or so, so I don't know too much else about it.
As far as cross platformability, however, GTK will not cut it, and you're mostly left (at least to my knowledge) with either QT (I can't remember if KDE will run on W$ or not..), or wxWindows. Neither I am too fond of, but I suppose they are probably better than MFC. If you do go with KDE, and want a RAD, then KIDE is probably a good choice. I have no clue about wxWindows.. Someone was porting GTK to W$, but I don't think its stable yet.. Abe
wxWindows is a great C++ framework but if you are looking for *RAPID* development then check out python and wxWindows. It is a combination that will be gaining serious steam once more people look at it! check out wxPython : alldunn.com
Use Python
I've been using it for the past four months for a simultaneous Mac and Windows development project and I think his API is the best I've used on any platform, even including single platform API's. I vastly prefer it to Java or Mac PowerPlant or even the Be Application Kit.
His API supports XWindows/Posix, MacOS, Windows, and BeOS. It's written in C++. It offers:
- Multithreading
- GUI with a really intriguing layout management system
- Platform appropriate UI renderers (so it looks like Windows when used on Windows, looks like Mac when used on Mac).
- Single-file database API suitable for small data or large (like serving multimedia over a network)
- Platform-independent C++ networking API
- Debugging (debugging allocator, leak detection, deadlock detection, etc.)
There's probably more that I haven't mentioned. If you have a serious interest in evaluating Andy's code, and preferably if you're using two or more of the above GUI platforms, drop a note to me at crawford@goingware.com and I'll send you the URL and a login password.I should caution that the XWindows implementation needs some work at present; it has worked well in the past but it has fallen behind changes to the internal API and is being updated right now. So it doesn't currently build on XWindows. But it will before we complete the beta test, and having some input from some X folks would be helpful.
Michael D. Crawford
-- Could you use my software consulting serv
OOPS! Me so sorry!
Mike Roberto (roberto@soul.apk.net) - AOL IM: MicroBerto
Berto
NO - he wants to develop this in linux. From what I know, there's no MS studio program in linux.
Mike Roberto (roberto@soul.apk.net) - AOL IM: MicroBerto
Berto
Been to its web site. Seems to be a VERY clean-looking scripting language (looks somewhat like structured BASIC to me, just more powerful).
Honestly, I think Visual Basic is a good scripting language if you look at the language constructs alone. (flame shield!!) No open braces, forced indentation, etc. scope is implicitly defined.
It's how I am looking at LUA now. Someone who's done anything with it please post and let us know your experience with it...
Thanks
It is obvious that your hammer is ANSI C. In the original post, the author says I am comfortable in C++, Java, Delphi. Why then would you recommend any other language to him? From the original post you don't know anything about his particular application so how could you recommend that ANSI C is better or worse than Java?
-- Freedom means letting other people do things you don't like.
I once tried a product called InstallAnywhere. It is basically an installer for Java software. The good part is that you can distribute it with or without JVMs. If you already have a JVM it will give you the choice of using your existing one or a new one (which won't conflict with the old one).
Python is *really* open.
They both interprete a bytecode.
Python can run from within java (JPython)
Python is also multiplatform
Python is more modular.
PYTHON CAN ACCESS THE UNDERLYING OPERATING SYSTEM AND HARDWARE !
how do you like them apples
Well if your users dont have the necessary JVM, bundle it in the installation program.
The software is downloadable over the internet, so we want to minimize to download time required. The Java 2 JRE is 6mbs I believe, not an insignificant download.
But whatever you do, move your GUI's up to Swing. Regardless of Swing's memory footprint(which isn't really a problem IMHO), AWT alone leaves a lot to be desired.
AWT does most of what we want to do fine at the present, so there isn't much reason to move to Swing.
====
Well, would you want to reboot a dozen times a day if you didn't have to?
Disclaimer: The opinions expressed are not necessarily my own, as I've not yet had my medication today.
>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.
The thing about a statement like this is that it is so often repeated that it has become something that people generally accept as fact without asking if it is actually true. Speaking as an experienced Java programmer I can tell you that it is not true. Java is not a slow language. It used to be slow due to design problems back in the 1.0 days and due to slow VMs, but it is not slow now. Some people will say that it is inherently slower than C++ due to the garbage collection and everything I've read says they're right. The real issue is how much slower. The answer: not much. If a program is written using a modern version of Java and runs on a reasonably up to date VM, it will not be slow due to the performance of the language itself. If it is slow, it is the fault of the programmer. One of the tradeoffs of Javas ease of use, is that it makes it disgustingly easy to write really lousy code. I see it all the time, sloppy programmers who don't really understand what the language and VM are actually doing with the code they write, will needlessly write their program to be an order of magnitude slower and more resource hungry. Beginner programmers assume that just because the code compiles and runs, that the work stops here. Languages like C++ are inherently more complex to develop in, meaning that you almost have to have a better grasp of what your code actually does to get them to work. Java is far easier to learn and use, so some of the developers it gets are not necessarily the best programmers in the business (VB works like this too). The easiest way to tell an experienced Java programmer who knows their code from somebody who can simply reproduce the syntax is to look at how they handle their Strings. Try it sometime, there is a big difference.
>> ny other scripting languages aren't even worth considering. What!? TCL/TK all the way, baby! If ya write it correctly, TCL/TK code is completely portable. GUI development is easy; writing applications in it is quick and relatively painless; and with TCLPro, you can make Win32 .EXEs.
Java 2 Applets running in either Netscape or IE with Suns plugin. The 1.3 RC2 plugin is a vast improvement over previous plugins in regards to gui responsiveness. Java now feels like a native gui ap in both windows and linux (actually better in linux). Requesting and loading the plugin onto "un-plugined" windows machines through a web page is a no-brainer. Linux takes a bit more work, but still simple. We currenly have a production swing-based applet/sevlet system that has proven to be the absolute answer. We run windows and linux clients, linux using blackdowns 1.2 plugin. Keep the applets as light as possible- only handle gui, putting most code in the servlets. You can use javascript to interface with the browser if need be for cookies and such. This architecture definatly works, works well, and should soon be the norm. I havn't used any developers; just a text editor and the jdk. Kwrite works very well with java as a text editor.
And in the meantime, back in the real world, we have a bunch of browsers whose 1.1 support ranges from mostly adequate to downright malicious.
As you point out, one can instruct users to download the 1.2 plugin - this is a fine solution for intranets and so forth. In the real world, however:
- 6 megs is too much to ask of a modem user (read: 90% of the world)
- It confuses newbies/idiots/republicans
- And, as you said, there are places and times where there's no option to download and install software.
So if you want a big potential audience, you're stuck with 1.1, and you have to be fucking crafty to make your applets work, if you plan on doing something ambitious, because there are several dozen monster gotchas on each platform, browser, and version.Fortunately, at least, Mac users are no longer shut out of the 1.1 party, if they can handle installing the newest Apple MRJ, which has, ironically, gone from being the single worst 1.1 JVM to the single best, IMHO.
We're on the road to Tycho.
Compilers, however, I can speak of.
We just went through an exhaustive process trying to determine which IDE we would use at my company. Opinion was strong in favor of Visual Cafe', but myself and three other holdouts work on Sun Ultra 10's. They'll get my Ultra from my cold dead fingers before I move to an NT box. A factor in our argument was that deployment was to Solaris servers.
We ended up with Borland Enterprise 5.5. It's got hooks into revision control (user specified), it's a Swing app, so it'll run anywhere (anywhere you have 128megs of ram and a JVM that is :) ), it's much faster than Forte' CE, less buggy than Forte', and you can actually get a copy of the Enterprise edition to TRY right now (unlike Forte'). Are you listening, Sun? Additionally, Sun reps wanted to send a developer at the cost of $8k for a week to teach us how to use Forte before they would sell us the IDE.
So, I can recommend JBuilder as a multi-platform IDE. I'm using it right now. I'm not used to the way the wizards create servlets, but they seem to work well.
"We apologize for the inconvenience."
I'm not a big follower of Java, but how, exactly, do you design non-obsolescence?
Unless you're claiming that the Java design somehow schedules when other, competing, technologies will become obsolete.
You know how dumb the average guy is? Well, by definition, half of them are even dumber than THAT.
-- J.R. "Bob" D
The PC and Mac versions will cross compile to one another; I don't know about the Linux one. However, the projects are compatible between platforms, so you can migrate code with remarkable ease.
IP is just rude.
Is there any torture so subl
But its faster than Python, almost as fast as perl. And if you want a proactical cross platform GUI in either of these languages, then you end up using the "Tk" toolkit, which, was written specifically for TCL and, surprise surprise ! is much eaisier to use with TCL than with any other language.
While TCL takes some getting used to (trust me - everything is not what it seems with this language!!) I have written applications with a couple of 1000 lines of TCL/Tk which compete effectivly with MFC/X Windows applications costing $1,000s.
PLUS and this is a really big PLUS and it actually surprised me. It is pheonominaly portable. With not a single change in the TCL/Tk source and with five or six IFDEFs in the C code I have ported an application from AIX to Solaris, HP, Windows NT (3.5 and 4.0), Windows 95 and OS/2. With a few more changes (including fiddling with the TCL source!) I have ported the application to VMS.
Portable or what!
Old COBOL programmers never die. They just code in C.
This combination is deadly good for two reasons:
1. Python is the most elegant language I have ever seen. Smalltalk is elegant too, but I found the "procedural programming sucks" message printed too loudly in the design of it. Python at least allows standard shell script type procedural programming (programming in the small?) and large object-oriented system programming (programming in the large) equally well. It can be an embedded part of your C applications, or you can start with Python and add C extensions where necessary. You don't normally need to add C extensions though, because the standard library is great. Sockets, HTML, XML, Windows COM/DCOM, CORBA/ORB, SQL and database links, are all written for you.
2. IMHO, wxPython is the best-of-breed GUI for Python. I personally dislike Tcl/Tk intensely (ugly, primitive, non-native looking, limited widget set) and find wxWindows (C++ library) much better looking. It's a little larger, but most systems can handle the size. There are still some quirks in it however, and I think it will be another 6 to 9 months before I'd feel comfortable shipping applications with it.
3. I think a nice IDE + GUI Builder (Boa Constructor?) combining Python+wxPython+IDE would be a killer combination. Keep watching out for this one.
Warren Postma
Don't forget Dreamcast and X-Box.
.
.
.
.
Plus any OS that runs Java.
I have to have Linux, I can't work in a Windows environment, but I too have users that require it. I just recently finished a project that I wrote entirely on my Linux box and then dropped on my client's Win98 boxes and it worked almost flawlessly (I actually had to rewrite a couple of functions that used Linux only code so that they would work both places.)
To accomplish this I used Python plus its defacto GUI which is Tkinter (uses the Tk libraries), plus ODBC. I used a Python package called mxODBC.
There is a great Win installer available for Python that will install everything you need on your client machines.
The bottom line is that I expected it to be a painful experience--even though it was "supposed" to work--it worked as advertised and I had very little pain.
Stand Fast,
Stand Fast,
tjg.
The point is; you don't want to lose your code when your machine accidentally reboots because you close internet explorer. Seriously; I develop under Linux but had to do some porting sometime ago and decided to use VC++ for it and lost my changes twice because the platform just /crashes/ man !
Religion is what happens when nature strikes and groupthink goes wrong.
We've been supporting Netscape and IE pretty much transparently for quite a while. We used to use mostly dynamically generated HTML (generated by the server), but in the past year or so, we've been using JavaScript, and haven't come across many inconsistencies between the browsers. It even works fairly well on WebTV, or so I'm told.
* mild mannered physics grad student by day *
* mild mannered physics grad student by day *
* daring code hacker by night *
http://www.silent-tristero.com
Until that is, you find out what I'm like and then I'll be out rotting too.
.oO0Oo.
Christians, Muslims, Hindus, Shintoists, Bhuddists, Jews, Pagans, Taoists, Catholics, Athiests, Agnostics, You, Me.
All wrong. None of the above have the slightest clue about any of it.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I'm afraid I completely disagree with you. I have also developed extensively on cross-platform Java and C++ projects, and I've come to the opposite conclusion. The most important problem with Java bugs is this: if you have a "gotcha" in C/C++, you can fix it, because you can "do anything" with C/C++, in the sense that you have complete control over the code, the libraries, etc.. However, in Java you are limited by the bugs in the run-time libraries. If the library has a problem deleting files (this is an example I ran into), you cannot fix it, whereas in C you always can. I have assisted multiple parties with cross-platform Java development, where I have arrived in the middle of a project. All of them had to resort to platform-specific code, written in C/C++, and called from Java. They had to do this to get around issues of speed, and of platform-incompatibilities. They all told me that, given the chance, they would have just stuck to C/C++, but it was too late at that point in the process to switch. Don't let this happen to you! ;-)
However, I don't mean to sound like Java is complete crap. I agree that, when it works, it is good, and perhaps better that C/C++. The problem is, it doesn't work.
I have a truly marvelous signature which this line is too small to contain.
However, the context of this article isn't about a language per se (i.e. without libraries), but about a cross-platform application development environment. Neither C nor Java is an environment without many libraries, as both are basically a syntax for pushing memory around. So the question isn't about the language, as you emphasis, but about the whole package, and so you have to consider the packages as well. The Java packages are, in my opinion, worse than the C packages, and more difficult to fix, if it's possible at all.
Also, I disagree with your statement that AWT and Swing have few cross-platform problems. Even in casual use, when I'm using Java in my browsers, I see tremendous differences between Netscape on linux, and IE on Window (for example). Sometimes, a java program is broken in different ways on the different platforms, which is a true nightmare to fix for a developer.
>If the library has a problem deleting files (this is an example I ran into), you cannot fix it...
Of course you can - just write your own code to delete files in a platform-specific way.
So you're writing C code again. That's my point -- if you're going to have to resort to non-Java solutions, why put Java in the mix to begin with? Surely, Java+C is worse than either alone! If you are writing a general-purpose application with lots of UI that has to go cross-platform, then Java is the right way to do it.
I would agree, if it weren't for the incompatibilities. As slow as Java may be, you are right in that it is being sped up, and besides, I'll admit that in all but 95% of most code, speed isn't an issue. All the GUI and main data handling can be slow as you please. The only speed-sensitive things I can think of are graphics functions (i.e. rotating, scaling), or some other kind of situation where you have millions of calculations to do, and where speed is important to the user. But I'd agree in a second that Java is best for most apps, or at least for 95% of the code in all apps, but for the incompatibilities.
In short, if Java did what Sun says Java does, I would drop C (except for the aforementioned fast stuff). But I just don't see that.
An example of this may lie in the fact that I cannot go down to CompUSA and buy a program written in Java. Why not? What is it about Java which prevents people from using it to create commercial-grade software?
I have a truly marvelous signature which this line is too small to contain.
Take a look at PTK (the Portable ToolKit). The libraries have a C interface, but also contain glue for full C++ integration. Most importantly, it supports all the standard operating system functionality (everything from file/network access to DLL's to database access to full-blown GUI development) on 13 platforms (including *nix, Windows, and the Macintosh) and 7 hardware architectures.
I have a truly marvelous signature which this line is too small to contain.
If you are looking to do your project in Java, a great packaging tool that you should look at is InstallAnywhere by ZeroG. It provides the same functionality as InstallShield, but is java based. It also allows you to bundle the JVM of your choice with your product, to allow for seamless installation and execution. IA is used as the installer for JBuilder (although no JVM is bundled), and I'm using it for an upcoming product at my work (Adaptec) (no, it's not a Linux version of EasyCD either =-). It supports Windows, MacOS, and Solaris out of the box, and will support virtually any java enabled Unix with trivial changes that ZeroG tech support is happy to provide.
I know I sound like a sales rep for ZeroG here, but it has really made my life a lot easier considerig the nature of the project I'm on.
"I shoulda never sent a penguin out to do a daemon's work."
Cat, the other, tastier white meat.
Personally, I'd probably go with Java, or C/C++ and OpenGL if you're looking for broad support. Others have mentioned some toolkits, such as Qt, that exist on multiple platforms. Naturally, if you want to use one of those, make sure it's ported to all of your targets.
Another alternative is to roll your own toolkit for OS-specific services and build your apps on top of that. This has the advantage that the library is no larger or more complex than you need it to be
Of course, that's more work...
3 words:
Money Oriented Programming
JVM for Java, VB4/5 for Visual Basic
Both are virtual machines.
VB - a functional not natively Object Oriented language
Java - OO top down, bottom up, an oversimplification of C++ with more natural human Language API's
So what?
Java is nice, it's defenetely less platform dependent than VB
More and more people write in Java (Java is the modern VB, RAD principles + platform independence.)
Look what STL author had to say about Java, go to this page Interview STL creator and search for "java" on the page. "Can I summarize your thinking as "find the [generic] data structure inside an algorithm" instead of "find the [virtual] algorithms inside an object"?
A: Yes. Always start with algorithms. "
The man is absolutely 100% correct.
Real programming has to do with finding the best possible algorithm and reducing your problem to that algorithm (Stephen Cook, creator of Computability and Complexity CSC364 here
in any case, all languages have their use, assembler for speed; Fortran, ADA, Logo, Forth, PL1 for math; basic for kids; lisp, scheme, ml, prolog for AI; C, C++ for systems and game programming; Pascal, Turing for studies; Cobol, VB, Java for Money Oriented Programming
I love assembler, c, c++, my first language was basic for Atari 600, my first hextris was written in tp 7, my first fax driver in assemblerx86 and c++, my first tic-tac-toe game in scheme, first adventure game in prolog, first spreadsheet calculator in c, first AT&T rebiller app in Java, first bellmobility.ca Invoice On Line app in ASP, COM and HTML, first dynamic catalog in VB6, first xerox price calculator in java and c with NetCommerce, first mobile phone service for bell mobility in JSP, JS and java servlets, first Trinity Activeweb mobile server product for davinci.ca in Enterprise Java Beans with OODB and/or LDAP for distributed cache, corba, rmi.........
it's always a first.
You can't handle the truth.
NS6 will ship with the latest VM (1.3), it's worth the wait. IE users can still d/l the plugin. let's hope sun & ms resolve their difference and get everybody on the same speed. NS4.x still ships with 1.1.5!!
actually, if this person is planning to hold the source closed or sell the product for a profit, QT doesn't give much value on any platform.
even for linux, it's $1550 up front, no gui builder, just a set of libraries.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
vdkBuilder uses VDK and GTK, and there are win32 ports of both of those. The RAD IDE is similar to C++Builder, and is GPL'd.
VDK Builder
WX Windows
WX GTK
VDK Builder is maturing rapidly, is on source forge, and has a responsive developer mailling list.
It's fair to say that WX leans towards inheritance, while VDK leans toward composition. After that, it's up to you.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Pretty much all game developers expect their users to have some version of DirectX. Whether DirectX comes via a CD, or a huge download, if the user wants to play the game, they'll install it.
The same could be said for your product and the JRE. If it's worth their time to install the JRE, they'll do it. Besides, the current version of the JRE (1.3 RC2) is quoted at being ~5MB, and that isn't horrible. As long as you streamline the installation so that the JRE seems to be behind the scenes, most people won't care that much.
Nice rad environment; native Win32 code generation; pluggable VMs, with some support for Java2.
Market realities being what they are, anybody on a non-windoze platform wanting to use your product can probably figure out how to get the required Java2 support themself...
Major downsides? proprietary product; native code (if you use it) defeats dynamic bytecode loading -- so none of the infinite extensibility Sun promised with Java and NeXT^H^H^H^HApple delivered with their Objective-C based technologies.
And of course, all the other downers associated with developing in Java.
QT will also be ported to MacOS X. It's somewhere on the QT page
Well if your users dont have the necessary JVM, bundle it in the installation program.
And you should definetly require Java2.
If you guys go through the trouble of writing a windows executable why not go through the trouble of having Install Shield or a similar program detect if you have Java2 installed? If not, install the JRE. If your worried about performance versus java 1.1 install Hotspot on top of 1.2.2.
If your installing to a Linux client you could also check for available JRE's the same way Star Office 5.1 does. Then have the installer create a script to launch the app (maybe even put a nice little kdelink to it if that's what they use).
But whatever you do, move your GUI's up to Swing. Regardless of Swing's memory footprint(which isn't really a problem IMHO), AWT alone leaves a lot to be desired.
I haven't tried it yet but I just came across this guy called V:
http://www.objectcentral.com/
However, it's not really a cross-platform development environment. It's a Win32 development environment that works on UNIX. You use Visual Studio to create your project, then compile the project on a UNIX system. And it's NOT trivial to use. Dependencies on stuff like DAO and VBA can throw you off, as can coding styles that your UNIX compiler doesn't like.
It's worth looking at.
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.
Wishful thinking, Kylix will be powered by Inprise's VCL. The VCL is an excellent class library that i have used first hand in Delphi and C++ Builder in windows.
-- Just the FAQs Ma'am.
As far as Java goes, there is a reason why the unofficial saying is "Write Once ... Debug Everywhere". Not to mention the performance hit you'll take unless you can find native compilers for every platform. (I'm not anti-Java ... the right tool for the right problem is the skilled Software Engineers credo. If your bashing an approach, you immediately flag yourself as an unskilled SE. (by this I mean statement like "Java sucks", "Windows sucks", "Linux is the solution to you every problem", or the one I saw recently "the x86 platform isn't good for anything .. you want Motorola 68K"))
:)
I could be wrong, but I don't believe there is any easy, good way to do multiple-platform development. You need to practive sound Software Engineering principles (a rare talent to be sure!) and properly decompose your problem so that common code can easily be reused. Specs need to be written with the targets (and any future ones too!) in mind, and then in the end you will have to write certain O.S. specific parts seperately and link them to the common code for each target platform.
It is especially important that you realize that writing code, when Software Engineering is done properly, is the smallest and easiest part of the task. If your development team (which may just be you) is spending more than 20% to 30% of it's (your?) effort writing code, you are going about it in the wrong manner!
People have been searching for the Holy Grail of multi-platform development for almost as long as there has been more than one platform
If you insist on doing it the easy way you won't succeed. As Ian Anderson says (Jethro Tull front-man) "Nothing is easy".
G00d 1uck,
ZK
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Gtk+ is very nice to use and is totally free (GPL) across multiple platforms (Win32/BeOS/*Nix). In spite of the fact that it is written in Object Oriented C, it is quite easy and nice to use with C++. Also, Gtk-- is a C++ wrapper that is supposed to be very nice as well, and they have a Win32 port going on right now. When you add Glade (visual gui builder) into the mix, you get a very slick and powerful package. Definitely look into it.
As an aside, another C++ portable library that i hear is quite tasty is WxWindows.
---
Xiphoid Process Records - http://xiphoidprocess.com
San Francisco based electronic music.
got drum'n'bass?
http://mp3.com/vitriolix
For that and other reasons, Microsoft has actually deprectated MFC. I think you're supposed to use ATL (Active Template Library) now. It's never a good idea to base something on a Microsoft standard - they like changing them out from under you... (at least it feels like it to me...)
You are in a maze of twisty little relative jumps, all alike.
Why does everyone love Java? It's so ungodly pathetic. Yeah, it works for cross platform crap, but it's an awful solution.
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.
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?
If you are writing for Windows, write on Windows. I'd be disappointed to hear my Nissan mechanic practised exclusively on Mazda cars, "trust me, I can make it work" he'd say. Meanwhile, I'm making a fast break for the yellow pages to find a new dude.
If you really hate windows, try Metrowerks for the Mac, it'll do Mac and Windows for you. You can get Metrowerks for Linux too, but so far as I can tell, the linux version is linux specific and the Windows version is Windows specific. Only the Mac version (correct me via email if you must) supports Java and C on Windows and the Mac.
No sig is worth reading.
Granted there are some thoughtful and informative answers. But these generally degrade into "Java sucks", "Java is slow and bloated", "C++ sucks", "C is the only real language" , "real programmers ... " blah blah blah, in the subsequent replies.
For fucks sake, can we progress a little?
Have you considered developing natively? Visual Studio isn't all that bad. If you don't want to deal with MFC (who would? :-), GTK is available for windows now (so you could develop with linux that way). Also, QT, though the Windows version requires a license. Alternatively, for the cygwin tools bring GNU cli power to windows.
I forgot to mention... OpenStep/GNUStep. If you can get a hold of OpenStep for NT (Web Objects), you could develop under linux with GNUStep, or NeXT, or Mac OS X. Of course, GNUStep is still in development.
real cute
2^3 * 31 * 647
The last time I wrote a cross-platform Java applet, fully 20% of the code was conditional on platform, browser, VM version, etc. It isn't write once run anywhere.
You indicated that your product will run on Windows. You'll already have enough headaches making it run on Windows NT 4.0, NT 2000, 95 (and 95 OSR2) and the two releases of Win98! Don't add Java into the mix and double or triple the number of possible combinations.
Use Microsoft tools. However, if you're careful to separate your code from the Microsoft application classes, you may be able to develop the core functionality on Linux, and then integrate these classes into a Windows application.
--- Speaking only for myself,
"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!"
In other words, if we're writing applets, most of the world isn't using 1.2 yet... and if a browser doesn't support 1.2, there's no point in telling users to download and install a JVM because they won't know how to do it (or won't be allowed to, in most web cafés) or can't be bothered to, and will go to another site...
Is this a fair interpretation?
- JAVA lacks parametrised types
- JAVA cannot specialize return types
- JAVA has disfunctional multiple inheritance
- JAVA lacks a preprocessor
- JAVA is not a good language, but it has a large array of good libraries
- JAVA has wierd behaviour for functions whose access has not been specified
Well, and there's just one thing that's both good and bad:Parametrised types are the building stones of type-safe generic programming. The lack of parametrised types is the reason why every time you use a JAVA container, you must cast to the correct type.
C++ solves some of these problems, but you still can't use types as first order values.
virtual functions must have the exact same return-type for both super and derived classes. This makes it really hard to write general interfaces which are specialized to typesafe implementations
JAVA implements virtual inheritance through interface'es. This is a really wierd thing to do for a language that does not have object variables (it only has object reference variables!)
That no stack-space objects can be created exactly allows JAVA to sidestep many of the C++ problems with multiple inheritance (i.e. allocation and copying).
That there are several conventions that one could use for "real" multiple inheritance, does not mean that you have to select the weakest one....
It's horrible to write the same code behind 5,6,7 or more implementations of an interface, just because JAVA-designers chose the easy to implement option.
Althoug the C-preprocessor allows for some of the ugliest code, it also allows for some utterly elegant hacks for assertions, unique ID's, and conditional compilation which are really handy, and which are not feasible to do using just JAVA constructions, not to mention the __FILE__, __LINE__, macro's for doing tracelogging.
I (myself) can live with this, there's nothing like a makefile saying:
%.java: %.javacpp
$(CPP) $< -o $@
But what about the poor IDE-developers, stuck without a preprocessor?
Don't confuse a good language for a bad language with a lot of standard-libraries.
if you dont specify "public", "protected" or "private" as method access modifier, you get a 4th behaviour: public inside the same package, private outside... now first of all, it's stupid to make an access modifier without having a keyword for it, but even worse.... package developers and testers won't catch a missing modifier until some poor soul uses their package "from the outside" (another package).
- JAVA does not have operator overloading
But it's not all bad, you know:this is both good and bad... Using operator overloading in the right places leads to much more readable code, but in the wrong places (i.e. where ^x is overloaded to do something like roof(x)) can make code utterly unreadable.
+,*,/,%,&,<,<=,=,... are general functions on many structures (rings, fields, groups, orders, lattices,...), it's kind'a sad that one can't overload them when implementing a Complex, FiniteField or TypeLattice class (think crypto, and compilers!)
- JAVA has only object references, and a garbage collector
- JAVA has a large standard library
I really think it's a shame, that all the nice compile-time type-safety is lost in JAVA, all those nice abstrations, and you can't get a descent type-warning.Having only object references save lots of trouble when doing copying, think how much trouble it is to store a C++ exception for later throwing!
A garbage-collector is a good-thing (TM), I just dont know, why C++ does not have an optional garbage-collector, which could be turned on or off on compile time. If you really want to free your memory yourself (and this is a good idea!) just assing NULL to the object reference...
All those nice networking functions, and abstractions, that really nice.
That some work has gone into designing these libraries, and that they function (relatively) well with each other is a seldom sight in the world of "real-world" oriented languages (as if ML and other functional (and contraint for that matter) languages, is not real-world ;)
SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
I'm sorry, but this is categorically false. Even fudged results from the most skewed tests put JIT Java code at least twice as slow as C++. I'm not saying you shouldn't use Java - there are times when it is the correct tool - but users should realize that they are going to take a significant performance hit.
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.
Bravo. I'm so tired of hearing people bellyache about perl being obfuscated and error-prone. This is simply nonsense. Any literate twelve year-old can read and digest Programming Perl. That fact alone should shame the moaners and groaners in here who simply aren't up to the challenge of a truly different language.
The Windows platform will continue to lose mindshare.
Bravo Twice. The web is the only platform that matters. Shrink-wrap is dead insofar that MS owns any aspect of the shrink-wrap market worth pursuing.
This is such a loaded statement. Without calling into question your C++ skills, I have seen unbiased tests that indicate that Hotspot is still twice as slow as C++.
Anecdotal information regarding Java's supposed performance gains are so numerous (and spurious) in /. that they are almost useless. How did you measure the performance gain? What features of C++ (templates, MI) were you using that Java does not support?
Until I see some concrete proof otherwise, I'll just have to judge Java apps as I continue to rate them - fat and slow.
Excessively poor performance put Tcl out of the running long ago. Scrptics is fighting an uphill battle - the perl mindshare is at least 10x the Tcl mindshare right now, and job ads show this.
This coercian is what leads me to conlude that Java is ultimately an idiot language. Don't get me wrong - there is a place for a "dumb" language - its good and right that more and more people be able to code, but ultimately I can't see a seasoned programmer being satisfied with being bound to one paradigm till death do us part.
Smart programmers want choice. C++ may shoot you in the foot and blow your brains out at the first chance, but at least it gives you freedom. Don't like objects? Don't use them. Don't want a vtable? Don't cause one to be created. Ultimately I see paradigm-agnostic languages as being the winners, once programmers start thinking.
As it stands, I also think that we are within five years of OO being laughed out of the office as a general development menthod. Forward looking writers have already lambasted or severely lambasted OO (see Gabriel's Patterns of Software).
There is no indication that OO improves programmer performance or reduces errors. Most studies that seek to validate OO as a method do so by studying superstar programmers. These folks would do well if forced to use an abacus. The everyday programmer typically misuses OO features, and the resulting hairball is anything but a advance in design.
We don't have the perfect paradigm/language yet, but I know Java and OO aren't it.
Its a dead market folks.
Corel is not the future, Yahoo and Amazon are.
No, it is not. Java has no parametric polymorphism, multiple inheritance, or optional virtual methods.
I'm not saying Java is good or bad per se by saying this, I'm simply saying that Java does not support more object-oriented featues than C++.
Object orientation allows large projects to be arranged and managed in a logical manner.
Yeah right. Reading Booch does not an expert make. Most real-world studies of large projects indicate that OO methods can significantly complicate and delay projects.
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,
Tk has been bound to numerous languages - you need not use Tcl to enjoy Tk.
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
Sorry, but now you've just gone off the deep end. The entire shrink-wrap market is dead (Microsoft owns any part of it worth owning), so I have to dismiss your advice categorically. Program for the web. Where would you rather be - Ebay or Corel?
Transmeta's codewarping is one of the reasons with the same ISA a transmeta CPU needs an extra 250Mhz or so to match an PIII-450.
The only place runtime optimization actually offsets the slowdowns from doing JIT compiliation are pathological cases arranged by vendors for demos. In the real world, java is ALWAYS slower, sometimes 10%, occasionally 100%.
The reason not to dismiss java out of hand is that most apps these days don't need the speed. The problem comes when someone tries to use java for an app that does, because they heard that java is "just as fast, or faster than C++, thanks to the patented HotSpot Technology (TM) (C) (all rights reserved)" marketing bullshit.
Sorry, this is just not true. I work on a team implementing a Java2 JVM and JRE. We were pleasantly surprised at the performance gains we saw when using HotSpot. It really does dramatically increase Java execution speed. We commonly see Java applications executing only 25-50% slower than their C++ counterparts.
But we also do see some not-uncommon cases of Java code excuting faster than natively compiled C++ code. This seems ocounter-intuitive, until you realize how optimizing native compilers work. They can only optimize within compile-time boundaries - typically they optimize within class or methods. They miss many potential runtime optimizations. There are repetitive code execution patterns that static compile-time optimization just misses.
For a detailed description of this sort of optimization, read: this ArsTechnica article. It describes HP's Dynamo technology, but HotSpot uses some of the same principles, as does TransMeta's code warping.
I can assure you this is not (just) marketing hype. There really are dramatic speed ups to be gained from this approach, and we are seeing them with real world code examples, not just "pathological cases arrranged by vendors for demos."
Sailing over the event horizon
You didn't mention having your app run on Linux as a requirement. If it's a Windows only product and you want to use C++ Builder, why not use it and just develop on Windows? Do you have some good reason for wanting to develop on Linux?
"It was not until their numbers had dwindled to nine that the other dwarves began to suspect Hungry."
I think he is pulling your leg. Or jerking your chain, or taking the piss. Whatever the American colloquial is. :-)
Remember, there is no "we" in megalomania !!
I am a Linux user myself, and I've contributed a few patches to various projects in the last couple of years.
Either you view Linux as a hobby or you are no longer intrested in Linux. If you indeed developed in Linux, certainly you would know of the various widget sets...now tell me that GNOME (GTK) or KDE (QT) is made out of a "primative" widget set. These UIs hail supreme for most Linux users, and rival (better put, better than) explorer in Windows.
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?
The ideal of crossing platforms is to make as little change to the source and be able to keep a consistant feel and functionality. Java was a pioneer in that regard, and since I don't know Java, I won't comment on how good it really is. Aside from Java, Tcl/Tk comes to mind. To what I best know, Tcl/Tk is like Java with JIT contemplation and the need for a interpetor. Both languages I have seen with some of the programs I use and these both fit the ideal of a cross-platform program.
With the various open-source projects out there distrbuting widget sets on multiple platforms (No, DevStudio doesn't count just because it can go from Win 9x to Win CE to Win NT to Win 2k), it allows for developers to again, fit the ideal of crossing platforms. The future of computers doesn't reside with M$ any longer -- cross-development is now. Those who learn now to cross-develop will be the ones with the highest salaries, where people who make remarks such as "Why bother with cross-platform?" will still be paid the lower salaries.
"Windows -- The Original Denial Of Service (DOS)"
People who've seen Java running faster than equivalent C++ code are like aging rock stars with convincing explanations for the collection of Brazilian child p0rn on their hard drive -- there's fucking millions of them, and nobody believes any of them.
That's my analogy for the day.
-- the most controversial site on the Web
http://www.devolution.com/~slouken /SDL/Xmingw32/
http://www.xraylith.wisc.edu /~khan/software/gnu-win32/
I use xmingw32, emacs, gdb, and cygwin as a pretty much comprehensive development platform for the game I'm working on, Reel Deal Slots ( A slot machine casino.... I know, not exactly a product targeted for geeks, but heh, I thought if I had to work on something like that, I might as well get some fun out of it! Close in the running to becoming the first hybrid Linux/Win32 game on same cd too.... www.phantomefx.com for details... ) SDL is pretty cool for us cross-platform people too.. Check it out: http://www.devolution.com/~slouken/SDL/
Also, I'm working on getting a cross-debugger for Win32 ( Debug a windows hosted program from a remote Linux station ), anyone else out there got something like this going?
Jeremy Peterson.
Try VisualSlickEdit :) It has ports for both Linux and Win32 and allows the source code to be portable ;) McKay
PowerBuilder and UNIFACE can both produce apps which cross-compile to UNIX (not Linux) but they are both expensive and a pain to work with. For corporate business apps, an alternative might be to use a transaction server instead. Linux has PHP while Windows has Sybase Jaguar and MS Transaction Server. If you stick with PHP you can have it sit behind Apache, tie in to MySql, then build your business logic in modules using any language which has a CORBA interface (TCL, Perl?, Python, C, C++, Java, Smalltalk?, shell scripts, etc.) Now, for true cross-platform applications, you just need an HTML WEB Browser on the client machine.
Check out Omnis Studio. It's a 4GL (Interpreted) rapid application development environment. Applications developed with it can run on Linux, Windows and the Mac. You can't write video games with it, but you can use it for pretty much anything else. Also it has a web component which allows you to run applications with a web browser. Omnis is at: http:\\www.omnis.net
You really should try Forte(tm) for java, it is free nd you can download it from SUN. I use it both on linux and Win, and there is no difference in how they run. //
I have tried Java applications combined with Python as system duct tape. I had the advantage of access to the deployment environments but the owners kept adding programs and utilities at their will. This combination continues to work well, I have learned quite a bit and can now send all my application updates via EMail. Java is used to create compiled applications that may or may not have a GUI. Python ties it all together and does much of the frontend system level GUI that seems to work on both the Windows & Linux machines inside this multi-tier business system. Lately I have been testing a client side Internet based version using CD booted preconfigured [embedded] Linux all set to go. The CD program connects via the net to the business service backend Web & Applications servers. IIOP provides direct application connection after a traditional web page signon. I am testing this by visiting friends booting their PC's using CD's I have burned. So far it worked on all machines. I suppose I could try distributing the programs, JRE, and Python using an installer, just have not tried that yet.
Well...it's a little crazy, but you could use Squeak (www.squeak.org). It's the cross-platformiest thing I've ever seen. Okay, it's Smalltalk. But it's a very complete, very good Smalltalk, and it runs essentially ideintically on practically anything you can imagine. I've personally run the same identical image on various flavors of Windows, various flavors of Linux, and various flavors of MacOS. It runs on a bunch of less mass-market machines too, including some PDAs.
I recently started a job developing CBT (training) applications. The company's tool of choice is an IDE called Visual Impact.
For something that I had never hear of before, this is a very slick package. I would call the language an "event-driven" BASIC (similar to Visual Basic) and it supports all of the handlers, functions, messages that one would expect. It ends up being very, very easy to use.
The IDE itself was, apparently, written in the iScript language and is therefor extensible by the user. I've been doing this after three weeks of work -- something that I wasn't comfortable trying after 6 months with Visual Basic.
Behind the scenes it compiles to platform independent byte-codes (like Java) which run on a VM under Windows and Linux (and a couple of other UNIX) or though a browser plug-in (I heard that Macintosh version is in the works.)
Anyway, pick a tool based on what you want to do. I wouldn't necessarily write an encryption engine with Visual Impact, but for visual/mutimedia applications this works very well.
Waltz, nymph, for quick jigs vex Bud.
I just tracked down the web site: www.emediat.com
Waltz, nymph, for quick jigs vex Bud.
visual RAD, component based, open component API, runs in Linux, Windows, MacOS, single code base, no compiling. Connects to Oracle, DB2/UDB, MySQL, any ODBC-compliant dbase. Has web client, it is awesome, www.omnis.net.
http://www.linuxplanet.com/linuxplanet/reviews/171 0/1/ RE: Omnis Studio as cross-platform visual RAD tool The author's closing statement: "With Microsoft Access and Visual Basic stuck on Windows and Borland's Kylix Linux tool still in the works, Omnis Studio stands out as the development tool that supports the three major PC platforms."
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.
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 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
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.
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!)
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