Slashdot Mirror
Migrate Win32 C/C++ Applications to Linux
An anonymous reader writes "This series of articles helps you migrate your Win32 C/C++ applications to Linux on POWER. Win32 C/C++ Apps to Linux Part-1 of this series covers the Win32 APIs mapping to Linux on POWER regarding the initialization and termination, process, thread, and shared memory services. Win32 C/C++ Apps to Linux Part-2 illustrates how to map Win32 to Linux with respect to mutex application program interfaces (APIs)."
The hardest part of porting to LINUX will be refactoring all of the GUI stuff.
That's what alot of FreeBSD people complain about. Programs for Linux are supposed to be so portable, but many times they are just as dependent as their Windows brethren.
Just moved J2EE webapp from windows to linux. Really nothing to it ;)
Apoptosis
I don't think portability is such a big problem for somebody who has time and resources. I think the biggest problem is people who make software for money are concerned that Linux users want everything to be available for free. And on top of that, a lot of them want it to be open source. So anybody who makes software for a living is going to feel like Linux is a hostile or unprofitable market to enter, unless they're making corporate software.
I'm taking a C++ class at the local college that's being taught by the Unix guru. The class is using Visual Studio .NET as the IDE (which the instructor is not familar with and is threatening to go to Linux instead).
;) I would like to learn how to program basic C++ fluently on both platforms.
No offense, but anyone who can't figure out how to use and become familar enough with the visual studio IDE to use it in a teaching environment shouldn't be called a guru of anything. It's extremely simple to use until you want to start doing very complex things. And that's when you start pining for makefiles. I can't imagine you're writing anything that complex for (what your post would indicate is) an introductory c++ class.
Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).
Actually, there is. Where it is buried in the settings? Couldn't tell you off the top of my head, but here is something for you to try: Navigate to the directory where the exe is being dumped and run the thing from the command line yourself.
Anyway, I tried compling the sample programs under gcc and g++ on my Linux file server, and I get a lot of errors. I thought C++ (or at least, C) was supposed to portable.
Not familiar with the book, but unless it is doing something windows specific (and it may be) you should not have any trouble compiling simple programs under gcc and the MS c++ compiler.
Migrating a Win32 app the way they suggest is going to be painful and time consuming. In addition, there are numerous things that they don't mention, like associated performance costs: is creating a thread going to be more expensive or cheaper on Linux vs. Win32? Don't look to the article for the answer. It doesn't even mention the biggest parts like the graphics/windowing library.
Secondly, it is making a wild assumption that your win32 app is written in a that is conducive to a Unix/Linux process model. Namely that you spawn processes and use environment variables as opposed to having a message loop and handlers (the way most windows apps are written).
Third, if it was so straight forward to port a Win32 app, why not just write a library that maps the windows calls onto the equivalent Linux calls instead of manually changing all your source?
Finally, why not look at a binary solution like Wine first and not touch your source at all?
This is the worst way migrate app. The source works and manually mucking with it like this is a good way to break it and introduce all sorts of bugs. Look for a binary solution like Wine. Then look to see if somebody implemented a Win32 on Linux library next to recompile (like Cygwin in reverse). Then, the last choice is to factor out your platform specific portions of your code and replace them with OS neutral calls. But beware of the performance of your app, it will probably take a hit. But, hacking apart your app like this makes me cringe.
Facts are meaningless. You could use facts to prove anything that's even remotely true! -Homer Simpson
Nope, it's because people hard code paths (and other distribution dependancies), use the innards of various structs, use /proc, assume the entire world is Intel, assume various GNU options are available for build - configure - install, etc.
Yes, but aren't those details Situation Normal in the *nix world?
Neither Linux nor FreeBSD have the right to complain about portability because neither strictly follow the Single Unix Specification.
The author might have meant: "Porting Windows programmers to POSIX" :-)
Writing perfectly portable code is possible, but as they say "there ain't no such thing as a free meal." Let's take your DirectX vs OpenGL example, just as a random example, to illustrate the problems.
1. It costs extra time and money.
And it costs time and money to also _test_ it on the new platform. Otherwise you won't even know what functions don't exactly work the same. Or you won't even know that the widget sizes are different on the other platform, and the whole GUI is a disfunctional piece of junk with truncated texts and buttons falling completely out of the dialog box.
(Writing the code is not the alpha and the omega, as you undoubtedly already know. Testing and debugging can easily account for 10 times more time.)
The promised DirectX-vs-OpenGL example: Now _Direct3D_ is pretty much an equivalent of OpenGL. No, not the same function calls, but you can get the same results.
But DirectX offers a lot more than that. Direct3D is just a part of it. You also get networking, sound, etc. If you wanted to stay portable and _only_ use OpenGL, you'd have to write all those extra bits yourself. Which costs time and money.
2. Performance problems, here we come.
Of course, you could just use a wrapper that encapsulates, abstracts and emulates everything. Proper software engineering, right? The problem is: it costs performance.
DirectX-vs-OpenGL fits nicely here too: as fate would have it, Matrox already tried handling that via a wrapper. Back in the days of the G100 and G200, Matrox thought the're smart. No use writing two different 3D libraries that do the same, right? So they actually wrote their OpenGL implementation as a wrapper around DirectX.
The problem? Performance was abysmal. No, not just bad. It _killed_ 3D gaming. With Doom 2 and such being the "killer apps" of video gaming back then, Matrox lost gamer market share (and game developper mind share) with both hands. And who rose like a star? NVidia, who to this day still has the fastest OpenGL implementation.
Just in case you wonder why no games are written using one of those wrapper libraries, now you know why. Because noone wants to make a game that looks like classic ass (low polygon count) or gets single digit FPS. Or both.
3. Those pesky users.
There's one thing that all these emulation and one-lib-to-rule-them-all apologists just don't get: reusing existing skills is good.
When Joe Average gets a Windows app.. actually, screw Joe: when even _I_ get a Windows app, I expect it to look and behave exactly like every other Windows app. No, I don't want it to look like Swing, I don't want it to look like QT, and I sure don't want Mozilla's skinned idiocy, and I'm gonna puke if I have to use another idiotic GTK file dialog in _Windows_, etc. I want it to look and _act_ exactly like one thing: the Win32 widgets. Nothing else.
And if I were on a Mac, I'd expect it to look and feel like on a Mac. I would _not_ want an app that looks and acts like Windows (e.g., wants me to right-click) in the middle of an Aqua desktop.
It's possible to get it right, yes. See for example IBM's SWT widget set for Java. But it's also quite the norm to get it awfully wrong: witness Sun's Swing.
A polar bear is a cartesian bear after a coordinate transform.
MSYS is what you are looking for.
A serious point, if IBM is really serious about people to port their Windows apps to "Linux on POWER" (which does have a nice ring to it) then why are all IBM's POWER based systems so expensive?!
;-)
Now Apple can make a PowerPC based system for £339 (BYODKM as Steve might say) why can't IBM create something similar? Preload it Linux and we'd all be happy little "porters". Now if they really wanted us to do this then a laptop would be really great. But presently IBM will only sell expensive POWER systems.
Now after you've ported your "killer app" to LoP, how the heck do you deploy it? On what? Some mega-expensive POWER Server? Doesn't IBM realise that Windows apps are usually run on the desktop or laptop? I mean they're not suggesting we're using Windows as a server OS are they?
PS. Anyone from IBM reading this - yes I would buy an IBM LoP box if it was sub £500 BYODKM.
... its true power lies in providing windows api's on linux that you can compile against.
As cool as that would be I seriously doubt people will get very far with this approach. There are too many libraries that WINE simply doesn't support without linking against MS' DLLs. There's structured storage, NDR / RPC, MAPI, workstation management and security network functions, etc, etc, etc. Sure they might have a few individual ops that have been cobbled together using libsmbclient or some OpenLDAP code but the API is not nearly as complete and robust as it needs to be to actually compile a stand alone binary that doesn't require emulation.
Reduced efficiency I'll give you, but because (and only because) Win32 and MFC are such mind-numbingly bad APIs, writing portable code can often be a massive time-saver if you use more well-designed libraries, like wxWidgets ... for our company's main project, I estimate that choosing wxWidgets over Win32 or MFC easily cut down development time by 30% (and that's in spite of our developers all having Win32/MFC experience). And as a bonus, our code is now only a stone's throw away from Linux and Mac ports, which we fully intend on developing.
No offense, but you seem to make two of them yourself.
1. Basically "if we don't have 100% consistency, we should go for 0% instead". Or, if you will, "bah, you already had a change of look-and-feel some 5 years ago, so suck it up and accept one daily, for each program."
Sorry, no. The real world isn't that clear-cut black-and-white. Sometimes you have to settle for "good enough" instead of "perfect".
2. More importantly, the underlying fallacy is "looks are all that matters." Seein' as what you came up with is flat buttons or different icons.
And that's not just a fallacy, it's also _the_ number one _failure_ of GUIs designed by programmers, graphics artists, marketting, etc. (Though each of them for very different reasons.) Generally anyone else who really has _zero_ clue about usability, and just thinks anything graphical will do.
What I'm more concerned with isn't "waaah, but they changed the 'new folder' icon in XP!" I'm more concerned with how things work. Which is why my point explicitly said "reusing skills" not "reusing graphics."
Take the Windows file open dialog for example. Sure, some apps might add a preview field next to it, or a couple of extra fields, but by and large it stayed the same since Windows '95. You can still do the same things (e.g., creating or renaming a folder right in the list), in the same way, in all apps that use it.
The important thing is: Once you've learned to use it once, you can do it mechanically, without even thinking about it. Even if you just bought/downloaded/compiled/whatever a brand new app, you already know how its file dialog works. That's one less thing to go through a learning curve about.
Now kindly open a GTK dialog box in Windows. E.g., open a file in Gimp. Ugh. WTF is that box? What was wrong with the "normal" box, that needed replacing? Or try it with a Swing app. Ugh. Why does everything look and act differently?
Try to answer those questions _without_ going into technical details about widget sets and libraries. Pretend I'm Joe Average, who doesn't even know what GTK is. And more importantly, who doesn't _care_ about such details. I just want to use the program, with a minimum of learning curve or thinking.
What was wrong, from a _functionality_ point of view, with the old dialog? What end-user functionality absolutely wasn't available through it, so that it needed a completely different dialog?
A polar bear is a cartesian bear after a coordinate transform.