16位程序和32位程序？？？？

[请我去完成]

开门见上提问几个疑问：1 在32位系统编译生成的16位程序可以在32位系统运行吗???（不知道这句话矛盾不）
2 tc编译的程序是16位程序吗，为什么能在32位的xp运行？？？
3 16位程序和32位程序的追根原因是不是16位的函数库与32位的函数库造成的（暂且不谈硬件从软件角度考虑）？？？
4 只要能在32位系统运行的程序都是32位程序吗？？？？不是请纠错
5 如果3成立的话那么64位的程序开发的话，32位的函数库就不能使用，是不是还要重新编写64位的函数库？？？？不对请纠错
6跨平台的程序对32位系统和64位的系统敏感吗？？？？？
请老师一一对题回答谢谢了小弟在线等候回复 （灌水的请自重谢谢了）

[WOBUGUAN]

66分那是每题11分吗？
我仿佛记得TC是可以在386机上跑的，而386是32位的，所以在奔腾上也应该没什么问题

[ialufiac]

答：
1 可以
2 TC是16位，为什么能在32位XP运行，如果32位是你开发的，你肯定也会支持
3 不知道
4 看第2个答案
5 不懂
6 既然是可以跨平台，安全自然可靠

[weir75034]

低位在高位系统上一般是可以运行的，因为一般操作系统是向前兼容的。如16位的程序拿到32位上，因为32位系统会模拟一个16位的环境。
至于16位、32位应该是地址的最大偏移量是16位或32位的吧，例如32位系统最大虚拟地址空间为4G（自己的理解具体自己查一下吧），反过来，高位到低位就一般不兼容，关键看系统支不支持

[Proteas]

不知道，没写过16位的程序。

[theone11]

楼主应该好好复习一下编译原理这门课了……明显连程序是怎么一回事都没有搞清楚

1.任何16位程序都只能在兼容16位的32位系统运行,在什么系统上编译程序无关紧要.难道你认为在嵌入式设备上运行的程序都是在嵌入式设备上编译的?

2.XP提供有限的16位程序兼容支持

3.函数库是什么?从源代码层面,多少位的函数库没有区别,除非你的函数库是用汇编写的.

4.你都问了问题2还问这个问题干啥

5.要明白这个问题,先搞清楚二进制可执行文件和源代码的区别吧

6.有没有影响就要看你的程序到底"跨"了什么平台,如果没有提供64位系统的支持就不行

[Dinelgua]

1 在32位系统编译生成的16位程序可以在32位系统运行吗???（不知道这句话矛盾不）
肯定可以，自己编译生成的 一定可以在自身运行

2 tc编译的程序是16位程序吗，为什么能在32位的xp运行？？？
同上

3 16位程序和32位程序的追根原因是不是16位的函数库与32位的函数库造成的（暂且不谈硬件从软件角度考虑）？？？
应该跟函数库没关系，编译时对不同数据类型大小的解释造成的吧

4 只要能在32位系统运行的程序都是32位程序吗？？？？不是请纠错
不是，64位的也可能再32为系统跑，只要没有使用冲突的变量就可以，例如int再32位是4字节，64为下也是4字节
那么
void main(){ int i = 100; cout<< i;}这样再64位环境编译的程序一样可以再32为下运行

5 如果3成立的话那么64位的程序开发的话，32位的函数库就不能使用，是不是还要重新编写64位的函数库？？？？不对请纠错
函数库中如果使用了冲突的数据类型 就需要调整

6 跨平台的程序对32位系统和64位的系统敏感吗？？？？？
敏感，可以跨平台的程序不一定能够跨32位与64位

[小赌移情]

[Quote=引用楼主 cuiyubing819 的帖子:]
开门见上提问几个疑问：1 在32位系统编译生成的16位程序可以在32位系统运行吗???（不知道这句话矛盾不）
2 tc编译的程序是16位程序吗，为什么能在32位的xp运行？？？
3 16位程序和32位程序的追根原因是不是16位的函数库与32位的函数库造成的（暂且不谈硬件从软件角度考虑）？？？
4 只要能在32位系统运行的程序都是32位程序吗？？？？不是请纠错
5 如果3成立的话那么64位的程序开发的话，32位的函数库就不能使用，是不是还要…
[/Quote]

1.32位系統一般都有16位的兼容模式,只不過不是正版的16位而已,可以運行一些,不能運行一些.
2.tc輸出是16位程序, 同上.
3.對.可以看Programming Windows 中關於Windows API的講解.
4.不是,看1.
5.是不能用,但是模擬層可以解決大部分問題.

[dttlgotv]

16位系统和32位系统的区别是寻址的不同，一个是16位寻址，一个是32位寻址；因此存储单元大小也不一样，一个是16位，一个是32位。

所以16为程序能在32位上运行，只是前面16位为0而已，但32位的不能再16位上运行。

[kiffa]

支持一下5楼。

从机器码的角度来比较16位程序和64位程序最容易说明这个问题。

首先，一切源代码最终都会转变成机器代码，也就是01序列，要想在某种机器上运行这些01序列，那么必须保证这个01序列在逻辑上属于该机器中处理器(cpu)指令集的一个子集。比如：

int i = 3;

其汇编伪代码可能是：

mov &i, 3 // 获取i的地址&i，然后把3写入这个地址

在64位机器上，其机器码可能是：

// 使用了绝对地址的简化版本
01 0010101101111010 0000000000000011 // 01表示指令功能（mov)，0010101101111010表示&i地
                                                 // 址，0000000000000011表示整数3

而在16位机器上，其机器码可能是：

1 1001 0011 // 1表示指令功能（mov)，1001表示&i地址，0011表示整数3

那么只要一个编译器包（不太严谨的自定义词，指包含了编译器、汇编器、连接器等的一个“包”）可以把int i = 3这句代码转换成01 0010101101111010 0000000000000011，这个编译器包产生的二进制代码就可以在64位机器上运行；同样，如果编译器包产生的是1 1001 0011，那么就可以在16位系统上运行。

而01 0010101101111010 0000000000000011不能在16位机器上运行，因为16位cpu根本就不认识这条指令；同理，1 1001 0011也不能在64位机器上运行（更确切的说是不能在64位机器的64位模式下运行，注：对此条我没有足够的自信，因为不清楚intel对向前兼容所做的处理，有误的话一定要指正。我的硬件体系知识还停留在32位单核上。）。

要想让01 0010101101111010 0000000000000011在16位机器上跑，除非有一个中间程序将01 0010101101111010 0000000000000011转换成1 1001 0011（或者cpu有独特的办法来兼容这种指令）。这正是tc编译出的16位程序可以在32位xp上跑的最基本原因，xp可以模拟出一个16位环境（同上：有误一定要指正）。

所以，即使是16位系统上的一个编译器包，也是可以编译出用于64位系统的可执行文件的，只要他把int i = 3 翻译成01 0010101101111010 0000000000000011就行了。

总之，编译器包是最直接的决定因素，编译器包能产生怎样的机器代码，就可以在怎样的机器平台上运行。而编译器包能产生怎样的代码，是不受编译器包本身所处平台限制的，也就是上面说的16位系统上的一个编译器包是可以产生64位的程序的。编译器包的抽象层次是处于硬件层次之上的。

从抽象概念上讲，机器平台的基本区别就在于处理器指令集的区别，那么，不同处理器指令集的区别具体体现在哪些方面呢？寻址空间是一个区别（16位、32位、64位一般指这个区别），不同家族的cpu本身也有区别（比如intel的IA32系列和IBM的power pc系列），同一家族内的cpu也有区别（286、386、双核等，一般向前兼容）.

最后关于数据类型大小，一个int在16位、32位、64位下的大小（所占字节数）有没有区别？有什么区别？
1，语言标准是最根本的约束，对于int，标准只要求sizeof(short) <= sizeof(int) <= sizeof(long)，同时还要保证short至少有16位，long至少有32位(TCPL++, 3rd特别版, Bj)。

2，其他的就由编译器自己去决定了，所以理论上来说即使在64位系统上，编译器也可以实现一个16位的int，这是完全合乎标准的（而且至少在Intel的cpu上是能够实现的）。

3，具体如何实现，由编译器综合各种因素自己权衡，因此，16位系统上int为16位，32位系统上int为32位，64位系统上int为64位，只是一种普遍的做法，而并非唯一的做法。

4，即使是指针，也不一定在16位系统上为16位，32位系统上为32位，64位系统上为64位。这个世界上甚至存在支持不定长的指针的系统，在这些机器上，char *和int * 的大小可以不相等。（看书上说的，自己没接触过。）

5，因此，最好只使用类型的抽象意义，不要依赖于其底层实现细节。

[axx1611]

建议楼主google一下“虚拟8086模式”
实际上32位系统能跑16位程序相当于windows内建了一个16位虚拟机
而且这个“虚拟8086模式”不是windows特有的，是intel x86处理器的一个扩展功能

[bjwantong]

http://www.bjwtnd.cn/zgc

[yefei999]

TC2.0编译生成的EXE文件里的机器指令是实模式的机器指令，如果是16位的8086机上指令长度1-6个字节不等，寻址方式是由指令第2个字节的其中5位来编码，刚好32种排列组合（2的5次方）来表示8种寄存器寻址和24种内存寻址，第1个字节的最右边一位（0,1两种情况）来表示是字节寻址或字寻址。指令中的偏移地址（靠中后的字节内容）会先送进CPU内部一个地址加法器合成20位物理地址送上20个输入的地址译码器打开相应的内存字节或字单元的“门”进行数据的读写。
在WINDOWS下是32位保护模式，CPU（386）的高12根地址线全部工作，OS通过EXE的头部信息识别出即将运行一个实模式指令格式的程序时就会通过让CPU中的指令译码器执行一条工作模式转换指令，让32根地址线的高12位“琐0”，段寄存器的用法也随即由选择子的用法回到提供段基值的用法。假如不切换到86实模式，这段TC编译生成的指令经过CPU保护模式下的译码执行后可能会得到不符合你本意的结果或者其中有无效的指令而发生错误。说白了就是当今的CPU应该有16位，32位和64位3种不同的工作模式，寄存器，地址译码器，指令译码器都有不同的工作方式，所以同样功能的程序其指令序列也不一样

[yefei999]

TC2.0编译生成的EXE文件里的机器指令是实模式的机器指令，如果是16位的8086机上指令长度1-6个字节不等，寻址方式是由指令第2个字节的其中5位来编码，刚好32种排列组合（2的5次方）来表示8种寄存器寻址和24种内存寻址，第1个字节的最右边一位（0,1两种情况）来表示是字节寻址或字寻址。指令中的偏移地址（靠中后的字节内容）会先送进CPU内部一个地址加法器合成20位物理地址送上20个输入的地址译码器打开相应的内存字节或字单元的“门”进行数据的读写。
在WINDOWS下是32位保护模式，CPU（386）的全部32根地址线全部工作，OS通过EXE的头部信息识别出即将运行一个实模式指令格式的程序时就会通过让CPU中的指令译码器执行一条工作模式转换指令，让32根地址线的高12位“琐0”，段寄存器的用法也随即由选择子的用法回到提供段基值的用法。假如不切换到86实模式，这段TC编译生成的指令经过CPU保护模式下的译码执行后可能会得到不符合你本意的结果或者其中有无效的指令而发生错误。说白了就是当今的CPU应该有16位，32位和64位3种不同的工作模式，寄存器，地址译码器，指令译码器都有不同的工作方式，所以同样功能的程序其指令序列也不一样

[bobommsky]

[Quote=引用 13 楼 yefei999 的回复:]
TC2.0编译生成的EXE文件里的机器指令是实模式的机器指令，如果是16位的8086机上指令长度1-6个字节不等，寻址方式是由指令第2个字节的其中5位来编码，刚好32种排列组合（2的5次方）来表示8种寄存器寻址和24种内存寻址，第1个字节的最右边一位（0,1两种情况）来表示是字节寻址或字寻址。指令中的偏移地址（靠中后的字节内容）会先送进CPU内部一个地址加法器合成20位物理地址送上20个输入的地址译码器打开相应的内存字节或字单元的“门”进行数据的读写。
在WINDOWS下是32位保护模式，CPU（386）的全部32根地址线全部工作，OS通过EXE的头部信息识别出即将运行一个实模式指令格式的程序时就会通过让CPU中的指令译码器执行一条工作模式转换指令，让32根地址线的高12位“琐0”，段寄存器的用法也随即由选择子的用法回到提供段基值的用法。假如不切换到86实模式，这段TC编译生成的指令经过CPU保护模式下的译码执行后可能会得到不符合你本意的结果或者其中有无效的指令而发生错误。说白了就是当今的CPU应该有16位，32位和64位3种不同的工作模式，寄存器，地址译码器，指令译码器都有不同的工作方式，所以同样功能的程序其指令序列也不一样
[/Quote]
是的。以前遇到过汇编写的16位程序在windows下跑出错，就是因为16位子系统损坏的问题。

[xiaji2007]

[Quote=引用 9 楼 kiffa 的回复:]
支持一下5楼。

从机器码的角度来比较16位程序和64位程序最容易说明这个问题。

首先，一切源代码最终都会转变成机器代码，也就是01序列，要想在某种机器上运行这些01序列，那么必须保证这个01序列在逻辑上属于该机器中处理器(cpu)指令集的一个子集。比如：


C/C++ code
int i = 3;

其汇编伪代码可能是：

C/C++ code
mov &……
[/Quote]


很好， 与我想的一样。