Slashdot Mirror
Porting From MFC To GTK
crazney writes "Linux.com has an article up by Ryan Gorden of Loki on porting from Windows to Linux, in particular the troubles faced with Microsofts MFC API and the extensions implemented by Microsofts Visual C++ on the C++ language." Talks about porting, the gaming industry, and gives suggestions for portability from someone who should know.
Legality aside, don't forget your end users; not only are win32 wrappers considered to be "cheating" by the Linux community, no one wants to run a native Linux application that looks like a native Windows application. After all, if we wanted to use Windows programs, we'd just run Windows in the first place and save all this hassle. Your users demand more from you. Do not cheat them out of it.
OK - granted, it would be nice if the games had a distinctive Linux look and feel, but I really don't care about that as much as being able to play the bloody game on Linux. If this is the kind of esoteric touching up that makes it impossible to get a game ported to Linux then I am pissed!! Just put out the freaking game already and take the time to make others Linux-distinctive after you have built more of a market for games running on Linux.
Just my $0.02
The Loki programmer clearly doesn't understand MFC. he also doesn't understand VC++'s extensions. That's ok, you can't know everything, but that's not a reason for ranting. It's a reason for investigation and to collect information about the topics he doesn't understand.
I've done some tools in MFC and all I can say is that using it is a breeze, but you have to study it to get to that point. That takes time and effort. The Loki programmer should take more time to clearly understand how the original sourcecode is using the MFC.
Another thing though... he's talking about the code to port to Linux. The code he's porting is from people who write tools that do what they want them to do AT THAT TIME, but not mainstream tools for every user on the planet: i.e.: the sourcecode can be cumbersome to understand. IMHO that's a much bigger reason why it's hard to port a tool from win32 to GTK+ than the MFC calls, which are clearly documented in the MSDN (which is shipped on 3 (not 2!) CD's, he must be using old MSDN's too). I mean... how hard can it be to read the clear MSDN explanation of an MFC method, understand what it does and to use an equivalent in GTK+....
--
Never underestimate the relief of true separation of Religion and State.
Yes, thank God. Granted, as pointed out in the article, you're not legally allowed to compile it on non-windows platforms.
As someone who's done a fair amount of programming with MFC before, I don't really see how you could say that. Intended... maybe... but in practice it's not at all.
MFC even has a whole bunch of (very badly designed) STL-equivalent classes that are used very pervasively. This basically means that, if you're doing a decent Model-View-Controller style program you either:
I'm not really fond of MFC in general, either. It's a really poor object-oriented design. It has a horrid set of macros that tend to obfuscate things during debugging, and it really abuses templates (much worse than STL), too.
Since when is it being a Microsoft product an excuse for anything?
DNA just wants to be free...
But user interface stuff is exactly the problem. Yes, you *can* write a win32 app with Visual C++ without using the MFC, but it is akin to writing an X program with raw Xlib calls. And as regard to portability, I doubt most companies give a damn -- that's why there are companies like Loki which buy the rights to do the Linux ports -- the original companies aren't interested.
One of Java's biggest strengths is its cross platform GUI ability. No need to deal with MFC and GTK. Just deal with AWT (or if you are willing to ditch the mac, SWING)
When you combine java jar files with some simple VBS scripts or some bash shell scripts, you can even make installation pretty seamless nowdays.
I'm sorry, but this is nuts. MFC is the worst example of OO UI that I have ever seen.
If you really buy into Object Oriented dogma, and you want to make an OO UI, you have two places to look for real examples:
Unfortunately, I can't speak for QT; I've never used it. {:(}=
Now MFC..?! An object oriented system? It's the epitome of bad OO design. Good lord; when you use MFC, it generates these enormous files for you with macro blocks that say, "DO NOT TOUCH THESE!" around them. You can't add anything except through the grace of the UI builder. Is this "modular design"? This from people who mindlessly repeat the mantra "We must have type safety"?! It's nuts. Okay, now lets move beyond the macro blocks. When you are using MFC, it generates functions for you, and you are supposed to manually modify these functions. You can't register your functions; you have to manually go in and modify the code that it generates for you. And we are supposed to believe that this is "object oriented" design.
I'm not an OO bigot. But really; If you have determined to be an OO bigot, at leastbe a good OO bigot. Pull out your SmallTalk books, Simula, Design Patterns, Objective-C. Trace your roots. Read them. Read about NextStep. Study. Look at well documented, and well implemented, OO UI designs. Please. I'm begging you. As much as I despise OO facists, at least I want to talk with quality OO facists. Please don't align yourself with MFC.
(I generally hate writing flames, but some just have to be written...)
Of course, another approach to the problem would have been to write the program in a portable library in the first place, and simply recompile it for the intended target platform, be it Windows or Linux.
I have seen this being done with a reasonably large project using the Qt 2.0 library. All development was done in Linux, and the project was later "ported" to Windows in the course of two days. Printing and some obscure font sizing problems required a bit of meddling, and several wrong assumptions and oversights were uncovered in the porting process, which turned out to be genuine errors in the original code. But all in all the project was easily converted from Linux to Windows with minimal effort.
The project (producing a 4 MB binary) is still being developed, in Linux, and regular compatibility testing is being done on the Windows platform mostly using vmware. All in all the money for the Windows Qt License and the vmware was well spent, as developing in the Linux environment still is much more comfortable, and debugging is easier, despite the shortcomings of the g++ compiler pointed out in the original article.
© Copyright 2000 Kristian Köhntopp
Hey, there.
I saw your response to my article on Slashdot:
(http://slashdot.org/comments.pl?sid=00/10/01/1422 222&cid=16)
Just wanted to let you know what I think about performance:
1) GTK+ tends to use a lot more stack space for signal handling, mostly for making more function calls. You can get a good 13-20 stack frames deep in signal handling. This is, honestly, nothing, but it makes Windows a little faster in this case. This is partially due to the fact that GTK is a little more flexible, and partially due to the more-flexible design of X. To be fair, you probably aren't going to notice a difference even on a 386, unless you are passing a LOT of signals; and unless you are using some bogus message passing scheme to transfer a file via signals or some other insanity, it isn't going to matter.
2) Most of the programs that use MFC or GTK are NOT speed-dependent, at least not in their signal handling, so it's moot.
3) This leaves one area, and I cover it in the article; Bitmaps verses Pixmaps. Bitmaps are faster, but that's the tradeoff you get for being able to separate the X client from the X server. I tend to think that a bitmap will also be faster than a GdkImage (which is a wrapper over an XImage), especially over a network connection. If you were to do some serious animation in GDK using GdkImages, you'll probably find an equivalent program written to use Win32 bitmaps will be a little faster, but again, this is a contrived comparison, because for this, you'd really want to use DirectDraw and/or SDL or something else.
In short, if MFC is faster, it's not by much, and it's basically not a problem anyhow. :)
Hope that's helpful.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
"The reason for this is to give a visual hint as to what is a comment and what is actual code. The rest of the syntax highlighting is less important in this case. While porting, never delete a line of code. Comment it out and make your changes below it. If you need to, comment out whole functions. You are going to find that having an immediate reference to the original code is immensely helpful, but all that text can get very confusing. Syntax highlighting makes everything much easier. "
/* */ blocks.
I couldn't disagree more. Large amounts of commented out code make programs unreadable. Why was it commented out? Was it test code? An older version? Something that wouldn't compile but needs to be fixed? Who knows...often not even the orignal commenter after a few months. Don't think that you will go back in fix it because you will not. There is almost never time to fix badly written code that seems to work because there is always new code to write. You will net get time to look at it again until a bug pops up. And then you will be left wondering what in the world was in that commented code. Writing things the correct way the first time makes life much easier.
Comments should be used for comments. Some text explaining code. They should be used for turning code on and off (use precompiler statments, much more flexible) and they should not be used to save old code. Try using a source repository that has version diff support like cvs. This is a much cleaner way to see what you had before without leaving your old code lying around in massive
As for comment syntax highlighting being the only usefull part of syntax highlighting, I have to disagree again. I like to see different parts of the lanugages syntax in different colors. Hence the name "syntax" highlighting, not comment highlighting.
-- soldack