4 ms·

Properly written Win16 applications are agnostic with respect to memory protection. Windows 3.0 could run in real mode (8086+), standard mode (80286+), or enha

by gldrk 1y ago

Properly written Win16 applications are agnostic with respect to memory protection. Windows 3.0 could run in real mode (8086+), standard mode (80286+), or enhanced mode (80386+). Enhanced mode used V86 mode, which didn’t exist on the 80286, to support DOS console windows. In standard mode, Windows suspended itself to allow running DOS applications. Real mode support was in fact dropped in Windows 3.1, so any program that runs under that is guaranteed to run under Linux/Wine (though not guaranteed not to crash because of some unimplemented API). In protected mode, all Win16 code runs in ring 1 or 3, including all drivers and application programs, as well as the so-called ‘kernel’, which is just a shared library that provides support for coroutines, among other things. The actual kernel that runs in ring 0 is the DPMI host. Memory segmentation is 100% supported on AMD64 in compatibility mode. This is entirely independent of the default operand size: it is purely a historical coincidence that 32-bit code segments tend to go hand-in-hand with flat memory models.

deaddodo 1y ago
Or you can just join the conversation in the middle instead of seeing all of that addressed in the replies: > even with LDTs, segments will not function with the legacy 16-bit wraparound; nor can you run 16-bit code segments. [...] <and no far pointers> And, most importantly: > That being said, this isn't worth arguing over. If you can provably run late 1980s-early 1990s 16-bit code in AMD64 compatibility mode, with full execution protections and support of even most, not all, commercial software; that goes against the general understanding of those architectures. Document it and add it to the academic sphere to expand the knowledge. Despite that entire conversation happening almost a week ago.
- gldrk 1y ago
  >even with LDTs, segments will not function with the legacy 16-bit wraparound Yes, this is why KERNEL exports __AHSHIFT and __AHINCR. >Despite that entire conversation happening almost a week ago. It’s difficult enough to find correct information about this stuff. There is no harm in providing corrections.

by gldrk 1y ago

deaddodo 1y ago

Or you can just join the conversation in the middle instead of seeing all of that addressed in the replies: > even with LDTs, segments will not function with the legacy 16-bit wraparound; nor can you run 16-bit code segments. [...] <and no far pointers> And, most importantly: > That being said, this isn't worth arguing over. If you can provably run late 1980s-early 1990s 16-bit code in AMD64 compatibility mode, with full execution protections and support of even most, not all, commercial software; that goes against the general understanding of those architectures. Document it and add it to the academic sphere to expand the knowledge. Despite that entire conversation happening almost a week ago.

gldrk 1y ago
>even with LDTs, segments will not function with the legacy 16-bit wraparound Yes, this is why KERNEL exports __AHSHIFT and __AHINCR. >Despite that entire conversation happening almost a week ago. It’s difficult enough to find correct information about this stuff. There is no harm in providing corrections.