Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Programming Software IT Technology Linux

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)."
This discussion has been archived. No new comments can be posted.

Migrate Win32 C/C++ Applications to Linux

Comments Filter:
  • by Jaidon (843279) on Monday February 14, 2005 @01:22AM (#11665342)
    ...that sometimes during the process the stragglers fall prey to hunters.
  • Portable code (Score:5, Interesting)

    by OneArmedMan (606657) on Monday February 14, 2005 @01:26AM (#11665357)
    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 (Score:5, Informative)

      by PhrostyMcByte (589271) <> on Monday February 14, 2005 @01:31AM (#11665378) Homepage
      It's not really that hard if that's what you have in mind. Things like Boost [] 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 (Score:3, Informative)

        by arkanes (521690)
        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 (Score:3, Interesting)

      by 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.
      • 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 (Score:5, Insightful)

        by dustmite (667870) on Monday February 14, 2005 @08:45AM (#11666754)

        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 [] ... 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.

    • _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 (Score:5, Informative)

      by Lisandro (799651) on Monday February 14, 2005 @01:39AM (#11665414)
      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.
      • 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 (Score:5, Insightful)

        by Moraelin (679338) on Monday February 14, 2005 @04:25AM (#11665922) Journal
        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 (Score:5, Insightful)

          by Quattro Vezina (714892) on Monday February 14, 2005 @07:33AM (#11666428) Journal
          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) (Score:5, Informative)

            by Anonymous Brave Guy (457657) on Monday February 14, 2005 @08:10AM (#11666581)
            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 (Score:5, Insightful)

            by Moraelin (679338) on Monday February 14, 2005 @09:58AM (#11667464) Journal
            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 (Score:3, Informative)

          by dustmite (667870)

          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 [].

    • Re:Portable code (Score:3, Informative)

      by ottothecow (600101)
      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.


    • Re:Portable code (Score:5, Insightful)

      by mboverload (657893) on Monday February 14, 2005 @01:40AM (#11665419) Journal
      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.
      • 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 (Score:5, Insightful)

      by AmberBlackCat (829689) on Monday February 14, 2005 @01:46AM (#11665441)
      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 (Score:3, Interesting)

        by bigberk (547360)

        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 (Score:3, Interesting)

          by Spacejock (727523)
          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 (Score:4, Interesting)

          by mikael (484) on Monday February 14, 2005 @10:58AM (#11668100)
          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 (Score:5, Interesting)

        by mangu (126918) on Monday February 14, 2005 @04:30AM (#11665933)
        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 (Score:5, Informative)

      by chesapeake (264414) <> on Monday February 14, 2005 @01:47AM (#11665445) Homepage
      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.)
      • man you have got to look at wxWidgets []. 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.
        • 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.

    • Re:Portable code (Score:3, Informative)

      by CodeBuster (516420)
      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 (Score:3, Interesting)

        by mboverload (657893)
        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

    • by JWhitlock (201845) <<John-Whitlock> <at> <>> on Monday February 14, 2005 @08:37AM (#11666702)
      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.

  • "windows" (Score:5, Insightful)

    by tonekids (465665) on Monday February 14, 2005 @01:32AM (#11665384) Homepage Journal
    The hardest part of porting to LINUX will be refactoring all of the GUI stuff.
    • Well there's wxWindows which eases porting the MFC programs.
    • by Greyfox (87712) on Monday February 14, 2005 @04:25AM (#11665921) Homepage Journal
      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.

  • by Apoptosis66 (572145) on Monday February 14, 2005 @01:43AM (#11665429)
    Just moved J2EE webapp from windows to linux. Really nothing to it ;)

  • 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.

  • Why Not Port Wine?!? (Score:5, Informative)

    by vinn (4370) on Monday February 14, 2005 @01:56AM (#11665472) Homepage Journal
    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.
    • 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.
      • by entrigant (233266) on Monday February 14, 2005 @02:23AM (#11665581)
        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.
        • by KidSock (150684) on Monday February 14, 2005 @04:49AM (#11665976)
          ... 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.
          • by Rob Y. (110975)
            >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
    • by Soko (17987)
      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
    • 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
      • 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 [] of large swaths of the computer business.
  • by RotateLeftByte (797477) on Monday February 14, 2005 @02:02AM (#11665507)
    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.
  • by bigberk (547360) <> on Monday February 14, 2005 @02:16AM (#11665549)
    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 [] I'm much more interested in rewriting the GUI from scratch using wxWidgets []. 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 [] and they're just amazing, really look like they belong on each target platform.
    • POWER = the PowerPC architecture
      pSeries = the line of IBM servers that use the PowerPC architecture
  • WINE compile against (Score:3, Interesting)

    by Anonymous Coward on Monday February 14, 2005 @02:41AM (#11665640)
    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?
  • by kemelma (610569) on Monday February 14, 2005 @03:11AM (#11665722)
    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
  • not much help (Score:3, Insightful)

    by savuporo (658486) on Monday February 14, 2005 @03:54AM (#11665838)
    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.
    • 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.
  • eek!

    strcasecmp() ? not quite... (the 'n' still missing... what now?)
  • by KidSock (150684) on Monday February 14, 2005 @04:20AM (#11665905)
    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 [] and a text.h [] 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.
    • by Malc (1751)
      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? (Score:4, Insightful)

    by Jezza (39441) on Monday February 14, 2005 @04:40AM (#11665959)
    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.
  • by unkaggregate (855265) on Monday February 14, 2005 @04:50AM (#11665980) Homepage
    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 (Score:3, Informative)

    by Mike McTernan (260224) on Monday February 14, 2005 @05:52AM (#11666159) Homepage

    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.

  • by meshko (413657) on Monday February 14, 2005 @09:37AM (#11667209) Homepage
    Unfortunately it doesn't cover the really fun part -- mapping windows Event into pthread's Conditional Variable.
  • by pclminion (145572) on Monday February 14, 2005 @11:47AM (#11668655)
    It's easy, really:

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


Business will be either better or worse. -- Calvin Coolidge