Migrate Win32 C/C++ Applications to Linux 393
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)."
Portable code (Score:5, Interesting)
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 (Score:3, Interesting)
Re:OS X? (Score:3, Interesting)
Re:Portable code (Score:1, Interesting)
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.
Design for Portability (Score:3, Interesting)
Re:Portable code (Score:3, Interesting)
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 (Score:1, Interesting)
WINE compile against (Score:3, Interesting)
Re:Portable code (Score:3, Interesting)
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 (Score:1, Interesting)
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;
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 (Score:3, Interesting)
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:"windows" (Score:1, Interesting)
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.
Re:Portable code (Score:3, Interesting)
Re:Portable code (Score:4, Interesting)
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
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?
Tell that to Oracle (Score:5, Interesting)
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 (Score:2, Interesting)
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.
Re:Portable code (Score:3, Interesting)
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%.
events/conditional variables (Score:3, Interesting)
Re:I18N - UTF-8 vs UTF-16 (Score:3, Interesting)
Re:Portable code (Score:4, Interesting)
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.
MingW + Cygwin (Score:2, Interesting)
I'm the guy who helped port the gaim-encryption [sf.net] 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 [cygwin.com] and MingW [sourceforge.net] 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?!? (Score:3, Interesting)
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.