linux and windows c++ difference.

Question

Hi is c++ different in linux to windows? I mean theres some obvious differences that I can already see from file extensions, like .exe and .dll, etc. I dont know what are the linux equivalent yet but I believe those win extensions are not goin to work in linux. Im still not sure but Im thinking on creating a program/game with linux as my primary os, then release the program/game both for windows and linux. or you can add mac for extra credit. haha ;)

Answer 1

Hi @Evil Minion (I hope not too evil!)

To develop the same app for Windows and Linux (and you can just extend this process for more OS's), you would normally do something like the following:

1. Install same standard C++ compiler on all OS's (lets say C++14).
2. Install IDEs of your preference on each Platform. Lets say CodeBlocks on Linux and Visual C++ on Windows (just to use a complicated example ;)
3. Create a C++ project in IDE on one OS (lets say CodeBlocks).
4. Create the necessary cpp/hfiles. Make sure you encapsulate the Linux specific stuff in separate cpp/h sources so that it does not contaminate the "common" cpp/h sources.
5. Build+debug+test+repeat until you are happy your Linux app is OK.
6. Create C++ project in IDE on next OS (Visual C++ this time).
7. Add the "common" cpp/h files developed in CodeProject project to your project.
8. Write the equivalent Windows specific stuff cpp/h sources for the Visual C++ project.
9. Build+debug+test+repeat until you are happy your Windows app is OK.

I recommend you try to use the exact same"common" cpp/h source files from both the Visual C++ and CodeBlocks projects. So you have to make sure you handle the <CR><LF> line break differences between the 2 OS's in your IDE setups.

If you end up with separate copies of the "common" cpp/h source files on each OS you will keep having to "back"-port any changes you make to the equivalent file on the other OS.

You can also abstract any OS specific calls to identical wrapper functions you write yourself - one for each OS - that calls the correct OS specific call. Your "common" code just calls these wrapper functions, which isolate the "common" sources from OS specific pollution.

The above works quite well, and it is the reason why C++ is quite portable at the "source code" level.

Answer 2

It is not as simple as that.

Firstly, C++ is standardized by ISO, so there are different versions of the standard. The last few releases are C++14 (2014), C++11 (2011), C++03 (2003) and C++08 (1998), and so on. (C++17 has not been released yet).

All C++ compilers implement some version of the standard, and the source code (your *.cpp, *.h files) should be portable between different OS's and be compilable by compilers that support the same (or higher) C++ standard.

But even here you have to be careful since Windows uses different line-break characters (<LF><CR>) than Linux (<LF> only). So your editor/IDE needs to be able to handle this else all your source code ends up on one line!

C++ standard is backwards compatible so a C++14 compiler will be able to compile source code written to comply with C++03 standard.

Then, as you noticed, the binaries produced by the compiler (*.exe, *.dll in windows; *.so in Linux (similar to dll, exe's do not have a specific extension in Linux)) are different. The reason for this is that the C++ standard does not specify the ABI as part of the standard (the ABI is the "application binary interface" i.e. the interface at the binary level).

This gives rise to all kinds of challenges, even on the the same OS! For example, this means that there is no standard way the compiler will mangle function names (since C++ function overloading requires name mangling). This means that you cannot just call a member-function from an exported class in a DLL compiled by GNU g++ from an EXE compiled by Visual C++, even with both being compiled on the same PC under the same OS!

There are other complications as well but, in short, you nearly always have to specify calling conventions on exported DLL functions for the above to work (see https://en.wikipedia.org/wiki/X86_calling_conventions), even on the same OS!

Then your source code must not make OS-specific library calls, etc.

The short answer is only the source code (cpp/h) files are portable between different OSs!

Answer 3

Hi @Evil Minion

I forgot to mention: if you are lucky IDE A may be able to import the project from IDE B.

For a complicated project with lots of cpp/h sources this will reduce the amount of work required, but it will not completely remove the requirement to edit the project after the import, since the (wrong) OS specific cpp/h sources will still be present in the new project.

For example, CodeBlocks can import Visual C++ projects, but not the other way round. In this case it will be better to do the VC++ (Windows) project first, and then import this project in full into CodeBlocks IDE (Linux in our case).

You then have to edit the project in CodeBlocks to remove the Windows specific stuff and add the Linux specific stuff.

Come to think of it, you may even have to edit the "common" windows/Linux header files if some platform specific options are specified in the headers.

For example, VC++ will always generate the following #include at the top of every header file if "Make precompiled headers" option is enabled in the Project setting:

#include "stdafx.h"

The g++ compiler in Linux will fail on this, so you will need to limit its inclusion to Visual C++ only, i.e. like this:

#ifdef (_MSC_VER)
#include "stdafx.h"
#endif

_MSC_VER is #defined by the Visual C++ compiler itself and will not be defined under g++, so the header will only be included under Visual C++. and you can use g++ specific #defines to achieve the same in the other direction.

You will also need to use this technique if you #include different 3rd party libraries on the 2 platforms, but which supply the same functionality.

But all of this are very common portability issues - nothing fancy going on here!

Answer 4

Hi thanks for the reply. Correct me if im wrong. So I need to write the entire code from scratch, having the fact that a lot of file extensions and call function is different from each OS? Or can I just change those file extensions and call functions then recompile it to run on a specific platform?

cause Im not planning to create just a single application that will run straight on different operating system. What Im looking forward to, is to create an application one for each platform. a copy of the app/game for windows and a copy of the app/game recompiled to run specifically for linux. remember when you download a certain app, and the download page in the website gives you a version of the app for windows, linux and mac.

ps; dont get me wrong I really appreciate your help. Im new and I know you know a lot better than me. But please just tell me if its possible or not. dont tell me if its easy or hard. cause it doesnt really matter to me if its hard or not. Ill figure it out. or maybe you find the way I ask question too light for a big subject, then Im sorry. Thanks for your reply man! your awesome ;D