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 point is one shouldn't need to generate (almost) any code. Never."
You don't need to generate code for an MFC app--it's just much easier if you do. Anyone can sit down and write an MFC app from scratch without the aid of a code generation tool if they so chose. Most would rather not.
"If your API needs exact the same code each time you want to make and MDI app then one should not make source code generator."
The thing is, if you're writing non-trivial apps, you don't need the exact same code every time. You need some minor specialization of the basic code. And this stuff gets tedious--very tedious--to write. Your idea of "new application.MDI()" is fine as far as it goes, but it doesn't go very far. What happens when you want a subclass of the default MDI? How would application.MDI() expose it's message handling architecture for the addition of new messages? How does one control the properties of the MDI window? There are lots of things that MFC can do that your application.MDI() approach couldn't. And that's where the complexity comes in.
Let's try not to let fact interfere with our speculation here, OK?
...MFC stuff doesn't abstract out well. If you use MFC and want to abstract out all but the UI, you're going to have a lot of translation layer code to abstract it. Why? Because MFC does a lot of stuff with strings and such that doesn't exist anywhere else but MFC (Like CStrings...) and you end up using them without an abstraction layer because the layer bloats up the code and makes it even slower than before.
The best policy for someone is NOT to use MFC- it's not the API for Windows, it's an app framework and a bad one for many applications at that.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Methinks you are a hypocrite - you want it free to use in your non free work. In short, a parasite.
KDevelop, btw, has app templates for GNOME apps.
As for KDE's programmers attitudes towards GNOMES programmers, who stole whose HTML renderer without attributing copyright, hmm? Hint - look for KDE names in GTKHtml
I agree that Wine is a bit "thicker" than other layers (mainly because the Win32 API encompasses a lot more than just widgets), but it's not like it's a whole layer thicker, so I don't think it's fair calling it "non-native".
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...
MFC generates Message Maps and macros rather than using virtual functions in its frameworks. The official Redmond Party Line on this is that speed is enhanced by using such an unholy mess. And speaking of unholy mess, sure it works, but you try dealing with scrolling views and having to convert back and forth between mapping modes and you're just about ready to scream "WHY DIDN'T YOU STANDARDISE THIS, CRETIN" at the nearest NT apologist.
GTK isn't OO either - it's a C API.
MFC's strengths don't lie in its technical implementation, but the fact that there is a half-decent application generator that spits out this code. If you want an application with a window, view, document, serialisation support etc etc etc all you have to do is fire up VC++ and run AppWizard.
What Linux development sorely needs is some kind of framework (Inti's a nice start) plus a half decent open source appbuilder that wraps around gcc and gdb. Would you like a default MDI application in KDE? BAM there you go, and INSERT CODE HERE. Ditto GNOME.
Freeing up the developer from pointless busywork is the key. Right click on the class, type in the function signature, BAM, there's your code.
I can here the vi guys choking right now, and some EMACS type is going to chime up that you can actually do that with some custom LISP script, but if we're going to try to leverage MFC leveraging what it does well is important.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
In recent work you've done for us, the quality has been slipping- oh, in spirit it's everything we could ask for, but if we may refresh your memory by this passage of 'Competitive Astroturfing':
Now, where do you get this 'kick in the teeth' language? Isn't that LITERALLY one of the examples you learned in training classes, almost a cliche? You know perfectly well that talk is for the management track, NOT undercover relations. So much of your post was in perfect form- the 'too busy hacking the Cue:Cat' (extra points for correctly spelling its name- elicits subconscious assumption of accuracy elsewhere), the '31337 H4X0R' (textbook assertion of the reality you're paid to present)... it's a shame you blew all this out of the water with your aggressive overtones. Please work harder at staying within the CA guidelines- it is important that this job be done RIGHT, as people are already beginning to not...Doh!
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.
Then I guess gcc is broken also. People can't use compilers other than gcc to compile the linux kernel because the linux uses non standard extensions that gcc provides and other gcc quirks.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
I am not joking. From the article:
DNA just wants to be free...
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...)
The article is full of twisted comparisons and faulty information. I develop for Linux, other Unix variants and also Windows 32. The first thing that jumped out:
"...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."
Am I missing something here? My customers and I want an application to work. Period. I don't give a flying fig if it "looks" like a Windows application. The "look" isn't whay I run Linux at home. The "look" provided by either Gnome or KDE or whatever is NOT the reason I run Linux, that's for damn sure. The ability to have a decent GUI and at the same time run all kinds of other nifty programs at the same time is why I run Linux. I only WISH the latest Mozilla milestones "looked" like the old Navigator.
And the MSDN Library consists of 3 CDs, not 2. He'd know this if he actually followed his own advice and kept one handy and used it once in a while. This guy is full of crap, IMO.
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.
Where are my moderator points when I need them?
By that definition, most environments are broken. There are Win32 extensions to perl, so that's a broken development environment, to give a less exotic example than the kernel. Java has the microsoft packages.
There will always be local extensions to your development enviroments. The trick is to know when to use them and when not to use them.
Maybe of greater concern is that developers are not usually very careful to ensure portability. Do you use sysconf(3), [f]pathconf(3), et al. a lot in your code? No? Do you still use strcmp(3) instead of strcoll(3). Anybody still using signal over sigaction (shudder!)? How about alloca, mknod, or vfork from BSD or [dej]rand48, popen, or remque from SYSV? Even ioctl is not part of POSIX.1 -- ever used it? Then don't worry about the development environment: worry about your code first.
Hi!
"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
But it all goes back to Microsoft's attempt to shut everybody out of Windows. Just like they did to J++, they have made the MFC and Visual C++ GUI classes so tied to Windows, its almost impossible to "digest" the code without 2 or 3 MFC and Windows API manuals. Thats why I have been programming C++ on UNIX for 5 years, and haven't written a line of Visual C++. I looked at doing a project in Visual C++ once, and soon decided that rather than waste 2 years of my life learning Windows API and MFC, I would just right the GUI portion in JAVA and do the back-end stuff in ANSI C++ on a UNIX. Got it done in a couple months. :)
Too bad the gaming industry can't come up with a standard, portable library tool-kit that they share and use for mutiple platforms. They would learn allot from taking an open-source approach. However, most of them guard their tools and programming methods so jealously, this would never happen.
Maybe there is an alternate universe where there is such a thing. ;)