不管哪家的编译器，都要独家设计在指定平台上的库支持，比如scanf()/printf()函数的实现，是调用宿主操作系统的API，不是C库自己的。gcc编译器在Linux和Windows上都有版本，它怎么编译代码，在高级层面上是一致的，但到了执行阶段，比如同样是调用printf()函数的代码，则相当于旧DOS时代的中断（亦即所谓API调用），那段实际执行的机器码是在Windows平台上的可执行码（调用User32.DLL），那不是gcc自己的，而是MS的，其行为和效率也一样的MS的（同样Borland在Windows上的编译器也都是这样）。C语言的可移植性是在这种重编译基础上说的。
同一段程序代码，在Linux上用gcc编译后的exe文件不能原封不动地拿到Windows上执行，必须在Windows版本的gcc编译器上重新编译一次才可以，反之亦然。道理如上述。事实上，没有任何C编译器可以脱离操作系统的控制，也没有什么纯C语言版本，你在Windows上跑，就在Windows的法律框架下做人做事，不要用着MS的可执行代码诅咒MS，很低级的。说MS不支持这标准那标准，但其实只要你用Windows平台上的gcc编译出来的程序能顺利执行，就表明Windows支持了该标准，是它自己推荐的编译器不认可那些标准而已（标准的制定只是建议，当厂家和程序员不屑于某种标准的时候，它就是废的）。编译器不支持，不等于该操作系统平台也不支持，你要支持，可以用我的规则来实现它，在你自己的编译器上支持就是了。没有什么软件和程序可以逃过那3个DLL的控制，除非你黑掉了它们。
[ 本帖最后由 TonyDeng 于 2014-6-8 21:28 编辑 ]
同一段程序代码，在Linux上用gcc编译后的exe文件不能原封不动地拿到Windows上执行，必须在Windows版本的gcc编译器上重新编译一次才可以，反之亦然。道理如上述。事实上，没有任何C编译器可以脱离操作系统的控制，也没有什么纯C语言版本，你在Windows上跑，就在Windows的法律框架下做人做事，不要用着MS的可执行代码诅咒MS，很低级的。说MS不支持这标准那标准，但其实只要你用Windows平台上的gcc编译出来的程序能顺利执行，就表明Windows支持了该标准，是它自己推荐的编译器不认可那些标准而已（标准的制定只是建议，当厂家和程序员不屑于某种标准的时候，它就是废的）。编译器不支持，不等于该操作系统平台也不支持，你要支持，可以用我的规则来实现它，在你自己的编译器上支持就是了。没有什么软件和程序可以逃过那3个DLL的控制，除非你黑掉了它们。
[ 本帖最后由 TonyDeng 于 2014-6-8 21:28 编辑 ]
授人以渔，不授人以鱼。
