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

[Anonymous Coward]

No, it's not that easy. See, I've tried to get used to running Windows in User mode instead of the normal Admin, full access mode. There are a few applications that just won't run that way, you can argue they're poorly written, but that's how it is: such scenarios weren't expected by their programmers. There's no such things as natural consistency in programming, you have to be expecting the contexts you wan't to support.

Now, there are ways of doing code that is more easily portable, which is basically similar to coding your own sandbox. You can build your program on top of a layer of your own that serves as an interface with whatever API is needed. Make the internals of your actual program rely only on its own set of functions, not direct API calls.

Re:Portable code

[bigberk]

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

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 will want to release the binaries (versions for a few different libc's for example) and am definitely not going to be releasing my source code. btw I'm also an open source developer but I don't intend to make money off that UNIX software.

I'll bet there are tons of other programmers in my situation. For instance, Mac OS X looks like a more attractive destination platform for diversifying my market, rather than Linux.

Re:Portable code

[Anonymous Coward]

Depends on your software. If it's server or enterprise software, there's certainly a Linux market outside of the cheapskate hippies. However, if it's desktop software, make a mac port with a good UI and you might be golden (Mac users love paying for shareware).

Re:Portable code

[Spacejock]

Me too, although my apps are written in VB6 so the likelihood of me porting them is slim.
Instead, I've made a load of internal changes to make them wine-friendly. For example, ditching all my database code which used to run on the MDAC and JET runtimes - now I use flat ascii for small stuff and records/random access databases for the larger ones.

When I started programming I had 640kb of RAM to play with, which means I automatically select disk-based access when storage needs exceed about 10kb. Nowadays who cares if you load a 100kb data file into memory when the program starts, and write it out from time to time?

Re:Portable code

[Anonymous Coward]

GCC supports zero length arrays, which are currently causing headaches for me

Good thing, though. It's common in some places to write code like

int a[0];

a = malloc(sizeof(int)*2);
a[0] = 100;
a[1] = 200;

rather than saying

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

I used to work at Microsoft, and all dynamically-allocated arrays were declared as zero-length arrays rather than simple pointers. Always. (Well, that was C code; not sure what the C++ guys did.)

Re:Portable code

[mboverload]

The problem is, the whole reason the OS is there is to support programs. Sure, you COULD have the work processor have its own kernel and other funtions, but the developer leaves that ot the OS. It is the purpose of the OS to make it easier on the developer by including shortcut and other goodies. However, in this day and age of "multi-platform" support developers are being pushed away from that crutch (not that it's a bad thing).

Making a program mutli-platform is like using peanut butter instead of sticky notes. Sure you CAN do it, but taking the shortcut (using OS APIs and other thing) is how an OS is supposed to work.

Re:Portable code

[mboverload]

??? I thought that Photoshop was way more efficient/faster on OSX than on a Windows. I guess thats just Apple marketing crap then?

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

[DrXym]

That's not the point. The point is that the version of STL that ships with Visual C++ is different and behaves differently from the version that ships with GNU libc++ which is different and behaves differently from [insert commercial Unix compiler here]. Even versions of the same STL library differ (e.g. comparing VC98 to VC2002). Reconciling those differences (and incompatibilities) in Mozilla is a waste of time. Mozilla has to build a broad range of platforms, not just the small fraction that possess sane STL implementations.

For example, the STL that ships with VC98 is atrociously inefficient and non-compatible. It doesn't even support fundamental methods such as basic_string::clear. The string buffer allocation reallocs the buffer in fixed 16 byte increments - just imagine what that does for performance. I'm sure libstdc++ has had similar problems in various iterations too.

It's no good either to suggest moving to .NET 2002 or later (which does have better STL), since these decisions were made before such a product even existed. Nor can you insist that everyone in Unix-land upgrade either since they often don't have the choice. Besides, Mozilla now has extremely mature and robust string and collection classes of its own which negates any reason to use anything else. Not only are they mature but they're tailored for multiple purposes. For example, the string classes come in several flavours for handling stack and heap based memory allocations - no such concept exists in STL. There are other flavours for dealing with nsIMemory allocated buffers and so on.

Using STL would be to replace these classes with bloaty and general purpose classes from varying and incompatible implementations. It would be a lot of effort and would make the executable considerably more inefficient and larger than it already is. And to even use STL would require enabling rtti & exception handling on Mozilla which would bloat the code by another 25%.

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.

Re:OS X?

[Stevyn]

Yeah, but aren't most computers running Linux backend servers? In terms of desktop users that need program X, I'd imagine there are more Mac users than Linux users.

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?

Re:"windows"

[Anonymous Coward]

Use wrappers.

Or better yet, dont use a SYSTEMS language for APPLICATIONS, use C# on Mono and GTK bindings or something or Java etc.

C and C++ and so on are SYSTEMS languages and applications in usermode should sit on a VM really, welcome to the year 2005. Performance, please, thats an stupid argument, you can compile and not run in JIT mode easily with virtual machine languages, you just lose out on dynamic optimisations that any JIT compiler may have and son on.

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.

Re:Tell that to Oracle

[Ingolfke]

When the software is important enough, having the source code is an absolute necessity which every system administrator will insist upon.

You addressed yourself on this point... That's bullshit.

There's a disturbing meme going through the industry that "COTS" (commercial, off-the-shelf) software can be sold without source code.

Your wording implies that this is somehow a change, a new trend moving through the industry... yeah right. Open Source and commercial software are not new bedfellows, but neither is the idea that you keep your commercial code locked up as far away from the users and the competition as you can.

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.

What are you going to do with that source code? Wouldn't the issue be that you purchased a piece of software to do a certain task and it doesn't, so the vendor needs to improve/fix their software. Even if you did find a bug, why are you supporting the vendor's software by digging through their code to identify the bug? That's there job... that's what you paid for. And even if you did patch the issue and fix it yourself, what good would that do you because that would invalidate your support contract? So what's the point? I guess you could use the code to better utilize any APIs exposed by the vendor, but again, why should you have to... why don't the APIs work like they should and why doesn't the documentation explain how to use them?

Plus, this is really pretty impractical. Even in a scenario where you have access to all of the source code, like w/ a LAMP setup, do you really know enough to risk editing the code, recompile it, and run it in production system that is absolutely critical to your business. And do you do this at the risk of forking away from the main branch of code, again for your business critical system? Do you review all of the code for Linux, Apache, PHP, MySQL, all of the related libraries and modules, and every new patch?

Having access to the source code can have its advantages, but it's not a must, and closed source commercial software is a viable and common business model that can provide a great deal of value (and has) to end users.

events/conditional variables

[meshko]

Unfortunately it doesn't cover the really fun part -- mapping windows Event into pthread's Conditional Variable.

Re:I18N - UTF-8 vs UTF-16

[Malc]

Personally I've just moved TCHAR.H around. I worked on a cross platform product a few years ago. I wrote it for Win32, and somebody else handled a Mac OS version. I kept the UI, etc separated out. It wasn't until late in the project that we decided that the Win32 build would be Unicode instead of multi-byte. I had used the TCHAR.H defines throughout all of the common code which of course made this decision easy as Microsoft have done a good job with the I18N stuff. TCHAR.H copied over to the Mac just fine and there were no problems with the common code on that platform.

MingW + Cygwin

[accessdeniednsp]

I'm not sure if this should be a reply to someone else's comment, so I'll start anew.

I'm the guy who helped port the gaim-encryption plugin FROM Linux over TO Win32. (The opposite of the article and this topic, I know). But, after I sent the patches back up to the maintainer, he was able to easily carry it in his source tree.

I used Cygwin and MingW to handle the compilation with his original autoconf, etc. build environment. Of course, there was the requisite GTK+ libraries, etc. that went along with it too. But the magic was MingW and Cygwin.

Perhaps this could give the various developers some insight that "it really can be done".

--
3. Don't forget to enjoy!

Re:Why Not Port Wine?!?

[Rob Y.]

>There are too many libraries that WINE simply doesn't support without linking against MS' DLLs...

True enough, but remember this article was directed at people trying to port their own code from Win32 to Linux. WINE should at least provide a good starting point. They don't *have* to use MS's DLL's.

But the real reason IBM doesn't deal with porting GUI-based code is that they're not interested in desktop Linux. They're talking about porting command-line based code only.

And the previous poster's point about buying a cheap X86 box rather than run a POWER-based Linux desktop misses the real value of a POWER WINE port. The ability to port WIN32 code to MacOS. I've had to resort to running my WIN32 code on Linux under WINE and accessing it via X-windows from OS/X - which, believe it or not, works fairly well. Then again, I've avoided using MFC or any MS DLL's.