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)."
...that sometimes during the process the stragglers fall prey to hunters.
Nope. It relates to porting Mac applications to run under Solaris. They just called it "Win32C/C++ Applications to Linux" to see if you'd ask a stupid question.
Worked brilliantly, too!
To fight the war on terror, stop being afraid.
The hardest part of porting to LINUX will be refactoring all of the GUI stuff.
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.
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.
But is it really that hard to write code that is portable?
:-/
;-P )
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
(I would just like to add that I'd rather code C/C++ under unix with GCC any day - I'd just rather eat.)
www.fearthecow.net
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.
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.
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.
The same can be applied to GUIs, though for Windows you'll have to write a WinMain wrapper.
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.
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.
I support the Center for Consumer Freedom