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

Re:Portable code

[PhrostyMcByte]

It's not really that hard if that's what you have in mind. Things like Boost [boost.org] can really help, if you can convince whoever your coding for that portability is a good thing.

The problem usually comes when dealing with the GUI or other slightly lower level system functions which sometimes can't be wrapped elegantly.

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

[ottothecow]

In my little experiance, I can tell you that the portability of code has much to do with its complexity and what it works with (and the level of the language).

If to systems have very similar network protocols (as most do), it becomes trivial to write a cross platform app that mostly deals with the net in a higher level language. But when you try to optimize it more and more or start linking it to more unique parts of a system (cocoa for instance), the process becomes exponentially more difficult.

Repeating libraries across systems helps this as show by wine, but then the software is nolonger running native to the system, it thinks that it is still running on a windows box.

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:Portable code

[CodeBuster]

The problem is with code that depends upon services and libraries provided by the platform in question and which vary from platform to platform such as graphical user interface and threading code. Since many applications provide either graphical user interface or threading or both and make use of other features which may not be common across platforms it is not generally possible to separate certain important parts of the code from the target system. This means that while some parts of the code, which are not dependant upon system specific resources, may be reused there are still major portions that will have to be rewritten (i.e. ported) to new platforms. Graphical user interface code especially tends to be verbose and tedious to rewrite multiple times on different platforms. Perhaps this helps you to have a better understanding of why porting is an issue.

Why Not Port Wine?!?

[vinn]

I don't get it. IBM seems to have some massive aversion to Wine. It seems to me the easiest thing they could do would be to port Wine to the Power architecture. It would consume a little time, but surely nothing as suggesting every application developer rewrite massive parts of their Win32 app. These articles basically suggest an app needs to be rewritten from scratch, which will immediately make any ISV laugh at Linux on Power. (Why would you bother porting a Win32 app to Power? Why not just keep using a cheap Intel box running Linux?)

Winelib was specifically designed to help with porting and you can do it tiny controlled steps:
1. Port from MSVC++ to the MinGW compiler and develop things like a Makefile.
2. Test the app.
3. Port the code from Windows to Linux (not as trivial as you'd think - there are problems with case sensitivity, etc.)
4. Test compiling.
5. Finish compiling using the custom Wine tools, such as winegcc (a wrapper around gcc that makes it behave like MinGW).
6. Test your Winelib app.
7. Begin ripping out chunks of Win32 specific code and replace them with native equivalents - Wine dialogs for KDE/GNOME ones.
8. Test

That's a valid and controlled migration path. Asking developers to basically rewrite massive chunks of code involving threading, memory management, and other such exciting things is a nightmare. Oh, and after rewriting you get to debug it all. Would you trust an enterprise app that just had it's whole threading model replaced?

The part I find amazing though, is just how much they haven't addressed. What do you do when your app relies on COM? What about Windows common controls? What about networking?

Anyway, it looks like IBM missed the ball - a few engineers porting Wine to Power could have solved many of their migration issues. It certainly would have solved every single one mentioned in these articles. Instead they want the software developers of the world to take on the task of rewriting their apps.

Re:Programming in C++ on Linux

[spectecjr]

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). At home, I'm using Visual C++ 6.0 Learning Edition that was provided by the Deitel and Deitel book. 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).

That's because you're running it under the debugger, and the assumption is that if you want it to stick around, you most likely have a breakpoint set somewhere.

Run it outside of the debugger - namely, by hitting CTRL+F5, or the "!" icon - and it'll run and when it terminates it'll ask you to press a key before finishing.

There you go. Learn your tools, and you'll find it much easier to use them.

Re:Why Not Port Wine?!?

[bombshelter13]

Wine emulates the Windows API... it does not emulate the x86 instruction set.

So even if Wine was for some reason compiled to run on Power, you'd still have to add something to emulate an x86 chip.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Programming in C++ on Linux

[vistic]

If you're programming a simple program in Visual Studio and it won't compile when you try doing it with gcc/g++, it's probably a very simple problem.

Your main in Visual Studio is probably "void main(void)" and returns nothing. To compile it in gcc, declare "int main()" and make the last line of main "return 0;" and it will probably compile.

Where did this come from?

[bigberk]

And what the hell is POWER and pSeries? I'm pretty much going to ignore this article. I've been writing win32 software for quite some time and am seriously fed up with that platform. Rather than tweaking my software so that it works with Wine [winehq.com] I'm much more interested in rewriting the GUI from scratch using wxWidgets [wxwidgets.org]. With a wx based application, you can then compile it into native Linux (GTK+), native win32, or even Mac OS X apps. To me that seems like the most promising route. I've used some wx based applications like Audacity [sourceforge.net] and they're just amazing, really look like they belong on each target platform.

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.

How to port CLI programs to OS 9

[hunterx11]

#include <SIOUX.h>

SIOUX basically just creates a simple MacOS 9 app with a window that acts as a console. Just add that, and standard I/O will behave almost exactly like it does on a *nix machine.

binary semaphore and mutex is not the same !!!!

[kemelma]

The second article "Migrate Win32 C/C++ application to Linux on POWER, Part 2: Mutexes" worth nothing, since you can't use semaphore (SysV semaphore) instead of mutex. It seems that the author do not know/understand the very basic difference between binary semaphore and mutex - and the difference is that there is no owner for semaphore and there is always owner for mutex. This means that once mutex taken/locked, only the thread/process which holds the lock able to release the lock, and this is not true for binary semaphore ... since it has no owner and any process/thread can unlock it.. I can even say that the example demonstrated in second article is dangerous.. Since it leads to misunderstanding and production of wrong/problematic code. At the moment there is no standard way to map Wind0ze inter-process mutex to Linux, this could probably be done using FUTEX API, but it is still changing, not standard and not well documented. Regards, Mike

Re:Where did this come from?

[d1v1d3byz3r0]

POWER = the PowerPC architecture
pSeries = the line of IBM servers that use the PowerPC architecture

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.

Direct X is not much of a problem.

[Anonymous Coward]

http://sourceforge.net/projects/dxglwrap/

Just expand dxglwrap to incude the functions you use. This is Direct X to opengl. Note there are performance problems ie Slower.

The trick is having a platform independant lib. Openoffice and Mozilla depend on a corelib system.

Note porting from Linux to Mac or Amiga is not a problem. It is just porting from windows due to no standard compad because they did not want it.

Only direct hardware access software not access by a standard lib have problems. Ie direct device access. This is they way it sould be.

I18N - UTF-8 vs UTF-16

[KidSock]

One notibly important difference between Win32 and Linux is that the internal Unicode encoding is UTF-8 as opposed to UTF-16LE. This takes some getting used as it requires special consideration when working with text (e.g. when iterating over individual characters). I have prepared a document [ioplex.com] and a text.h [ioplex.com] header file [1] that could assist people with porting Win32 applications to Linux. Or at the very least it explains how to maintain I18N support as you migrate code.

[1] The header is part of a library but you can easily remove the library specific #defines.

int b[0] when you mean int* b is a *bad* habit

[The Darkness]

In gcc declaring an array of 0 length does not allocate space for the pointer! It's basically an inline memory pointer. Given:

struct {
int a;
int b[0]; // inline ptr
} test;

Assuming a 4 byte int and the object is at address 0. (yes, yes, NULL pointer and all that rot)

sizeof(test) = 4
&test.a = 0x0
&test.b[0] = 0x4
&test.b[1] = 0x8

One use is to allocate the memory yourself and then use the struct to map that memory. The sizeof() would give you the header size. Then (sizeof(header) + allocated data storage) is the total size to alloc.

See: Zero Length (gcc) [gnu.org]

IMO, it is a very bad habit to use "type name[0]" when you mean "type* name".

Doing what you claim (sorry, you're AC) is the "Microsoft way" will cause memory corruption in GCC.

Re:Portable code

[Yokaze]

Well, since

int a[N];

is an array of fixed length N, I'd acutally expect the compiler to issue a warning on the following lines.

a[0] = 100;
a[1] = 200;

If you want dynamic sizes in C, you go through pointers. So

int *a; /* will use as a[n] later */

would be correct.

If you find the latter lacking the expressiveness, go Hungarian,

int *prgA;

but don't abuse a unportable laxity in certain compiler. The reason should be obvious from the existance of the grandparents post.

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.

Testing

[Mike McTernan]

I cant write code myself, so obviously there is a lot that i dont know. But is it really that hard to write code that is portable?

Part of the problem is that unless a developer tests their code on another platform, you don't know if it is truely portable (unless you are writing a pretty basic application that is compiled with -ansi -pedantic). As you can imagine, a lot of developers will not take the time to do this testing, maynot want to support other platforms, or maynot own other platforms on which to test their code.

Re:Portable code

[DrXym]

Take a look at what Mozilla does. Basically it uses the same build system (& autoconf script) for Unix and Win32 but it invokes gcc (or cc / icc etc.) on Unix and cl on Win32. It manages this trick by using lots and lots of macros - project makefiles use macros to specify paths, libs, targets etc. and pull in global rule files to turn these into compiler switches.

Building on multiple compilers also requires writing code to the subset of functionality common to all of them and avoiding dangerous stuff like STL / exceptions etc. Instead of STL, Mozilla uses its own string classes and portable functionality for threads, collections, memory allocation etc. exposed by the NSPR.

Re:"windows"

[johannesg]

Here's an argument or two against HN:

- HN seems, for many people, to serve as a replacement for the actual name. It is easy to write psz1 and psz2 when you want two pointers to zero-terminated strings, but really - I'd rather have their meaning than their type. You may argue that this is simply bad usage (and I'd agree) but I've seen too much code by now that does this to believe it is coincidental. Coming up with good names for variables is hard. Once you have a few characters, even if they don't mean much, people tend to stop thinking and just use it.

- HN adds long strings of unpronouncable garbage throughout the source. That decreases general readability.

- When a variable changes type, you should also rename it everywhere it is used. People tend to not do this, resulting in a system that actually gives the wrong information.

- HN places a great deal of stress on variable type. In my not so humble opinion type is important, but not quite _that_ important. In reality I find myself caring about meaning, then about scope, and finally about type - in that order. And you should be thinking "objects" anyway, not actually caring about type since that's all encapsulated.

More here [triumvir.org]...

Re:Where did this come from?

[Anonymous Coward]

wxWidgets does a lot more than just GUI. It also includes threading [wxwidgets.org] (including mutexes and semaphores), collections and data structures, file I/O, networking...pretty much everything you need to write a portable application. It's a nice library.

Yes and yes (and no)

[Anonymous Brave Guy]

That's a fallacy. Windows hasn't had anything resembling a consistent look and feel since Windows 3.1, if even then.

While what you say is true to an extent, I think you're ignoring a valid point. Sure, Microsoft plays fast and loose with its own apps, particularly the menu, toolbar and open/save dialogs. Others tailor the interface somewhat as well. But the vast majority of the conventions -- the things an average user will just assume to work -- are the same in pretty much all native Windows apps. A right-click brings up a context menu. You save your work by going to File->Save, and you'll find the Open, Print and Exit commands in the same place. The max/min/restore buttons are at the top-right of the window if applicable. And so it goes.

Some variations on the theme work very well. I was impressed with the simple but effective variation Firefox has adopted for its "find" feature, for example. Others suck: after my first experience using the GIMP on Windows, when it insisted on trying to use completely unfamiliar UI conventions, I gave up.

But the bottom line is that most native Windows apps do have a high level of UI consistency, and if you're going to vary the theme, it should be for a clear reason (such as the Firefox feature I mentioned) and not just because you're developing an app with an inadequate toolkit that can't handle native widgets properly.

Native look and feel

[dustmite]

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.

You are 100% right --- ported apps should have "native look and feel" on each platform! A good cross-platform API that has been designed with this goal in mind since the start is wxWidgets [wxwidgets.org].

Re:Where did this come from?

[dustmite]

Firstly, simple things like spawning threads/processes are typically the least of your worries when porting a Win32/MFC app, because these are small simple APIs with no or little dependencies and easy to abstract. It usually takes a few hours to give these wrappers and add a few simple preprocessor directives (e.g. #ifdef WIN32) to compile the right implementation on the right platform. GUI stuff is usually the big pain.

Secondly: I wonder what all these classes are then: wxCriticalSection, wxThread, wxMutex, etc. wxWidgets covers a lot of stuff, not just UI stuff. We use it for our apps, and it really is a great solution, not only is it a well-designed easy to use API, but has "native look and feel" on each platform.

Re:Portable code

[arkanes]

Portable GUIs aren't too hard these days, with several high quality toolkits. Writing these toolkits is much harder, but GTK and Win32 are similiar enough that it's not too hard. Sockets are pretty easy at this point, although there's some behavior differences that can bite you. Threads are a big problem, Linux (and Unix) threading has traditionally sucked, and while Linux has a high quality system now I don't know that any of the cross platform libraries take advantage of it.

Reliance on COM/ActiveX controls and libraries can make porting quite a chore - even when similiar functionality exists on Linux (and it usually does), the API is totally different and that affects the basic application architecture..

All my desktop apps are totally cross-platform

[Anonymous Coward]

Because I use REALbasic [realsoftware.com] I can deploy my desktop applications on Windows, MacOS Classic, MacOS X and Linux by selecting target platform(s) and pressing a button. The finished apps do not require an installer (everything is in the executable.) REALbasic isn't suitable for everything, but more than adequate for the average desktop program. It has a Visual Basic Project Converter and a nice IDE. It also has OOP RAD. I'm done with C/C++ hell.