前进中……
今天把在VC下写的jpeg文件发送程序移植到Linux下面，碰到了一个问题，找了n久原因，才发现原来是定义的一个结构体中的数据类型在VC和Linux中不匹配所致（具体说来是BOOL 和 bool），后来把他们都改成与街哦股无关的uint8_t才成功。
下面引用一篇文章，讲了VC程序移植到Linux下要注意的一些问题。
zz:http://www.xxlinux.com/linux/article/development/soft/20080528/14472.html
| 将VC程序移植到Linux系统的几点经验心得 |
有时我需要制作LINUX与WINDOWS下都可以运行的程序。在一般情况下，我会选择在WINDOWS平台下完成初始的开发。因为VC提供的图形化的编辑与调试界面的确较GCC要高产得多。在完成了测试之后，就开始把它向LINUX移植，移植的过程会有一些需要注意的地方。下面就是我的一些心得。
文件名
由于ext2文件系统对文件名是大小写敏感的，当你在这种文件系统上进行编译的时候，源文件中出现的#include 语句必须小心了。因为在VC环境下，由IDE自动生成的#include 语句，其中的文件名全部是小写的。所以，你需要在一开始就注意这个问题，严格的使用大小写敏感的文件名格式，避免在LINUX下编译时出现找不到头文件的错误。
数据类型
千万不要使用VC独有的数据类型，象__int16, __int32 和__int64 等等，你无法保证其它的编译器能否支持它们。特别是__int64，它确实简化了编程工作，但是当你的逻辑里充满了这样的数据类型的时候，改动就变得无比困难了。还有一个问题就是，我们经常在VC中使用WORD,DWORD，INT，UINT这样的扩展数据类型，不直接使用编译器的数据类型有助于提高在不同平台之间的可移植性。但是LINUX下没有定义这样的类型啊？其实只需要将windows.h和basetypes.h中对这些数据进行定义的语句复制到一个头文件中，再在linux下包括进来就行了。
关键字
关键字是比较好处理的东西，凡是VC中带两个下划线的关键字，比方__asm都是VC独有的。尽量不使用它们，如果实在无法避免，就用#ifdef 和#endif为LINUX和WINDOWS编写两个版本。
MAKEFILE的编写
你可以先用VC导出一个makefile，然后对其进行修改，但我倾向于从中拷贝出一段来生成GCC的makefile，比起手工编写要快许多。
程序设计结构
这绝对是移植过程中问题最大的一个部分。应用程序难免要用到操作系统的服务，如果完全使用标准的C/C++编写，这将不是一个问题，但是当我们使用到多进/线程，管道，或者对WINDOWS图形界面的程序进行移植的时候，这个问题就变得突出了。我们应当从设计上就为程序的移植打好基础。
解决这个问题首先必须搞清楚应用程序的逻辑模块。对于这个模块必须使用标准的C/C++进行编写。同时将应用程序使用的线程数最小化，线程越多越难移植。将输入输出模块独立出来。最后划分出控制模块，这个模块与用户进行交互。
来源：CSDN
作者：floatdu
链接：https://blog.csdn.net/floatdu/article/details/2536116