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)."

The problem with migration is...

[Jaidon]

...that sometimes during the process the stragglers fall prey to hunters.

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

[PhrostyMcByte]

It's not really that hard if that's what you have in mind. Things like Boost [boost.org] can really help, if you can convince whoever your coding for that portability is a good thing.

The problem usually comes when dealing with the GUI or other slightly lower level system functions which sometimes can't be wrapped elegantly.

Re:Portable code

[arkanes]

Portable GUIs aren't too hard these days, with several high quality toolkits. Writing these toolkits is much harder, but GTK and Win32 are similiar enough that it's not too hard. Sockets are pretty easy at this point, although there's some behavior differences that can bite you. Threads are a big problem, Linux (and Unix) threading has traditionally sucked, and while Linux has a high quality system now I don't know that any of the cross platform libraries take advantage of it.

Reliance on COM/ActiveX contro

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

[Afrosheen]

For more on this, see the crappy performance of any Adobe app in MacOSX. They refuse to conform to the new standards (coconut or whatever the hell they're calling it) and end up with slow slow apps.

Funny how Adobe made all their money from Apple to begin with and NT was once a hobbled stepchild to them. Now Apple's the stepchild. Oh how things have changed.

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

[dustmite]

Reduced efficiency I'll give you, but because (and only because) Win32 and MFC are such mind-numbingly bad APIs, writing portable code can often be a massive time-saver if you use more well-designed libraries, like wxWidgets [wxwidgets.org] ... for our company's main project, I estimate that choosing wxWidgets over Win32 or MFC easily cut down development time by 30% (and that's in spite of our developers all having Win32/MFC experience). And as a bonus, our code is now only a stone's throw away from Linux and Mac ports, which we fully intend on developing.

Re:Portable code

[mingot]

_what everyone else said_

AND in addition to generally being a bit more difficult to code (or less efficient when using a cross platform libraries/language) is that it can be a real bitch to support code running on multiple platforms.

Re:Portable code

[Lisandro]

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.

Re:Portable code

[Nasarius]

Libraries allowing you to do similar things on both OSs can be completely different to implement. Audio, file management, program intercomunication, etc.

Well, that's why we need cross-platform toolkits. Qt (which is much more than just a GUI library) will be available in GPL form on Windows soon, making it a good choice for open-source programs.

Yes and no

[Moraelin]

Writing perfectly portable code is possible, but as they say "there ain't no such thing as a free meal." Let's take your DirectX vs OpenGL example, just as a random example, to illustrate the problems.

1. It costs extra time and money.

And it costs time and money to also _test_ it on the new platform. Otherwise you won't even know what functions don't exactly work the same. Or you won't even know that the widget sizes are different on the other platform, and the whole GUI is a disfunctional piece of junk with truncated texts and buttons falling completely out of the dialog box.

(Writing the code is not the alpha and the omega, as you undoubtedly already know. Testing and debugging can easily account for 10 times more time.)

The promised DirectX-vs-OpenGL example: Now _Direct3D_ is pretty much an equivalent of OpenGL. No, not the same function calls, but you can get the same results.

But DirectX offers a lot more than that. Direct3D is just a part of it. You also get networking, sound, etc. If you wanted to stay portable and _only_ use OpenGL, you'd have to write all those extra bits yourself. Which costs time and money.

2. Performance problems, here we come.

Of course, you could just use a wrapper that encapsulates, abstracts and emulates everything. Proper software engineering, right? The problem is: it costs performance.

DirectX-vs-OpenGL fits nicely here too: as fate would have it, Matrox already tried handling that via a wrapper. Back in the days of the G100 and G200, Matrox thought the're smart. No use writing two different 3D libraries that do the same, right? So they actually wrote their OpenGL implementation as a wrapper around DirectX.

The problem? Performance was abysmal. No, not just bad. It _killed_ 3D gaming. With Doom 2 and such being the "killer apps" of video gaming back then, Matrox lost gamer market share (and game developper mind share) with both hands. And who rose like a star? NVidia, who to this day still has the fastest OpenGL implementation.

Just in case you wonder why no games are written using one of those wrapper libraries, now you know why. Because noone wants to make a game that looks like classic ass (low polygon count) or gets single digit FPS. Or both.

3. Those pesky users.

There's one thing that all these emulation and one-lib-to-rule-them-all apologists just don't get: reusing existing skills is good.

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.

And if I were on a Mac, I'd expect it to look and feel like on a Mac. I would _not_ want an app that looks and acts like Windows (e.g., wants me to right-click) in the middle of an Aqua desktop.

It's possible to get it right, yes. See for example IBM's SWT widget set for Java. But it's also quite the norm to get it awfully wrong: witness Sun's Swing.

Re:Yes and no

[Quattro Vezina]

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.

Yes and yes (and no)

[Anonymous Brave Guy]

That's a fallacy. Windows hasn't had anything resembling a consistent look and feel since Windows 3.1, if even then.

While what you say is true to an extent, I think you're ignoring a valid point. Sure, Microsoft plays fast and loose with its own apps, particularly the menu, toolbar and open/save dialogs. Others tailor the interface somewhat as well. But the vast majority of the conventions -- the things an average user will just assume to work -- are the same in pretty much all native Windows apps. A right-click brings up a context menu. You save your work by going to File->Save, and you'll find the Open, Print and Exit commands in the same place. The max/min/restore buttons are at the top-right of the window if applicable. And so it goes.

Some variations on the theme work very well. I was impressed with the simple but effective variation Firefox has adopted for its "find" feature, for example. Others suck: after my first experience using the GIMP on Windows, when it insisted on trying to use completely unfamiliar UI conventions, I gave up.

But the bottom line is that most native Windows apps do have a high level of UI consistency, and if you're going to vary the theme, it should be for a clear reason (such as the Firefox feature I mentioned) and not just because you're developing an app with an inadequate toolkit that can't handle native widgets properly.

The real falacies

[Moraelin]

No offense, but you seem to make two of them yourself.

1. Basically "if we don't have 100% consistency, we should go for 0% instead". Or, if you will, "bah, you already had a change of look-and-feel some 5 years ago, so suck it up and accept one daily, for each program."

Sorry, no. The real world isn't that clear-cut black-and-white. Sometimes you have to settle for "good enough" instead of "perfect".

2. More importantly, the underlying fallacy is "looks are all that matters." Seein' as what you came up with is flat buttons or different icons.

And that's not just a fallacy, it's also _the_ number one _failure_ of GUIs designed by programmers, graphics artists, marketting, etc. (Though each of them for very different reasons.) Generally anyone else who really has _zero_ clue about usability, and just thinks anything graphical will do.

What I'm more concerned with isn't "waaah, but they changed the 'new folder' icon in XP!" I'm more concerned with how things work. Which is why my point explicitly said "reusing skills" not "reusing graphics."

Take the Windows file open dialog for example. Sure, some apps might add a preview field next to it, or a couple of extra fields, but by and large it stayed the same since Windows '95. You can still do the same things (e.g., creating or renaming a folder right in the list), in the same way, in all apps that use it.

The important thing is: Once you've learned to use it once, you can do it mechanically, without even thinking about it. Even if you just bought/downloaded/compiled/whatever a brand new app, you already know how its file dialog works. That's one less thing to go through a learning curve about.

Now kindly open a GTK dialog box in Windows. E.g., open a file in Gimp. Ugh. WTF is that box? What was wrong with the "normal" box, that needed replacing? Or try it with a Swing app. Ugh. Why does everything look and act differently?

Try to answer those questions _without_ going into technical details about widget sets and libraries. Pretend I'm Joe Average, who doesn't even know what GTK is. And more importantly, who doesn't _care_ about such details. I just want to use the program, with a minimum of learning curve or thinking.

What was wrong, from a _functionality_ point of view, with the old dialog? What end-user functionality absolutely wasn't available through it, so that it needed a completely different dialog?

Native look and feel

[dustmite]

And if I were on a Mac, I'd expect it to look and feel like on a Mac. I would _not_ want an app that looks and acts like Windows (e.g., wants me to right-click) in the middle of an Aqua desktop.

You are 100% right --- ported apps should have "native look and feel" on each platform! A good cross-platform API that has been designed with this goal in mind since the start is wxWidgets [wxwidgets.org].

Re:Portable code

[ottothecow]

In my little experiance, I can tell you that the portability of code has much to do with its complexity and what it works with (and the level of the language).

If to systems have very similar network protocols (as most do), it becomes trivial to write a cross platform app that mostly deals with the net in a higher level language. But when you try to optimize it more and more or start linking it to more unique parts of a system (cocoa for instance), the process becomes exponentially more difficult.

Repe

Re:Portable code

[mboverload]

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.

Orders of magnitude

[mangu]

Programs for Linux are supposed to be so portable, but many times they are just as dependent as their Windows brethren.

They may not be 100% portable, but they are, definitely, not *just as* dependent as Windows programs. Setting a symbolic link pointing to /usr/bin/local is somewhat easier than converting an application from DirectX to OpenGL or from MFC to Qt, for instance.

Re:Portable code

[Anonymous Coward]

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.

Re:Portable code

[Anonymous Coward]

Yes, but aren't those details Situation Normal in the *nix world?

Neither Linux nor FreeBSD have the right to complain about portability because neither strictly follow the Single Unix Specification.

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

[Anonymous Coward]

MSYS [mingw.org] is what you are looking for.

Re:Portable code

[RKBA]

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

Use macros that expand to the API call appropriate to the OS being compiled under.

The best way to handle Win32

[Anonymous Coward]

#ifdef WIN32
# error "Get a real operating system."
#endif

Re:Portable code

[DrXym]

Take a look at what Mozilla does. Basically it uses the same build system (& autoconf script) for Unix and Win32 but it invokes gcc (or cc / icc etc.) on Unix and cl on Win32. It manages this trick by using lots and lots of macros - project makefiles use macros to specify paths, libs, targets etc. and pull in global rule files to turn these into compiler switches.

Building on multiple compilers also requires writing code to the subset of functionality common to all of them and avoiding dangerous stuff

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

Re:Portable code

[DrXym]

To be frank, those things are trivial to fix and can be expected when moving any Unix program to some other platform. Once a program goes through a few iterations, gains an autoconf script and some maintainers, it will build and run happily on lots of platforms.

Contrast that with Win32 vs Linux where the API is different, the compiler is different, the build system is different, the underlying OS is totally different etc.

Re:Portable code

[AmberBlackCat]

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.

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)

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

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.

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:Portable code

[chesapeake]

But is it really that hard to write code that is portable?

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 ;-P )

(I would just like to add that I'd rather code C/C++ under unix with GCC any day - I'd just rather eat.)

Re:Portable code

[bigberk]

man you have got to look at wxWidgets [wxwidgets.org]. It provides a uniform API under many platforms, so you can use wx's threads, wx's file I/O, wx's sockets (instead of say winsock vs BSD sockets), wx's GUI and widgets. This will seriously cut down, if not eliminate, OS-dependent stuff.

Re:Portable code

[Nasarius]

wx's sockets (instead of say winsock vs BSD sockets)

Kind of a bad example. If you don't use the Winsock functions (WSA*, except for WSAStartup), your sockets code should be easily portable between Windows and Unix.

int b[0] when you mean int* b is a *bad* habit

[The Darkness]

In gcc declaring an array of 0 length does not allocate space for the pointer! It's basically an inline memory pointer. Given:

struct {
int a;
int b[0]; // inline ptr
} test;

Assuming a 4 byte int and the object is at address 0. (yes, yes, NULL pointer and all that rot)

sizeof(test) = 4
&test.a = 0x0
&test.b[0] = 0x4
&test.b[1] = 0x8

One use is to allocate the memory yourself and then use the struct to map that memory. The sizeof() would give you the header size. Then (sizeof(header) + allocated data storage) is the total size to alloc.

See: Zero Length (gcc) [gnu.org]

IMO, it is a very bad habit to use "type name[0]" when you mean "type* name".

Doing what you claim (sorry, you're AC) is the "Microsoft way" will cause memory corruption in GCC.

Re:Portable code

[Yokaze]

Well, since

int a[N];

is an array of fixed length N, I'd acutally expect the compiler to issue a warning on the following lines.

a[0] = 100;
a[1] = 200;

If you want dynamic sizes in C, you go through pointers. So

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

would be correct.

If you find the latter lacking the expressiveness, go Hungarian,

int *prgA;

but don't abuse a unportable laxity in certain compiler. The reason should be obvious from the existance of the grandparents post.

Re:Portable code

[CodeBuster]

The problem is with code that depends upon services and libraries provided by the platform in question and which vary from platform to platform such as graphical user interface and threading code. Since many applications provide either graphical user interface or threading or both and make use of other features which may not be common across platforms it is not generally possible to separate certain important parts of the code from the target system. This means that while some parts of the code, which are n

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 stic

Re:Portable code

[JWhitlock]

I can't 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?

I'm not a polygamist, so obviously there is a lot that I don't know, but I imagine it's about as hard as dating two people at once. Once it goes into production, it's more like being married to two people. Not impossible, but surely you can imagine some of the difficulties. Unless you haven't dated, in which case you should have plenty of time to pick up programming.

Re:Portable code

[starfishsystems]

You can build your program on top of a layer of your own that serves as an interface with whatever API is needed.

The idea being that all of the portability issues will be confined to the interface layer. Moving to a different platform, or even tracking changes to an existing platform, should then have no effect on the majority of program code, since it lies outside of this layer.

That's the theory. In practice the effort required can vary a lot from one application to another. The easiest cases are op

Re:Portable code

[BarryNorton]

Portability between washing machine controllers...

"windows"

[tonekids]

The hardest part of porting to LINUX will be refactoring all of the GUI stuff.

Re:"windows"

[lachlan76]

Well there's wxWindows which eases porting the MFC programs.

Re:"windows"

[Greyfox]

The hardest part of porting to Linux will be figuring out what all those hungarian notation variables were supposed to be. pszStringVar3? WTF?! Hungarian notation is always a warning sign that deeper evil lurks within the code disguised by programmers pretending that they know what they're doing because they can adhere to a naming convetion for warts while choosing actual variable names that make absolutely no sense. If you notice that hungarian notation is in use, it's going to mean that the project is going to end badly. Insure that programmers who insist in using it are removed or assigned to little projects that will probably never be used so they don't end up dragging everyone else down with them.

You'd think I was overgeneralizing, but I'm not. Absolutely every single time I see HN in use, I quickly end up learning that the programmer who wrote the code was an idiot. On at least two separate occasions, I've had to correct C code with HN that did not allocate space for the null terminator on any strings anywhere in the code. That's pretty much the level of programming talent you can expect when you see HN in use.

Conversely, I have never seen any code using HN which I looked at and thought to myself "Well that's a sweet way to solve that problem!" Not even once have I ever seen an elegant algorithm expressed in code written with HN. Not one single time.

Now I could propose several different reasons why I think this might be the case. It could be that HN actually causes brain damage in otherwise able individuals. It could be that it is a harbinger of doom, like some programmatic horseman of the apocalypse. More likely the programmers in question went through some community college somewhere and HN was the only thing they can remember from their beer-and-drug soaked college days. They've advertised that they know how to program and probably claim to have invented C, and they point to their strict adherence to programming convention, missing the fact that conventions without understanding is still stupidity. And it's not like managers typically know any better.

Which is why every trace of HN must be eradicated from any code which is ported, before it is allowed near our pristine and pure operating system. Well that, and the code will be more maintainable in the long run.

Re:"windows"

[johannesg]

Here's an argument or two against HN:

- HN seems, for many people, to serve as a replacement for the actual name. It is easy to write psz1 and psz2 when you want two pointers to zero-terminated strings, but really - I'd rather have their meaning than their type. You may argue that this is simply bad usage (and I'd agree) but I've seen too much code by now that does this to believe it is coincidental. Coming up with good names for variables is hard. Once you have a few characters, even if they don't mean much, people tend to stop thinking and just use it.

- HN adds long strings of unpronouncable garbage throughout the source. That decreases general readability.

- When a variable changes type, you should also rename it everywhere it is used. People tend to not do this, resulting in a system that actually gives the wrong information.

- HN places a great deal of stress on variable type. In my not so humble opinion type is important, but not quite _that_ important. In reality I find myself caring about meaning, then about scope, and finally about type - in that order. And you should be thinking "objects" anyway, not actually caring about type since that's all encapsulated.

More here [triumvir.org]...

My Java Programs Port Really Nice

[Apoptosis66]

Just moved J2EE webapp from windows to linux. Really nothing to it ;)

Apoptosis

Re:

[account_deleted]

Comment removed based on user account deletion

Should be: Migrating an App the Worst Possible Way

[IrresponsibleUseOfFr]

Migrating a Win32 app the way they suggest is going to be painful and time consuming. In addition, there are numerous things that they don't mention, like associated performance costs: is creating a thread going to be more expensive or cheaper on Linux vs. Win32? Don't look to the article for the answer. It doesn't even mention the biggest parts like the graphics/windowing library.

Secondly, it is making a wild assumption that your win32 app is written in a that is conducive to a Unix/Linux process model. Namely that you spawn processes and use environment variables as opposed to having a message loop and handlers (the way most windows apps are written).

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?

Finally, why not look at a binary solution like Wine first and not touch your source at all?

This is the worst way migrate app. The source works and manually mucking with it like this is a good way to break it and introduce all sorts of bugs. Look for a binary solution like Wine. Then look to see if somebody implemented a Win32 on Linux library next to recompile (like Cygwin in reverse). Then, the last choice is to factor out your platform specific portions of your code and replace them with OS neutral calls. But beware of the performance of your app, it will probably take a hit. But, hacking apart your app like this makes me cringe.

Re:

[account_deleted]

Comment removed based on user account deletion

Re:Should be: Migrating an App the Worst Possible

[GbrDead]

The author might have meant: "Porting Windows programmers to POSIX" :-)

Re:Should be: Migrating an App the Worst Possible

[cduffy]

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.

Re:Should be: Migrating an App the Worst Possible

[MichaelSmith]

Of course it could _help_ in migration even with the source. You could partly port the application and partly extend wine until it ran the application

Re:Should be: Migrating an App the Worst Possible

[owlstead]

There are several assumptions that you make that are not that []
- Associated performance costs; for most (business related) applications, you don't give a darn. You want it well designed, but the difference in creating a thread? I don't think that would matter much (linux is very probably faster anyway).
- About having a message loop and handlers; it seems to me that this is about an application that is written from the GUI down. If you cannot seperate your core logic from your GUI, there comes a time where

Why Not Port Wine?!?

[vinn]

I don't get it. IBM seems to have some massive aversion to Wine. It seems to me the easiest thing they could do would be to port Wine to the Power architecture. It would consume a little time, but surely nothing as suggesting every application developer rewrite massive parts of their Win32 app. These articles basically suggest an app needs to be rewritten from scratch, which will immediately make any ISV laugh at Linux on Power. (Why would you bother porting a Win32 app to Power? Why not just keep using a cheap Intel box running Linux?)

Winelib was specifically designed to help with porting and you can do it tiny controlled steps:
1. Port from MSVC++ to the MinGW compiler and develop things like a Makefile.
2. Test the app.
3. Port the code from Windows to Linux (not as trivial as you'd think - there are problems with case sensitivity, etc.)
4. Test compiling.
5. Finish compiling using the custom Wine tools, such as winegcc (a wrapper around gcc that makes it behave like MinGW).
6. Test your Winelib app.
7. Begin ripping out chunks of Win32 specific code and replace them with native equivalents - Wine dialogs for KDE/GNOME ones.
8. Test

That's a valid and controlled migration path. Asking developers to basically rewrite massive chunks of code involving threading, memory management, and other such exciting things is a nightmare. Oh, and after rewriting you get to debug it all. Would you trust an enterprise app that just had it's whole threading model replaced?

The part I find amazing though, is just how much they haven't addressed. What do you do when your app relies on COM? What about Windows common controls? What about networking?

Anyway, it looks like IBM missed the ball - a few engineers porting Wine to Power could have solved many of their migration issues. It certainly would have solved every single one mentioned in these articles. Instead they want the software developers of the world to take on the task of rewriting their apps.

Re:Why Not Port Wine?!?

[bombshelter13]

Wine emulates the Windows API... it does not emulate the x86 instruction set.

So even if Wine was for some reason compiled to run on Power, you'd still have to add something to emulate an x86 chip.

Re:Why Not Port Wine?!?

[entrigant]

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.

Re:Why Not Port Wine?!?

[KidSock]

... its true power lies in providing windows api's on linux that you can compile against.

As cool as that would be I seriously doubt people will get very far with this approach. There are too many libraries that WINE simply doesn't support without linking against MS' DLLs. There's structured storage, NDR / RPC, MAPI, workstation management and security network functions, etc, etc, etc. Sure they might have a few individual ops that have been cobbled together using libsmbclient or some OpenLDAP code but the API is not nearly as complete and robust as it needs to be to actually compile a stand alone binary that doesn't require emulation.

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

Re:Why Not Port Wine?!?

[Soko]

I don't get it. IBM seems to have some massive aversion to Wine.

Stop thinking purely as a techie/develper for a second, will you? THINK for a second about the whole, big picture, not just implications for developers.

IBM is pushing Linux, has it's own line of pretty nice processors and just sold off it's PC division. And now they want native ports of applications to thier chosen OS and platform. Hmmmmm...

I'm no business genius by any stretch, but do you see any place for Wintel in the picture that's bein

Re:Why Not Port Wine?!?

[ciroknight]

I think one of the reasons IBM won't touch Wine is legality concerns. Sure, it's an open source re-engineered version of Win32, but there's no way to completely trust the source, to say that some of it didn't come directly from Windows. And Microsoft could very easily pull that trap on anyone, if they felt the need to.

Besides, why use WinAPI when you can natively port the code? It saves a boatload in interpretation time, and is better interoperable with other programs on the system (some/most of which wo

Re:Why Not Port Wine?!?

[gmhowell]

there's no way to completely trust the source, to say that some of it didn't come directly from Windows

I thought Darl McBride stopped posting on slashdot...

And Microsoft could very easily pull that trap on anyone, if they felt the need to.

MS doing anything like that would result in a MAD [wikipedia.org] of large swaths of the computer business.

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.

Where did this come from?

[bigberk]

And what the hell is POWER and pSeries? I'm pretty much going to ignore this article. I've been writing win32 software for quite some time and am seriously fed up with that platform. Rather than tweaking my software so that it works with Wine [winehq.com] I'm much more interested in rewriting the GUI from scratch using wxWidgets [wxwidgets.org]. With a wx based application, you can then compile it into native Linux (GTK+), native win32, or even Mac OS X apps. To me that seems like the most promising route. I've used some wx based applications like Audacity [sourceforge.net] and they're just amazing, really look like they belong on each target platform.

Re:Where did this come from?

[d1v1d3byz3r0]

POWER = the PowerPC architecture
pSeries = the line of IBM servers that use the PowerPC architecture

Re:Where did this come from?

[dustmite]

Firstly, simple things like spawning threads/processes are typically the least of your worries when porting a Win32/MFC app, because these are small simple APIs with no or little dependencies and easy to abstract. It usually takes a few hours to give these wrappers and add a few simple preprocessor directives (e.g. #ifdef WIN32) to compile the right implementation on the right platform. GUI stuff is usually the big pain.

Secondly: I wonder what all these classes are then: wxCriticalSection, wxThread, wxMute

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?

binary semaphore and mutex is not the same !!!!

[kemelma]

The second article "Migrate Win32 C/C++ application to Linux on POWER, Part 2: Mutexes" worth nothing, since you can't use semaphore (SysV semaphore) instead of mutex. It seems that the author do not know/understand the very basic difference between binary semaphore and mutex - and the difference is that there is no owner for semaphore and there is always owner for mutex. This means that once mutex taken/locked, only the thread/process which holds the lock able to release the lock, and this is not true for binary semaphore ... since it has no owner and any process/thread can unlock it.. I can even say that the example demonstrated in second article is dangerous.. Since it leads to misunderstanding and production of wrong/problematic code. At the moment there is no standard way to map Wind0ze inter-process mutex to Linux, this could probably be done using FUTEX API, but it is still changing, not standard and not well documented. Regards, Mike

Re:binary semaphore and mutex is not the same !!!!

[IamTheRealMike]

Ask and ye shall receive [winehq.org].

Or what, did you really think we could run apps like Office and iTunes without such a basic sync primitive?

not much help

[savuporo]

Well, considering that most of the apps i've written under MSVC utilize either MFC ( yea i know its 'orrible but gets the job done ), ATL and COM, with very little direct code interfacing to Win32 layer, this doesnt help much.
For similar app under linux its easier to start from a scratch and just lift the parts of the code that are separate classes/libs with no or little platform-specific dependencies.

separate the GUI and the activity

[oo_waratah]

I wrote an application that worked on Windows, Unix, Linux, and mainframe. I wrote the GUI separately calling the library function then a simple command line version for Unix.

What I should have done is totally separate the GUI and the application entirely. I could rewrite the GUI in in a portable framework on linux faster than any port of the Windows software. I could then install the framework on all the windows desktops and have them work the same. Not port but total rewrite in a portable framework.

strncmpi(...)

[Domini]

eek!

strcasecmp() ? not quite... (the 'n' still missing... what now?)

I18N - UTF-8 vs UTF-16

[KidSock]

One notibly important difference between Win32 and Linux is that the internal Unicode encoding is UTF-8 as opposed to UTF-16LE. This takes some getting used as it requires special consideration when working with text (e.g. when iterating over individual characters). I have prepared a document [ioplex.com] and a text.h [ioplex.com] header file [1] that could assist people with porting Win32 applications to Linux. Or at the very least it explains how to maintain I18N support as you migrate code.

[1] The header is part of a library but you can easily remove the library specific #defines.

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

Cheap POWER?

[Jezza]

A serious point, if IBM is really serious about people to port their Windows apps to "Linux on POWER" (which does have a nice ring to it) then why are all IBM's POWER based systems so expensive?!

Now Apple can make a PowerPC based system for £339 (BYODKM as Steve might say) why can't IBM create something similar? Preload it Linux and we'd all be happy little "porters". Now if they really wanted us to do this then a laptop would be really great. But presently IBM will only sell expensive POWER systems.

Now after you've ported your "killer app" to LoP, how the heck do you deploy it? On what? Some mega-expensive POWER Server? Doesn't IBM realise that Windows apps are usually run on the desktop or laptop? I mean they're not suggesting we're using Windows as a server OS are they? ;-)

PS. Anyone from IBM reading this - yes I would buy an IBM LoP box if it was sub £500 BYODKM.

What about good old C++ abstraction and #ifdef?

[unkaggregate]

I regularly do this all the time: I write a basic main() routine for both platforms (these are usually console apps) then add #ifdef WIN32...#endif and #ifdef LINUX....#endif for each case. If necessary, complex functions are split off into subroutines, internal libraries, or C++ classes (and #ifdefd like so). Then just make a Makefile for each platform (For Win32, the usual .DSP .DSW duo as I use MSVC 6, and Linux a simple Makefile that includes -DLINUX in the CFLAGS) and compile for each.

The same can be applied to GUIs, though for Windows you'll have to write a WinMain wrapper.

Testing

[Mike McTernan]

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?

Part of the problem is that unless a developer tests their code on another platform, you don't know if it is truely portable (unless you are writing a pretty basic application that is compiled with -ansi -pedantic). As you can imagine, a lot of developers will not take the time to do this testing, maynot want to support other platforms, or maynot own other platforms on which to test their code.

events/conditional variables

[meshko]

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

How to migrate a Windows app:

[pclminion]

It's easy, really:

$ cp /mnt/samba/xyzzy/programs/windows_app.exe .
$ objcopy -O elf32-i386 windows_app.exe windows_app
$ ./windows_app

;-)

Re:Stupid question

[laughingcoyote]

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!

Re:Stupid question

[cyfer2000]

and why did we port those mainframe programs to Win32 10 years ago?

KEEP THE CUSTOMER SATISFIED [lyricsfreak.com], that sounds good.

Re:OS X?

[mark-t]

Linux actually has a larger market share.

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.

Re:OS X?

[Anonymous Coward]

No. No it wouldn't.

OS-X has the market share of Linux with the cost of Windows. If you want a Server, Linux is a better option. If you want a desktop, Windows generally wins out. Why the hell would it be smarter to "move apps to OS X"?

Re:Programming in C++ on Linux

[mingot]

I'm taking a C++ class at the local college that's being taught by the Unix guru. The class is using Visual Studio .NET as the IDE (which the instructor is not familar with and is threatening to go to Linux instead).

No offense, but anyone who can't figure out how to use and become familar enough with the visual studio IDE to use it in a teaching environment shouldn't be called a guru of anything. It's extremely simple to use until you want to start doing very complex things. And that's when you start pining for makefiles. I can't imagine you're writing anything that complex for (what your post would indicate is) an introductory c++ class.

Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).

Actually, there is. Where it is buried in the settings? Couldn't tell you off the top of my head, but here is something for you to try: Navigate to the directory where the exe is being dumped and run the thing from the command line yourself.

Anyway, I tried compling the sample programs under gcc and g++ on my Linux file server, and I get a lot of errors. I thought C++ (or at least, C) was supposed to portable. ;) I would like to learn how to program basic C++ fluently on both platforms.

Not familiar with the book, but unless it is doing something windows specific (and it may be) you should not have any trouble compiling simple programs under gcc and the MS c++ compiler.

Re:Programming in C++ on Linux

[MidnightBrewer]

No offense, but anyone who can't figure out how to use and become familar enough with the visual studio IDE to use it in a teaching environment shouldn't be called a guru of anything. It's extremely simple to use until you want to start doing very complex things.

Being able to jump from one software package to another isn't always easy, even if the new one is supposedly better. I just recently change video compositing packages to a better one and expect to take a few months of constant use (or more) bef

Re:Programming in C++ on Linux

[b17bmbr]

if someone has been doing something a certain way for years, then it will become second nature. any changes and they get all tweaked. and as for programmers, especially older c/c++ guys, probably cut their teeth on vt100 terminals, etc., "the good old days...", VS would be like putting richard petty into the space shuttle. not to typecast or stereotype, but programmers (not wannabes like myself, i do java, php, etc.), guys who are real gearheads, are gonna be a little compulsive, like musicians. fine.

Re:Programming in C++ on Linux

[spectecjr]

I'm taking a C++ class at the local college that's being taught by the Unix guru. The class is using Visual Studio .NET as the IDE (which the instructor is not familar with and is threatening to go to Linux instead). At home, I'm using Visual C++ 6.0 Learning Edition that was provided by the Deitel and Deitel book. Tried using Visual C++ Express edition but it seems more trouble to use (e.g., there's no automatic prompt to prevent the DOS box from disappearing).

That's because you're running it under the debugger, and the assumption is that if you want it to stick around, you most likely have a breakpoint set somewhere.

Run it outside of the debugger - namely, by hitting CTRL+F5, or the "!" icon - and it'll run and when it terminates it'll ask you to press a key before finishing.

There you go. Learn your tools, and you'll find it much easier to use them.

Re:Programming in C++ on Linux

[EvanED]

And he was also asking about books for C++ programming on *Linux*, saying that the class might change to *Linux*, and complaining that *GCC* was giving error messages. Clearly he has some interest in portability.

Re:Programming in C++ on Linux

[miyako]

Most C++ books will cover C++ in a way that should be applicable to Window or Linux, so long as you don't go for one that specifically mentions VC++ in the tittle. I've been partial to "C++ The Complete Reference", since in my experience, if you already know how to program, a reference style book is more useful in the long term for a particular language. Another book I've been particularly partial to is C++ GUI Programming with Qt.

Re:Programming in C++ on Linux

[vistic]

If you're programming a simple program in Visual Studio and it won't compile when you try doing it with gcc/g++, it's probably a very simple problem.

Your main in Visual Studio is probably "void main(void)" and returns nothing. To compile it in gcc, declare "int main()" and make the last line of main "return 0;" and it will probably compile.

Re:Programming in C++ on Linux

[CodeBuster]

I remember my early days in CS when my simple first year lab assignments, written in C++, wouldn't port between the CodeWarrior compiler on the Macs in the labs and my Visual C++ compiler at home. The problem is not in the language per se, but more often with differences in the ways that compilers handle certain situations such as the classic:

What happens when you call an overridden virtual method from a virtual base class's constructor?

C++ is a powerful language, but it is too easy to shoot yourself

Visual C++ sucks...

[katharsis83]

I'd recommend using gcc/g++ to learn the languages. Using Visual C++ lets you make certain mistakes without punishing you for them; gcc/g++ WILL let you know when you haven't initalized a variable; Visual C++ - most of the time - will assume it's been set to zero and let you work from there. It makes bad habits easier to form.

Also, code written in gcc/g++ is pretty much guranteed to work in VC++; the reverse is not always true.

Re:Visual C++ sucks...

[hobo2k]

Whatever compiler you use, it is a good idea to learn which option adjusts the warning level and set it to the max.

I don't recall which warning level is needed for uninitialized variables, but level 4 definately will catch it.

Re:Programming in C++ on Linux

[Mystic0]

I take it back when I said "C++ is not supposed to be portable." It really depends. Straight C++ with no OS specific calls should work just fine on any platform. (You'll have to recompile it of course)

If you are having problems, make sure that there aren't any OS specific calls being used.

How to port CLI programs to OS 9

[hunterx11]

#include <SIOUX.h>

SIOUX basically just creates a simple MacOS 9 app with a window that acts as a console. Just add that, and standard I/O will behave almost exactly like it does on a *nix machine.

Re:Programming in C++ on Linux

[pe1rxq]

Just make sure you are not using a pre-ANSI version....

Jeroen

Re:Programming in C++ on Linux

[ccoakley]

As far as I can tell, C++ is rather standardized (nowhere near Java though...).

Funny you should say that as C++ is an ISO standard and Java is not a standard at all. In fact, the Java Language specification can't really be called a standard definition because it defines Java's lexical grammar in terms of Java classes:

Section 3.8 of the java language specification:
A "Java letter" is a character for which the method Character.isJavaIdentifierStart returns true. A "Java letter-or-digit" is a character for

Re:But...

[Anonymous Coward]

That's because most programs for Linux are written with portability in mind, including the libraries. That's why the Linux code compile fine on other platforms, including Win32, and not always the other way around.