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

Portable code

[OneArmedMan]

I was thinking about this today. everyone complains that there isnt *Insert Random Program HERE* available for Linux, isnt part of the problem that most code being written isnt portable? eg its too dependant on specific libraries.

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?

Thoughts , Ideas?

Comments and/or Flames should be posted below this line .

---------------------

Re:Portable code

[Anonymous Coward]

Portable code can be more time consuming to write, and the resulting application is sometimes less efficient than if it utilized APIs more heavily integrated into the operating system.

Re:Portable code

[KiloByte]

I'm working on something that's supposed to be über-portable -- as the very minimum, I want Win32 and everything that can be called Unix.

Yet, I rely on autoconf, which, even though extremely portable among unices, depends on some type of a shell... uh oh. Show me a shell on Windows :p

So, I'm ending up with something "portable" that requires GNU tools to even build for win32 -- either CygWin or cross-compiling. I even use gcc-specific flags for the win32 binary ("-Xlinker --subsystem -Xlinker windows" to avoid spawning the console window).

What way would you suggest to have both Un*x and win32 native support from the same source tree in a clean way?

Re:Portable code

[mikael]

Put me in this category. I use both Windows and Linux and would love to partially rewrite some of my best selling apps so that they run under Linux. But I'm not sure whether it's worth the effort.

I've been through this phase. As an experiment, I ported one of our in-house tools from MFC to Qt. The stages are quite straightforward:

(1) Split your MFC application into shared libraries and the MFC event handlers. Your shared libraries should be independent of all MFC constructs (CString etc...). The MFC event handlers shouldn't do anything more than make API calls to your the objects defined by the core libraries, and change the state of other MFC widgets.

(2) Port your shared libraries over to Linux. You'll probably end up shuttling the libraries back and forth to ensure any changes made haven't broken anything on the other platform. Both GCC and the MFC compilers pick up different errors, so if your code can compile without warnings or errors on both platforms, it should be fairly reliable.

You can use 'automake' to automatically create the Makefiles for you.

And you can also create command line versions for script file testing.

(3) Port the MFC interface over to Qt using 'designer'. For an application with six dialog windows and one main window, this took me a week working part-time. This will also include icons
and any custom widgets you might need (eg. Combo boxes, List boxes). You'll probably want to look at using the 'configure/make install' framework to allow you to clean and automatically rebuild your application.

Once this stage is complete, you will have an empty application shell ready to be linked
with your shared libraries.

(4) The final stage is to stitch together the Qt GUI interface with your shared libraries. This is probably the most time-consuming part.

All of this took around me around three months working part-time while learning Qt for the first time.

The benefits are:

1. Your source code is more modular.
2. Your source code has been tested with more than one compiler.
3. Your source code is now platform independent.
4. Trolltech can only place distribution rights on the GUI of your application.

Design for Portability

[RotateLeftByte]

IMHO, the ease or difficulty in porting an application really begins at the design stage. If you design for a standard(GUI apps excepted) like POSIX then porting is much easier. Granted that many things on Windows become more difficult but usually not impossible. I have written many apps over the years for diverse platforms and usualy only have to rewrite one module that contains the platform specific code. For example, calling SYS$ & LIB$ functions on OpenVMS. However, whe it comes to the GUI then things get a lot more indeterminate which it where the auhor is coming from. There are some tradeoffs to be done here. Either:- 1) Design for performance 2) Design for portability If you take the former and for example, design the GUI using Visual Studio tools then you will get something that will work and perform well on Windows but moving to other platforms is nigh on impossible. So, where do we go in the future? Well Microsoft would want you to go down the .NET route but they ave singularly failed to release it for other platforms. Mono is there but it does not have the cachet of Mictosoft support which is needed in many companies. Java is pretty portable and there are lots of skill out there to continue development. There are other niche languages & environments that are portable but these have their roots in OSS and sometimes trying to itroduce something like Python into a totally Microsoft shop is like trying to make the Red Sea part. {I know as I tried this and was regarded as a subversive influence.} The overall situation is cloudy but there are breaks of sunlight where Portability is a prime consideration and the company can reap the benefits in a MultiPlatform world.

WINE compile against

[Anonymous Coward]

I am not that familiar with WINE, but isn't there a package to install on Windows that integrates nicely with VisualStudio where you can simply check to see if your application will also work on Linux under WINE? That way, it would make developers conscious of whether they were using libraries that would make it incompatible with WINE. Is this already possible?

Tell that to Oracle

[mangu]

Well, there are some companies that do sell software for Linux and get a profit from that. But they must make some adaptations to their business models. It's not that Linux users don't want to pay for software, the problem is that Linux users are used to test their software before buying. With free software one can download lots of programs just for testing and settle on the one that's best suited for the purpose. With commercial business software, one usually goes through a much longer evaluation program before buying, because there's no turning back once the purchase is done. So, if you want to get a profit from Linux software, be prepared to offer much better demos than the usual crippleware.

And source code delivery has nothing to do with it being commercial or free, in either the "beer" or "speech" sense. When the software is important enough, having the source code is an absolute necessity which every system administrator will insist upon. There's a disturbing meme going through the industry that "COTS" (commercial, off-the-shelf) software can be sold without source code. That's bullshit. When your company's business is totally dependent on a system, you must have access to the source code, no matter what the licence is.