These 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 coveres 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).
Migrate Win32 C/C++ application to Linux on POWER
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’ve read both articles.
2 huge problems:
1. Its all low level stuff – no actual UI stuff so you’d better hope that the code to be ported is written with a rigid document/view architecture yet uses no MFC. How likely is that?
2. The “port” is a re-write. It amounts to a whole new application.
If you need to port, might I suggest WINE would be a better bet?
I have gone through this exercise before. 1st one should goto http://sources.redhat.com/pthreads-win32/ and try to get their win32 mutex to migrate over to pthread. You will be comfortable debugging on win32 and you will have access to most of the pthread* functions.
Then try porting to *nix – it is much much easier.
Unless I woke up today in an alternate universe, the Linux code for IPC from part 2 will never work:
if( ( semKey = (key_t) atol( “My Mutex” ) ) == 0 )
return RC_INVALID_PARAM;
atol will obviously always return zero, since the string “My Mutext” doesn’t begin with a number.
Too bad really, since I faced exactly this problem a few months ago. In the end, I just put the port on ice.
The high-level stuff is easy. There are plenty of cross platform toolkits that Windows users out there may have used, and all the GUI toolkits for Linux come with complete documentation. Certainaly, there’s no possible way of creating a one-to-one correspondence for GUI actions.
It’s the low-level details that are hard, and you don’t program on Windows for long before you come in contact with them. If you ever want to launch a program and wait for it to finish (not an uncommon thing) you need to master CreateProcess(). The same goes for threading and DLLs. I use Delphi, but in version six at least, the Delphi TThread class does not work in DLLs[1]. I ended up having to use BeginThread (a Delphi wrapper) and WaitForSingleObjectEx().
For a professional Windows Developer, this stuff is pretty interesting, even if a lot of the “GUI” toolkits now provide high-level wrappers.
[1] Delphi’s TThread relies on Windows message passing, the semantics of which are different in the context of a DLL to those in the context of an application
Listing 14. Win32 sample code
#include <stdio.h>
#include <stdlib.h>
#include “windows.h>
That last line is… hmmmmmm
Basically no, it’s not much use. The vast majority of Win32 apps use some kind of GUI, and indeed far more API services than just the POSIX equivalents. For that matter, how many interesting Linux programs use only POSIX APIs? Virtually none.
IBM do not cover using Wine here because they have some absurd allergy to it which they cannot explain for “legal reasons”. For instance their migration red book mentioned it once, in a derogatory manner. I don’t think anybody really takes IBM seriously in the Win32->Linux porting business, as they are apparently living in a dreamworld where everybody will rewrite their apps from scratch onto Linux/PPC. Not going to happen.
Others have already pointed out a few mistakes, here are a few more:
The DLL initialization function is called DllMain, not _DLL_InitTerm: I am not sure where they got this name from but it’s by no means the standard
They leak the process handle in their “terminate process” example:
if(DuplicateHandle(OpenProcess(PROCESS_ALL_ACCESS, TRUE, processId)
but the return of OpenProcess is never closed.
They do it again in the GetExitCodeProcess example.
They state that it is recommended that a thread terminates itself using TerminateThread, but the use of this API is never recommended as it kills the thread dead and can corrupt internal OS state (don’t even think about doing it on another thread …). They “map” it to pthread_cancel even though the semantics are totally different: pthread_cancel aborts the thread at the next cancellation point, not straight away.
They claim sched_yield is a suitable mapping for SleepEx, even though they do totally different things.
I didn’t review the other bit, I think I proved my point. These people are in no way experts in porting Windows software to Linux. There *are* people and companies out there who can help those who want to do real ports (of real, non toy apps).
“IBM do not cover using Wine”
There’s a good reason for that, as it won’t work. Wine Is Not an Emulator. POWER isn’t x86.
Correct, but Winelib is portable to PowerPC and allows you to recompile win32 apps as Linux/PPC ELF binaries.
“Correct, but Winelib is portable to PowerPC and allows you to recompile win32 apps as Linux/PPC ELF binaries.”
Theoretically. However, for anything beyond a fairly basic set of Win32 calls, you’re going to need an emulator.
No, not theoretically, in practice. Why do you think it doesn’t work? I can assure you it does.
” Why do you think it doesn’t work? I can assure you it does.”
Only for the subset of the available APIs. MFC support, for instance.