grub

[[e-mail]]

I don't know what Dell's game is, but for whatever
reason, they disabled legacy boot on my new
laptop.

And I haven't finished organizing 1990 to my
satisfaction, so I'm not interested in learning
about GPT or whatever they're peddling instead.

However, it occurred to me that maybe Grub or
something else could boot from USB stick, and
then boot PDOS/86, even if it means bypassing
the MBR.

But this still wouldn't work on the Mac - as there
is no BIOS, and PDOS/86 uses that.

I am wondering whether my new Dell is likely to
have a BIOS or whether they have saved costs or
whatever by eliminating the BIOS.

Furthermore, I am wondering whether Grub or
whatever can provide their own BIOS, so that it
would even work on a Mac.

They could implement a BIOS in terms of UEFI,
maybe?

BFN. Paul.

[Branimir Maksimovic]

Post by ***@gmail.com
I don't know what Dell's game is, but for whatever
reason, they disabled legacy boot on my new
laptop.
And I haven't finished organizing 1990 to my
satisfaction, so I'm not interested in learning
about GPT or whatever they're peddling instead.
However, it occurred to me that maybe Grub or
something else could boot from USB stick, and
then boot PDOS/86, even if it means bypassing
the MBR.

You can boot from anything, I use external disks and have main system
MBR formated.. that is I need UEFI as map above 4GB feature (AMD GPU
mapping) only works with CSM disabled.

Post by ***@gmail.com
But this still wouldn't work on the Mac - as there
is no BIOS, and PDOS/86 uses that.

What Mac? You have Mac or Dell laptop?

[[e-mail]]

Post by Branimir Maksimovic

Post by ***@gmail.com
I don't know what Dell's game is, but for whatever
reason, they disabled legacy boot on my new
laptop.
And I haven't finished organizing 1990 to my
satisfaction, so I'm not interested in learning
about GPT or whatever they're peddling instead.
However, it occurred to me that maybe Grub or
something else could boot from USB stick, and
then boot PDOS/86, even if it means bypassing
the MBR.

You can boot from anything, I use external disks and have main system
MBR formated.. that is I need UEFI as map above 4GB feature (AMD GPU
mapping) only works with CSM disabled.

That's above my head.

Post by Branimir Maksimovic

Post by ***@gmail.com
But this still wouldn't work on the Mac - as there
is no BIOS, and PDOS/86 uses that.

What Mac? You have Mac or Dell laptop?

I have:

1. Old Dell laptop
2. New Dell laptop
3. Old x86 Macbook Pro

I can boot PDOS from (1) only. I would like to boot from
(2) and (3) if possible, without changing MBR-based
PDOS. Well, maybe some small changes to PDOS
would be OK, so long as they don't impact running on
a real 8086 or 80386 from 1990.

I wish to boot from USB (preferably burnt as hard disk
rather than floppy), not internal or external hard disk.

Thanks. Paul.

[[e-mail]]

On Wednesday, May 12, 2021 at 9:49:43 AM UTC+10, Branimir Maksimovic wrote:

BTW, I think you are Melzzzzz and you may have forgotten
to log off someone else's account. That happened to me too! :-)

BFN. Paul.

[Joe Monk]

"I don't know what Dell's game is, but for whatever
reason, they disabled legacy boot on my new
laptop."

All PC makers are now pretty much using UEFI exclusively. BIOS is dead.

Joe

[[e-mail]]

Post by Joe Monk
"I don't know what Dell's game is, but for whatever
reason, they disabled legacy boot on my new
laptop."
All PC makers are now pretty much using UEFI exclusively. BIOS is dead.

Wow. No-one at all wants to run Windows 7 or
whatever that still does legacy boot?

I was planning on getting a new computer next year
and I was going to check that it booted PDOS from
USB stick before buying it. ie it needs to support
legacy mode and BIOS. That's no longer possible?
Not even for extra money? Why are they doing this?
To save money on paying for a BIOS? Can't they use
the same one that Bochs uses?

Actually, these new computers have flash BIOS. Can
I reflash it with my own BIOS? Actually, no need to stop
there. Can I flash it with a 32-bit BIOS and get my
computer to boot in 32-bit protected mode with
protected mode interrupts beginning at 0x400 and
the GDT beginning after that?

I'm surprised to become a BIOS vendor so quickly,
but I was forced into a corner!

Thanks. Paul.

[Joe Monk]

The newer processors do not support legacy bios... So anything Skylake or newer will only boot UEFI and GPT.

Also, you should take note ... no more 32-bit drivers. Its 64-bit only from now on.

https://www.intel.com/content/dam/support/us/en/documents/intel-nuc/Legacy-BIOS-Boot-Support-Removal-for-Intel-Platforms.pdf

Joe

[[e-mail]]

Post by Joe Monk
The newer processors do not support legacy bios... So anything Skylake or newer will only boot UEFI and GPT.

The processor is independent of the BIOS, isn't it?

The only thing the processor can choose to do is
drop the 8086 real mode option, which would force
it to boot in perhaps long mode. Which would be
a cool option anyway.

Post by Joe Monk
Also, you should take note ... no more 32-bit drivers. Its 64-bit only from now on.

And drivers are also a feature of the OS. If PDOS/386
provides 32-bit drivers that is completely my choice.
I can't be stopped unless the processor takes away
32-bit protected mode.

Post by Joe Monk
https://www.intel.com/content/dam/support/us/en/documents/intel-nuc/Legacy-BIOS-Boot-Support-Removal-for-Intel-Platforms.pdf

That just says they aren't going to answer questions,
not that their processors don't support it.

And to prevent me from gaining access to 8086 real
mode, AMD would need to drop support too.
Deliberately remove it from their processor.

BFN. Paul.

[Joe Monk]

"That just says they aren't going to answer questions,
not that their processors don't support it."

No, thats not what that "just" says.

UEFI class 3 means that there is no CSM (compatibility support module) available. So, there are no legacy bios functions available...

UEFI classes
UEFI machines can have one of the following "classes", which were used to help ease the transition to UEFI. Intel has ended Legacy BIOS in 2020.

Class 0: Legacy BIOS
Class 1: UEFI in CSM-only mode (i.e. no UEFI booting)
Class 2: UEFI with CSM
Class 3: UEFI without CSM
Class 3+: UEFI with Secure Boot Enabled

https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

"Intel's plan is to scrap the CSM entirely. This will simplify the hardware—no need to validate it with both CSM off and on—and will mean that developers of things such as new network cards, disk controllers, and video cards no longer need to offer legacy Option ROMs just in case someone is using brand-new hardware with ancient software. It will also firmly relegate that old software to virtual machines or other ways of mimicking old environments."

https://arstechnica.com/gadgets/2017/11/intel-to-kill-off-the-last-vestiges-of-the-ancient-pc-bios-by-2020/

"Once CSM is removed, the new platforms will be unable to run 32-bit operating systems, unable to use related software (at least natively), and unable to use older hardware, such as RAID HBAs (and therefore older hard drives that are connected to those HBAs), network cards, and even graphics cards that lack UEFI-compatible vBIOS (launched before 2012 – 2013). Those who need older programs will still be able to run them in virtualization mode, but outdated hardware will have to be retired or remain on older platforms."

https://www.anandtech.com/show/12068/intel-to-remove-bios-support-from-uefi-by-2020

Joe

[[e-mail]]

Post by Joe Monk
Intel's plan is to scrap the CSM entirely.

I still don't get it.

How does Intel manage to dictate how their CPUs
are used?

Also, there are some computers that give you
access to some flash memory and allow you
to use it as a hard disk, and boot off it. I don't
know if it is read-only. Will they still be available?
They might be able to give me what I want.

BFN. Paul.

[Joe Monk]

Post by ***@gmail.com

Post by Joe Monk
Intel's plan is to scrap the CSM entirely.

I still don't get it.
How does Intel manage to dictate how their CPUs
are used?

ME. Management Engine.

Joe

[Scott Lurndal]

Post by ***@gmail.com
I am wondering whether my new Dell is likely to
have a BIOS or whether they have saved costs or
whatever by eliminating the BIOS.

BIOS has been dead for a decade, replaced with
UEFI. Which you should be aware of by now.

[[e-mail]]

Post by Scott Lurndal

Post by ***@gmail.com
I am wondering whether my new Dell is likely to
have a BIOS or whether they have saved costs or
whatever by eliminating the BIOS.

BIOS has been dead for a decade, replaced with
UEFI. Which you should be aware of by now.

Why would I be aware of that? I haven't even
finished learning the BIOS. It was only in the
last few weeks that I found out that the BIOS
supported COM ports. And then I wanted to
know whether it returned or hung when there
was no data to read.

I had heard of UEFI, it looked complicated and
of no interest, and I am used to things being
upwardly compatible, so I wasn't expecting
anyone to delete the BIOS.

BFN. Paul.

[Joe Monk]

Post by ***@gmail.com
I had heard of UEFI, it looked complicated and
of no interest, and I am used to things being
upwardly compatible, so I wasn't expecting
anyone to delete the BIOS.

BIOS is not secure.

EFI provides secure boot (i.e. signed boot) because of all of the dumbass script kiddies out there trying to do rootkits and other dumb things.

Joe

[Scott Lurndal]

Post by Joe Monk

Post by ***@gmail.com
I had heard of UEFI, it looked complicated and
of no interest, and I am used to things being
upwardly compatible, so I wasn't expecting
anyone to delete the BIOS.

BIOS is not secure.

BIOS is not extensible (PCI option roms non-withstanding). UEFI is easily extended.
BIOS (Phoenix, AMI) were an incredibly horrible mess of 8086 assembler and were very
difficult to maintain. UEFI is free, open source and written in C.
BIOS didn't provide any of the feature required by modern computer systems, including

Post by Joe Monk
EFI provides secure boot (i.e. signed boot) because of all of the dumbass script kiddies out there trying to do rootkits and other dumb things.

https://www.tianocore.org/

[[e-mail]]

difficult to maintain. UEFI is free, open source and written in C.

Can I flash a replacement interface, using UEFI
as a base? Maybe I can get a 32-bit BIOS natively.

Thanks. Paul.

[[e-mail]]

Post by ***@gmail.com

difficult to maintain. UEFI is free, open source and written in C.

Can I flash a replacement interface, using UEFI
as a base? Maybe I can get a 32-bit BIOS natively.

Actually, what I am looking for is something like this:

bios pdos.exe disk.img potentially some command here

pdos.exe would be a pure 32-bit or pure 64-bit program,
and it expects to be loaded with relocations applied,
and to receive a parameter on the stack that provides
callback functions.

I know how to write bios.c as a normal program running
under any OS.

And I'm happy to replace bios.c with anything at all, so
long as the interface is the same.

And I don't mind producing different USB sticks for
32-bit vs 64-bit and BIOS vs UEFI.

But it would be nice to have one FAT-16 or FAT-32
USB stick that worked everywhere and adjusted to
its environment and loaded whatever was actually
runnable (I don't mind the user choosing from a
list what he expects will actually work - PDOS/386
or PDOS/x64).

It can be multi-step, ie the boot sector loads this,
which loads this, which provides a UEFI interface,
which then loads something resembling a bios.exe,
so that finally pdos.exe has some nice callback
functions.

Where do I stand?

Thanks. Paul.

[Joe Monk]

BIOS and UEFI are mutually exclusive. One or the other, but not both.

Joe

[[e-mail]]

Post by Joe Monk
BIOS and UEFI are mutually exclusive. One or the other, but not both.

My understanding is that UEFI is dependent on some
specific files being located on a disk, as well as some
files being "registered" in the firmware.

Unless they specifically read sector 0 (or is it 1?) to
check to see if an MBR appears to be present, then
how do they stop a USB stick from working on both
a BIOS-only machine as well as a UEFI-only machine?
(obviously via different code paths, at least during
initial boot).

BFN. Paul.

[Joe Monk]

Post by ***@gmail.com
Unless they specifically read sector 0 (or is it 1?) to
check to see if an MBR appears to be present, then
how do they stop a USB stick from working on both
a BIOS-only machine as well as a UEFI-only machine?
(obviously via different code paths, at least during
initial boot).

UEFI doesnt use the MBR. It only reads the FAT formatted USB and looks for (I think) a file called boot***.efi. If for instance, you look at the Windows 10 CD, you will see a file called bootmgr.efi. This is the boot loader. There is also a directory called EFI and subdir under that called BOOT. In that subdir is a file called bootx64.efi, which is chained to from bootmgr.efi.

When a UEFI system is powered on/reset, it is hardwired to go to address 0xFFFFFFF0, the top of a 4GB address space which on a UEFI system is mapped to NVRAM where the UEFI firmware is. This is the start of the SEC phase for UEFI.

https://edk2-docs.gitbook.io/edk-ii-build-specification/2_design_discussion/23_boot_sequence

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
Unless they specifically read sector 0 (or is it 1?) to
check to see if an MBR appears to be present, then
how do they stop a USB stick from working on both
a BIOS-only machine as well as a UEFI-only machine?
(obviously via different code paths, at least during
initial boot).

UEFI doesnt use the MBR.

That's fine. So long as it doesn't deliberately check
the MBR and reject the disk entirely, that's all I need.

If it deliberately checks the MBR for a signature
(x'55') or whatever, I would then need to write a
utility called "setuefi" which changes that x'55'
to x'66' and another utility "setbios" which changes
the x'66' to x'55', which I would run prior to moving
to a "legacy" system, and then back to "modern".

However, if the UEFI systems aren't deliberately
being bastards, I don't need to do anything. I can
have my MBR.

Although if they're expecting to see a FAT root
directory straight away, the MBR will screw that up.
In which case, Plan B would be to have a small
FAT root directory, followed by an MBR layout, and
then a separate FAT partition.

I would then need an 80386 BIOS that is capable
of having the MBR location configurable instead
of requiring it to be in sector 0. I don't have a
problem with that.

And for 80386 BIOSes that aren't configurable, I
can instead boot from floppy disk, and have a
bootloader load the MBR from the configurable
offset.

I don't have a problem with the OS (PDOS) needing
to be aware of this arrangement and coded to adjust
MBR location as required.

Post by Joe Monk
When a UEFI system is powered on/reset, it is
hardwired to go to address 0xFFFFFFF0, the top
of a 4GB address space which on a UEFI system
is mapped to NVRAM where the UEFI firmware is.

Ok, thanks.

BFN. Paul.

[Joe Monk]

Post by ***@gmail.com
Although if they're expecting to see a FAT root
directory straight away, the MBR will screw that up.

How so?

The MBR is part of the FAT file system (first sector). Plus, remember that UEFI only reads FAT32 formatted devices.

A USB stick is a non-partitioned device. So, the MBR would be the first sector, and since it is not read until UEFI has already gotten thru the DXE phase, UEFI just ignores the first sector on a FAT32 formatted device.

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
Although if they're expecting to see a FAT root
directory straight away, the MBR will screw that up.

How so?
The MBR is part of the FAT file system (first sector).

No, hard disks have both an MBR and (potentially
multiple) FAT boot sectors.

Post by Joe Monk
Plus, remember that UEFI only reads FAT32 formatted devices.

Ok, thanks for the info.

I don't have a bootable FAT32 sector yet, but it has
been coded (it just doesn't work yet).

Post by Joe Monk
A USB stick is a non-partitioned device.

What does that mean? Note that I am able to write
a hard disk image (ie MBR + FAT partition) to my
USB stick and it works fine (on my old Dell).

Post by Joe Monk
So, the MBR would be the first sector, and since it is
not read until UEFI has already gotten thru the DXE
phase, UEFI just ignores the first sector on a FAT32
formatted device.

To get to the FAT root directory it needs to skip the MBR
plus maybe more sectors from other partitions plus
the applicable FAT boot sector. Not sure if there is more
stuff that needs to be skipped, I've forgotten.

BFN. Paul.

[Joe Monk]

"To get to the FAT root directory it needs to skip the MBR
plus maybe more sectors from other partitions plus
the applicable FAT boot sector. Not sure if there is more
stuff that needs to be skipped, I've forgotten."

"The Protective MBR, beginning in sector 0, precedes the GPT partition table on the disk. The MBR contains one type 0xEE partition that spans the disk."

So, like I said, it skips the MBR.

"GPT and MBR disks can be mixed on systems that support GPT, as described earlier. However, you must be aware of the following restrictions:
Systems that support UEFI require that boot partition must reside on a GPT disk. Other hard disks can be either MBR or GPT.
Both MBR and GPT disks can be present in a single dynamic disk group. Volume sets can span both MBR and GPT disks."

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq

Joe

[[e-mail]]

Post by Joe Monk
"The Protective MBR, beginning in sector 0, precedes the GPT partition table on the disk. The MBR contains one type 0xEE partition that spans the disk."
So, like I said, it skips the MBR.
Systems that support UEFI require that boot partition must reside on a GPT disk. Other hard disks can be either MBR or GPT.
Both MBR and GPT disks can be present in a single dynamic disk group. Volume sets can span both MBR and GPT disks."
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq

From that link, I saw this:

UEFI specifies booting from either GPT or MBR. The ESP on an MBR disk is identified by partition type 0xEF. However, Windows does not support booting UEFI from MBR disks or 0xEF partitions.


I'm interested in booting PDOS, not Windows, so I'm wondering
if 0xEF gives me some options.

My guess is that 0xEF is designed for systems that still use
BIOS calls.

And if the BIOS itself is disappearing, that won't be an option
for me on most modern machines anyway. Is that correct?
Or is it just the Mac that has ditched the BIOS?

Assuming I want to support BIOS-less systems, I will need to
use 0xEE for the "protective MBR", followed by a UEFI-aware
boot loader.

But I can put that on a small GPT partition.

Then on another GPT partition I can put a traditional MBR
with BIOS-dependent code, followed by a BIOS-aware
boot loader, perhaps on a FAT-16 partition (all within the
single GPT partition).

And can I then have another GPT partition, FAT-32, for my
data, which would be accessible to both the UEFI boot
sequence and the BIOS boot sequence?

This would mean having the traditional MBR (which is
no longer at sector 0) pointing outside its GPT partition
and into the new FAT-32 partition.

Actually, the BIOS boot loader could be located within
the FAT-32 partition, and the traditional MBR would be
the only thing at all in its own GPT partition.

That way, as before, on an old 80386 system, the only
change required is to have a configurable sector to
look for the MBR, instead of assuming it is always
going to be 0. I don't think this is an onerous requirement.
Basically, with the benefit of hindsight, all BIOSes should
have been configured like this in the first place, to allow
expansion to GPT one day.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
That way, as before, on an old 80386 system, the only
change required is to have a configurable sector to
look for the MBR, instead of assuming it is always
going to be 0. I don't think this is an onerous requirement.
Basically, with the benefit of hindsight, all BIOSes should
have been configured like this in the first place, to allow
expansion to GPT one day.

And to allow 68000 instructions, in a different MBR
section, instead of 8086 instructions.

And x64 instructions too.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com

Post by ***@gmail.com
That way, as before, on an old 80386 system, the only
change required is to have a configurable sector to
look for the MBR, instead of assuming it is always
going to be 0. I don't think this is an onerous requirement.
Basically, with the benefit of hindsight, all BIOSes should
have been configured like this in the first place, to allow
expansion to GPT one day.

And to allow 68000 instructions, in a different MBR
section, instead of 8086 instructions.

And even within 8086 instructions, maybe some systems
don't use a standard BIOS with INT 13H etc. Maybe they
have some other mechanism to load the OS into memory.

I guess the hardware setup should provide start sector
number, number of sectors, memory load location and
code start location.

And if they had at least done this on more modern machines,
the legacy boot sector could have remained at sector 0 and
the GPT sector is the thing that could have been relocated.
Or maybe there could have been an extension (like "PE")
where the legacy MBR says that a GPT sector follows, so
read that one instead.

BFN. Paul.

[[e-mail]]

Actually, is there any reason why the "protective MBR"
can't be a real MBR? I assume UEFI systems aren't
deliberately scanning the MBR to make sure there are
no INT 13H instructions.

And what does an old 80386 system look for? Maybe
it doesn't care that it is marked x'EE' instead of whatever
is normal.

BFN. Paul.

[[e-mail]]

Post by Joe Monk
When a UEFI system is powered on/reset, it is hardwired
to go to address 0xFFFFFFF0, the top of a 4GB address
space which on a UEFI system is mapped to NVRAM
where the UEFI firmware is.

It just occurred to me - that means it is in protected
mode already, for an 80386. In order to do that, you
need to set up an IDT and GDT. I assume that these
are located in normal memory somewhere.

That would mean that the OS needs to know where
they are, so that it can avoid changing them.

I'm after a flat address space, starting at location 0.
Does UEFI give that before the OS is even run?

Thanks. Paul.

[Joe Monk]

Post by ***@gmail.com
It just occurred to me - that means it is in protected
mode already, for an 80386. In order to do that, you
need to set up an IDT and GDT. I assume that these
are located in normal memory somewhere.

The processor starts in unreal mode.

Post by ***@gmail.com
I'm after a flat address space, starting at location 0.
Does UEFI give that before the OS is even run?

Yes... It does it even before SEC.

Transition32FlatTo64Flat:

OneTimeCall SetCr3ForPageTables64

mov eax, cr4
bts eax, 5 ; enable PAE
mov cr4, eax

mov ecx, 0xc0000080
rdmsr
bts eax, 8 ; set LME
wrmsr

mov eax, cr0
bts eax, 31 ; set PG
mov cr0, eax ; enable paging

jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
BITS 64

https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
It just occurred to me - that means it is in protected
mode already, for an 80386. In order to do that, you
need to set up an IDT and GDT. I assume that these
are located in normal memory somewhere.

The processor starts in unreal mode.

I see. I just read some more about that:

https://en.wikipedia.org/wiki/Unreal_mode

and it still requires a GDT to be set up. So how does the
OS know where in memory that is, to avoid it, or to
change it?

Also, I saw this:

A special case of unreal mode is attained by, in addition, loading the code selector (CS) from a descriptor having the 32-bit attribute ("D" bit) set to one. This rarely used variant presents some advantages, mainly because it allows avoiding the Operand Size Override Prefixes normally required when using 32-bit addressing in 16-bit code segment,


This actually sounds like what I want for PDOS/386.

For starters, I want completely unkludged Win32
executables, that work on real Windows, and are
dependent only on msvcrt, or at most kernel32.
That much is not negotiable. And that also means
there will be no x'66' to override addresses, which
is normally seen in unreal mode.

But pretty much everything after an executable hits
one of those DLLs is up for grabs.

My rough plan at the moment is for an application
fopen() call to go into MSVCRT.DLL (my own),
which eventually calls an os_fopen() or similar in
PDOS/386 (all with stack calls, no security, no
interrupts).

And then PDOS/386 itself will do a call to
bios_fopen() or similar to read a hard disk (not
just a file). The bios_fopen() code may or may
not reside in a separate executable.

On a system with a real BIOS used to access the
hard disk, bios_fopen(), or rather, bios_fread(), will
do an INT 13H to read a sector. I am expecting all
code to have flat addresses starting from location
0, ie cs/ds are pointing to 0, and the full 4 GiB is
accessible. However, in preparation for doing a
BIOS INT 13H, I traditionally need to exit protected
mode and get back to real mode.

If I'm instead running in unreal mode, I need to
modify my int86() routine to switch the "D" bit
and so long as it is large memory model, it
won't care that only the IP is being saved during
the interrupt. I'm not sure how it works with "cs"
values that aren't in the GDT, which is what would
be happening here when I'm running some far
memory model code instead of flat 32-bit code
that doesn't touch "cs".

This would save me constant protected to real
switches, but I'm not sure anyone will notice any
difference. When doing something CPU-intensive,
like a GCC compile, which is what interests me,
the vast bulk of time is in the application, not in
the OS which is the only place where mode
switches are done.

But it would seem to me that unreal mode is the
most natural mode for a 32-bit version of MSDOS
to be doing 16-bit BIOS calls.

But I would like to add memory protection at some
point, and for that, I need to stay in protected mode
and start using paging so that I can make low
memory inaccessible.

But if a computer is starting in unreal mode, it would
make booting a bit simpler. And I need to do something
different for UEFI regardless. If there's no BIOS, I can't
switch back to real mode to do an INT 13H anyway.

I guess it comes down to UEFI requirements. If I am
required to be in unreal mode to use UEFI to read disk
sectors, then I will constantly be switching from
protected mode to unreal mode instead of constantly
switching from protected mode to real mode.

Maybe if that is the case I should stay in unreal mode.

But like I said, I'm expecting to one day get the OS to
protect itself, and produce an MVS-style dump whenever
there is a memory violation. I can do this even using
a call/stack model. Applications would still be running
privileged, but unless they actually revalidate segments,
they won't be able to write to OS memory.

Actually, I might have a separate PDOS-generic that uses
the call/stack model, and doesn't have the ability to print
an MVS-style dump, and the current PDOS/386 which
does.

BFN. Paul.

[Joe Monk]

Post by ***@gmail.com
and it still requires a GDT to be set up. So how does the
OS know where in memory that is, to avoid it, or to
change it?

Youre still missing the concept that its not the OS in control of that... its UEFI :)

mov bx, 0xf000
mov ds, bx

mov bx, ADDR16_OF(gdtr)

o32 lgdt [cs:bx]


Thats how UEFI does it.

Remember ... processor power on/reset -> vector 0xFFFFFFF0 in 16-bit unreal mode -> UEFI which transitions to 32 or 64 bit and loads from the boot volume bootx64.efi

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
and it still requires a GDT to be set up. So how does the
OS know where in memory that is, to avoid it, or to
change it?

Youre still missing the concept that its not the OS in control of that... its UEFI :)
mov bx, 0xf000
mov ds, bx
mov bx, ADDR16_OF(gdtr)
o32 lgdt [cs:bx]
Thats how UEFI does it.

Is that UEFI internals, or code from an example
OS that communicates with UEFI?

I'm not familiar with "o32".

Post by Joe Monk
Remember ... processor power on/reset -> vector 0xFFFFFFF0
in 16-bit unreal mode

Again, this involves a GDT existing somewhere in memory.
Or is there a way around that? I guess it doesn't matter
where it is. Like the UEFI code itself, it will just be
unavailable to the OS when it tries to find out where the
free memory is, by calling the appropriate API.

Post by Joe Monk
-> UEFI which transitions to 32 or 64 bit
and loads from the boot volume bootx64.efi

I assume the transition is done depending on what
the name of the .efi file is?

Does UEFI present the 32-bit OS with a flat
address space starting at address 0?

And what is the load module format of the 32-bit
.efi file? Is it ELF or is it a binary image? If it is a
binary image, what is the load address required
to be, and is the entry point required to be offset 0?

And how does the OS access UEFI services? Is it
provided with a callback pointer at startup, or does
it do an interrupt?

Thanks. Paul.

[Joe Monk]

"Is that UEFI internals, or code from an example
OS that communicates with UEFI?"

That is the UEFI reset code, which is executed every time the CPU is powered on or reset.

"I assume the transition is done depending on what
the name of the .efi file is?"

No, there are values stored in NVRAM.

"Does UEFI present the 32-bit OS with a flat
address space starting at address 0?"

When a 32-bit UEFI OS is loaded, the system firmware hands off control to the OS in flat 32-bit mode. All descriptors are set to their 4GiB limits so that all of memory is accessible from all segments.

"And what is the load module format of the 32-bit
.efi file? Is it ELF or is it a binary image? If it is a
binary image, what is the load address required
to be, and is the entry point required to be offset 0?"

UEFI uses a subset of the PE32+ image format with a modified header signature. The modification to the signature value in the PE32+ image is done to distinguish UEFI images from normal PE32 executables. The “+” addition to PE32 provides the 64-bit relocation fix-up extensions to standard PE32 format.

A UEFI image is loaded into memory through the EFI_BOOT_SERVICES.LoadImage() Boot Service. This service loads an image with a PE32+ format into memory. This PE32+ loader is required to load all sections of the PE32+ image into memory. Once the image is loaded into memory, and the appropriate fix-ups have been performed, control is transferred to a loaded image at the AddressOfEntryPoint reference according to the normal indirect calling conventions of applications based on supported 32-bit, 64-bit, or 128-bit processors. All other linkage to and from an UEFI image is done programmatically.

"And how does the OS access UEFI services? s it
provided with a callback pointer at startup, or does
it do an interrupt? "

Unless otherwise stated, all functions defined in the UEFI specification are called through pointers in common, architecturally defined, calling conventions found in C compilers. Pointers to the various global UEFI functions are found in the EFI_RUNTIME_SERVICES and EFI_BOOT_SERVICES tables that are located via the system table. Pointers to other functions defined in this specification are located dynamically through device handles. In all cases, all pointers to UEFI functions are cast with the word EFIAPI. This allows the compiler for each architecture to supply the proper compiler keywords to achieve the needed calling conventions. When passing pointer arguments to Boot Services, Runtime Services, and Protocol Interfaces, the caller has the following responsibilities:

• It is the caller’s responsibility to pass pointer parameters that reference physical memory locations. If a pointer is passed that does not point to a physical memory location (i.e., a memory mapped I/O region), the results are unpredictable and the system may halt.
• It is the caller’s responsibility to pass pointer parameters with correct alignment. If an unaligned pointer is passed to a function, the results are unpredictable and the system may halt.
• It is the caller’s responsibility to not pass in a NULL parameter to a function unless it is explicitly allowed. If a NULL pointer is passed to a function, the results are unpredictable and the system may hang.
• Unless otherwise stated, a caller should not make any assumptions regarding the state of pointer parameters if the function returns with an error.
• A caller may not pass structures that are larger than native size by value and these structures must be passed by reference (via a pointer) by the caller. Passing a structure larger than native width (4 bytes on supported 32-bit processors; 8 bytes on supported 64-bit processor instructions) on the stack will produce undefined results.

Calling conventions for supported 32-bit and supported 64-bit applications are described in more detail below. Any function or protocol may return any valid return code.
All public interfaces of a UEFI module must follow the UEFI calling convention. Public interfaces include the image entry point, UEFI event handlers, and protocol member functions. The type EFIAPI is used to indicate conformance to the calling conventions defined in this section. Non public interfaces, such as private functions and static library calls, are not required to follow the UEFI calling conventions and may be optimized by the compiler.

All of this and more can be found at: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf

Joe

[Joe Monk]

Let me give you an analogy that you will understand.

When a S/370 box is powered on, it goes thru a process called IML, which reads in the microsode for that system. Once IML is done, the system is ready to IPL.

Think of UEFI as IML'ing a PC. Once UEFI is done, it is ready to IPL via loading BOOTX64.EFI

Joe

[[e-mail]]

Post by Joe Monk
Let me give you an analogy that you will understand.
When a S/370 box is powered on, it goes thru a process called IML, which reads in the microsode for that system. Once IML is done, the system is ready to IPL.
Think of UEFI as IML'ing a PC. Once UEFI is done, it is ready to IPL via loading BOOTX64.EFI

BTW, FYI, that is not a helpful analogy. I'm not familiar
with S/370 IML. My knowledge of S/370 starts when
a IPL CCW is automatically issued and the first block
on the disk is loaded (to memory location 0), and I
have a choice of creating a CCW chain to load more
blocks, or starting to execute S/370 code.

And when my disk load chain is complete, it then
starts executing S/370 code (contained in my
block or blocks).

BFN. Paul.

[Scott Lurndal]

Post by Joe Monk
BIOS and UEFI are mutually exclusive. One or the other, but not both.
Joe

All Paul apparently cares about is the standard INT calls into the
legacy BIOS. The rest of the BIOS (all the hardware discovery
and chip-specific processor initailization code) is irrelevent to
his needs.

There should be no reason that he couldn't add a legacy INT handler
as UEFI module, assuming he can build his UEFI or that the UEFI
provider has a mechanism to load extensions.

I think he'd be better off using VT-x on Intel or AMD SVM to
run his code in a virtual machine. At least one of them, I can't
recall which, supports running real-mode code in the VM.

You just need hypervisor (e.g. KVM).

[Joe Monk]

"All Paul apparently cares about is the standard INT calls into the
legacy BIOS."

Which dont exist in UEFI, so what's the point?

Joe

[Scott Lurndal]

Post by Joe Monk
"All Paul apparently cares about is the standard INT calls into the
legacy BIOS."
Which dont exist in UEFI, so what's the point?

He has expressed a desire to use a modern UEFI system that
doesn't have a compatability layer for his 8086 real-mode
code.

[Joe Monk]

Post by Scott Lurndal
He has expressed a desire to use a modern UEFI system that
doesn't have a compatability layer for his 8086 real-mode
code.

UEFI doesnt even recognize real mode. How will this even be possible?

Joe

[Joe Monk]

"Actually, is there any reason why the "protective MBR"
can't be a real MBR?"

Yes. The protective mbr has no partition table, that is in the GPT at LBA 1.

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
Actually, is there any reason why the "protective MBR"
can't be a real MBR?

Yes. The protective mbr has no partition table, that is in the GPT at LBA 1.

That's fine. It would be a modified protective MBR
that loads (using INT 13H) LBA 1 into memory to
get the partition table.

The goal is to stick a USB stick into either a Mac
(with no BIOS) or a very old 80386 computer
(with no UEFI) and the user doesn't notice any
difference whatsoever. PDOS/386 comes up
either way, on a FAT-32 partition. And PDOS/386
is a Windows PE relocatable executable that
doesn't mind which way it was loaded, and is
expecting a parameter from the caller that
provides an array of callback functions to
retrieve sectors from disk etc. Those callback
functions will use the BIOS, or UEFI, or even
directly manipulate the hardware. That's beyond
the scope of the PDOS/386 kernel.

Any technical problem with that?

BFN. Paul.

[Joe Monk]

Post by ***@gmail.com
That's fine. It would be a modified protective MBR
that loads (using INT 13H) LBA 1 into memory to
get the partition table.
Any technical problem with that?

Like, INT 13h doesnt exist on a UEFI system?

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
That's fine. It would be a modified protective MBR
that loads (using INT 13H) LBA 1 into memory to
get the partition table.
Any technical problem with that?

Like, INT 13h doesnt exist on a UEFI system?

On a UEFI system, the 8086 code in the protective MBR
would be ignored, and instead UEFI is responsible for
going to LBA 1 and figuring things out.

So where's the problem?

BFN. Paul.

[Joe Monk]

"Once my bootloader receives control from UEFI,
surely it can switch the processor to real mode if
it wants to, and install an interrupt vector into
INT 13H which receives control and then does a
UEFI call? "

UEFI runs in 32-bit protected mode or 64-bit long mode only. No such thing as a real mode UEFI call.

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
Once my bootloader receives control from UEFI,
surely it can switch the processor to real mode if
it wants to, and install an interrupt vector into
INT 13H which receives control and then does a
UEFI call?

UEFI runs in 32-bit protected mode or 64-bit long mode only. No such thing as a real mode UEFI call.

What I meant was that my real mode code (that
receives control when INT 13H is invoked) will
switch to protected mode, do the UEFI call to
read a sector from disk or whatever, switch back
to real mode, then return from the interrupt.

BFN. Paul.

[Joe Monk]

"On a UEFI system, the 8086 code in the protective MBR
would be ignored, and instead UEFI is responsible for
going to LBA 1 and figuring things out."

A BIOS based system will not see a type 0xEE partition as bootable. In addition, the type 0xEE partition spans the entire disk ... all 2GB.

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
On a UEFI system, the 8086 code in the protective MBR
would be ignored, and instead UEFI is responsible for
going to LBA 1 and figuring things out.

A BIOS based system will not see a type 0xEE partition as
bootable.

Says who?

Doesn't the BIOS just load sector 0 into low memory (location
x'600' and begin execution at that address?

It is then up to the 8086 code to decide what to do next.

Regardless, I am happy to have a USB that requires
either:

1. The 80386 BIOS to be zapped to allow 0xEE instead
of whatever is normal.

2. A boot from floppy that then loads the MBR and
accepts 0xEE.

3. A utility that zaps the 0xEE to normal prior to putting
the USB stick into an 80386 system.

Post by Joe Monk
In addition, the type 0xEE partition spans the entire
disk ... all 2GB.

You might mean 2 TiB, but regardless, I don't see a problem
with this.

The 8086 code in the MBR (which I will custom write) will
know what to do.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
Doesn't the BIOS just load sector 0 into low memory (location
x'600' and begin execution at that address?

Actually, the BIOS loads the MBR to location x'7c00' and
then (I guess up to the MBR's discretion) the MBR
relocates itself to x'0600'.

BFN. Paul.

[Joe Monk]

Let me make it simple for you...

This is directly from the AMD System Programming book: https://www.amd.com/system/files/TechDocs/24593.pdf?print=anzwix&show=1 page 14...

"Virtual-8086 mode is not supported when the processor is operating in long mode. When long mode is enabled, any attempt to enable virtual-8086 mode is silently ignored."

So, on an AMD processor, there is no switching between "real mode" and long mode. Thus, is it simpler to write code that doesn't do this, and runs on any processor, or do you want to exclude AMD processors from your software?

Joe

[[e-mail]]

Post by Joe Monk
Virtual-8086 mode is not supported when the processor
is operating in long mode. When long mode is enabled,
any attempt to enable virtual-8086 mode is silently ignored.

Virtual 8086 mode is different from real mode. PDOS/386
switches to real mode, not V8086 mode. I have no interest
in V8086 mode.

On top of that, my main interest is 32-bit, not 64-bit
long mode. An AMD processor operating in 32-bit
protected mode is capable of invoking V8086 mode
anyway. Not that I want or need it, but it's available.

Post by Joe Monk
So, on an AMD processor, there is no switching between
"real mode" and long mode.

Both wrong and irrelevant.

Post by Joe Monk
Thus, is it simpler to write code that doesn't do this, and
runs on any processor, or do you want to exclude AMD
processors from your software?

When you say "runs on any processor" - I'm going to a
lot of trouble to do exactly that. But that includes the
first 80386 computer ever shipped.

BFN. Paul.

[Joe Monk]

"> So, on an AMD processor, there is no switching between

Post by Joe Monk
"real mode" and long mode.
Both wrong and irrelevant."

OK, once again... from the same guide, same page:

"Real mode is entered after reset or processor power-up. The mode is not supported when the processor is operating in long mode because long mode requires that paged protected mode be enabled."

So, no its neither wrong nor irrelevant. Once an AMD processor is put into long mode (in this case, by the UEFI functions before the bootloader is ever called), there is no returning to real mode.

Joe

[[e-mail]]

Post by Joe Monk
Real mode is entered after reset or processor power-up. The
mode is not supported when the processor is operating in
long mode because long mode requires that paged
protected mode be enabled.

I didn't say that real mode was supported in long mode.
I said you can switch from long mode to real mode.

Post by Joe Monk
So, no its neither wrong nor irrelevant. Once an AMD
processor is put into long mode (in this case, by the
UEFI functions before the bootloader is ever called),
there is no returning to real mode.

Says who?

I can certainly switch from 32-bit protected mode to
real mode. I've never gone into long mode, so I've
never personally tried to get out of it again, but I
believe it's straightforward.

It's not straightforward on the 80286 though.

And once again, I have no interest in going into long
mode in the first place. When UEFI sees a 32-bit
boot loader, there's no point entering long mode. It
needs to enter 32-bit protected mode (or 32-bit
unreal mode), or legacy mode or whatever it is called.

BFN. Paul.

[Joe Monk]

Post by ***@gmail.com
When UEFI sees a 32-bit
boot loader, there's no point entering long mode. It
needs to enter 32-bit protected mode (or 32-bit
unreal mode), or legacy mode or whatever it is called.

The SEC phase of UEFI executes before the bootloader is even loaded. On a 64-bit processor, the SEC phase places the processor into long mode, and performs its functions. If the bootloader is 32-bit, an AMD processor will run it in "compatibility mode"...

"Compatibility mode, a submode of long mode, allows system software to implement binary compatibility with existing 16-bit and 32-bit x86 applications. It allows these applications to run, without recompilation, under 64-bit system software in long mode..."

"From an application viewpoint, compatibility mode looks like a legacy protected-mode environment. From a system-software viewpoint, the long-mode mechanisms are used for address translation, interrupt and exception handling, and system data-structures."

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
When UEFI sees a 32-bit
boot loader, there's no point entering long mode. It
needs to enter 32-bit protected mode (or 32-bit
unreal mode), or legacy mode or whatever it is called.

The SEC phase of UEFI executes before the bootloader
is even loaded. On a 64-bit processor, the SEC phase
places the processor into long mode, and performs its
functions. If the bootloader is 32-bit, an AMD processor
will run it in "compatibility mode"...
"Compatibility mode, a submode of long mode, allows
system software to implement binary compatibility with
existing 16-bit and 32-bit x86 applications. It allows these
applications to run, without recompilation, under 64-bit
system software in long mode..."
"From an application viewpoint, compatibility mode looks
like a legacy protected-mode environment. From a
system-software viewpoint, the long-mode mechanisms
are used for address translation, interrupt and exception
handling, and system data-structures."

Ok, fair enough (to some extent). How then do 32-bit
versions of Windows work? I believe they run on the
latest processors and support V8086 mode. So they
must be switching to long mode to do UEFI calls, and
then back to legacy mode.

It's a bit strange that 32-bit versions of Windows
would need to have knowledge of long mode
though, in order to work at all.

BFN. Paul.

[Joe Monk]

How then do 32-bit versions of Windows work? I believe they run on the
latest processors and support V8086 mode

They use NTVDM....

"Windows doesn't give NTVDM, and any program running under it, direct access to physical memory, just like it doesn't any other Windows application direct access. Instead accesses by the program to memory are translated from linear addresses to physical addresses through page tables. This means that if your MS-DOS application writes to memory location 074B:0000 the CPU will convert this to a linear address of 000074B0 and then through a page table look up converts it a completely different physical address chosen by Windows. Windows also doesn't allow NTVDM, or the application running under it direct, access to device hardware, so any access to device memory will either be blocked or emulated by NTVDM."

It's a bit strange that 32-bit versions of Windows
would need to have knowledge of long mode
though, in order to work at all.

They dont. Read this again:

"From an application viewpoint, compatibility mode looks like a legacy protected-mode environment. From a system-software viewpoint, the long-mode mechanisms are used for address translation, interrupt and exception handling, and system data-structures."

So a 32-bit version of Windows thinks it is executing in protected mode. But the underlying system is translating any system level 32-bit calls into 64-bit versions and executing it...

Joe

[[e-mail]]

Post by Joe Monk
So a 32-bit version of Windows thinks it is executing in
protected mode. But the underlying system is translating
any system level 32-bit calls into 64-bit versions and executing it...

Ok, so long as my 32-bit OS has what looks like a
32-bit protected mode environment, that's all I
need. I assume that cs/ds will point to address 0.

When running PDOS/386 on a UEFI system, I have
no interest in real mode.

When running PDOS/386 on a BIOS-only system, I
wish to drop back to real mode (as I am doing now),
to access BIOS INT 13H.

So, the remaining question is - can I have a GPT disk
that boots on either UEFI-only or BIOS-only systems?

If not, what's the technical problem?

I'm only interested in the 32-bit OS at the moment.

Thanks. Paul.

[Joe Monk]

Post by ***@gmail.com
So, the remaining question is - can I have a GPT disk
that boots on either UEFI-only or BIOS-only systems?
If not, what's the technical problem?

"Can Windows 7, Windows Vista, and Windows Server 2008 read, write, and boot from GPT disks?"

"Yes, all versions can use GPT partitioned disks for data. Booting is only supported for 64-bit editions on UEFI-based systems."

"Can Windows 2000, Windows NT 4, or Windows 95/98 read, write, and boot from GPT?"

"No. Again, legacy software will see only the Protective MBR."

https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn640535(v=vs.85)?redirectedfrom=MSDN

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
So, the remaining question is - can I have a GPT disk
that boots on either UEFI-only or BIOS-only systems?
If not, what's the technical problem?

"Can Windows 7, Windows Vista, and Windows Server 2008 read, write, and boot from GPT disks?"
"Yes, all versions can use GPT partitioned disks for data. Booting is only supported for 64-bit editions on UEFI-based systems."

I saw another comment:

but since efi in macs is 64bit, you are required to match also os bitness.


That sounds like on a modern machine that only supports
64-bit UEFI, there is no way to boot a 32-bit OS.

And I thus have no choice but to provide a PDOS/x64
if I wish to boot from USB stick.

I could still do the modified "protective MBR" to allow
a separate OS and set of executables to run from the
same FAT-32 partition though. Sharing data at least.

BFN. Paul.

[Joe Monk]

Post by ***@gmail.com
That sounds like on a modern machine that only supports
64-bit UEFI, there is no way to boot a 32-bit OS.

No, thats incorrect. You can run a 32-bit OS on a 64-bit UEFI platform.

In fact, Apple does this still today.

Joe

[[e-mail]]

Post by Joe Monk

Post by ***@gmail.com
That sounds like on a modern machine that only supports
64-bit UEFI, there is no way to boot a 32-bit OS.

No, thats incorrect. You can run a 32-bit OS on a 64-bit UEFI platform.
In fact, Apple does this still today.

Ok, thanks for confirming. I came to the same
conclusion overnight. Instead of currently
switching to/from 16-bit real mode as PDOS/386
currently does, the BIOS abstraction layer just
needs to switch to/from 64-bit mode.

And if I had my own 32-bit drivers, I wouldn't even
need to return to 64-bit mode ever.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com

Post by Joe Monk
No, thats incorrect. You can run a 32-bit OS on a 64-bit UEFI platform.
In fact, Apple does this still today.

Ok, thanks for confirming. I came to the same
conclusion overnight. Instead of currently
switching to/from 16-bit real mode as PDOS/386
currently does, the BIOS abstraction layer just
needs to switch to/from 64-bit mode.
And if I had my own 32-bit drivers, I wouldn't even
need to return to 64-bit mode ever.

I have been told (in the ReactOS chat) that this is not true
after all. On a 64-bit UEFI with no CSM, you need a 64-bit
OS, because only usermode ring 3 can run in 32-bit
protected mode.

Unless I write a hypervisor, which doesn't work on all
64-bit CPUs, only ones which have:

vtd, vtx and nested paging on intel, svn, iommu and nested paging in amd's case


In the case of PDOS/386, I'm actually willing to run in
usermode, and rely on a BIOS abstraction layer, which
looks like it will need to be 64-bit and doing 64-bit
UEFI calls.

That's an interesting exercise in itself.

BFN. Paul.

[[e-mail]]

Ok, I have a 13-inch late 2011 Macbook Pro
(see apple button in the top left of screen
and then choose "about this mac")

That means it should still have CSM.

And in addition, I would expect USB support
to be more mature than earlier versions.

I did this:

sudo bless --device /dev/disk1s1 --setboot --nextonly --legacy
("diskutil list" shows my FAT-16 freedos hard disk partition)

sudo reboot

and when it reboots it shows:

No bootable device -- insert boot disk and press any key


Any idea what is happening?

Thanks. Paul.

[Scott Lurndal]

Post by ***@gmail.com
I have been told (in the ReactOS chat) that this is not true
after all. On a 64-bit UEFI with no CSM, you need a 64-bit
OS, because only usermode ring 3 can run in 32-bit
protected mode.
Unless I write a hypervisor, which doesn't work on all
vtd, vtx and nested paging on intel, svn, iommu and nested paging in amd's case

All processers made in the last decade have the listed features, even the ATOM.

[[e-mail]]

Post by Scott Lurndal

Post by ***@gmail.com
Unless I write a hypervisor, which doesn't work on all
vtd, vtx and nested paging on intel, svn, iommu and nested paging in amd's case

All processers made in the last decade have the listed features, even the ATOM.

Ok, in that case - how useful would a hypervisor be?
For some reason ReactOS doesn't have access to one,
but could apparently use one. But is it useful beyond
ReactOS and PDOS/386? I guess it's only of interest
to people who specifically want to run a 32-bit OS.
But I guess I'm the guy who doesn't want to invalidate
32-bit OSes. Including OS/2 etc.

And how much work is involved in writing one?

Thanks. Paul.

[[e-mail]]

Post by ***@gmail.com
But I guess I'm the guy who doesn't want to invalidate
32-bit OSes. Including OS/2 etc.

Well - I guess my main interest is not invalidating PDOS/386,
or other 32-bit OSes that the author is willing to maintain
because they didn't "write it properly".

Where "writing it properly" is something I haven't quite
isolated, and may not even be possible, but I'm talking
about knowledge of GPT partitions and the ability to
boot from a FAT-32 partition.

Something that was technically possible on the first
80386 by anyone who had "sufficient forethought".

Basically the people who created GPT probably had
sufficient information available in 1985 to sit down
and spec out GPT then and there, to prepare for the
future. The fact that there was a delay doesn't bother
me, I'm happy to return to all the OSes that were
written in 1986 and say "sorry guys, we took a while
to create the specs, please update your code".

And PDOS/386 and ReactOS can fit into that.

BFN. Paul.

[Branimir Maksimovic]

Post by ***@gmail.com

Post by ***@gmail.com
But I guess I'm the guy who doesn't want to invalidate
32-bit OSes. Including OS/2 etc.

Well - I guess my main interest is not invalidating PDOS/386,
or other 32-bit OSes that the author is willing to maintain
because they didn't "write it properly".
Where "writing it properly" is something I haven't quite
isolated, and may not even be possible, but I'm talking
about knowledge of GPT partitions and the ability to
boot from a FAT-32 partition.
Something that was technically possible on the first
80386 by anyone who had "sufficient forethought".
Basically the people who created GPT probably had
sufficient information available in 1985 to sit down
and spec out GPT then and there, to prepare for the
future. The fact that there was a delay doesn't bother
me, I'm happy to return to all the OSes that were
written in 1986 and say "sorry guys, we took a while
to create the specs, please update your code".
And PDOS/386 and ReactOS can fit into that.

386 is dead, long gone. Better write for current x86 architecture
that is AMD64, or no one will use your OS...

Post by ***@gmail.com
BFN. Paul.

[[e-mail]]

Post by Branimir Maksimovic

Post by ***@gmail.com
And PDOS/386 and ReactOS can fit into that.

386 is dead, long gone. Better write for current x86 architecture
that is AMD64, or no one will use your OS...

I will use it. That's a good start.

For 3 decades I have mostly kept myself constrained
to text mode that I know can be done even if I'm using
a 3270 terminal. I don't use IDEs. I use grep. etc.

The largest activity I do is GCC 3.2.3 optimized compiles
which require a system with about 24 MiB of memory.
I may use 3.4.6 which requires more, so I'm looking for
a 64 MiB environment. So S/380 and 80386. From there
I will go down (to 8086 and S/350 (16-bit) or even
8080 and S/340 (8-bit)), up (x64 and z/Arch) and
sideways (e.g. to Amiga). I don't have a solid roadmap.
This is a vague plan.

But at the moment I'm still sorting out the 80386. How
far can I go with it?

BFN. Paul.

[Branimir Maksimovic]

Post by ***@gmail.com

Post by ***@gmail.com
But I guess I'm the guy who doesn't want to invalidate
32-bit OSes. Including OS/2 etc.

Well - I guess my main interest is not invalidating PDOS/386,
or other 32-bit OSes that the author is willing to maintain
because they didn't "write it properly".
Where "writing it properly" is something I haven't quite
isolated, and may not even be possible, but I'm talking
about knowledge of GPT partitions and the ability to
boot from a FAT-32 partition.

You don't need GPT to boot from UEFI, except if there is some artificial
limit, but I think that is Windows thing more then BIOS. So if you write
your OS, you can hapilly boot from MBR, you just need FAT32 partition
as BIOS only undertands that format during boot. You also need PE file
to run. No loader, no GPT needed.

[Joe Monk]

You don't need GPT to boot from UEFI...

Yes, you do. As the UEFI spec says:

"A legacy MBR may be located at LBA 0 (i.e., the first logical block) of the disk if it is not using the GPT disk layout (i.e., if it is using the MBR disk layout). The boot code on the MBR is not executed by UEFI firmware."

https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf - page 115

Joe

[[e-mail]]

Post by Joe Monk

You don't need GPT to boot from UEFI...

"A legacy MBR may be located at LBA 0 (i.e., the first logical block) of the disk if it is not using the GPT disk layout (i.e., if it is using the MBR disk layout). The boot code on the MBR is not executed by UEFI firmware."
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf - page 115

I don't need it executed. If I can create a normal FAT-32
partition, and the MBR is ignored, that's fine, and is easier
than creating GPT.

BFN. Paul.

[[e-mail]]

Post by Branimir Maksimovic

Post by ***@gmail.com
Where "writing it properly" is something I haven't quite
isolated, and may not even be possible, but I'm talking
about knowledge of GPT partitions and the ability to
boot from a FAT-32 partition.

You don't need GPT to boot from UEFI,

Great!

Post by Branimir Maksimovic
except if there is some artificial
limit, but I think that is Windows thing more then BIOS. So if you write

Windows is not going to involved.

I'm interested in a modern Dell and in a 2011 Macbook Pro.

Both are 64-bit UEFI I believe.

I'd like a traditional hard disk, not GPT.

I'm happy to do FAT-32.

Post by Branimir Maksimovic
your OS, you can hapilly boot from MBR, you just need FAT32 partition
as BIOS only undertands that format during boot. You also need PE file
to run. No loader, no GPT needed.

Ok, so I need to provide a 64-bit PE file. I can work on
that. Currently I only produce 32-bit PE files, but all
indications are I need to provide a 64-bit PE file that
uses UEFI, and that's fine by me. Using a 16-bit BIOS
is fine too.

Can someone give me a "hello, world" program that
does it using 64-bit UEFI?

Thanks. Paul.

[Scott Lurndal]

Post by ***@gmail.com

Post by Scott Lurndal

Post by ***@gmail.com
Unless I write a hypervisor, which doesn't work on all
vtd, vtx and nested paging on intel, svn, iommu and nested paging in amd's case

All processers made in the last decade have the listed features, even the ATOM.

Ok, in that case - how useful would a hypervisor be?
For some reason ReactOS doesn't have access to one,
but could apparently use one. But is it useful beyond
ReactOS and PDOS/386? I guess it's only of interest
to people who specifically want to run a 32-bit OS.
But I guess I'm the guy who doesn't want to invalidate
32-bit OSes. Including OS/2 etc.
And how much work is involved in writing one?

I've written two (one in 1998, while VMware was still
a gleam in a Stanford professors eye), and one in
2004-2010. The former was more of a PoC, with
linux and windows running in parallel on a two cpu
HP Kayak (Pentium Pro). The team include the SGI
Chief engineer and three senior engineers.

The latter was a commercial product and had a team of
fifteen programmers and 12 quality assurance engineers
over a eight year stretch.

https://venturebeat.com/2008/09/22/3leaf-systems-raises-35-million-round-for-enterprise-virtualization-technology/


You could certainly write one sufficient for your
needs with less effort than any commercial offering.

[[e-mail]]

Post by Scott Lurndal
You could certainly write one sufficient for your
needs with less effort than any commercial offering.

I only need to run 32-bit ReactOS on a 64-bit
UEFI system.

So far the ReactOS people have only said that the only
way that will work is with a Hypervisor.

I couldn't give a shit how hacky that is. How many
lines of code are we talking about, and is it true that
that's the only way it is going to work?

Post by Scott Lurndal

I'm guessing those are things that run under some
other OS.

If you mean that either hypervisor runs on _top_ of
other OS, then no.

Yes, this is what I meant. Something has to load the
hypervisor into memory, so I assumed that would be
Windows, and then the hypervisor would somehow
take over the machine and require you to boot Windows
again if you wanted to actually use Windows.

Post by Scott Lurndal
Look up Type 1 and Type 2 hypervisors.
VMware is "type 1". KVM is "type 2".

Ok, I looked it up. So it seems these Type-1 hypervisors
are booted before Windows.

Ok, so for ReactOS, the situation is that no-one has yet
written a freeware type-1 hypervisor that ReactOS could
run under? KVM can't be trimmed down to do that?

I also just discovered that Freedos supposedly supports
LFN if you add some driver. That would give me an
alternative. ie I am interested in running Win32 executables
under HX.

However, that puts me back to being dependent on a BIOS,
and I seem to have run out of rope on that.

It seems to me that what I should do is transfer my data
to a FAT-32 64 GB USB stick, and remain with Windows 10.

And replace my BIOS-using IO.SYS with a 64-bit UEFI
IO.SYS, in due course.

Ironically, that would mean the only thing PDOS/386 can't
boot under would be 32-bit UEFI.

The 64-bit UEFI would switch between long mode and
PM32.

And I should forget both Freedos and ReactOS. Just stick
with Windows 10 and PD-Windows (PDOS/386). The model
used with PDOS/386 is more conducive for these different
hardware interfaces (16-bit BIOS, 32-bit UEFI, 64-bit UEFI).

And hopefully a lot of HX can be ported to PD-Windows.

And actually if I put Bochs on the USB stick, I would have
a system that I can take to any computer capable of running
Bochs. Which is probably good enough for now.

Although in future I will ask if a computer supports legacy
boot before buying to give me more options.

Hmmm. One more option. I could keep PDOS/386 as is,
and let it do INT 13H calls (which cause it to execute
IO.SYS that returns to real mode), and then switch to
64-bit UEFI to do the INT 13H equivalent. ie create an
artificial BIOS. And if I do that, I might be able to do
something that covers Freedos too.

Actually, when PDOS/386 does a BIOS call, it looks
like this:

/* BosVBEGetModeInfo - BIOS Int 10h Function 4F01h */

int BosVBEGetModeInfo(unsigned int mode, void *buffer)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;

regsin.x.ax = 0x4f01;
regsin.x.cx = mode;
sregs.es = FP_SEG(buffer);
regsin.x.di = FP_OFF(buffer);
#ifdef __32BIT__
sregs.es = (((unsigned long)buffer) >> 4) & 0xffffU;
regsin.x.di = ((unsigned long)buffer) & 0xf;
regsin.d.edi = (sregs.es << 16) | regsin.x.di;
#endif
int86x(0x10 + BIOS_INT_OFFSET, &regsin, &regsout, &sregs);
if (regsout.h.al != 0x4f) return (2);
return (regsout.h.ah);
}


ie 32-bit is already "unnatural". May as well go the whole
hog and set it up for UEFI 32 and 64.

BFN. Paul.

[[e-mail]]

On a UEFI64 system without BIOS, is the memory
region x'E0000' free?

What I could do is have a UEFI64 module that
relocates to x'E0000' and installs BIOS interrupt
vectors for INT 13H etc and produces UEFI64
calls. That would solve the problem of BIOS
being unmaintainable 8086 code.

It would then load sector 0 into memory and
pass control to it.

So PDOS/386 would be literally unchanged, the
only unusual thing would be that it was on
FAT-32 instead of FAT-16 and there would be
an extra BOOT.x64 or whatever file, and maybe
another BIOS.x64 file containing the 8086 code
that switches to long mode and back.

Having control of the BIOS would also mean that
I can interpret ANSI control characters, and return
ANSI keyboard sequences, at this level, which is
probably the correct place to be doing it. It's a
substitute for an external ANSI terminal and the
Atari does that too from memory.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
What I could do is have a UEFI64 module that
relocates to x'E0000' and installs BIOS interrupt
vectors for INT 13H etc and produces UEFI64
calls. That would solve the problem of BIOS
being unmaintainable 8086 code.

Although I don't know what's wrong with CM or
whatever it is called doing the same thing. Maybe
there's too many BIOS calls to do, whereas I only
need a few.

And it will really piss some people off that my
apps and OS are running PM32, switching to
real mode, switching to long mode, switching
back to real mode, then switching back to PM32.
One sector at a time.

It's worth doing just to see their heads explode.

BFN. Paul.

[[e-mail]]

Given that my hand is basically being forced by
UEFI, and given that FAT-32 disks "need" to be at
least 33 MB, and I would like PDOS/x86 to be
able to boot from a 20 MB hard disk, my options
are:

1. Assume that UEFI systems would be updated
to handle FAT-16 and FAT-12 if necessary.

2. Ignore Microsoft's rules and use FAT-32
universally, even for floppy disks.

Which is the better option?

Thanks. Paul.

[[e-mail]]

It occurred to me - I wondered what UEFI was going
to give me to replace COM1, because I want PDOS/x86
to bang COM1 to communicate with a BBS. Bochs
normally does that for me.

There is something called PXE. It needs a server. I'm
happy to provide one of them on Windows or whatever.

So it seems to me that I should be booting PDOS/x86
from the network, then the BIOS COM1 interface
(INT 14H) should be doing some sort of network calls
(or even talking to a different hard disk which my PXE
server knows is really COM1 accesses, which of
course get translated into internet connections).

BFN. Paul.

[Scott Lurndal]

Post by ***@gmail.com
It occurred to me - I wondered what UEFI was going
to give me to replace COM1, because I want PDOS/x86
to bang COM1 to communicate with a BBS. Bochs
normally does that for me.
There is something called PXE. It needs a server. I'm
happy to provide one of them on Windows or whatever.

Pre-eXecution Environment (PXE) provides a subset
of IP networking (UDP-based) to support booting from
a remote server.

PXE requires a remote DHCP server and a TFTP server.

The DHCP server provides UEFI with the IP address
assigned to the system (perhaps based on the MAC
address, or allocated from a pool) and also provides
the address of the TFTP server from which the
boot image will be retrieved). You need to configure
your DHCP server to provide the server address.

It does not provide a complete network stack;
only connectionless (UDP) packets.

[[e-mail]]

Post by Scott Lurndal

Post by ***@gmail.com
It occurred to me - I wondered what UEFI was going
to give me to replace COM1, because I want PDOS/x86
to bang COM1 to communicate with a BBS. Bochs
normally does that for me.
There is something called PXE. It needs a server. I'm
happy to provide one of them on Windows or whatever.

Pre-eXecution Environment (PXE) provides a subset
of IP networking (UDP-based) to support booting from
a remote server.
PXE requires a remote DHCP server and a TFTP server.
The DHCP server provides UEFI with the IP address
assigned to the system (perhaps based on the MAC
address, or allocated from a pool) and also provides
the address of the TFTP server from which the
boot image will be retrieved). You need to configure
your DHCP server to provide the server address.
It does not provide a complete network stack;
only connectionless (UDP) packets.

Ok, I have a really unusual "requirement", so this may in
fact be what I am after.

I don't care about the cost or inconvenience of having a
second computer. But I would like to run PDOS/386
directly on the hardware.

But since I'm still in 1990, I want to drive a COM port
to connect to a BBS (actually, I mainly want to connect
to eternal-september to get access to this newsgroup,
and I don't really see any conceptual difference between
that and a BBS).

I don't need PDOS/386 to have involvement with any
networking. Just a simple BBS (aka news server). I
don't need to connect directly to eternal-september,
I just connect to whoever happens to be connected
to COM1.

But of course I know exactly who is going to be on
COM1, because the "BBS" is the master computer
in the same room, running Linux or whatever, and
THAT has the network stack/encryption etc, and
does the actual connection to eternal-september.
And just passes that data through to COM1.

I have my 1990s PC with a COM port and a BIOS,
and everyone is happy. And when I'm running GCC,
which is CPU-bound, and the only thing I really care
about, it will be blazingly fast, because it is running
directly on a modern CPU.

And that includes if I am running the S/3X0 version
of GCC on my x64 hardware, using Hercules or my
own emulator.

All under 32-bit PDOS/386 which is already good
enough to run GCC 3.2.3 (x86 version only though -
I don't have the ability to run S/3X0 interpretation
software yet - not sure what is required to get that
up and running).

BFN. Paul.

[[e-mail]]

Actually, if I do a network boot, and it loads my
UEFI-64 BIOS, there is no reason why that BIOS
can't load a *different* MBR disk, which contains
a FAT-16 partition, containing PDOS/386.

So everything will look absolutely normal.

Surely someone has already done this? A simple
8086 BIOS that does UEFI64 calls?

Rather than invalidating every 8086 OS and
application?

BFN. Paul.

[[e-mail]]

After a LOT of experimentation and reading, I think my
Macbook requires a "hybrid MBR" before it will attempt
a boot off the USB stick in BIOS legacy mode.

Otherwise it just says:

No bootable device -- insert boot disk and press any key

I'm planning on writing a utility to update a .img file with
whatever is required to get the Mac to accept it.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
After a LOT of experimentation and reading, I think my
Macbook requires a "hybrid MBR" before it will attempt
a boot off the USB stick in BIOS legacy mode.

What is the logic here? As far as I can tell, this is 2011,
Mac supports BIOS, so for what reason would they go
to an effort to force GPT to be involved at all, instead of
doing the very straightforward thing of reading the MBR
into memory and end of story?

I'm guessing that they ignore the code in the MBR, so
I don't need to bother supplying that, and then after
going via the GPT they arrive at the boot sector, and
they probably don't second-guess that, so I can provide
a FAT-16 boot sector like I normally use.

BFN. Paul.

[Joe Monk]

"A) Are we allowed to exit long-mode once entered?

According to the Intel processor manuals, you can exit IA-32e mode
(long-mode) after it has been entered. See "9.8.5.4 Switching Out of
IA-32e Mode Operation". According to the AMD processor manuals, you can
also exit long mode after is has been entered. See "14.7 Leaving Long
Mode".

So, long-mode (LM64) can be switched out of by the OS at the processor
level, and the processor can then be switched into other processor
modes. I.e., once long-mode is entered the OS isn't forced to stay in
long-mode. The OS may switch out of long-mode and into another mode,
such as real-mode.

(This is contradictory to what you said.) "


This is incorrect.

On UEFI boot, on an X64 system, this is the code: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/ResetVector/Vtf0/Main.asm

%ifdef ARCH_IA32

;
; Restore initial EAX value into the EAX register
;
mov eax, esp

;
; Jump to the 32-bit SEC entry point
;
jmp esi

%else

;
; Transition the processor from 32-bit flat mode to 64-bit flat mode
;
OneTimeCall Transition32FlatTo64Flat


Now, look at Transition32FlatTo64Flat: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/ResetVector/Vtf0/Ia32/Flat32ToFlat64.asm

;------------------------------------------------------------------------------
; @file
; Transition from 32 bit flat protected mode into 64 bit flat protected mode
;
; Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.<BR>
; SPDX-License-Identifier: BSD-2-Clause-Patent
;
;------------------------------------------------------------------------------

BITS 32

;
; Modified: EAX
;
Transition32FlatTo64Flat:

OneTimeCall SetCr3ForPageTables64

mov eax, cr4
bts eax, 5 ; enable PAE
mov cr4, eax

mov ecx, 0xc0000080
rdmsr
bts eax, 8 ; set LME
wrmsr

mov eax, cr0
bts eax, 31 ; set PG
mov cr0, eax ; enable paging

jmp LINEAR_CODE64_SEL:ADDR_OF(jumpTo64BitAndLandHere)
BITS 64
jumpTo64BitAndLandHere:

debugShowPostCode POSTCODE_64BIT_MODE

OneTimeCallRet Transition32FlatTo64Flat


So, before the OS is ever loaded, the processor is placed into long mode and everything else in the boot sequence happens from long mode. Thus, when the OS is loaded, long mode is already enabled, the OS doesnt have a choice.

Joe

[Joe Monk]

"Ok, in that case - how useful would a hypervisor be?"

Ask VMWare. Or Microsoft (hyper-v).

Joe

[Scott Lurndal]

Post by Joe Monk
"Ok, in that case - how useful would a hypervisor be?"
Ask VMWare. Or Microsoft (hyper-v).

I'm guessing those are things that run under some
other OS.

If you interpret "under" to mean at in a more privileged
ring (e.g. ring -1 instead of the formerly most privileged
ring 0), then yes.

If you mean that either hypervisor runs on _top_ of
other OS, then no.

Look up Type 1 and Type 2 hypervisors.

VMware is "type 1". KVM is "type 2".

The 3Leaf DVMM (Distributed Virtual Machine Manager) was "type 1".

[Joe Monk]

The question is whether the loader/OS can transition
OUT of long mode, even though we're all agreed that
it will be ENTERED in long mode.

The loader cannot, as the UEFI environment is pure 64 bit. The OS can provided it is done correctly, see WOW64... "Wow64win.dll's functions on the x86-64 architecture, which switches the processor hardware from its 64-bit mode to compatibility mode when it becomes necessary to execute a 32-bit thread, and then handles the switch back to 64-bit mode."

Joe

[[e-mail]]

Post by Joe Monk

The question is whether the loader/OS can transition
OUT of long mode, even though we're all agreed that
it will be ENTERED in long mode.

The loader cannot, as the UEFI environment is pure 64 bit.
The OS can provided it is done correctly, see WOW64...

Ok, it sounds like all of us are in agreement on that then.

Post by Joe Monk
"Wow64win.dll's functions on the x86-64 architecture,
which switches the processor hardware from its 64-bit
mode to compatibility mode when it becomes necessary
to execute a 32-bit thread, and then handles the switch
back to 64-bit mode."

But I suspect that that Wow64 mode is not in supervisor
state.

The next question is - can you switch from long mode to
CM32 while retaining supervisor status?

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
The next question is - can you switch from long mode to
CM32 while retaining supervisor status?

Sorry, it wouldn't be CM32. The goal is to get out of
long mode and into PM32 so that you can have
supervisor status.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com

Post by ***@gmail.com
The next question is - can you switch from long mode to
CM32 while retaining supervisor status?

Sorry, it wouldn't be CM32. The goal is to get out of
long mode and into PM32 so that you can have
supervisor status.

Yes, here's the official list:

https://www.sandpile.org/x86/mode.htm

But it doesn't mention whether CM32 can be
supervisor status or not. I assume common
knowledge is that CM32 can't be supervisor
status unless you use a Hypervisor.

But surely ReactOS only needs to do a switch
to legacy mode (and thus PM32) to solve that
problem, no longer requiring a Hypervisor. I'll
ask why they aren't considering that.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
But surely ReactOS only needs to do a switch
to legacy mode (and thus PM32) to solve that
problem, no longer requiring a Hypervisor. I'll
ask why they aren't considering that.

I checked again what I was told:

even if you don't need the services, there are still SMM32 or 64 bolts running on the cpu which makes ACPI things to work

bitness has to match these

actually there is a sort of trickery which loonix does to make for example, go from UEFI32 to 64bit OS

but the inverse can't be done because architecture limitations in supervisor mode


I don't really understand the above, but is it true
that the "inverse can't be done"? Because of
supervisor mode?

BFN. Paul.

[Branimir Maksimovic]

Post by Joe Monk
So, before the OS is ever loaded, the processor is placed
into long mode and everything else in the boot sequence
happens from long mode. Thus, when the OS is loaded,
long mode is already enabled, the OS doesnt have a choice.

It will be the OS's loader that is loaded first, most
likely, rather than a direct load of the kernel. But
even if that is not the case, an OS can have a
loader added. And even if THAT isn't the case,
that's still not a problem, you just need appropriate
assembler in the kernel entry point.
The question is whether the loader/OS can transition
OUT of long mode, even though we're all agreed that
it will be ENTERED in long mode.
BFN. Paul.

UEFI is just Windows PE format. That is you can place
it in FAT32 partitition and boot directly without loader.
Loader is remnant of MBR boot and is not needed at all for UEFI.

[Scott Lurndal]

Post by ***@gmail.com

Post by Joe Monk

Post by ***@gmail.com
When UEFI sees a 32-bit
boot loader, there's no point entering long mode. It
needs to enter 32-bit protected mode (or 32-bit
unreal mode), or legacy mode or whatever it is called.

The SEC phase of UEFI executes before the bootloader
is even loaded. On a 64-bit processor, the SEC phase
places the processor into long mode, and performs its
functions. If the bootloader is 32-bit, an AMD processor
will run it in "compatibility mode"...
"Compatibility mode, a submode of long mode, allows
system software to implement binary compatibility with
existing 16-bit and 32-bit x86 applications. It allows these
applications to run, without recompilation, under 64-bit
system software in long mode..."
"From an application viewpoint, compatibility mode looks
like a legacy protected-mode environment. From a
system-software viewpoint, the long-mode mechanisms
are used for address translation, interrupt and exception
handling, and system data-structures."

Ok, fair enough (to some extent). How then do 32-bit
versions of Windows work? I believe they run on the
latest processors and support V8086 mode.

I'm pretty sure that Windows dropped support for V8086
mode in NT5.

The _only_ way to execute real-mode code after long-mode
has been enabled is to use the SVM or VT-X extensions.

(and only one of them supports virtualization of real-mode
applications, if I recall correctly).

[Joe Monk]

BTW, you should note that as of Windows 10 2004, Microsoft is no longer producing 32-bit versions of Windows.

Joe

[Joe Monk]

"I'm pretty sure that Windows dropped support for V8086
mode in NT5."

https://docs.microsoft.com/en-us/windows/compatibility/ntvdm-and-16-bit-app-support

Joe

[Rod Pemberton]

On Sat, 15 May 2021 06:42:52 -0700 (PDT)

Post by Joe Monk
Let me make it simple for you...
https://www.amd.com/system/files/TechDocs/24593.pdf?print=anzwix&show=1
page 14...
"Virtual-8086 mode is not supported when the processor is operating
in long mode. When long mode is enabled, any attempt to enable
virtual-8086 mode is silently ignored."

That means it ignores attempts to set RFLAGS.VM=1.
CR4.VME and TSS32.IRB are probably ignored too.

Of course, he should be able to disable long.mode by clearing
EFER.LMA=0. This should drop him into one of PM32, PM16, VM16E1,
VM16E0, or VM16 depending on the state of RFLAGS.VM, CR4.VME,
TSS32.IRB, CS.ar.D. He would need to turn off PAE too.
https://www.sandpile.org/x86/mode.htm

Intel "9.8.5.4 Switching Out of IA-32e Mode Operation" says it's a bit
more complicated to exit long-mode than simply clearing EFER.LMA which
is read-only: (rough summary) switch to CM16/CM32, clear CR0.PG=0 which
clears EFER.LMA, then clear EFER.LME, set CR0.PG=1.

Post by Joe Monk
So, on an AMD processor, there is no switching between "real mode"
and long mode. Thus, is it simpler to write code that doesn't do
this, and runs on any processor, or do you want to exclude AMD
processors from your software?

1) CM16 is the "equivalent" in long-mode (LM64) to virtual-mode (VM16,
VM16E0, VM16E1) for protected mode (PM16, PM32). He should only need
to jump to a code segment from long-mode with the CS.ar.D and CS.ar.L
descriptor bits set correctly to select CM16 or CM32 (equivalent to
PM32).
https://www.sandpile.org/x86/mode.htm

(You made note of using CM16/CM32 later in the thread, but only after
you told him "virtual" mode wasn't available ... What are CM16 and
CM32 if not "virtual" modes for LM64? Were you being pedantic here, or
just unaware of CM16/CM32 equivalence to PM16/PM32?)


2) Unless there is a hypervisor or microkernel as part of UEFI which
forces long-mode upon any guest OSes, by maintaining control of Ring-0,
as soon as his OS code takes control from UEFI, he can switch the
processor into any processor mode of his choice as his OS has
Ring-0 control. This includes switching out of long-mode or
compatibility mode and into either real-mode or protected-mode, the
latter from which he can access virtual-mode. In other words, as long
as his OS was entered in Ring 0 from UEFI, which it seems to be
according to one of the UEFI sections mentioned below, then his OS has
total control over which processor mode is executing. (Admittedly, I
didn't read the entire UEFI specs, just a quick search and skim. So, I
have no idea if an bootx68.efi or some other .efi loader file etc acts
as a Ring-0 shim.)


A) Are we allowed to exit long-mode once entered?

According to the Intel processor manuals, you can exit IA-32e mode
(long-mode) after it has been entered. See "9.8.5.4 Switching Out of
IA-32e Mode Operation". According to the AMD processor manuals, you can
also exit long mode after is has been entered. See "14.7 Leaving Long
Mode".

So, long-mode (LM64) can be switched out of by the OS at the processor
level, and the processor can then be switched into other processor
modes. I.e., once long-mode is entered the OS isn't forced to stay in
long-mode. The OS may switch out of long-mode and into another mode,
such as real-mode.

(This is contradictory to what you said.)


B) Is there any reason an OS couldn't switch the processor into the
mode of it's choice once control from UEFI is transferred to it?

If there is a hypervisor or microkernel controlling Ring-0 for UEFI,
that would prevent his OS from switching processor modes. This would
prevent exiting long-mode to enter protected-mode or real-mode, or
virtual mode via protected-mode. If such a hypervisor or microkernel
exists for UEFI, it is not mentioned in the UEFI sections regarding the
processor state upon transfer to the OS kernel. These sections state
that the processor mode can be changed for IA-32, but there is no
mention of this ability for x64. It appears to me, that this is an
oversight, as all the other processors in the specification have the
exact same statement on changing processor modes, and also have some
more notes on ACPI etc, all of which are missing from the x64 section.
If not, why would x64 be the only processor not capable of "altering
the processor execution mode" when both AMD and Intel manuals say x64
is capable of doing so? ... I.e., there should be an explicit
statement in the x64 section explaining why the processor can't be
switched out of long-mode (LM64), if it can't be for some reason with
UEFI. In other words, what's the difference for UEFI with x64
long-mode (LM64) from the other setups?


#1) UEFI 32-bit

UEFI "2.3.2 IA-32 Platforms"

"An application written to this specification may alter the processor
execution mode, ..."

The spec says that UEFI transfers to the OS in protected mode (assuming
32-bit), optional paging, PAE recommended for paging, memory map must
be identify mapped if paging is enabled, selectors are flat, interrupts
enabled but no interrupt services are available except timer functions,
direction flag is clear, (more stuff) ...

UEFI "2.3.2.1 Handoff State"

"When a 32-bit UEFI OS is loaded, the system firmware hands off control
to the OS in flat 32-bit mode. All descriptors are set to the 4GiB
limits so that all of memory is accessible from all segments.

"... in the image's PE32+ header ..."


#2) UEFI 64-bit

UEFI "2.3.4 x64 Platforms"

The spec says that UEFI transfers to the OS in long-mode, 64-bit mode,
paging is enabled, memory define by UEFI memory map is identity mapped,
selectors are flat, interrupts are enabled but no interrupt services
are available except timer functions, direction flag is clear, (more
stuff) ...

UEFI "2.3.4.1 Handoff State"

RCX - EFI_HANDLE
RDX - EFI_SYSTEM_TABLE *
RSP - <return address>

The spec doesn't mention the 64-bit processor state here for OS entry,
but one must assume that it is just like 2.3.2.1 but for 64-bit, as
2.3.2.1 matches 2.3.2, so 2.3.4.1 should match 2.3.4.

[wolfgang kern]

On 16.05.2021 10:30, Rod Pemberton wrote:

[...about return to trueRM(tm) from LM]

yes it is a bit tricky and need several steps but it works
if all involved memory are physical mapped and as long UEFI
wont act nasty with restricted privilege and until AMD/Intel
doesn't remove CM32.
__
wolfgang

[[e-mail]]

Post by Joe Monk

Post by Scott Lurndal
He has expressed a desire to use a modern UEFI system that
doesn't have a compatability layer for his 8086 real-mode
code.

Note that I'm mainly focused on PDOS/386. It's
true that it currently makes use of 8086 real mode
code (BIOS), but if it instead stays in 32-bit mode,
I don't consider that to be a disadvantage. If the
80386 had shipped with a 32-bit BIOS I would
definitely have used it.

PDOS/86 I'm mainly interested in having run on a
real 8086.

Post by Joe Monk
UEFI doesnt even recognize real mode. How will this even be possible?

Once my bootloader receives control from UEFI,
surely it can switch the processor to real mode if
it wants to, and install an interrupt vector into
INT 13H which receives control and then does a
UEFI call?

From then on, all applications, including an OS
kernel, could do INT 13H calls.

That's how I see it being possible, but that's not my
current plan.

BFN. Paul.

[Scott Lurndal]

Post by Joe Monk

Post by Scott Lurndal
He has expressed a desire to use a modern UEFI system that
doesn't have a compatability layer for his 8086 real-mode
code.

UEFI doesnt even recognize real mode. How will this even be possible?

Don't ask me. I find his obsession with DOS and 8086 real mode puzzling.

[Kerr-Mudd, John]

On Sat, 15 May 2021 15:22:49 GMT

Post by Scott Lurndal

Post by Joe Monk

Post by Scott Lurndal
He has expressed a desire to use a modern UEFI system that
doesn't have a compatability layer for his 8086 real-mode
code.

UEFI doesnt even recognize real mode. How will this even be possible?

Don't ask me. I find his obsession with DOS and 8086 real mode puzzling.

People at some point in their lives get stuck on what they (used to?) know and don't want to move on. I should know, I'm running WinXP & coding a Minefield prog in 8086 asm! (355 bytes - maybe I'll add scoring & go to 512; I pretty certain I can't get it under 256).

FFI see my clax post.