Windows vs Linux

Do I need to know about the OS I am programming for? If I want to program for Windows in C++ should I know more about Windows? If I want to program in Linux using C++ do I need to know about the Linux platform?

What are you really asking? Do you want to write cross-platform software?

I want to write programs that are for both Linux and Windows. Say I have a web page with download links. There are 2 download links for the same program. One for Linux and one for Windows. That's what I'm looking forward to doing.

Since on such a hypothetical website you are providing two individual links for two separate operating systems then inevitably that does mean that you want to make your programs independent of anything that makes them cross platform(Or else why would you need two separate links right?). Those two different client will have to be reprogrammed to work with what ever platform it is you need it to work on. So unless you want to write your code using a cross platform GUI library then you will basically have to learn to write code for both windows and linux.

It takes a little bit of effort to set up correctly (be careful to read and follow the directions in the documentation), but once you do you can install any version of Linux you want and use it to compile your program natively, which is much less grievous than trying to cross-compile.

It is impossible to provide an executable for every possible *nix system out there, so choose the ones you want to support and compile for them.

As for the code itself, the differences between OSes depend on what you are doing, exactly. If your program is basically an SFML game, or the like, then you don't really need to do much to recompile -- platform differences are fairly well abstracted away for you.

If you are doing something like writing a text editor, then you need to be much more aware of how to work with the native window manager.

The best way to become familiar with the issues is to begin programming and trying to compile for each system.

Since on such a hypothetical website you are providing two individual links for two separate operating systems then inevitably that does mean that you want to make your programs independent of anything that makes them cross platform(Or else why would you need two separate links right?). Those two different client will have to be reprogrammed to work with what ever platform it is you need it to work on. So unless you want to write your code using a cross platform GUI library then you will basically have to learn to write code for both windows and linux.

I'd suggest focusing on the Windows platform first. Not only will it be a larger market\user-base but the *nix guys know that they have WINE which is a truly awesome creature. If you do end up going cross-platform then learning how to script for CMake will make it a lot easier for your users to compile your project (very few people enjoy downloading and running random binaries they find online). The syntax for CMake is already cross-platform so you won't have to write it twice.

WINE is quite finicky, unfortunately, and I speak as someone who uses it whenever I need to run a Windows application that there's no *nix equivalent for. Some applications work better than they do on Windows, but more often than not issues arise.

I personally would recommend picking up a good cross-platform library for what you're trying to do (if on is available) and learning that, rather than learning a Windows-specific API and then a *nix-specific API. That way, your code will port a lot more elegantly.

I wouldn't dismiss the input from Albatross right away, that is another valid option (and one that most people on this site choose for themselves). Cross-Platform libraries in fact are one of the main reasons tools like CMake exist and are so popular, so the user can just grab the code written for that cross-platform API and compile it on their system which all but guarantee's compatibility. The problem with cross-platform API's though is the same one with cross-platform frameworks and that is that you sometimes run into pretty significant changes between versions that end up with you tearing down entire sections of your code and redoing them.

I personally would recommend picking up a good cross-platform library for what you're trying to do (if on is available) and learning that, rather than learning a Windows-specific API and then a *nix-specific API. That way, your code will port a lot more elegantly.

There there, Computergeek. Just because you're not a Java fan (I'm not either) doesn't mean it's completely horrid. :P

@kingcong
That depends on what you mean by "as portable as". Generally, you can't really create binaries that will work seamlessly across all operating systems without some additional software on the machines you're trying to run them on. As far as the portability of the actual source code goes... well, that depends on the libraries you choose!

Firstly, make the program run well on your "Native" PC.
Like, if you usually program on Windows, use Windows.
If you usually do it on Linux, use Linux.

Then, try to use the most standardized things around.
E.G., everything that lies in namespace std, RARELY needs changes between Operating Systems.

Usually it's about forcing forward-slashed paths on Unix.

When you go using GUI's, don't go with the native headers.
Find a crossplatform library (GTK+ is very suggested from me, but also QT and wxWidgets are widely used).

About compiling, if you want to provide binary files you usually need to go on the target operating system (Unless you cross-compile but that's a bit harder to do, and/or to debug).

Just try as hard as you can to use cross-platform libraries and you'll be good to go.
They have been MADE to be cross-platform, don't just ignore them.

If you want java-like porting, you should probably choose QT, but you will need a lot of HDD space... and a good internet bandwidth.

About java, it's one of the most love-hate languages over here.

Love, because of its portability.
Hate, because it requires end-users to install the Java Runtime Environment, and developers to install the Java Development Environment, because it's easier to de-compile than C/C++, and because (usually) it performs bad and requires more RAM than a native equivalent.