Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Migrate Win32 C/C++ Applications to Linux

Zonk posted more than 9 years ago | from the fun-crafts-for-a-rainy-day dept.

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

cancel ×

393 comments

The problem with migration is... (5, Funny)

Jaidon (843279) | more than 9 years ago | (#11665342)

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

Re:The problem with migration is... (-1, Offtopic)

isometrick (817436) | more than 9 years ago | (#11665346)

Here's to hoping that you get mod-bombed to disprove your little theory :-p

Oh no, don't mod me!

Mod Parent UP! (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#11665502)

+0.5 Mildly amusing.

Stupid question (0, Troll)

Mercedes308 (832423) | more than 9 years ago | (#11665343)

I don't have any programing skills or anything, but does this relate to porting win32 applications to run in Linux?

Re:Stupid question (5, Funny)

laughingcoyote (762272) | more than 9 years ago | (#11665354)

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 (1)

Mercedes308 (832423) | more than 9 years ago | (#11665370)

What I was getting at is if it was a porting or the application ran in a virtual OS.

Re:Stupid question (0)

Anonymous Coward | more than 9 years ago | (#11665427)

you, sir, are a moron.

Re:Stupid question (0, Offtopic)

Mercedes308 (832423) | more than 9 years ago | (#11665457)

Riiiggghhhttt....So anyone posting an honest question about something they don't know about gets replies from people like you. At least the guy above you didn't wimp out and post AC. Afraid of a girl are we?

Re:Stupid question (1)

0x461FAB0BD7D2 (812236) | more than 9 years ago | (#11665554)

Actually, it's neither. The article describes the use of a portability layer abstracting the APIs.

Re:Stupid question (0)

Anonymous Coward | more than 9 years ago | (#11665607)

What I was getting at is if it was a porting or the application ran in a virtual OS.

The article (which you likely haven't bothered to read) specifically mentions porting and talks of changes to source code. So if you're wondering if it's talking about porting or something else, I guess you already have your answer.

Of course, ask a stupid question and you'll get the answers you have. Being female is no excuse for not first trying to comprehend the material.

Re:Stupid question (1)

cyfer2000 (548592) | more than 9 years ago | (#11665524)

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

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

Re:Stupid question (1)

mirko (198274) | more than 9 years ago | (#11665529)

Because some could not wait 10 years to get the labour done a cheaper way.

Portable code (4, Interesting)

OneArmedMan (606657) | more than 9 years ago | (#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 (4, Informative)

PhrostyMcByte (589271) | more than 9 years ago | (#11665378)

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 (1)

adlaiff6 (810221) | more than 9 years ago | (#11665383)

Programs written in Java are relatively portable, given that they run in a runtime that has been written for multiple OSes.

Re:Portable code (3, Interesting)

Anonymous Coward | more than 9 years ago | (#11665392)

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 (1)

mingot (665080) | more than 9 years ago | (#11665410)

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

Lisandro (799651) | more than 9 years ago | (#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.

Re:Portable code (1)

Lisandro (799651) | more than 9 years ago | (#11665423)

...for example, widgets (the windows and buttons drawn on screen) might be handled completely the same.

Sorry, make that "completely different". I need my caffeine dose.

Re:Portable code (1)

Nasarius (593729) | more than 9 years ago | (#11665672)

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.

Re:Portable code (2, Informative)

ottothecow (600101) | more than 9 years ago | (#11665415)

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.

Repeating libraries across systems helps this as show by wine, but then the software is nolonger running native to the system, it thinks that it is still running on a windows box.

Re:Portable code (5, Insightful)

mboverload (657893) | more than 9 years ago | (#11665419)

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.

Re:Portable code (0)

Anonymous Coward | more than 9 years ago | (#11665468)

Isn't that mainly because FreeBSD has incomplete/incompatible threading APIs?

Re:Portable code (5, Insightful)

Anonymous Coward | more than 9 years ago | (#11665546)

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 (3, Insightful)

Anonymous Coward | more than 9 years ago | (#11665598)

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 (5, Insightful)

AmberBlackCat (829689) | more than 9 years ago | (#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 (2, Interesting)

bigberk (547360) | more than 9 years ago | (#11665571)

I don't think portability is such a big problem for somebody who has time and resources. I think the biggest problem is people who make software for money are concerned that Linux users want everything to be available for free
Put me in this category. I use both Windows and Linux and would love to partially rewrite some of my best selling apps so that they run under Linux. But I'm not sure whether it's worth the effort. I will want to release the binaries (versions for a few different libc's for example) and am definitely not going to be releasing my source code. btw I'm also an open source developer but I don't intend to make money off that UNIX software.

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

Re:Portable code (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11665636)

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

Re:Portable code (2, Interesting)

Spacejock (727523) | more than 9 years ago | (#11665663)

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

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

Re:Portable code (0)

Anonymous Coward | more than 9 years ago | (#11665443)

Sometimes you just dont realize that the code is not portable until you try to port it...

I code with unix in mind. So my programs work on mac, linux and aix with just a recompile. Never got it to work on windows... that os is just so strange.

Re:Portable code (5, Informative)

chesapeake (264414) | more than 9 years ago | (#11665445)

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 (1)

bigberk (547360) | more than 9 years ago | (#11665588)

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 (2, Informative)

CodeBuster (516420) | more than 9 years ago | (#11665450)

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 not dependant upon system specific resources, may be reused there are still major portions that will have to be rewritten (i.e. ported) to new platforms. Graphical user interface code especially tends to be verbose and tedious to rewrite multiple times on different platforms. Perhaps this helps you to have a better understanding of why porting is an issue.

Re:Portable code (0)

Anonymous Coward | more than 9 years ago | (#11665493)

I have a similar question.

Say I would use Qt for Windows - could I write something as trivial as a little advanced text editor and port it to Linux _just_ by recompiling it? That's what their website says.

Re:Portable code (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11665495)

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

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

Re:Portable code (2, Insightful)

starfishsystems (834319) | more than 9 years ago | (#11665660)

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 operations which are to be expressed have fairly conventional meaning, for example getting a list of network interfaces from the system. Conversely, the most challenging cases involve fundamentally dissimilar models or capabilities, or else semantic complexity and context that has to be carried around.

The strategy for the first alternative, if you're committed to portability, is to restrict your design to a modest set of platform capabilities. That's always a good design discipline anyway, so I think you actually come out ahead if you think in terms of portability for any design project, excepting perhaps proofs of concept and other transient projects.

The second alternative is the really expensive one, since what you're really doing in the interface layer is building some kind of elaborate context management system on top of some other elaborate context management system. And I think this illustrates the point being made by the parent in saying you have to be expecting the contexts you want to support.

OS X? (-1, Troll)

ericdano (113424) | more than 9 years ago | (#11665368)

Wouldn't it be smarter to move apps to OS X?

Re:OS X? (1)

mark-t (151149) | more than 9 years ago | (#11665416)

Linux actually has a larger market share.

Re:OS X? (2, Interesting)

Stevyn (691306) | more than 9 years ago | (#11665433)

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? (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11665420)

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:OS X? (0, Troll)

bigberk (547360) | more than 9 years ago | (#11665602)

Why the hell would it be smarter to "move apps to OS X"?
Because unlike Linux, customers will actually pay for the OS X software, funding your time/effort and making it worthwhile for you to develop even more good software for that platform. Also I suspect there are more serious Mac users out there. Think of all the multimedia people and Engineers who use Macs because of the power. (I'm not a Mac nut, btw)

Re:OS X? (0)

Anonymous Coward | more than 9 years ago | (#11665483)

Wouldn't it be smarter if you Mac Zealots didn't troll every single discussion? You guys are the worst advertising imaginable.

Re:OS X? (0)

Anonymous Coward | more than 9 years ago | (#11665535)

Consider the source. This information is coming from IBM, who have been been proponents of Linux. While IBM may make the G5 processor in the new line of Macs, they also make the iSeries, pSeries, and zSeries line of servers, all of which use POWER architecture and are capable of running Linux. I didn't RTFA, but I'm pretty sure what IBM is talking about here is companies moving their custom code off of Windows based servers and onto one of their servers running Linux. They aren't talking about porting your favorite desktop app.

Re:OS X? (0)

Anonymous Coward | more than 9 years ago | (#11665536)

That's what I was wondering. Linux users will demand that you release your software for free. Apple users on the other hand are accustomed to paying 3 or 4 times the value of the products they buy.

Petzold for Linux (0)

Essef (12025) | more than 9 years ago | (#11665377)

Something which would be a brilliant resource on Linux would be something like Petzold's excellent "Programming Windows" (Amazon Link). [amazon.com]

I have not found a Linux equivalent text discussing KDE and GNOME programming at this level.

Stephan.

"windows" (5, Insightful)

tonekids (465665) | more than 9 years ago | (#11665384)

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

Use GTK in the first place (0)

Anonymous Coward | more than 9 years ago | (#11665485)

Just use a cross-platform GUI library in the first place.

Re:"windows" (1)

lachlan76 (770870) | more than 9 years ago | (#11665527)

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

Programming in C++ on Linux (0, Offtopic)

creimer (824291) | more than 9 years ago | (#11665402)

Does anyone know of a good book on C++ programming in Linux?

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

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.

Re:Programming in C++ on Linux (4, Insightful)

mingot (665080) | more than 9 years ago | (#11665451)

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 (1)

dejavudeux (855613) | more than 9 years ago | (#11665503)

>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). This is a real annoyance for me, too. I've searched through the dialogs a little and didn't find it. (Although if I program with the IDE a little more I would just Google for the option.) Incidentally, another quick hack you can use in this situation is to add a std::cin.getline() at the end of the program. However, I feel bad saying that because you'll be far more productive in the long run if you just look it up.

Now with paragraphs! (1)

dejavudeux (855613) | more than 9 years ago | (#11665516)

Sorry, I got lazy and decided for the first time not to preview. That will teach me.

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

This is a real annoyance for me, too. I've searched through the dialogs a little and didn't find it. (Although if I program with the IDE a little more I would just Google for the option.)

Incidentally, another quick hack you can use in this situation is to add a std::cin.getline() at the end of the program. However, I feel bad saying that because you'll be far more productive in the long run if you just look it up.

Re:Programming in C++ on Linux (1)

MidnightBrewer (97195) | more than 9 years ago | (#11665686)

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) before I'm as fluent in it as I was in the previous software, which I've been using for seven years. The workflow is different, the terminology is different; it's a lot like learning a new programming language.

You get comfortable with your tools, it's going to take you a while to get used to new ones. It has nothing to do with your ability as a programmer.

Re:Programming in C++ on Linux (1)

BlurredWeasel (723480) | more than 9 years ago | (#11665486)

I am taking a class right now focusing on Linux C++. As far as I can tell, C++ is rather standardized (nowhere near Java though...).

The things that are standard are the basic syntax and structure (declaring variables/classes/everything). The other thing that is standard is the STL and a few standard functions left over from the C days.

The things that aren't standard are the system libraries. So in windows when you use MFC and similar (I don't program windows, don't jump on me about windows junk), or in linux when you program against GTK, or QT, you need those libraries in Windows. Similarly, if you wanted to compile windows apps in linux, you'd need those windows libraries. The problem being that you can't get windows libraries in linux.

Wine tries to provide those libraries to already compiled programs so that they can run, but honestly it isn't very good for anything non-standard (but definatly getting better by the day!).

Hope this clears up the universe and shown you how programming windows via windows apis is a bad idea in terms of portabilty.

Re:Programming in C++ on Linux (1)

ccoakley (128878) | more than 9 years ago | (#11665644)

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 which the method Character.isJavaIdentifierPart returns true.

You could iterate through all characters (not that you can really do that for all Unicode character sets... but anyway...), and Sun could change their mind and say, "Naw, that's no longer a valid letter." Changing Character's static methods would keep the spec correct but change the lexical rules of the language.

OK, your meaning was actually obvious, just ranting...

Incidentally, the Win32 APIs *are* a standard. ECMA standardized them many years ago (yes, they have changed since). None of the GUI libraries for linux are standard (I may be full of shit, X may be recognized by a standards body). Of course, this just means that ECMA really is a "Standards for sale" organization.

Re:Programming in C++ on Linux (1)

Mystic0 (807930) | more than 9 years ago | (#11665488)

C++ is not supposed to be portable. Don't expect the Deitel examples to always work if they are designed for a Windows enviornment.

I don't know of any Unix / Linux specific C / C++ book, but considering that C was originally meant to be used in a Unix environment, you should have no trouble using it in a Linux enviornment if the book is a traditional C / C++ Unix book and isn't clobbered with Windows junk. "The C Programming Language", by Kernighan and Ritchie comes to mind.

Your instructor sounds like he is unfamiliar with your school's software. This is unfortunate, because that software costs money and it is a shame to have it go to waste.

A good, free, Windows IDE is Bloodshed Dev-C++, which is basically the GNU C Compiler bundled with a GUI. It's quite nice, and it's free. On Linux, well, I just use a text editor and a terminal. But there are IDEs out there if that's your inclination.

Here is a link to the Dev-C++ page: http://www.bloodshed.net/devcpp.html [bloodshed.net]

Re:Programming in C++ on Linux (2, Insightful)

Mystic0 (807930) | more than 9 years ago | (#11665501)

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.

Re:Programming in C++ on Linux (0)

Anonymous Coward | more than 9 years ago | (#11665557)

Don't forget that even the console is OS specific (MacOS 9 or embedded for example). So, congrats, you've just written a useless program.

How to port CLI programs to OS 9 (2, Informative)

hunterx11 (778171) | more than 9 years ago | (#11665699)

#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 (1)

creimer (824291) | more than 9 years ago | (#11665626)

Your instructor sounds like he is unfamiliar with your school's software. This is unfortunate, because that software costs money and it is a shame to have it go to waste.

After waiting three years for funding, the school finally upgraded from Visual Studio 6. Seems like all the instructors are having a hard time adjusting to the new IDE since the upgrade took place over the winter break. If the upgrade happened over the summer break, I think the instructors would've been better prepared.

Classes that uses programming languages that can be downloaded free (i.e., Java, Javascript, Perl, etc.) are usually more current since you're not tied to an platform- and/or language-specific IDE.

Re:Programming in C++ on Linux (1)

izakage (808061) | more than 9 years ago | (#11665665)

Thank you for pointing me towards "The C Programming Language" book. My dad had purchased it tens of years ago, but never got around to messing with it, and I had noticed it in his bookshelf many times when I was younger. You've inspired me to pick up the book and start learning. Thanks.

Re:Programming in C++ on Linux (4, Informative)

spectecjr (31235) | more than 9 years ago | (#11665494)

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 (0)

Anonymous Coward | more than 9 years ago | (#11665514)

Or you can put a simple system("pause"); at the end.

And that's not a DOS box, it's a command prompt (on Linux, you would call it bash, shell, terminal)

Re:Programming in C++ on Linux (1)

EvanED (569694) | more than 9 years ago | (#11665540)

Which will run really well when you try compiling it with another compiler...

Re:Programming in C++ on Linux (0)

Anonymous Coward | more than 9 years ago | (#11665544)

He said they are using VS.NET

Re:Programming in C++ on Linux (1)

EvanED (569694) | more than 9 years ago | (#11665563)

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 (0)

Anonymous Coward | more than 9 years ago | (#11665584)

No, was he said was:

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

Something like this couldn not occur on Linux (and system("pause")) wouldn't matter because you have to run that app from the shell.

Re:Programming in C++ on Linux (1)

miyako (632510) | more than 9 years ago | (#11665504)

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 (1)

AmberBlackCat (829689) | more than 9 years ago | (#11665506)

I was using CodeWarrior, Visual C++, and GCC and my main professor was a Linux guru who despises Windows. From what I can remember, Visual C++ was the most troublesome. I think it would be a good idea to set your compiler to only accept ansi C++ code because that's what GCC handles. If that doesn't work then try downloading DJGPP [delorie.com] . It's like a DOS version of GCC. If you can get your code to compile on that, it will probably compile on GCC. And it's been a while since I used GCC but I'm pretty sure you have to type G++ instead of GCC to compile C++ code instead of C code, just in case you didn't know.

For book recommendations, I think your Deitel book is fine because ansi C++ is crossplatform as long as you're not including unistd.h or windows.h or whatever that other unix include file is.

I hope that helps.

Re:Programming in C++ on Linux (2, Informative)

vistic (556838) | more than 9 years ago | (#11665522)

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 (1)

CodeBuster (516420) | more than 9 years ago | (#11665532)

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 in the foot if you do not fully understand the language and the ins and outs of your compiler. That is why I now tend to avoid it, if possible, in favor of more modern languages such as Java or C#. You give up some fine grained control and speed but frequently the gain in productivity is worth the small price that you pay (you can often do in a few lines of Java what might have taken 50 or 100 lines of C++).

Re:Programming in C++ on Linux (1)

creimer (824291) | more than 9 years ago | (#11665570)

That is why I now tend to avoid it, if possible, in favor of more modern languages such as Java or C#.

I prefer Java a whole lot better and I'm also taking Java Servlets this semester. But resume-wise I'm trying to broaden my prospects by taking other programming language classes and then specializing on whatever language is being used at the next job.

I recently had an interview for a testing/programming position at one of the local software companies. If I get the job, Javascript will be my bread-and-butter programming language for a while.

Re:Programming in C++ on Linux (0)

Anonymous Coward | more than 9 years ago | (#11665595)

So you're saying code that compiles in VC++ won't compile in gcc? It might be this:

In VS.NET 2003 (I have not used prior versions), a default c++ win32 console application has all kinds of extra crap in it. Your empty program looks like this to begin with:

#include "stdafx.h"

int _tmain(int argc, _TCHAR* argv[])
{
return 0;
}

Make sure when you first start the project to click Application Settings and then select empty project...this will give you a 100% empty c++ project.

Visual C++ sucks... (1)

katharsis83 (581371) | more than 9 years ago | (#11665600)

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.

My Java Programs Port Really Nice (5, Insightful)

Apoptosis66 (572145) | more than 9 years ago | (#11665429)

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

Apoptosis

A nice idea, but.. (1)

gayak (745124) | more than 9 years ago | (#11665453)

I'm not that surprised IBM releases something like this, and looking at the documents, they seem well written. Yet they only seem to scratch the surface, and help porting the "background" part of the program. Porting the GUI will be an ultimate challenge anyway, there's no easy to way to port Win32-calls to X. And even the actual program will take a lot more than just what's told in these 2 parts. How many are they going to release, 2^n ? Somehow seems more like a marketing tool instead of real usage. Obviously someone from /. was going to post this article here, and the document has done it's publicity stunt. Offtopic, first article was released in June 2004. If it takes 8 months to write a short addition to it, how long would it take to actually port something?-) And will "part 3" in 8 months bring again new headlines to /. by some moderator hoping for Microsoft's death? - Yak

Re:A nice idea, but.. (1)

Anonymous Coward | more than 9 years ago | (#11665489)

The easiest way to port Win32 GUIs is using Wine [winehq.org] . Also, if one was going down this route one might also question the logic of going to the trouble of porting the file/mmap/synchronisation functions away from Win32.

But... (0, Flamebait)

Duncan3 (10537) | more than 9 years ago | (#11665456)

What's funny is that all the "Linux" code will compile fine on Windows with Services for UNIX installed correctly.

Windows and OS X will already compile and run 99% of all Open Source code anyone cares about.

Re:But... (2, Insightful)

Anonymous Coward | more than 9 years ago | (#11665691)

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.

Good For Porting Example Code (1, Insightful)

Anonymous Coward | more than 9 years ago | (#11665466)

While well meaning, the articles are only really useful for porting example code.

In reality, any large codebase will interact with APIs that don't have any mapping to Linux APIs, such as GUI components, services, and the registry. I can't think how these articles would be useful without wrappers for the above types of functions, and anyone familiar enough with Linux and Win32 application developement to write these wrappers will already know the equivalent Linux functions for Win32 functions.

To make matters worse, the first article is riddled with typos.

Should be: Migrating an App the Worst Possible Way (4, Insightful)

IrresponsibleUseOfFr (779706) | more than 9 years ago | (#11665470)

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:Should be: Migrating an App the Worst Possible (2, Informative)

kormoc (122955) | more than 9 years ago | (#11665521)

Then look to see if somebody implemented a Win32 on Linux library next to recompile (like Cygwin in reverse).

Winelib [winehq.com] is the tool you are looking for.

Re:Should be: Migrating an App the Worst Possible (0)

Anonymous Coward | more than 9 years ago | (#11665568)

> it is making a wild assumption that your win32 app is written in a that is conducive to a Unix/Linux process model

Just read it in reverse and you can now easily port Linux apps to Windows!

Re:Should be: Migrating an App the Worst Possible (3, Insightful)

GbrDead (702506) | more than 9 years ago | (#11665698)

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

Why Not Port Wine?!? (4, Informative)

vinn (4370) | more than 9 years ago | (#11665472)

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?!? (3, Informative)

bombshelter13 (786671) | more than 9 years ago | (#11665499)

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?!? (5, Informative)

entrigant (233266) | more than 9 years ago | (#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.

Re:Why Not Port Wine?!? (2, Insightful)

Soko (17987) | more than 9 years ago | (#11665538)

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 being painted?

Soko

Re:Why Not Port Wine?!? (0)

Anonymous Coward | more than 9 years ago | (#11665590)

IBM still has not provided a reasonable alternative for x86 server hardware, which is why their x86 server division still is a very prominent part of their business (judging by the advertisments).

Why exactly would someone run Linux on Power? (Unless they are migrating from AIX or need a very large system) -- it seems that Linux/Power and Win32 are two entirely different markets.

Re:Why Not Port Wine?!? (0)

Anonymous Coward | more than 9 years ago | (#11665547)

Because Wine is not an emulator... it depends on the CPU architecture. If you port the source it will run on any CPU version of Linux.
Have you really not discovered why IBM is interested in Linux ??
Linux run on ALL IBM HW...

It'd be nice.... (1)

yuriismaster (776296) | more than 9 years ago | (#11665473)

But realize one thing: sometimes those libraries make your life SOOOO much easier to program. When you're writing a GUI (even in Java), certain libraries make the process much more simplistic. Window Handlers, Toolkits, and other toys exist to make the coders life much easier.

If we didn't make these libraries, we'd all still be coding our temperature converter GUI in assembly and it'd be ugly and broken and would take 1000 times as long to code.

I dont claim to know much about the differences between Linux and Windows, but my guess is that when you build an app for windows, using windows' libraries makes the whole thing snap together well. (which actually presents a security hole, but if those libraries were written well...)

If you want to make code portable, you sometimes have to give up the tricks provided by the operating system. That is why, I suppose, that standards-based applications are 'better' because any app written to that standard can be used in any other app written to that standard. Windows may accept those standards, but you can bet your ass they aren't going to translate THEIR standards into OUR standards. </aimless rant>

Re:It'd be nice.... (1)

starfishsystems (834319) | more than 9 years ago | (#11665697)

This is also why so many applications are now designed for the web. In effect, it takes care of the portability layer. For the cases where you really only want something like a "temperature converter GUI" it seems like an ideal solution.

It's such a compelling solution for these cases that I think the industry tends to want to shoehorn all applications into this form. And I find nothing more pathetic than the misapplication of a perfectly good idea to the wrong problem.

Design for Portability (3, Interesting)

RotateLeftByte (797477) | more than 9 years ago | (#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.

good point, why not separate GUI from core? (1)

thrad (829144) | more than 9 years ago | (#11665597)

In my opinion, GUI is not all that important part in the software. Yet, nowdays its really impossible to make portable (unless you use java for gui, which hardy a good choice). So why not logically separate GUI from app core?

Good example of that is mldonkey. Their server-client does not come with any gui by default, but it just provides an network interface (tcp) for it. So there are thosounds of GUIs now for all the platforms, and they work great.

Not to mention technologies like j2ee :)

Re:good point, why not separate GUI from core? (0)

Anonymous Coward | more than 9 years ago | (#11665666)

Well that approach might work for midonkey (which has very limited user interaction), but try it with a word processor.

Many Windows apps are basically entirely "front-end" code -- think VB database apps and so on. They are already seperated, but that doesn't make a rewrite cheap or easy.

Linus Torvalds vs Andy Tanenbaum (0)

Anonymous Coward | more than 9 years ago | (#11665539)

This article reminds me of the famous flaming between MINIX author and Torvalds. And I quote Linus:

"Portability is for people who cannot write new programs"
-me, right now (with tongue in cheek)

http://groups-beta.google.com/group/comp.os.mini x/ browse_frm/thread/c25870d7a41696d2

Where did this come from? (4, Informative)

bigberk (547360) | more than 9 years ago | (#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 [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.

WINE compile against (3, Interesting)

Anonymous Coward | more than 9 years ago | (#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?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...