AMD64 and 16-bit compatibility

[glugglug]

Can DOS apps that relied on the old hacked up 286 memory extenders work under a 64-bit OS?

I know the compatible mode it starts off in before you load a 64-bit OS will run everything, but are all those awkward addressing modes supported when keeping track of 64-bit stuff in the MMU?

 

[Soulkeeper]

i believe they can
should all be backwards compatitable

 

[MDE]

It should work for all the same reasons 32-bit x86 CPUs can run old 8 and 16-bit stuff.

 

[sonoran]

My understanding is that 64-bit Windows will not support 16-bit DOS or Windows apps. Nor will it support 32-bit device drivers.

* Not speaking for Intel Corp *

 

[alexruiz]

Originally posted by: sonoran
My understanding is that 64-bit Windows will not support 16-bit DOS or Windows apps. Nor will it support 32-bit device drivers.

* Not speaking for Intel Corp *

I think you are talking about the windows for Itanic..... Win XP for AMD64 should be perfectly compatible

 

[sonoran]

Nope, I was referring to Windows 64 for x86-64 platforms. I don't believe I'm at liberty to give the details on where I got that impression. But I will grant that the info may be wrong, and will graciously defer to anyone who has a definitive answer...

* Not speaking for Intel Corp *

 

[Jeff7181]

Originally posted by: sonoran
Nope, I was referring to Windows 64 for x86-64 platforms. I don't believe I'm at liberty to give the details on where I got that impression. But I will grant that the info may be wrong, and will graciously defer to anyone who has a definitive answer...

* Not speaking for Intel Corp *

LOL.... LOL

:beer:








If I told you I'd have to kill you... LOL

 

[Acanthus]

Is sonoran a wingznut wannabe or something?

Just wondering.

 

[InlineFive]

Originally posted by: sonoran
My understanding is that 64-bit Windows will not support 16-bit DOS or Windows apps. Nor will it support 32-bit device drivers.

* Not speaking for Intel Corp *

LOL, what's with you? Windows 64 won't be truely backwards compatible, yes. However Microsoft has improved WoW so they said it can run older apps with only a 1% or 2% decrease in performance. The hardware itself is entirely compatible with 8-Bit, 16-Bit, 32-Bit and 64-Bit apps.

-Por

 

[MDE]

Originally posted by: PorBleemo

Originally posted by: sonoran
My understanding is that 64-bit Windows will not support 16-bit DOS or Windows apps. Nor will it support 32-bit device drivers.

* Not speaking for Intel Corp *

LOL, what's with you? Windows 64 won't be truely backwards compatible, yes. However Microsoft has improved WoW so they said it can run older apps with only a 1% or 2% decrease in performance. The hardware itself is entirely compatible with 8-Bit, 16-Bit, 32-Bit and 64-Bit apps.

-Por

The only hitch is that you NEED ALL 64-bit drivers.

 

[Cerb]

That depends on the OS. Many DOS apps won't run in WinNT as it is, even XP. That won't change one bit going to 64-bit.

 

[InlineFive]

Originally posted by: MDE

Originally posted by: PorBleemo

Originally posted by: sonoran
My understanding is that 64-bit Windows will not support 16-bit DOS or Windows apps. Nor will it support 32-bit device drivers.

* Not speaking for Intel Corp *

LOL, what's with you? Windows 64 won't be truely backwards compatible, yes. However Microsoft has improved WoW so they said it can run older apps with only a 1% or 2% decrease in performance. The hardware itself is entirely compatible with 8-Bit, 16-Bit, 32-Bit and 64-Bit apps.

-Por

The only hitch is that you NEED ALL 64-bit drivers.

I know that. You need all 64-Bit drivers however it can emulate older hardware using an improved version of WoW.

-Por

 

[jhu]

i'm not sure that the processor will be able to execute 16-bit code correctly in 64-bit mode. but it will execute it correctly in 32-bit mode.

 

[KF]

The key point is that the OS is running in 64 bit mode. If the OS is in 32 bit mode, as for normal Windows XP, then we are back to 100% compatibility. For non-programmers: The OS sets up an environment which determines how an application will run. Once control is passed to the program, it is confined to that environment. After the processor has switched to 64 bit mode for the OS, the OS can set an apps environment to 64 bit or 32 bit, even though the OS itself is running as 64 bit.

I'm unclear about this, but this is as much as I understand. Once AMD64 is switched into 64 bit mode for the OS, one old mode is unavailable. (real mode?) I am not sure if this mode is required to run 16 bit programs or not. If it is, then I believe sonoran is right. I just do not know how the 16 bit compatibility mode is accomplished while in Windows.

The default Windows mode for applications has been 32 bit since Windows 95. Before that the default mode for Windows apps had been 16 bits. In the Windows 3.1 era, there was a Win32 module that could be added to allow 32 bit programming, but it was not used much. A prefix also could be added to opcodes to make it use 32 bit wide data even while the mode was set to 16 bits, although that was not used much either. (There is no corresponding capabilty to use 64 bit wide data while set to 32 bit mode for AMD64.)

True, in AMD64 64 bit mode, programs can be set to run in 32 bit mode, where all the 64 bit extensions are unavailable, and everything looks exactly like the old x86 32 bit environment we have been using. Can 16 bit programs run correctly that way? No. The instructions act differently. The same op codes do different things in 16 bit mode as compared to 32 bit mode. Is there a mode available for true 16 bit programs? I don't know.

It is true that you can convert an instruction in 32 bit mode to act as 16 bit instruction by adding a prefix op, but that is not how native 16 bit programs are coded. So native 16 bit programs would be executing 32 bit opcodes without know it. Unless every native 16 bit instruction produces the expected result (which is unlikely), then some results would be wrong, and the program will not run right. For instance, if you add two 16 bit numbers whose sum goes over 16 bits, the carry flag is set to true in 16 bit mode, but to untrue in 32 bit mode.

To sum up, it seems possible that programs from the 16 bit era may not run in XP64. If not, then possibly there is some sort of emulator that could convert the programs on the fly.

 

[Cerb]

Actually, much of windows was NOT 32-bit as of '95. It was mixed (it had to be: it still ran on DOS!). WinNT was a completely 32-bit rewrite.
Many 3.1, '95/98 and DOS apps do not work in NT or Win2K, and many don't quite work properly in XP (though 2k is better than NT was, and XP can even run old DOS games, even if not very fast). The changes to 64-bit w/ AMD's extensions should not change this compatability. Normal 32-bit apps run in the OS just fine. Based on office apps performing pretty well (around -5%, IIRC), and games doing poorly (from -15% to -50%), it appears things work fine, and we're basically waiting on validation and drivers. The thing is, while the chip can work just as if the program running were in 32-bit mode, the OS and drivers must be 64-bit, and they must be able to translate anything that is accessed differently.
Old WoW will work like it always did, AFAIK. If your app can run IN 2k or XP SP2 (I dobut there will be a non-SP2 version of XP64), chances are extrmely good it will work in XP-64.

 

[jhu]

opteron/athlon 64 have severl modes and submodes of operations:

? Long mode
? 64-bit mode
? Compatibility mode
? Legacy mode
? Protected mode
? Virtual mode
? Real mode

i don't think 16-bit programs will be able to run in long mode

 

[KF]

> The changes to 64-bit w/ AMD's extensions should not change this compatability.
Can you be more specific as to why not?

>Actually, much of windows was NOT 32-bit as of '95. It was mixed (it had to be: it still ran on DOS!).
The faciltiies provided by DOS were very limited. It could read/write to the COM and LPT ports. It could send characters to the graphics card. It could read/write sectors to the HD and FD. All working through the BIOS, I believe. No sophisticated graphics or sound were built into DOS. DOS programs that used bit-graphics or sound directly accessed the hardware, not working through DOS. In order for even Windows 3.1 to work, all the DOS hooks were systematically replaced with protected mode versions as Windows started. (In other words, DOS "ran on top of " Windows, once Windows was done.) I believe the main reason 16 bit code was used originally was for compactness, and later for compatibility with the earlier versions. The reason for keeping DOS is that it is the most foolproof way to supply 100% DOS compatibilty, rather than a simulation, because programmers always were using DOS in "unusual" ways depending on undefined idiosyncrasies. Windows apps use (or are supposed to) the Windows API (Application Programming Interface), which is vastly larger than DOS, and for which DOS is largely irrelevant. Windows 3.x had a 286 version (16 bit OS) and a 386 version (32 bit mode OS), and automatically detected the version to load at start up, although you could overide it with a command line switch.

When Windows is loaded, the processor is switched into protected mode, and then applications do not have the "privilege level" to write directly to ports nor to access all areas of memory. The way DOS programs work in a window (or full screen) is that read/writes to certain areas of memory (such as the graphics card memory) and I/O ports are intercepted by the OS and reinterpreted as the OS see fit. The OS then makes calls to code such as drivers to do the work. This is invisible to the application, but if the application does things in a strange way not anticpated or detected by Windows, it won't work. Later DOS apps used extended memory which might be supplied by a DOS extender, which is actually a sort OS itself switching into protected mode. Windows has to be able to detect that and supply the substitutions. Again, if the app does this in some way Windows can't figure out, the app won't work.

This all has nothing to do directly with whether the processor can run 16 bit code from 64 bit mode.