是不是在64位系统下跑32位程
64位应用程序不能在32位(或更低)操作系统上运行。而不是在64位OS上作出的程序只能在64位OS上运行，因为在64 bit OS上一样可以完成32bit应用程序的编译。
64位的操作系统上完全可以完成32应用程序的编译，这其实很简单，只需调整一下编译器的参数就行了。
不过要注意，编译器理论上可以编译任何位数的程序，但是这还是和代码有关的(如果是JAVA开发程序就不必太多考虑)，C/C++ 和 汇编 的跨平台性就不是很好，所以这要求程序员在开发程序时要考虑全面，比如考虑Debug版本和Release版本的编译问题。 而像32bit和64bit的代码只用注意一些常规的习惯，不要自作聪明...全部
64位应用程序不能在32位(或更低)操作系统上运行。而不是在64位OS上作出的程序只能在64位OS上运行，因为在64 bit OS上一样可以完成32bit应用程序的编译。
64位的操作系统上完全可以完成32应用程序的编译，这其实很简单，只需调整一下编译器的参数就行了。
不过要注意，编译器理论上可以编译任何位数的程序，但是这还是和代码有关的(如果是JAVA开发程序就不必太多考虑)，C/C++ 和 汇编 的跨平台性就不是很好，所以这要求程序员在开发程序时要考虑全面，比如考虑Debug版本和Release版本的编译问题。
而像32bit和64bit的代码只用注意一些常规的习惯，不要自作聪明就行，比如下面这代码：
int *p= (int*)malloc(sizeof(int));
这样编译器在64bit模式下就知道sizeof(int)=8，在32bit模式下sizeof(int)=4。
这样就保证内存的申请和使用不会出错。但是程序员如果习惯不好，同样的代码写成如下形式，那就糟糕了：
int *p= (int *)malloc(4);
这个程序员他只考虑常规的int长度而忘了跨越平台出现的问题，这个代码在32bit的windows上是不会出现问题的，但到了Windows 7这类64bit的OS上就会出现实际的int比你预料的要长2倍。
这会这样呢？如果你在这段代码之后这样使用这个指针：(64bit 的应用程序)
*p= 10;
很明显，p是int 类型的，有8个长度，而你只申请了4个长度的内存，这个错误在编译环节是编译器是不检查的，即编译器认为代码无错。
一旦运行起来，毛病小一点的话，这8个长度的数据有4个会直接住进邻居家；毛病大点就直接出错，这个程序的主进程被OS挂起，然后被结束。
总而言之，代码要考虑周全一点。收起
