Everyone (who knows C) always tells me to be careful when using gcc to compile on Windows, yet they never actually tell me what the compatibility issues are. I'm left to believe that gcc is just 'not optimal' for Windows usage.

I've already designed several applications using gcc, and everything seems to work fine. Currently, I am about to publish a package that has to be cross platform, and now I have to know the discrepancies that might arise between gcc and Windows.

Keep in mind that I use mingw32, which is designed for windows.

closed as too broad by user22815, gnat, Doc Brown, Ixrec, Bart van Ingen Schenau Mar 22 '16 at 8:19

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 7
    Maybe you should ask those people to back up their assertions. Not because they are necessarily right or wrong, but simply to learn their reasoning. – user22815 Mar 21 '16 at 19:41
  • When you do not know what those people want you to be careful for, how shall we? Or do they mean "careful if you want to keep your code cross-platform"? Of course, that is true, but that is also true for Java, Python, Perl, C#, or any other language which can be used for cross-platform development. – Doc Brown Mar 21 '16 at 22:28
  • @Snowman Yeah I do, and they say that is just 'is'. – Nick Pandolfi Mar 22 '16 at 0:36
  • @Doc Brown Yeah I'm sorry, I don't know, thus the question. – Nick Pandolfi Mar 22 '16 at 0:37
  • Just remember not to use back slashes and you should be good... – Snoop Mar 22 '16 at 2:05

There are many variations between UNIX-like operating systems and Windows. GCC is most commonly used on UNIX-like operating systems. There are situations where defaults are chosen in tools or code that are only relevant on that type of operating system. A simple example would be the separator for directories in a directory tree. In DOS/Windows environments it's a \ while in UNIX environments it's a /. A slightly more complex example might be a library looking for a system setting in /etc/* (standard location for UNIX) versus calling a system call to retrieve that setting from within Windows. However, both of my examples above here are specifically about the code compiled BY GCC vs VisualC and NOT anything to do with the compilers themselves. Many people confuse the compiler with the compiler plus the libraries that are often distributed with it. GCC will compile code just fine for use on Windows. GNU's LibC will usually (not always) work for cross compiling to Windows as long as you have an intermediary level for it to work with like MinGW. Beyond that, other libraries that work with GCC may or may not be portable so use them at your own risk.

Another way to look at this issue is this: GCC and the libraries associated with it often take portability into account and, therefor, allow us to write portable code. Microsoft's Visual C and the libraries associated with it almost never take portability into account and, therefor, pretty much always limit your code to Windows. That said, which would you want to use?


This is quite possibly a calling convention issue as the Linux and Windows differ despite using the same x86 CPU. Even with code generated for the same instruction set, two pieces of code compiled for different calling conventions will sometimes but not always be able to successfully call each other.

Calling convention differences usually occur in passing/returning of structs and floating point values, and groupings of CPU registers into caller vs. callee saves. (When there is a material difference between conventions for some signature, garbage without warning will be the result.) (There may also be potential differences in alignment of field in structs, i.e. where padding goes).

(Windows also has several alternate calling conventions used in certain system calls).

Look further into "calling conventions", and "ABI" (application binary interface).


If you want a program to be portable you have to be careful to stick to functions that are defined in the standard for the C runtime, and even those functions may behave slightly differently on Windows versus other platforms. One of the most common headaches is that UNIX style systems expect lines terminated by a line feed, while Windows expects a carriage-return/linefeed pair.

Operating Systems vary widely in the API they provide, so outside of the C standard runtime, there is no guarantee that a particular function will be supported across platforms. For example, the fundamental function for process creation on UNIX style systems is fork(), and on Windows, it's CreateProcess(). The two functions have very different behaviors.

Microsoft's MSDN provides some advice on porting between Windows and UNIX.

Not the answer you're looking for? Browse other questions tagged or ask your own question.