I have some corrections for some obscure things...
On 28/01/2025 01:19, Liam Proven via Freedos-devel wrote:
On Fri, 24 Jan 2025 at 16:10, Bret Johnson<bretj...@juno.com> wrote:
It also turns out that 16-bit protected mode is EXTREMELY useful, especially
for things like TSR's. AFAIK, all CPUs that support 32-bit PM also support
16-bit PM, and it's possible to take advantage of that fact to do some
interesting things. A little more on that further below.
Correct.
*But* 64-bit chips in 64-bit mode do not.
x86-64 removes support for V86 mode, and I believe, for 286 protect mode too.
V86 mode is not available in 64-bit mode, but that's about it.
You absolutely can still run 16-bit protected-mode code in 64-bit long
mode and in fact this is still possible on 64-bit Linux and is most
likely what Wine uses.The modify_ldt(2) syscall is still available for
64-bit processes, and one can clear the "seg_32bit" flag and get a
genuine 16-bit selector. (The default kernel on Artix supports
this.)Microsoft has an explanation somewhere of why 16-bit programs
don't run under 64-bit Windows, claiming that it's because some of the
handles are wider and don't fit in the API. But if that were the case,
then Windows 95 would *also* not be able to handle 16-bit programs,
because about then was when the handles were made wider in the first place.
Having said that, this arrangement *is* very awkward to use as one has
to move the stack... typically twice (although with a sysctl setting
there's a way to do it once) - once to below 4 GB so that one can leave
64-bit code and enter 32-bit code which makes segmentation available,
and then again to a segmented address with an offset less than 64 KB so
that one can enter 16-bit code. (Hint: mmap(2) with the MAP_32BIT flag
is your friend.)
Just as an FYI, in 16-bit PM you can access the entire 4 GB of addressable
memory just like 32-bit PM
No, that's wrong.
The 80286 has a 24-bit address bus and can access a maximum of 16MB of
RAM directly.
Its _virtual_ address space was much bigger. I think, but am not sure,
that the 80286 supported 16k of segments instead of 16 -- so a total
of 16384 segments of 64kB, meaning a _virtual_ address space of 1GB.
But 16GB of real physical RAM was the max, as with the 386SX.
NOTE: I am pretending that all addressable physical memory is RAM here,
in reality that's not the case.
Yes the upper bound of virtual memory is... 1 GB before tax (you lose 2
descriptors because one is unusable and you also need a descriptor for
the LDT as far as I know).
I'm guessing the 16GB is a typo, as the 386SX appears to only have 24
address bits as per the 80286, meaning this would be 16 MB. But the 386
onwards does allow selecting any 32-bit "physical" address. And the
reason for the "scare quotes" around "physical" is it still has to go
through the page table if that's enabled...
Which theoretically when paired with PAE one could access 64 GB of
physical memory. And of course on a 64-bit CPU, it's going to depend on
how many physical bits there are. As an example, this machine I'm using
has a CPU with 48 physical memory bits, which means we're talking up to
256 TB of physical memory available for various 16-bit processes to consume._______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
