blocks|key|169845|text|一般的方法是使用仿真器，例如DosBox。没有一种方法可以更改二进制文件的某些内容，使其使用不同的指令集运行。这必须从源代码开始。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|169846|entityMap|0|LINK|mutability|MUTABLE|url|http://www.dosbox.com/^0|E|6|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

The general approach is to use an emulator, such as <a href="http://www.dosbox.com/" rel="nofollow">DosBox</a>. There is not a way to change something about a binary to make it run using a different instruction set. That would have to be done starting from the source code.

blocks|key|169875|text|安装DOSBox并玩得开心。在http://www.dosbox.com/免费|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|169876|编辑：|169877|代码的比特表示关于寄存器/操作数大小的假设。另一方面，CPU当前的"bitness“是16，在实模式下，在保护模式下，它是内存结构中的一个标志，它描述当前正在执行的代码(准确地说，是段描述符和/或页面条目)。操作系统设置所述内存元数据并维护bitness。根据后者，相同的命令位可能意味着|169878|add+ax,+bx|code-block|syntax|javascript|169879|或|169880|add+eax,+ebx|169881|169882|add+rax,+rbx|169883|CPU的比特性和代码的假设更好地匹配。如果他们不这样做，应用程序崩溃或行为不当的时间不会太长。一旦代码试图从内存加载寄存器，并且CPU级别的寄存器大小不是代码所认为的那样，CPU就会加载垃圾(或者无法加载寄存器的一部分)。想象一下在32位模式下会发生什么情况：|169884|MyData+dw+0x17+;2+bytes+of+data
SomeOtherData+dw+0x200+;2+more
...
mov+ax,+[MyData]+;We+think+we+mean+AX,+but+the+CPU+thinks+it's+EAX|169885|EAX将加载0x2000017的值。绝对不是计划期望的那样。现在假设程序将该值与0x17进行比较，并在此基础上执行条件跳转。|169886|可以手动将16位实模式程序集转换为32位保护模式，但它不仅仅是转换寄存器名。从DOS程序中，你必须转到Windows程序，而这些程序是不同的。不是一个简单的翻译-更像是移植。|169887|entityMap|0|LINK|mutability|MUTABLE|url|http://www.dosbox.com/^0|F|M|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@]|9|@$A|1A|B|1B|1|1C]]|C|$]]|$1|D|3|E|5|6|7|1D|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1E|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|1F|8|@]|9|@]|C|$K|L]]|$1|M|3|N|5|6|7|1G|8|@]|9|@]|C|$]]|$1|O|3|P|5|J|7|1H|8|@]|9|@]|C|$K|L]]|$1|Q|3|N|5|6|7|1I|8|@]|9|@]|C|$]]|$1|R|3|S|5|J|7|1J|8|@]|9|@]|C|$K|L]]|$1|T|3|U|5|6|7|1K|8|@]|9|@]|C|$]]|$1|V|3|W|5|J|7|1L|8|@]|9|@]|C|$K|L]]|$1|X|3|Y|5|6|7|1M|8|@]|9|@]|C|$]]|$1|Z|3|10|5|6|7|1N|8|@]|9|@]|C|$]]|$1|11|3|-4|5|6|7|1O|8|@]|9|@]|C|$]]]|12|$13|$5|14|15|16|C|$17|18]]]]

Install DOSBox and have fun. It's free at <a href="http://www.dosbox.com/" rel="nofollow">http://www.dosbox.com/</a>

EDIT:

The bitness of the code means assumptions about register/operand size. The current "bitness" of the CPU, on the other hand, is 16 in real mode, and in protected mode, it's a flag in the in-memory structure that describes the currently executing piece of code (segment descriptor and/or page entry, to be precise). The OS sets up said memory metadata and maintains the bitness. Depending on the latter, the same command bits might mean

<pre><code>add ax, bx
</code></pre>

or

<pre><code>add eax, ebx
</code></pre>

or

<pre><code>add rax, rbx
</code></pre>

The bitness of the CPU and the assumptions of the code better match. If they don't, it won't take long before the application crashes or misbehaves. As soon as the code tries to load, say, a register from memory and the CPU-level register size is not what the code thinks it is, the CPU would load garbage (or fail to load a portion of the register). Just imagine what would happen to the following in 32-bit mode:

<pre><code>MyData dw 0x17 ;2 bytes of data
SomeOtherData dw 0x200 ;2 more
...
mov ax, [MyData] ;We think we mean AX, but the CPU thinks it's EAX
</code></pre>

The EAX would load the value of 0x2000017. Definitely not what the program expects. Now imagine the program then compares the value to 0x17 and does a conditional jump based on that.

It's possible to translate 16-bit real mode assembly to 32-bit protected mode by hand, but it would not just be translating the register names. From a DOS program you'd have to go to a Windows program, and those are a different bunch. Not a straightforward translation - more like porting.

blocks|key|2262397|text|其实有不止一个问题。首先，处理器对每个"bitness“都有不同的操作模式。但是，每种类型的应用程序都需要一个超出bitness的执行环境。它被称为应用程序二进制接口+(ABI)。例如，.com文件包含需要真正模式DOS环境的代码，包括某些硬件。早期版本的windows需要启动类似于DosBox的东西才能运行它们。每种类型的可执行文件都可能不需要完整的硬件仿真，而是需要大量的代码与主操作系统进行交互。因此，对于每种类型的可执行文件，操作系统都会检查需要什么样的运行时环境，并且拒绝运行可执行文件，除非它能够提供正确的环境。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2262398|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Application_binary_interface^0|22|9|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

There are actually more than one issue. First of all the processor has different modes of operation for each "bitness". But each type of application requires an execution environment that goes beyond the bitness. It's called an <a href="http://en.wikipedia.org/wiki/Application_binary_interface" rel="nofollow">Application Binary Interface</a> (ABI). For example .com files contain code that expects a real mode DOS environment, including certain hardware. Earlier versions of windows needed to fire up something similar to DosBox in order to run them. Every type of executable might not need full blown hardware emulation but a great deal of code to interact with the main operating system. So for every type of executable the operating system will check what kind of runtime environment is needed and refuse to run the executable unless it can provide the right environment.

blocks|key|1185909|text|要运行“16位应用程序”(在本例中指的是DOS应用程序)，Windows需要在VM86模式下设置任务。问题是，这是当CPU处于32位VPAM+(虚拟保护地址模式)时工作，这是i386操作系统所使用的，而不是当CPU处于所谓的“长模式”时。amd64+CPU“长模式”只支持运行32位和64位任务。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1185910|因此，64位操作系统内核没有选择直接在CPU上运行16位任务，您必须始终使用某种模拟。如果你找到一个能做到这一点的操作系统，它要么内置仿真，要么以32位模式运行，而不是64位模式，或者在32位和64位模式下运行，并在它们之间愉快地切换，我在某个地方读到过一些邪恶的、扭曲的黑客。|1185911|从经验来看，使用DOSBOX是你最好的选择。|1185912|编辑:Windows如何检测到它无法运行您的代码？|1185913|这在很大程度上取决于检测到的程序类型。还有它知道要处理的批处理文件(BAT、CMD)、PIF文件(我认为它们仍然没有杀死它们)，最后还有COM和EXE可执行文件。COM的情况很简单:65280字节-最大值.16位MS程序，out。另一方面，EXE文件有特定的文件头:一个用于16位DOS+(或Win3.x)部分(关键字:+MZ)，一个用于32位/64位部分(LE、LX、PE+(至少)、a.out和COFF+)，其中一些用于OS/2兼容性或仅用于它，另一些则由各种NT变体使用。|offset|length|style|CODE|1185914|entityMap^0|0|0|0|0|Y|3|12|3|17|3|1W|3|20|3|29|3|3C|3|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$J|U|K|V|L|M]|$J|W|K|X|L|M]|$J|Y|K|Z|L|M]|$J|10|K|11|L|M]|$J|12|K|13|L|M]|$J|14|K|15|L|M]|$J|16|K|17|L|M]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|O|$]]

To run a “16-bit Application”, which in this case means a DOS application, Windows® needs to set up a task in VM86 mode. The problem is that this works when the CPU is in 32-bit VPAM (Virtual Protected Address Mode), which is what an i386 OS uses, but not when the CPU is in the so-called “Long Mode” that AMD introduced. The amd64 CPU “Long Mode” only supports running 32-bit and 64-bit tasks.

So, a 64-bit OS kernel has no option to run 16-bit tasks directly on the CPU, you always must use some kind of emulation. If you find an OS that can do it, it either has that emulation built in, or is running in 32-bit mode instead of 64-bit mode, or is running in both 32-bit and 64-bit mode and switching happily between them in some kind of evil, twisted hack I've read about somewhere.

From experience, using DOSBOX is your best bet.

Edit: how does Windows® detect that it cannot run your code?

This largely depends on the program type detected. There are batch files (<code>BAT</code>, <code>CMD</code>) which it knows to handle, <code>PIF</code> files (I think they still didn't kill them off), and finally, <code>COM</code> and <code>EXE</code> executables. The <code>COM</code> case is easy: 65280-byte-max. 16-bit MS-DOS® program, out. <code>EXE</code> files, on the other hand, have certain file headers: one for the 16-bit DOS (or Win3.x) part (keyword: MZ), one for the 32-bit/64-bit part (LE, LX, PE (at the least), a.out and COFF are keywords here, some of which are used for OS/2 compatibility or by it only, some by various NT variants).

blocks|key|1185919|text|这纯粹是一项商业决定--根本没有技术上的原因，你的机器本身可以运行64位或32位版本的windows7+--这是你的选择，然后你可以运行微软的XP仿真器来运行.COM文件。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1185920|微软显然拥有可用的技术--它描述了这里，但不允许它在Home*版本上运行。|1185921|entityMap|0|LINK|mutability|MUTABLE|url|http://windows.microsoft.com/en-us/windows7/install-and-use-windows-xp-mode-in-windows-7^0|27|4|0|Q|5|H|2|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@$9|V|A|W|1|X]]|E|$]]|$1|H|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

It's purely a commercial decision - there is simply no technical reason, as is proved by the fact that your machine itself could run a 64-bit or 32-bit version of windows7 - your choice, and you could then run Microsoft's XP emulator which WILL run <code>.COM</code> files.

Microsoft clearly has the technology available - it's described <a href="http://windows.microsoft.com/en-us/windows7/install-and-use-windows-xp-mode-in-windows-7" rel="nofollow">HERE</a> but don't allow it to run on <code>Home*</code> editions.

blocks|key|169524|text|我的问题是:究竟是什么使代码16、32或64位，是什么触发了16位应用程序显然存在的不兼容问题？|type|blockquote|depth|inlineStyleRanges|entityRanges|data|169525|很明显的答案是:取决于使用8,16,32或64位寄存器的程序。显然但不正确:在MS中运行的程序可以使用8,16，或32位寄存器，如果处理器支持这些寄存器的话。或者，Windows程序除了使用32位寄存器和(如果处理器和操作系统支持的话)+64位寄存器之外，还可以使用(实际上也使用)8和16位寄存器。|unstyled|169526|我认为问题应该是:究竟是什么使程序在DOS或Windows+32位或Windows+64位下运行。|169527|第一，可执行文件的结构。32位或64位Windows可执行文件与16位可执行文件不同.Windows使用所谓的“可移植可执行”(PE的缩写)。MS使用.COM文件(从CP/M继承)和.EXE文件(也称为MZ可执行文件)。|offset|length|style|BOLD|169528|第二个：其中一个程序存储在内存中并开始执行，那里有一些程序期望的环境，例如，由一些特殊指令访问的大量函数调用，比如INT，它们负责执行不同的任务，从将一个字符输出到控制台，到打开和读取文件等等。|169529|第三代：MS应用程序期望内存中的某些结构位于特定的内存地址；例如屏幕内存。此外，它还期望某些I/O设备存在于特定的I/O地址。许多所谓的“不良行为”应用程序不使用BIOS或DOS在屏幕上打印，而是直接写入屏幕内存，以获得更快的输出。我记得在Turbo，Turbo，或者可能是Turbo编译器中设置了一个设置，让程序员选择控制台输出函数通过BIOS，或者直接进入硬件。|169530|第四：程序期望处理器以一种特定的方式运行。16位DOS程序的设计是为了使用所谓的实模式的x86处理器，这种模式强加了它的特殊的内存地址的视觉，以命名这种模式的最独特的特点。随着将处理器置于保护模式的32位OS的到来，实模式程序无法工作，因为内存地址在保护模式下工作的方式与它在实模式下的工作方式有很大的不同。|169531|一个愿意运行MZ可执行文件的操作系统需要--某种类型的加载器来处理这些文件(为了遵守第一点)--和一个必须模仿应用程序应该工作的文件到中的环境(以遵守其余的要点)。在Linux中，这些组件是他们所称的特性的一部分(这是Linux从其他操作系统(如FreeBSD+)运行代码的一种方式，前提是这段代码适用于两个平台上相同的处理器)。在Windows世界中，这被称为子系统。例如，Windows和Windows7有Win32子系统和DOS子系统。Windows的古老版本(可能是WindowsNT3.5或NT4.0)也具有+OS/2+特性，能够运行OS/2+16位文本模式应用程序。|169532|因此，您的Windows操作系统需要批准子系统来运行为另一个操作系统设计的代码，比如MS。但处理器必须以任何可能的方式提供帮助。这是因为x86平台在80386中引入了8086虚拟模式:以便能够创建处理器行为与实际模式8086非常相似的任务。|169533|因此，在CPU本身的帮助下，审批加载程序、能够将DOS请求转换为Windows请求的INT处理程序、能够捕获对特定内存部分的访问并将它们转换为在屏幕上绘制字符的请求的智能页面处理程序以及能够模拟应用程序使用的设备的I/O错误处理程序、为DOS编写的程序可以在Windows或Linux+(DOSemu)下运行。|169534|那么，64位呢？为了使代码能够在访问64位寄存器的情况下运行，使用了另一种保护模式，称为long+mode。我对这种长模式不太了解，但据我所读，这种模式不允许处理器使用8086虚拟模式创建任务。还有另一种模式叫做兼容性模式或类似的模式，它允许处理器创建64位和32位任务，而不是8086虚拟模式任务。|169535|如果没有CPU的帮助，DOS子系统就很难实现:您可以模拟内存映射，捕获对特定内存区域的任何访问或I/O，陷阱INT指令，但除此之外，您还应该捕获任何更新段寄存器的尝试，以便尝试模拟真正的模式寻址，而我并不确定段是否在长模式下使用。这是可行的，像DOSBox这样的应用程序证明了这一点，但是微软不再需要DOS了(它已经很长一段时间不需要它了，但是客户直到Windows2000/XP的引入才会分享他们的观点)。Windows+7+32位可以使用与以前的Windows版本相同的DOS子系统(我之前甚至读过一篇关于将OS/2子系统重新引入Windows+2000或Windows的文章)，但对于Windows+7+64位，必须设计(或购买)一个全新的DOS子系统。|169536|更多信息在这里：http://www.codeproject.com/Articles/45788/The-Real-Protected-Long-mode-assembly-tutorial-for#Main|169537|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codeproject.com/Articles/45788/The-Real-Protected-Long-mode-assembly-tutorial-for#Main^0|0|0|0|0|2|0|0|3|0|0|3|0|0|2|14|3|2M|4|0|K|A|1C|J|5P|5|5Y|3|77|6|0|0|0|18|9|2Y|5|0|0|8|2P|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1D|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|1E|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|1F|8|@$I|1G|J|1H|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|1I|8|@$I|1J|J|1K|K|L]]|9|@]|A|$]]|$1|O|3|P|5|D|7|1L|8|@$I|1M|J|1N|K|L]]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1O|8|@$I|1P|J|1Q|K|L]|$I|1R|J|1S|K|L]|$I|1T|J|1U|K|L]]|9|@]|A|$]]|$1|S|3|T|5|D|7|1V|8|@$I|1W|J|1X|K|L]|$I|1Y|J|1Z|K|L]|$I|20|J|21|K|L]|$I|22|J|23|K|L]|$I|24|J|25|K|L]]|9|@]|A|$]]|$1|U|3|V|5|D|7|26|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|27|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|D|7|28|8|@$I|29|J|2A|K|L]|$I|2B|J|2C|K|L]]|9|@]|A|$]]|$1|10|3|11|5|D|7|2D|8|@]|9|@]|A|$]]|$1|12|3|13|5|D|7|2E|8|@]|9|@$I|2F|J|2G|1|2H]]|A|$]]|$1|14|3|-4|5|D|7|2I|8|@]|9|@]|A|$]]]|15|$16|$5|17|18|19|A|$1A|1B]]]]

<blockquote>
 My question is: What exactly makes a code 16, 32 or 64 bit, what
 triggers the incompatibility problems 16-bit applications apparently
 have?
</blockquote>

Well: the obvious answer would be: depends on that program using 8,16,32 or 64 bit registers. Obvious but not true: a program running in MS DOS can use 8,16, or 32 bit registers if the processor supports them. Alternatively, a Windows program can use (and indeed uses) 8 and 16 bit registers, besides using 32 bit registers and (if the processor and OS supports it) 64 bit registers.

The question, I think, should be: what exactly makes a program to be run under DOS or Windows 32 bits or Windows 64 bits.

First, the structure of the executable file. A 32-bit or 64-bit Windows executable file is not the same as the 16-bit executable file. Windows uses the so called "Portable Executable" (short for PE). MS DOS uses both .COM files (inherited from CP/M) and .EXE files (also known as MZ executables).

Second: one the program is stored in memory and begin executing, there some environment that the program expects to be there, for example, an army of function calls accessed by special instructions, like INT, which are in charge of performing different task, from outputting a character to the console, to open and read files, and many more.

Third: MS DOS applications expects some structures in memory to be at a specific memory address; for example the screen memory. Also it expects some I/O devices to exist at a specific I/O address. Many so called "bad behavioured" applications don't use BIOS or DOS to print on screen, but write directly to screen memory, for faster output. I remember a setting in Turbo Pascal, Turbo Basic, or maybe Turbo C compiler, to let the programmer choose console output functions to go through BIOS, or to go directly to hardware.

Fourth: the program expects the processor to behave in a particular way. 16-bit DOS programs are designed to use the so called Real Mode of x86 processors, and this mode imposes its particular vision of memory addresses, to name the most distinct feature of this mode. With the arriving of 32-bit OS's that puts the processor in Protected Mode, real mode programs cannot work because the way memory addresses work in protected mode is very different from the way it worked for real mode.

An OS willing to run MZ executables need some sort of loader for these files (to comply with the first point) and an environment that has to mimic the one the application should work into (to comply with the rest of points). In the Linux world these components are part of what they call personalities (a way for Linux to run code from other OS's such as FreeBSD, providing that code is intended for the same processor on both platforms).
In the Windows world this is known as subsystems. Windows XP and Windows 7, for example, have the Win32 subsystem and the DOS subsystem. Ancient versions of Windows (Windows NT 3.5 or NT 4.0 perhaps) had an OS/2 personality too, capable of running OS/2 16-bit text mode applications.

So, your Windows OS need the appropiate subsystem to run code designed for another OS like MS DOS. But the processor must help in any possible way. This is because the x86 platform introduced the 8086 virtual mode in the 80386: to be able to create a task in which the processor behaves much like a real mode 8086.

So with assistance from the CPU itself, the appropiate loader, an INT handler capable of translating DOS request into Windows request, an intelligent page handler that is able to catch accesses to specific sections of memory and translate them into requests for drawing characters on screen, and a I/O fault handler capable of impersonate the devices that the application used to work with, a program written for DOS can run under Windows, or Linux (DOSemu)

So, what happens with 64 bits? For a code to be able to run with access to 64-bit registers, another kind of protected mode is employed, called long mode. I don't know much about this long mode, but from what I have read, this mode doesn't allow the processor to create a task using the 8086 virtual mode. There is another mode called compatibility mode or something like that, that allows the processor to create 64 and 32-bit tasks, but no 8086 virtual mode tasks.

Without CPU assistance, a DOS subsystem is much difficult to achieve: you could mimic the memory map, trap any access to special memory regions or I/O, trap INT instructions, but besides, you should trap any attempt to update the segment registers in order to try to mimic the real mode addressing as well, and I'm not actually sure segments are in use in long mode. It's doable, as applications like DOSBox prove it, but Microsoft doesn't need DOS anymore (it hasn't need it for a long time, but customers didn't share their point until, perhaps, the introduction of Windows 2000/XP). Windows 7 32-bits can use the same DOS subsystem as previous Windows versions used (I even read some time ago about a hack to bring the OS/2 subsystem back into Windows 2000 or Windows XP), but for Windows 7 64-bits, a complete new DOS subsystem had to be designed (or bought).

More info here:
<a href="http://www.codeproject.com/Articles/45788/The-Real-Protected-Long-mode-assembly-tutorial-for#Main" rel="nofollow">http://www.codeproject.com/Articles/45788/The-Real-Protected-Long-mode-assembly-tutorial-for#Main</a>

I recently discovered that 64-bit window won't run 16-bit applications (.com in this case), because 64-bit windows doesn't have a 16-bit subsystem (or so the internet says). I came across this when trying to execute an .bat file that called for EDIT.

I've got quite some experience with x86 assembly, but never wrote programmes to run under windows (or any other OS for that matter). Due to the backwards compatibility of the x86 family, I never really paid to much attention to how much bit my program was. As long as it didn't use instructions that weren't introduced tot the CPU the program had to run on, it was fine.

My question is: What exactly makes a code 16, 32 or 64 bit, what triggers the incompatibility problems 16-bit applications apparently have?

Is it possible to disassembly small 16-bit applications and change a bit to get it working, or is that really ill-advised?

Update: I am not looking for a way to run these kind of applications as it is, i.e. via emulators or other programmes, that I can work out for myself. I merely want to understand the underlying mechanics that make windows accept or refuse a program.

16-bit assembly incompatibility with 64-bit windows 7

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我最近发现64位窗口不会运行16位应用程序(在本例中是.com)，因为64位窗口没有16位子系统(或者互联网这么说)。我在尝试执行一个调用编辑的.bat文件时遇到了这种情况。我对x86程序集有相当丰富的经验，但从未编写过在windows下运行的程序(或任何其他操作系统)。由于x86家族的向后兼容性，我从来没有真正关注过...

问16位程序集与64位windows 7不兼容
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问16位程序集与64位windows 7不兼容EN