LZ的题目好像有点宏观了。
其实可以这样理解:
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挂起,然后被结束。
总而言之,代码要考虑周全一点。