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)."

Comments

Re:Portable code

[Lisandro]

Generally, the *code* itself it's quite easy to port (specially C/C++). The problems are the OS architecture and underlying libraries. Functions available in one can't be available in the other, or be so wildly different that rewriting them becomes quite a chore.

DirectX - OpenGL is a good example (for graphics). Both accomplish pretty much the same, have similar features and perform the same. Yet, telling OpenGL "hey, draw me a few polygons here" can be completely different than telling DX the same. Now, OpenGL is supported in Linux, so if your Windows program uses it, converting it to Linux becomes more or less inmerdiate (you'll still have to retouch here and there, but not much). Not the other way arround - converting DX to OGL might be doable, but doing it consistently all over big programs it's an awful chore.

This also happens in quite a few other areas, not all related to the so called "multimedia". For example, widgets (the windows and buttons drawn on screen) might be handled completely the same. Libraries allowing you to do similar things on both OSs can be completely different to implement. Audio, file management, program intercomunication, etc.

The way to deal with this is thinking ahead. It's actually not hard to write portable code - the problem is porting code which wasn't designed for it.

Re:Portable code

[chesapeake]

But is it really that hard to write code that is portable?

Well, that's an interesting question. My current work is probably pure evil in the eyes of most slashdotters - I'm currently porting a compiler/interpreter/virtual machine of a special variant of prolog from unix->win32 native code.

While writing c/c++ that's portable seems relatively straight-forward, there's lot of gotchas. Different compilers support standards differently, and GCC is one of the worse in some ways - it supports many, many extensions to the standards - what we'd normally bash Microsoft for 'embracing-and-extending'. As a consequence, code that heavily relies on these features can be somewhat involved to port to another compiler/OS. For example, GCC supports zero length arrays, which are currently causing headaches for me as I attempt to fix a garbage collector. :-/

Also, should you wish to interact with the operating system (ie: write any program more complex than hello_world.c), there is no choice - you must use the relevant api. If you look at the article, you'll see tables, with things like GetCurrentProcess() mapping to getpid() under unix. You don't have a choice which one to use under what OS unless you write a compatibility layer of your own.

And that's the whole thing really - code has to be dependant upon specific libraries if you value your time and/or don't want to reinvent the wheel. Thankfully, it appears that cross-platform libraries are starting to become a bit trendier (eg: QT, GTK, etc). Hopefully this will help here a little.

Should you choose a language like Java, however, these issues are supposed to just go away - a nice ideal... ("Write once, test everywhere", I believe ;-P )

(I would just like to add that I'd rather code C/C++ under unix with GCC any day - I'd just rather eat.)

Re:Why Not Port Wine?!?

[entrigant]

You missed the point. Unfortunately WINE has become known for being able to run windows executables on linux, when its true power lies in providing windows api's on linux that you can compile against. The point being you take your windows source code, compile it in linux, and link it to the wine libraries providing a win32 api in linux. If you do this, you don't need an x86 emulator because you have freshly compiled POWER code linked to WINE's libraries which provide a source compatible win32 API.

Of course the matter is oversimplified, and wine definately doesn't cover the entire win32 api yet. It can still provide an easier path than completely rewriting an app. I hope this clarifies things a bit about how wine can be used to not only port windows code to linux, but to linux on a different architecture as well.

Re:Should be: Migrating an App the Worst Possible

[cduffy]

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?

What do you think WINE is? It's exactly that library, plus a loader and relinker and other related tools. You certainly can compile win32 programs against it for porting purposes.

WINE is a binary solution only in the worst case -- if the port is being done by someone with the source, they can recompile against winelib and so be portable to non-x86 targets.

What about good old C++ abstraction and #ifdef?

[unkaggregate]

I regularly do this all the time: I write a basic main() routine for both platforms (these are usually console apps) then add #ifdef WIN32...#endif and #ifdef LINUX....#endif for each case. If necessary, complex functions are split off into subroutines, internal libraries, or C++ classes (and #ifdefd like so). Then just make a Makefile for each platform (For Win32, the usual .DSP .DSW duo as I use MSVC 6, and Linux a simple Makefile that includes -DLINUX in the CFLAGS) and compile for each.

The same can be applied to GUIs, though for Windows you'll have to write a WinMain wrapper.