Migrate Win32 C/C++ Applications to Linux 393
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)."
"windows" (Score:5, Insightful)
Re:Portable code (Score:5, Insightful)
Re:OS X? (Score:2, Insightful)
OS-X has the market share of Linux with the cost of Windows. If you want a Server, Linux is a better option. If you want a desktop, Windows generally wins out. Why the hell would it be smarter to "move apps to OS X"?
My Java Programs Port Really Nice (Score:5, Insightful)
Apoptosis
Re:Portable code (Score:5, Insightful)
Re:Programming in C++ on Linux (Score:5, Insightful)
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.
Good For Porting Example Code (Score:1, Insightful)
In reality, any large codebase will interact with APIs that don't have any mapping to Linux APIs, such as GUI components, services, and the registry. I can't think how these articles would be useful without wrappers for the above types of functions, and anyone familiar enough with Linux and Win32 application developement to write these wrappers will already know the equivalent Linux functions for Win32 functions.
To make matters worse, the first article is riddled with typos.
Should be: Migrating an App the Worst Possible Way (Score:5, Insightful)
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.
Re:Programming in C++ on Linux (Score:2, Insightful)
I take it back when I said "C++ is not supposed to be portable." It really depends. Straight C++ with no OS specific calls should work just fine on any platform. (You'll have to recompile it of course)
If you are having problems, make sure that there aren't any OS specific calls being used.
Re:Why Not Port Wine?!? (Score:3, Insightful)
Stop thinking purely as a techie/develper for a second, will you? THINK for a second about the whole, big picture, not just implications for developers.
IBM is pushing Linux, has it's own line of pretty nice processors and just sold off it's PC division. And now they want native ports of applications to thier chosen OS and platform. Hmmmmm...
I'm no business genius by any stretch, but do you see any place for Wintel in the picture that's being painted?
Soko
Re:Portable code (Score:5, Insightful)
Re:Portable code (Score:3, Insightful)
Neither Linux nor FreeBSD have the right to complain about portability because neither strictly follow the Single Unix Specification.
Re:Portable code (Score:2, Insightful)
The idea being that all of the portability issues will be confined to the interface layer. Moving to a different platform, or even tracking changes to an existing platform, should then have no effect on the majority of program code, since it lies outside of this layer.
That's the theory. In practice the effort required can vary a lot from one application to another. The easiest cases are operations which are to be expressed have fairly conventional meaning, for example getting a list of network interfaces from the system. Conversely, the most challenging cases involve fundamentally dissimilar models or capabilities, or else semantic complexity and context that has to be carried around.
The strategy for the first alternative, if you're committed to portability, is to restrict your design to a modest set of platform capabilities. That's always a good design discipline anyway, so I think you actually come out ahead if you think in terms of portability for any design project, excepting perhaps proofs of concept and other transient projects.
The second alternative is the really expensive one, since what you're really doing in the interface layer is building some kind of elaborate context management system on top of some other elaborate context management system. And I think this illustrates the point being made by the parent in saying you have to be expecting the contexts you want to support.
Re:But... (Score:2, Insightful)
Re:Should be: Migrating an App the Worst Possible (Score:3, Insightful)
Re:Stupid question (Score:0, Insightful)
not much help (Score:3, Insightful)
For similar app under linux its easier to start from a scratch and just lift the parts of the code that are separate classes/libs with no or little platform-specific dependencies.
Yes and no (Score:5, Insightful)
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.
Re:Should be: Migrating an App the Worst Possible (Score:2, Insightful)
Of course it could _help_ in migration even with the source. You could partly port the application and partly extend wine until it ran the application
Re:Portable code (Score:3, Insightful)
Cheap POWER? (Score:4, Insightful)
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.
Re:Why Not Port Wine?!? (Score:4, Insightful)
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.
Re: hungarian notation and newbies (Score:1, Insightful)
Note: You're also very likely to find very beautiful, very badly written linux code that uses prfx_lwrcs notation. Why? Linux examples are in that style, and linux newbies have access to the indent program.
In conclusion: Newbies will be newbies. Don't judge a style based on what a newbie can break with it.
Re:Portable code (Score:3, Insightful)
Contrast that with Win32 vs Linux where the API is different, the compiler is different, the build system is different, the underlying OS is totally different etc.
Re:binary semaphore and mutex is not the same !!!! (Score:1, Insightful)
Re:Yes and no (Score:5, Insightful)
That's a fallacy. Windows hasn't had anything resembling a consistent look and feel since Windows 3.1, if even then.
Even Windows applications made by Microsoft don't have a consistent look and feel. IE draws its own widgets. Office not only draws its own widgets, but it drastically changes those widgets with every version (fyi, Office XP was patterned on a theme for the WinXP beta that MS later decided not to include in Windows). Same goes with Windows Media Player--it's even less consistent than Office. Visual Studio does the same thing--try running VS2003 on Windows 2000 and you'll see what I mean.
Speaking of Office, not only does it draw its own widgets, but it creates its own open and save dialogs. Office 2000's open and save dialogs look like the Windows 2000 dialogs, but they still look like the Windows 2000 dialogs even on older versions of Windows. "Older versions of Windows" also includes Windows NT 3.x. Try running Office 97 or 2000 on NT 3.x and note the stark contrast between Office's 3D widgets and NT's fugly flat widgets.
Also, I'll add that some of the most popular non-Microsoft 3rd party apps do this as well. WinAmp was the most popular media player on Windows for a long time, and it never had anything remotely resembling the Win32 widgets.
Hey! (Score:2, Insightful)
*imagines a crocodile picking off Mr. Iwritespam Formoney while he's trying to port "New Smileys For Your Computer!" to Linux
Re:Portable code (Score:5, Insightful)
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 [wxwidgets.org] ... 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.
Re:Portable code (Score:1, Insightful)
Sadly, not as good as you might think. All non-standard toolkits - and Java, GTK, and
For traditional CD-based apps, or large apps where the toolkit is not disproportionately large compared to the program, it can make sense. But for most people it just doesn't work.
Even wxWidgets, which proudly proclaims that it uses native widgets, adds a couple of megabytes to the download. That MORE THAN DOUBLES the size of most programs. Doubling the size is not exactly convenient in a world where many people still use dialup connections...
The real falacies (Score:5, Insightful)
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?
separate the GUI and the activity (Score:3, Insightful)
What I should have done is totally separate the GUI and the application entirely. I could rewrite the GUI in in a portable framework on linux faster than any port of the Windows software. I could then install the framework on all the windows desktops and have them work the same. Not port but total rewrite in a portable framework.
Problem with a lot of GUI code is that the business logic becomes intertwined with the GUI logic. It is incredibly easy to do especially with the Rapid Application Development (RAD) tools and this cause nightmares in porting if your RAD tool is not cross platform.