事实上很多情况下MinGW已经够了（因为值得移植的程序通常不会包含太多与系统结合紧密的部分，完全可以使用条件编译来支持不同平台），此时Cygwin中完整的POSIX反而成了累赘。
引用
评论
Visual C++可移植性报告
Visual C++的特点：
窄字符只支持单字节编码(如1252/437)和双字节编码(如GBK)，不支持UTF-8
增加了很多宽字符函数，比如_wfopen，wmain，只有使用这些函数才能兼容Unicode
当年16位/Win9x编程需要使用GBK等双字节编码，为了正确处理这种编码，添加了一些MBCS函数，如_mbscpy、_mbsstr等
为了16位/Win9x与WinNT移植方便，添加了通用字符类型TCHAR和通用函数宏定义如_tfopen，写一套代码就可以生成两个版本的程序
POSIX函数大多有下划线前缀，如_creat
针对Windows系统和编程的方便性添加了很多增强函数，如_chdrive，_getdcwd，_strrev等
对文本的处理要转换换行符，并且有UNICODE/UTF-8/UTF-16LE模式
POSIX程序移植到Visual C++，会发现的问题：
1.不支持Unicode和UTF-8，只能支持系统默认的单字节/双字节编码，然而经常无法正确处理双字节编码
2.需给POSIX函数添加下划线，如creat变为_creat
3.很多POSIX函数无法使用(如fork)，需更新代码
Visual C++程序移植到POSIX也会有困难：
A. 程序不使用Unicode：可能可移植，移植后支持UTF-8，需改POSIX函数名，有些函数(如_getdcwd)无法使用
B. 程序使用Unicode：大多数情况下不可移植
C. 程序使用MBCS：不可移植
D. 程序使用TCHAR：可能可移植，移植后支持UTF-8，需重新编写tchar.h，需改POSIX函数名，有些函数(如_getdcwd)无法使用
编写Windows/Linux可移植程序比较现实的方法：
1. 使用Cygwin
2. 使用Java
3. 使用Qt (限图形界面)
4. 使用Python
5. 使用.NET Core/Mono-Xamarin (可能只有文本界面)
不推荐使用MinGW编译器，因为它是把一个POSIX C++编译器嫁接到了VC++ Runtime上。
如果想使用Visual C++，就不要追求可移植性了，因为可移植的都是古代部分，现代部分根本就不可移植。
窄字符只支持单字节编码(如1252/437)和双字节编码(如GBK)，不支持UTF-8
增加了很多宽字符函数，比如_wfopen，wmain，只有使用这些函数才能兼容Unicode
当年16位/Win9x编程需要使用GBK等双字节编码，为了正确处理这种编码，添加了一些MBCS函数，如_mbscpy、_mbsstr等
为了16位/Win9x与WinNT移植方便，添加了通用字符类型TCHAR和通用函数宏定义如_tfopen，写一套代码就可以生成两个版本的程序
POSIX函数大多有下划线前缀，如_creat
针对Windows系统和编程的方便性添加了很多增强函数，如_chdrive，_getdcwd，_strrev等
对文本的处理要转换换行符，并且有UNICODE/UTF-8/UTF-16LE模式
POSIX程序移植到Visual C++，会发现的问题：
1.不支持Unicode和UTF-8，只能支持系统默认的单字节/双字节编码，然而经常无法正确处理双字节编码
2.需给POSIX函数添加下划线，如creat变为_creat
3.很多POSIX函数无法使用(如fork)，需更新代码
Visual C++程序移植到POSIX也会有困难：
A. 程序不使用Unicode：可能可移植，移植后支持UTF-8，需改POSIX函数名，有些函数(如_getdcwd)无法使用
B. 程序使用Unicode：大多数情况下不可移植
C. 程序使用MBCS：不可移植
D. 程序使用TCHAR：可能可移植，移植后支持UTF-8，需重新编写tchar.h，需改POSIX函数名，有些函数(如_getdcwd)无法使用
编写Windows/Linux可移植程序比较现实的方法：
1. 使用Cygwin
2. 使用Java
3. 使用Qt (限图形界面)
4. 使用Python
5. 使用.NET Core/Mono-Xamarin (可能只有文本界面)
不推荐使用MinGW编译器，因为它是把一个POSIX C++编译器嫁接到了VC++ Runtime上。
如果想使用Visual C++，就不要追求可移植性了，因为可移植的都是古代部分，现代部分根本就不可移植。
[ 修改于11年0个月前 - 2015/11/29 20:24:49 ]
引用 金星凌日:事实上用MinGW做移植和用VC++直接做移植是一样的效果。。。因为MinGW是基于MSVCRT的。。。
事实上很多情况下MinGW已经够了（因为值得移植的程序通常不会包含太多与系统结合紧密的部分，完全可以使用条件编译来支持不同平台），此时Cygwin中完整的POSIX反而成了累赘。
条件编译多了不利于管理，编程起来也相当麻烦，从实用性的角度来说，直接使用原生C/C++跨平台不是一个好选择。。。
通常使用Cygwin/Java/Qt/Python/.NET Core等可以把平台差异隐藏起来的编程方法会更方便。。。
引用
评论
引用 acmilan:如果只考虑编译器，那你说的还算比较正确。但问题在于，可移植程序需要的不仅仅是一个编译器，而是完整的工具链。
事实上用MinGW做移植和用VC++直接做移植是一样的效果。。。因为MinGW是基于MSVCRT的。。。
条件编译多了不利于管理，编程起来也相当麻烦，从实用性的角度来说，直接使用原生C/C++跨平台不是一个好选择。。。
通常使用Cygw...
MinGW通常会与MSYS一起使用，因而可以直接用开源软件中常见的automake，而VC++就不行。
引用
评论
引用 金星凌日:然而可以同时支持automake、msbuild、cmake等多种构建工具，支持不同工具链也是条件编译的一个方面。。。
如果只考虑编译器，那你说的还算比较正确。但问题在于，可移植程序需要的不仅仅是一个编译器，而是完整的工具链。
MinGW通常会与MSYS一起使用，因而可以直接用开源软件中常见的automake，而VC++就不行。
引用
评论
引用 acmilan:Mono只是某些跟系统关系太深的控件不能用 比如webbrowser
然而可以同时支持automake、msbuild、cmake等多种构建工具，支持不同工具链也是条件编译的一个方面。。。
引用
评论
引用 张静茹:Mono的Windows Forms是用什么技术支持的？
Mono只是某些跟系统关系太深的控件不能用 比如webbrowser
WPF好像需要DirectX支持，一直没有移植过去，XAML的只有Silverlight可以使用。。。
.NET Core好像是只有文本界面的，轻量级可移植，并不是像Mono那样完整复制.NET框架。。。
引用
评论
引用 acmilan:不知道,我在windows下用.net写的exe,拖到已经装了mono环境的Ubuntu系统中 直接就能运行,
Mono的Windows Forms是用什么技术支持的？
WPF好像需要DirectX支持，一直没有移植过去，XAML的只有Silverlight可以使用。。。
.NET Core好像是只有文本界面的，轻量级可移植，并不是像Mono那样...
我爱死.net了
引用
评论