This newsgroup.

149 views
Skip to first unread message

Dan Cross

unread,
Mar 21, 2023, 8:14:40 PMMar 21
to
So, is anyone here actually working on developing real, novel
operating systems on modern hardware here? It would be
interesting to have a USENET outlet for such things, which I had
hoped this newsgroup might be, but it seems dominated by other
things.

- Dan C.

T. Ment

unread,
Mar 21, 2023, 9:44:52 PMMar 21
to
On Wed, 22 Mar 2023 00:14:38 -0000 (UTC), Dan Cross wrote:

> is anyone here actually working on developing real, novel
> operating systems on modern hardware here?

Novel or not, an OS can't go far without device drivers. For that you
need manpower. I don't see much around here.


Scott Lurndal

unread,
Mar 21, 2023, 9:55:47 PMMar 21
to
cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>So, is anyone here actually working on developing real, novel
>operating systems on modern hardware here?

Been there, done that, moved on. Microkernels, distributed
operating systems, massively parallel systems, MCP, Unix,
Linux. All have common features, all have unique implementations.

I've sometimes considered that the golden age of operating system
design is behind us.

wolfgang kern

unread,
Mar 21, 2023, 10:10:43 PMMar 21
to
me too like to see attempts to create an UEFI compliant OS from scratch
w/o reusing C-libraries nor copies from already existing Lonnix/M$.

My own OS retired with me (1985..2018). Contracts end Dec.2024.
I'm too old for a complete restart on new motherboards, they all are
UEFI only now :(
__
wolfgang

muta...@gmail.com

unread,
Mar 22, 2023, 1:53:06 AMMar 22
to
On Wednesday, March 22, 2023 at 10:10:43 AM UTC+8, wolfgang kern wrote:
> On 22/03/2023 01:14, Dan Cross wrote:
> > So, is anyone here actually working on developing real, novel
> > operating systems on modern hardware here? It would be
> > interesting to have a USENET outlet for such things, which I had
> > hoped this newsgroup might be, but it seems dominated by other
> > things.

> me too like to see attempts to create an UEFI compliant OS from scratch
> w/o reusing C-libraries nor copies from already existing Lonnix/M$.

What's wrong with using a C library to do the UEFI calls?

BFN. Paul.

Dan Cross

unread,
Mar 22, 2023, 8:04:31 AMMar 22
to
In article <aumk1idql89fao2ku...@4ax.com>,
This is true. It strikes me that there are options here.

Virtualization with emulated devices is the obvious one.
While it doesn't eliminate it, this at least limits the scope
for drivers one must implement, if one is willing to use, say,
virtio for things like block storage, networking, etc.

Another option would be to use something like a rump kernel to
provide drivers for actual devices.

Porting drivers from existing systems is always an option,
though one that is a fair bit more labor intensive than the
others. Still, for a particularly complex device, it may be
less overall effort than building a new driver from scratch.

In many ways, we are lucky these days: there's far less
variation across bus architectures, storage options, etc, as
there once was.

- Dan C.

Dan Cross

unread,
Mar 22, 2023, 8:18:41 AMMar 22
to
In article <AetSL.205754$jiuc....@fx44.iad>,
I'm not sure I agree. We're largely stuck with system
interfaces that were first described in the late 1960s through
the early 1980s, but hardware has changed dramatically since
then. I don't think we've really stopped to ask ourselves
whether the systems we seem to have gravitated towards are still
a good fit for either the hardware we have, or the sorts of
programs we're running.

In particular, one sees lots of inate parallelism and
distribution across CPU, RAM, and IO fabrics at the hardware
level, implying asynchrony to use effectively. And one also
sees lots of asynchrony at the application layer, often embedded
in language runtimes and the like. But most systems provide a
highly synchronous system interface: so the asynchronous and
parallel application talks to the asychronous and parallel
hardware through this soda-straw of an interface designed to
make a multiprocessor machine with gigabytes of main memory,
a deep memory cache hierarchy, and an inherently asynchronous,
parallel IO architecture look like a PDP-11.

Interfaces like Linux's ioring implementation try to bridge this
gap within the context of an existing system, but are not
particularly orthogonal to the rest of the OS. One wonders if
we can do better, but it will require a shift in the accepted
wisdom about the system's overall architecture.

- Dan C.

Dan Cross

unread,
Mar 22, 2023, 8:19:52 AMMar 22
to
In article <tvdo30$bv1c$1...@dont-email.me>,
If you have a bootloader that is UEFI compliant, then can it not
load the OS, start it, and then basically get out of the way?

- Dan C.

Scott Lurndal

unread,
Mar 22, 2023, 10:31:43 AMMar 22
to
That depends. UEFI does more than just load and transfer control,
it isolates the OS from various hardware dependencies making the
OS more portable.

I can't imagine why someone would believe that the legacy BIOS
is in any way superior to UEFI.

Scott Lurndal

unread,
Mar 22, 2023, 10:35:09 AMMar 22
to
There are standards for several OS <-> hardware interfaces,
such as UHCI/EHCI/XHCI for USB, AHCI for SATA, NVME for
PCIe SSDs; yet there are many, just as important that don't
have a standard hardware interface (I2C, I3C, eMMC/SD, SMI,
and particularly, network interfaces and hardware accelerators).

Dan Cross

unread,
Mar 22, 2023, 11:02:46 AMMar 22
to
In article <hjESL.1556084$iS99....@fx16.iad>,
Eh....

>I can't imagine why someone would believe that the legacy BIOS
>is in any way superior to UEFI.

It is certainly not.

However, while it has utility, I wouldn't call it a "good"
interface. Did you catch Mothy Roscoe's OSDI'21 keynote on
rediscovering hardware?
https://www.usenix.org/conference/osdi21/presentation/fri-keynote

Don't get me wrong: interfaces are good. But they're better
when they are well-architected.

UEFI is part of the interface that has congealed.

- Dan C.

T. Ment

unread,
Mar 22, 2023, 11:10:02 AMMar 22
to
On Wed, 22 Mar 2023 12:18:39 -0000 (UTC), Dan Cross wrote:

> We're largely stuck with system interfaces that were first
> described in the late 1960s through the early 1980s, but
> hardware has changed dramatically since then.

Right, now we have bugs like Spectre.


Dan Cross

unread,
Mar 22, 2023, 11:10:55 AMMar 22
to
In article <tmESL.1556142$iS99....@fx16.iad>,
Don't forget SPI, GPIO, memory controllers, and on and on. I'm
not saying it's a completely solved problem, but at least we
mostly have commonality in terms of a bus architecture for fast
perhipherals. MSI and MSI-X dramatically simplifies interrupt
routing, and so on.

I suspect the situation is far worse on user-oriented devices.

- Dan C.

Dan Cross

unread,
Mar 22, 2023, 11:14:03 AMMar 22
to
In article <b06m1i5q7sps38bi1...@4ax.com>,
Yup. A system architecture that prefers all of physical memory
into the kernel's virtual address space doesn't make a lot of
sense anymore.

- Dan C.

wolfgang kern

unread,
Mar 22, 2023, 12:41:52 PMMar 22
to
easy answer: it is C, aka limited+bloated+weird HLL-stuff.
__
wolfgang

wolfgang kern

unread,
Mar 22, 2023, 12:52:11 PMMar 22
to
this is unfortunately not working. New bought PCs are don't have a
bootloader and my OS don't use GPT. So any try to install failed.
Also failed all attempts to boot from USB, I only see my start-screen
but everything locked up. (would need to rewrite all device drivers).
__
wolfgang

Dan Cross

unread,
Mar 22, 2023, 2:33:05 PMMar 22
to
In article <tvfb4e$mrsf$1...@dont-email.me>,
It certainly seems like the time for building large systems in C
has passed. Frankly, we have better choices now.

- Dan C.

Scott Lurndal

unread,
Mar 22, 2023, 2:55:21 PMMar 22
to
We had better choices three decades ago when we were writing full
operating systems (large scale, distributed) in C++[*][**].

We designed a hypervisor at SGI in the late 90's in C++[**].

Or a modula-like language called Sprite which we used at burroughs
for the mainframe MCP (medium systems) or NEWP which the large systems
folks used for MCP development.

[*] Circa 1989, C++2.1.

[**] In both cases using a subset that eschewed features with significant
run-time overhead, such as RTTI and Exceptions (most of which showed
up in C++3.0). And avoiding SGIs standard C++ library.

Dan Cross

unread,
Mar 22, 2023, 3:08:11 PMMar 22
to
In article <qaISL.960766$t5W7....@fx13.iad>,
Scott Lurndal <sl...@pacbell.net> wrote:
>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <tvfb4e$mrsf$1...@dont-email.me>,
>>wolfgang kern <now...@never.at> wrote:
>>>easy answer: it is C, aka limited+bloated+weird HLL-stuff.
>>
>>It certainly seems like the time for building large systems in C
>>has passed. Frankly, we have better choices now.
>
>We had better choices three decades ago when we were writing full
>operating systems (large scale, distributed) in C++[*][**].

Eh.... I don't know that C++ is a particularly compelling
improvement over C. It retains many of C's poor semantics, such
as the type promotion rules that can lead to hidden UB,
nullable pointers, etc, while the object and template semantics
are often surprising and unintuitive.

>We designed a hypervisor at SGI in the late 90's in C++[**].

Was that part of the Disco work?

>Or a modula-like language called Sprite which we used at burroughs
>for the mainframe MCP (medium systems) or NEWP which the large systems
>folks used for MCP development.

For that matter, Modula-2, Modula-3 or Oberon. Wirth's efforts
are underappreciated in the space.

>[*] Circa 1989, C++2.1.
>
>[**] In both cases using a subset that eschewed features with significant
>run-time overhead, such as RTTI and Exceptions (most of which showed
>up in C++3.0). And avoiding SGIs standard C++ library.

I've been pleasantly surprised at how well Rust fits the problem
domain. It's not perfect, but is much better than I had assumed
it would be when I first started playing around with it and it's
miles ahead of C.

- Dan C.

Scott Lurndal

unread,
Mar 22, 2023, 6:24:01 PMMar 22
to
cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <qaISL.960766$t5W7....@fx13.iad>,
>Scott Lurndal <sl...@pacbell.net> wrote:
>>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>>In article <tvfb4e$mrsf$1...@dont-email.me>,
>>>wolfgang kern <now...@never.at> wrote:
>>>>easy answer: it is C, aka limited+bloated+weird HLL-stuff.
>>>
>>>It certainly seems like the time for building large systems in C
>>>has passed. Frankly, we have better choices now.
>>
>>We had better choices three decades ago when we were writing full
>>operating systems (large scale, distributed) in C++[*][**].
>
>Eh.... I don't know that C++ is a particularly compelling
>improvement over C. It retains many of C's poor semantics, such
>as the type promotion rules that can lead to hidden UB,
>nullable pointers, etc, while the object and template semantics
>are often surprising and unintuitive.
>
>>We designed a hypervisor at SGI in the late 90's in C++[**].
>
>Was that part of the Disco work?

More like inspired by it. It was a skunkworks project with
about 8 people working on it, including the chief scientist jwag.


>I've been pleasantly surprised at how well Rust fits the problem
>domain. It's not perfect, but is much better than I had assumed
>it would be when I first started playing around with it and it's
>miles ahead of C.

It's on my list to look at, but probably not 'til I retire.

muta...@gmail.com

unread,
Mar 22, 2023, 6:25:05 PMMar 22
to
On Thursday, March 23, 2023 at 12:52:11 AM UTC+8, wolfgang kern wrote:

> > If you have a bootloader that is UEFI compliant, then can it not
> > load the OS, start it, and then basically get out of the way?

> this is unfortunately not working. New bought PCs are don't have a
> bootloader and my OS don't use GPT. So any try to install failed.
> Also failed all attempts to boot from USB, I only see my start-screen
> but everything locked up. (would need to rewrite all device drivers).

I have a x64 MBR FAT12 UEFI disk image at pdos.org and it
works fine on all the modern PCs I have tested it on.

I buy really cheap laptops though. Somewhere around US$200.

Some of the laptops are Chromebooks with Tianocore loaded.

Some are Windows laptops, but of course Windows is being
bypassed. All the Windows laptops are running American
Megatrends, which incidentally I couldn't get to do a legacy
boot, even though CSM or similar was shown in the BIOS.

BFN. Paul.

muta...@gmail.com

unread,
Mar 22, 2023, 6:34:33 PMMar 22
to
On Thursday, March 23, 2023 at 12:41:52 AM UTC+8, wolfgang kern wrote:

> >> me too like to see attempts to create an UEFI compliant OS from scratch
> >> w/o reusing C-libraries nor copies from already existing Lonnix/M$.
> >
> > What's wrong with using a C library to do the UEFI calls?
> > easy answer: it is C, aka limited+bloated+weird HLL-stuff.

Like UEFI itself?

The C library that I use that wraps the UEFI calls is 46k in total
(executable).

I suspect the requirements for UEFI are a modern machine
with much more than 46k of RAM.

You could use the generated assembler, and you could trim
it down, but is there a purpose to that?

You mentioned you want to see "attempts" (multiple, and
presumably in assembler) - why? Are you going to use them,
or you just want to look at them, even if they all have the
same design?

BFN. Paul.

Dan Cross

unread,
Mar 22, 2023, 8:51:51 PMMar 22
to
In article <2eLSL.316602$5S78....@fx48.iad>,
Scott Lurndal <sl...@pacbell.net> wrote:
>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <qaISL.960766$t5W7....@fx13.iad>,
>>Scott Lurndal <sl...@pacbell.net> wrote:
>>>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>In article <tvfb4e$mrsf$1...@dont-email.me>,
>>>>wolfgang kern <now...@never.at> wrote:
>>>>>easy answer: it is C, aka limited+bloated+weird HLL-stuff.
>>>>
>>>>It certainly seems like the time for building large systems in C
>>>>has passed. Frankly, we have better choices now.
>>>
>>>We had better choices three decades ago when we were writing full
>>>operating systems (large scale, distributed) in C++[*][**].
>>
>>Eh.... I don't know that C++ is a particularly compelling
>>improvement over C. It retains many of C's poor semantics, such
>>as the type promotion rules that can lead to hidden UB,
>>nullable pointers, etc, while the object and template semantics
>>are often surprising and unintuitive.
>>
>>>We designed a hypervisor at SGI in the late 90's in C++[**].
>>
>>Was that part of the Disco work?
>
>More like inspired by it. It was a skunkworks project with
>about 8 people working on it, including the chief scientist jwag.

Oh cool. I always thought that MIPS would be hard to virtualize
because of the ksegs and soft-TLBs. It was never clear to me
how a hypervisor could, in general, know the format of the guest
page tables. I know the Disco folks had to make some changes to
Irix to get it to work.

>>I've been pleasantly surprised at how well Rust fits the problem
>>domain. It's not perfect, but is much better than I had assumed
>>it would be when I first started playing around with it and it's
>>miles ahead of C.
>
>It's on my list to look at, but probably not 'til I retire.

Highly recommended. The first time I walked off the end of an
array in an ersatz ACPI parser and got a well-defined panic
instead of overwriting random data, the hair on my wrist stood
up.

- Dan C.

wolfgang kern

unread,
Mar 23, 2023, 4:39:07 AMMar 23
to


On 22/03/2023 23:34, muta...@gmail.com wrote:

>>>> me too like to see attempts to create an UEFI compliant OS from scratch
>>>> w/o reusing C-libraries nor copies from already existing Lonnix/M$.

>>> What's wrong with using a C library to do the UEFI calls?
>>> easy answer: it is C, aka limited+bloated+weird HLL-stuff.

> Like UEFI itself?

yes.

> The C library that I use that wraps the UEFI calls is 46k in total
> (executable).

> I suspect the requirements for UEFI are a modern machine
> with much more than 46k of RAM.

it's unfortunately the other way around:
I can't buy any new PC-hardware w/o UEFI on it.
an alternative option would be Raspberry Pi II :)

> You could use the generated assembler, and you could trim
> it down, but is there a purpose to that?

there's is no way to trim C-created code. Concept of C is wrong.

my OS need the BIOS only to load the first 1024 byte, it then deploys
itself with everything required incl. Debugger, GUI and device drivers.
So my Function-Call link is less than 46k namely just 2 byte:

mov eax,...;all parameters are in registers either VAL or PTR.
int 0x7f ;works in all CPU modes except BigReal(RM16,32bit CS).
...........;returned parameters are in registers by VAL or PTR

> You mentioned you want to see "attempts" (multiple, and
> presumably in assembler) - why? Are you going to use them,
> or you just want to look at them, even if they all have the
> same design?

I'm interested how and where to start such an attempt, but I wouldn't
"use" it because my program style was/is uncommon anyway.
for now I feel too old for a new start, but if all stars align ...
__
wolfgang

muta...@gmail.com

unread,
Mar 23, 2023, 5:09:00 AMMar 23
to
On Thursday, March 23, 2023 at 4:39:07 PM UTC+8, wolfgang kern wrote:

> > The C library that I use that wraps the UEFI calls is 46k in total
> > (executable).
>
> > I suspect the requirements for UEFI are a modern machine
> > with much more than 46k of RAM.

> it's unfortunately the other way around:
> I can't buy any new PC-hardware w/o UEFI on it.

I don't understand.

What's wrong with UEFI?

What's wrong with 46k as part of a BOOTX64.EFI?

> > You could use the generated assembler, and you could trim
> > it down, but is there a purpose to that?

> there's is no way to trim C-created code. Concept of C is wrong.

What I meant is that the 46k above can be trimmed
down. You don't need the entire C library linked in,
depending on what you want to do.

> > You mentioned you want to see "attempts" (multiple, and
> > presumably in assembler) - why? Are you going to use them,
> > or you just want to look at them, even if they all have the
> > same design?

> I'm interested how and where to start such an attempt,

You want to know how to write a hello world using UEFI?

There are examples on the net, and I have one too
(also on the net - but you have to go back to an older
version - also on the net - of the code to see that,
because I have since moved on from "hello world".

But the "hello world" code is still there, just commented out:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/efistart.c

if ((Status = print_string ("Hello, world!\n")))

static EFI_STATUS print_string (char *str) {

BFN. Paul.

muta...@gmail.com

unread,
Mar 23, 2023, 5:12:35 AMMar 23
to
On Thursday, March 23, 2023 at 5:09:00 PM UTC+8, muta...@gmail.com wrote:

> if ((Status = print_string ("Hello, world!\n")))

Clarification - that code doesn't use a C library,
even though it is written in C. It simply calls
the UEFI interface.

And I can provide the generated x64 code if you
want to see that.

So that would be standalone, small assembler code
to print hello world.

BFN. Paul.

wolfgang kern

unread,
Mar 23, 2023, 7:25:24 AMMar 23
to


On 23/03/2023 10:08, muta...@gmail.com wrote:

>>> The C library that I use that wraps the UEFI calls is 46k in total
>>> (executable).
>>
>>> I suspect the requirements for UEFI are a modern machine
>>> with much more than 46k of RAM.
>
>> it's unfortunately the other way around:
>> I can't buy any new PC-hardware w/o UEFI on it.

> I don't understand.
> What's wrong with UEFI?
> What's wrong with 46k as part of a BOOTX64.EFI?

first it's HLL-styled stack abusing bloatware. And I cannot boot my OS
on it nor use my own tools. it needs on INT13 to start.
So what is the UEFI equivalent to INT13 and how can I make it boot my
old stuff from either CD or USB ?

>> I'm interested how and where to start such an attempt,
> You want to know how to write a hello world using UEFI?

No! I like to see what tools are required to format and prepare a new PC
for my needs.
__
wolfgang

muta...@gmail.com

unread,
Mar 23, 2023, 9:15:57 AMMar 23
to
Not on my computer at the moment so can't reply properly.

You said you just needed your bootloader loaded and then you no longer use the bios, right?

In that case, the equivalent of int 13h is nothing.

You just need to name your bootloader bootx64.efi

Uefi has the bloat in firmware to recognize an entire file system.

There are some other issues though.

muta...@gmail.com

unread,
Mar 23, 2023, 10:45:57 AMMar 23
to
Ok, finally back at my computer.

On Thursday, March 23, 2023 at 7:25:24 PM UTC+8, wolfgang kern wrote:

> So what is the UEFI equivalent to INT13 and how can I make it boot my
> old stuff from either CD or USB ?

As mentioned, if all you need is a bit of code loaded,
you don't need to anything at all except plonk a
bootx64.efi into \efi\boot of a FAT-formatted disk.

Here is some assembler code:

C:\devel\pdos\pdpclib\xxx3>type efi64.asm
# Written by Paul Edwards
# Released to the public domain


.code64
.intel_syntax noprefix


.globl efimain
efimain:

# ret is 1 byte, jmp is 2 bytes
# So for testing, comment out the jmp and add 2 rets

# xxx: jmp xxx
ret
ret

ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret
ret


C:\devel\pdos\pdpclib\xxx3>


The assembler can be compiled and linked like this
(with mingw64 for Windows)

C:\devel\pdos\pdpclib\xxx3>type doit.bat
x86_64-w64-mingw32-as -o efi64.o efi64.asm
x86_64-w64-mingw32-ld -s -subsystem 10 -e efimain -nostdlib -o bootx64.efi efi64.o

C:\devel\pdos\pdpclib\xxx3>



Here are two executables:

C:\vbox\x64test\efi\boot>dir
Volume in drive C has no label.
Volume Serial Number is 4E58-AF11

Directory of C:\vbox\x64test\efi\boot

2023-03-23 22:17 <DIR> .
2023-03-23 22:17 <DIR> ..
2023-03-23 22:17 2,048 bootx64.efi
2023-03-23 22:15 2,048 loop.efi

C:\vbox\x64test\efi\boot>hexdump loop.efi
000000 4D5A9000 03000000 04000000 FFFF0000 MZ..............
000010 B8000000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80000000 ................
000040 0E1FBA0E 00B409CD 21B8014C CD215468 ........!..L.!Th
000050 69732070 726F6772 616D2063 616E6E6F is program canno
000060 74206265 2072756E 20696E20 444F5320 t be run in DOS
000070 6D6F6465 2E0D0D0A 24000000 00000000 mode....$.......
000080 50450000 64860200 F25E1C64 00000000 PE..d....^.d....
000090 00000000 F0002E02 0B020224 00020000 ...........$....
0000A0 00020000 00000000 00100000 00100000 ................
0000B0 00000040 01000000 00100000 00020000 ...@............
0000C0 04000000 00000000 05000200 00000000 ................
0000D0 00300000 00040000 79FD0000 0A006001 .0......y.....`.
0000E0 00002000 00000000 00100000 00000000 .. .............
0000F0 00001000 00000000 00100000 00000000 ................
000100 00000000 10000000 00000000 00000000 ................
000110 00200000 14000000 00000000 00000000 . ..............
000120 00000000 00000000 00000000 00000000 ................
000130 00000000 00000000 00000000 00000000 ................
000140 00000000 00000000 00000000 00000000 ................
000150 00000000 00000000 00000000 00000000 ................
000160 00000000 00000000 00000000 00000000 ................
000170 00000000 00000000 00000000 00000000 ................
000180 00000000 00000000 2E746578 74000000 .........text...
000190 60000000 00100000 00020000 00040000 `...............
0001A0 00000000 00000000 00000000 20005060 ............ .P`
0001B0 2E696461 74610000 14000000 00200000 .idata....... ..
0001C0 00020000 00060000 00000000 00000000 ................
0001D0 00000000 400030C0 00000000 00000000 ....@.0.........
0001E0 00000000 00000000 00000000 00000000 ................
0001F0 00000000 00000000 00000000 00000000 ................
000200 00000000 00000000 00000000 00000000 ................
000210 00000000 00000000 00000000 00000000 ................
000220 00000000 00000000 00000000 00000000 ................
000230 00000000 00000000 00000000 00000000 ................
000240 00000000 00000000 00000000 00000000 ................
000250 00000000 00000000 00000000 00000000 ................
000260 00000000 00000000 00000000 00000000 ................
000270 00000000 00000000 00000000 00000000 ................
000280 00000000 00000000 00000000 00000000 ................
000290 00000000 00000000 00000000 00000000 ................
0002A0 00000000 00000000 00000000 00000000 ................
0002B0 00000000 00000000 00000000 00000000 ................
0002C0 00000000 00000000 00000000 00000000 ................
0002D0 00000000 00000000 00000000 00000000 ................
0002E0 00000000 00000000 00000000 00000000 ................
0002F0 00000000 00000000 00000000 00000000 ................
000300 00000000 00000000 00000000 00000000 ................
000310 00000000 00000000 00000000 00000000 ................
000320 00000000 00000000 00000000 00000000 ................
000330 00000000 00000000 00000000 00000000 ................
000340 00000000 00000000 00000000 00000000 ................
000350 00000000 00000000 00000000 00000000 ................
000360 00000000 00000000 00000000 00000000 ................
000370 00000000 00000000 00000000 00000000 ................
000380 00000000 00000000 00000000 00000000 ................
000390 00000000 00000000 00000000 00000000 ................
0003A0 00000000 00000000 00000000 00000000 ................
0003B0 00000000 00000000 00000000 00000000 ................
0003C0 00000000 00000000 00000000 00000000 ................
0003D0 00000000 00000000 00000000 00000000 ................
0003E0 00000000 00000000 00000000 00000000 ................
0003F0 00000000 00000000 00000000 00000000 ................
000400 EBFEC3C3 C3C3C3C3 C3C3C3C3 C3C3C3C3 ................
000410 C3C3C3C3 C3C3C3C3 C3C3C3C3 C3C3C3C3 ................
000420 C3C3C3C3 C3C3C3C3 C3C3C3C3 C3C3C3C3 ................
000430 C3C3C3C3 C3C3C3C3 C3C3C3C3 C3C39090 ................
000440 FFFFFFFF FFFFFFFF 00000000 00000000 ................
000450 FFFFFFFF FFFFFFFF 00000000 00000000 ................
000460 00000000 00000000 00000000 00000000 ................
000470 00000000 00000000 00000000 00000000 ................
000480 00000000 00000000 00000000 00000000 ................
000490 00000000 00000000 00000000 00000000 ................
0004A0 00000000 00000000 00000000 00000000 ................
0004B0 00000000 00000000 00000000 00000000 ................
0004C0 00000000 00000000 00000000 00000000 ................
0004D0 00000000 00000000 00000000 00000000 ................
0004E0 00000000 00000000 00000000 00000000 ................
0004F0 00000000 00000000 00000000 00000000 ................
000500 00000000 00000000 00000000 00000000 ................
000510 00000000 00000000 00000000 00000000 ................
000520 00000000 00000000 00000000 00000000 ................
000530 00000000 00000000 00000000 00000000 ................
000540 00000000 00000000 00000000 00000000 ................
000550 00000000 00000000 00000000 00000000 ................
000560 00000000 00000000 00000000 00000000 ................
000570 00000000 00000000 00000000 00000000 ................
000580 00000000 00000000 00000000 00000000 ................
000590 00000000 00000000 00000000 00000000 ................
0005A0 00000000 00000000 00000000 00000000 ................
0005B0 00000000 00000000 00000000 00000000 ................
0005C0 00000000 00000000 00000000 00000000 ................
0005D0 00000000 00000000 00000000 00000000 ................
0005E0 00000000 00000000 00000000 00000000 ................
0005F0 00000000 00000000 00000000 00000000 ................
000600 00000000 00000000 00000000 00000000 ................
000610 00000000 00000000 00000000 00000000 ................
000620 00000000 00000000 00000000 00000000 ................
000630 00000000 00000000 00000000 00000000 ................
000640 00000000 00000000 00000000 00000000 ................
000650 00000000 00000000 00000000 00000000 ................
000660 00000000 00000000 00000000 00000000 ................
000670 00000000 00000000 00000000 00000000 ................
000680 00000000 00000000 00000000 00000000 ................
000690 00000000 00000000 00000000 00000000 ................
0006A0 00000000 00000000 00000000 00000000 ................
0006B0 00000000 00000000 00000000 00000000 ................
0006C0 00000000 00000000 00000000 00000000 ................
0006D0 00000000 00000000 00000000 00000000 ................
0006E0 00000000 00000000 00000000 00000000 ................
0006F0 00000000 00000000 00000000 00000000 ................
000700 00000000 00000000 00000000 00000000 ................
000710 00000000 00000000 00000000 00000000 ................
000720 00000000 00000000 00000000 00000000 ................
000730 00000000 00000000 00000000 00000000 ................
000740 00000000 00000000 00000000 00000000 ................
000750 00000000 00000000 00000000 00000000 ................
000760 00000000 00000000 00000000 00000000 ................
000770 00000000 00000000 00000000 00000000 ................
000780 00000000 00000000 00000000 00000000 ................
000790 00000000 00000000 00000000 00000000 ................
0007A0 00000000 00000000 00000000 00000000 ................
0007B0 00000000 00000000 00000000 00000000 ................
0007C0 00000000 00000000 00000000 00000000 ................
0007D0 00000000 00000000 00000000 00000000 ................
0007E0 00000000 00000000 00000000 00000000 ................
0007F0 00000000 00000000 00000000 00000000 ................

C:\vbox\x64test\efi\boot>



C:\vbox\x64test\efi\boot>hexdump bootx64.efi
000000 4D5A9000 03000000 04000000 FFFF0000 MZ..............
000010 B8000000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80000000 ................
000040 0E1FBA0E 00B409CD 21B8014C CD215468 ........!..L.!Th
000050 69732070 726F6772 616D2063 616E6E6F is program canno
000060 74206265 2072756E 20696E20 444F5320 t be run in DOS
000070 6D6F6465 2E0D0D0A 24000000 00000000 mode....$.......
000080 50450000 64860200 825F1C64 00000000 PE..d...._.d....
000090 00000000 F0002E02 0B020224 00020000 ...........$....
0000A0 00020000 00000000 00100000 00100000 ................
0000B0 00000040 01000000 00100000 00020000 ...@............
0000C0 04000000 00000000 05000200 00000000 ................
0000D0 00300000 00040000 E1C20000 0A006001 .0............`.
0000E0 00002000 00000000 00100000 00000000 .. .............
0000F0 00001000 00000000 00100000 00000000 ................
000100 00000000 10000000 00000000 00000000 ................
000110 00200000 14000000 00000000 00000000 . ..............
000120 00000000 00000000 00000000 00000000 ................
000130 00000000 00000000 00000000 00000000 ................
000140 00000000 00000000 00000000 00000000 ................
000150 00000000 00000000 00000000 00000000 ................
000160 00000000 00000000 00000000 00000000 ................
000170 00000000 00000000 00000000 00000000 ................
000180 00000000 00000000 2E746578 74000000 .........text...
000190 60000000 00100000 00020000 00040000 `...............
0001A0 00000000 00000000 00000000 20005060 ............ .P`
0001B0 2E696461 74610000 14000000 00200000 .idata....... ..
0001C0 00020000 00060000 00000000 00000000 ................
0001D0 00000000 400030C0 00000000 00000000 ....@.0.........
0001E0 00000000 00000000 00000000 00000000 ................
0001F0 00000000 00000000 00000000 00000000 ................
000200 00000000 00000000 00000000 00000000 ................
000210 00000000 00000000 00000000 00000000 ................
000220 00000000 00000000 00000000 00000000 ................
000230 00000000 00000000 00000000 00000000 ................
000240 00000000 00000000 00000000 00000000 ................
000250 00000000 00000000 00000000 00000000 ................
000260 00000000 00000000 00000000 00000000 ................
000270 00000000 00000000 00000000 00000000 ................
000280 00000000 00000000 00000000 00000000 ................
000290 00000000 00000000 00000000 00000000 ................
0002A0 00000000 00000000 00000000 00000000 ................
0002B0 00000000 00000000 00000000 00000000 ................
0002C0 00000000 00000000 00000000 00000000 ................
0002D0 00000000 00000000 00000000 00000000 ................
0002E0 00000000 00000000 00000000 00000000 ................
0002F0 00000000 00000000 00000000 00000000 ................
000300 00000000 00000000 00000000 00000000 ................
000310 00000000 00000000 00000000 00000000 ................
000320 00000000 00000000 00000000 00000000 ................
000330 00000000 00000000 00000000 00000000 ................
000340 00000000 00000000 00000000 00000000 ................
000350 00000000 00000000 00000000 00000000 ................
000360 00000000 00000000 00000000 00000000 ................
000370 00000000 00000000 00000000 00000000 ................
000380 00000000 00000000 00000000 00000000 ................
000390 00000000 00000000 00000000 00000000 ................
0003A0 00000000 00000000 00000000 00000000 ................
0003B0 00000000 00000000 00000000 00000000 ................
0003C0 00000000 00000000 00000000 00000000 ................
0003D0 00000000 00000000 00000000 00000000 ................
0003E0 00000000 00000000 00000000 00000000 ................
0003F0 00000000 00000000 00000000 00000000 ................
000400 C3C3C3C3 C3C3C3C3 C3C3C3C3 C3C3C3C3 ................
000410 C3C3C3C3 C3C3C3C3 C3C3C3C3 C3C3C3C3 ................
000420 C3C3C3C3 C3C3C3C3 C3C3C3C3 C3C3C3C3 ................
000430 C3C3C3C3 C3C3C3C3 C3C3C3C3 C3C39090 ................
000440 FFFFFFFF FFFFFFFF 00000000 00000000 ................
000450 FFFFFFFF FFFFFFFF 00000000 00000000 ................
000460 00000000 00000000 00000000 00000000 ................
000470 00000000 00000000 00000000 00000000 ................
000480 00000000 00000000 00000000 00000000 ................
000490 00000000 00000000 00000000 00000000 ................
0004A0 00000000 00000000 00000000 00000000 ................
0004B0 00000000 00000000 00000000 00000000 ................
0004C0 00000000 00000000 00000000 00000000 ................
0004D0 00000000 00000000 00000000 00000000 ................
0004E0 00000000 00000000 00000000 00000000 ................
0004F0 00000000 00000000 00000000 00000000 ................
000500 00000000 00000000 00000000 00000000 ................
000510 00000000 00000000 00000000 00000000 ................
000520 00000000 00000000 00000000 00000000 ................
000530 00000000 00000000 00000000 00000000 ................
000540 00000000 00000000 00000000 00000000 ................
000550 00000000 00000000 00000000 00000000 ................
000560 00000000 00000000 00000000 00000000 ................
000570 00000000 00000000 00000000 00000000 ................
000580 00000000 00000000 00000000 00000000 ................
000590 00000000 00000000 00000000 00000000 ................
0005A0 00000000 00000000 00000000 00000000 ................
0005B0 00000000 00000000 00000000 00000000 ................
0005C0 00000000 00000000 00000000 00000000 ................
0005D0 00000000 00000000 00000000 00000000 ................
0005E0 00000000 00000000 00000000 00000000 ................
0005F0 00000000 00000000 00000000 00000000 ................
000600 00000000 00000000 00000000 00000000 ................
000610 00000000 00000000 00000000 00000000 ................
000620 00000000 00000000 00000000 00000000 ................
000630 00000000 00000000 00000000 00000000 ................
000640 00000000 00000000 00000000 00000000 ................
000650 00000000 00000000 00000000 00000000 ................
000660 00000000 00000000 00000000 00000000 ................
000670 00000000 00000000 00000000 00000000 ................
000680 00000000 00000000 00000000 00000000 ................
000690 00000000 00000000 00000000 00000000 ................
0006A0 00000000 00000000 00000000 00000000 ................
0006B0 00000000 00000000 00000000 00000000 ................
0006C0 00000000 00000000 00000000 00000000 ................
0006D0 00000000 00000000 00000000 00000000 ................
0006E0 00000000 00000000 00000000 00000000 ................
0006F0 00000000 00000000 00000000 00000000 ................
000700 00000000 00000000 00000000 00000000 ................
000710 00000000 00000000 00000000 00000000 ................
000720 00000000 00000000 00000000 00000000 ................
000730 00000000 00000000 00000000 00000000 ................
000740 00000000 00000000 00000000 00000000 ................
000750 00000000 00000000 00000000 00000000 ................
000760 00000000 00000000 00000000 00000000 ................
000770 00000000 00000000 00000000 00000000 ................
000780 00000000 00000000 00000000 00000000 ................
000790 00000000 00000000 00000000 00000000 ................
0007A0 00000000 00000000 00000000 00000000 ................
0007B0 00000000 00000000 00000000 00000000 ................
0007C0 00000000 00000000 00000000 00000000 ................
0007D0 00000000 00000000 00000000 00000000 ................
0007E0 00000000 00000000 00000000 00000000 ................
0007F0 00000000 00000000 00000000 00000000 ................

C:\vbox\x64test\efi\boot>



If you rename loop.efi to bootx64.efi, you will get an
infinite loop as the first instruction.

bootx64.efi as it stands just returns immediately (via
ret) so you will return to your BIOS or a shell may be
executed or something else.

I included a whole lot of "ret" instructions as padding
so that you can zap your own machine code in to do
further testing.

I didn't use "nop" because the assembler pads with nop.

If you zap your own machine code, the required checksum
of the PE executable will change - I don't know if all/any
UEFI actually check that. The location of the checksum
is presumably one of these:

C:\vbox\x64test\efi\boot>fc /b loop.efi bootx64.efi
Comparing files loop.efi and BOOTX64.EFI
00000088: F2 82
00000089: 5E 5F
000000D8: 79 E1
000000D9: FD C2
00000400: EB C3
00000401: FE C3

That's strange - a recompilation changed both:

C:\devel\pdos\pdpclib\xxx3>fc /b \vbox\x64test\efi\boot\bootx64.efi bootx64.efi
Comparing files \VBOX\X64TEST\EFI\BOOT\bootx64.efi and BOOTX64.EFI
00000088: 82 49
00000089: 5F 64
000000D8: E1 A8
000000D9: C2 C7

Maybe the timestamp is included in the checksum.

So take a guess.

You'll presumably need to disable secure boot in the BIOS too.

Issues:

1. I'm not sure you will be in ring 0. Maybe try writing to the serial
port - I don't think you can write to b8000 because I think you
will be in graphics mode.

2. The loop will terminate after a while (minutes?) because of a
watchdog timer. There is a UEFI call to disable the watchdog.
I'm not sure you will need to do that if your bootloader does
something substantial.

3. As far as I know, most people do a UEFI call to "exit boot
services" before they start doing something substantial.
I don't know if you can bypass that.

So you may need to do 0, 1 or 2 UEFI calls.

I can provide the offsets if required:

C:\devel\pdos\pdpclib>grep -i exit efi.h
efi.h: void *Exit;
efi.h: void *ExitBootServices;

C:\devel\pdos\pdpclib>grep -i watchdog efi.h
efi.h: typedef EFI_STATUS (EFIAPI *EFI_SET_WATCHDOG_TIMER) (IN UINTN Timeout, IN UINT64 WatchdogCode, IN UINTN DataSize, IN CHAR16 *WatchdogData);
efi.h: EFI_SET_WATCHDOG_TIMER SetWatchdogTimer;

C:\devel\pdos\pdpclib>

But I've only tested the watchdog.

BFN. Paul.

Scott Lurndal

unread,
Mar 23, 2023, 10:52:17 AMMar 23
to
Indeed, it took another decade and a half before MIPS added
virtualization support to the architecture, IIRC; Cavium
was also a MIPS shop (until 2012, when we started the switch
to ARM64) and we had looked at the MIPS virtualization extensions around
that time.

The SGI skunkworks project used a 2 processor HP Kayak with
Pentium II (IIRC) processors; we had an instance of windows
running alongside an instance of linux. Microsoft had
given us the source for NT4 - this was about the time
that SGI was looking to move the graphics workstations
to intel/microsoft based boxen.

> It was never clear to me
>how a hypervisor could, in general, know the format of the guest
>page tables. I know the Disco folks had to make some changes to
>Irix to get it to work.

When I was working on IRIX, I was not fond of either the software
managed TLB, coloring or the Kseg stuff; the MIPS project I worked on was called
Teak and was a distributed version of Irix (eventually cancelled)
for networks of R10k boxes.

Rick C. Hodgin

unread,
Mar 23, 2023, 1:32:27 PMMar 23
to
On Tuesday, March 21, 2023 at 8:14:40 PM UTC-4, Dan Cross wrote:
> So, is anyone here actually working on developing real, novel
> operating systems on modern hardware here? It would be
> interesting to have a USENET outlet for such things, which I had
> hoped this newsgroup might be, but it seems dominated by other
> things.
>
> - Dan C.

I have one called "in/OS" for my RISC-like Inspire hardware architecture design.

I'm not posting in this group any more though, so you won't hear about it.

FWIW, I miss this group.

--
Rick C. Hodgin

wolfgang kern

unread,
Mar 23, 2023, 1:37:40 PMMar 23
to


On 23/03/2023 15:45, muta...@gmail.com wrote:

>> So what is the UEFI equivalent to INT13 and how can I make it boot my
>> old stuff from either CD or USB ?

> As mentioned, if all you need is a bit of code loaded,
> you don't need to anything at all except plonk a
> bootx64.efi into \efi\boot of a FAT-formatted disk.

here I have my first problem:
with a new assembled PC I get a main-board with a CD that contains only
a few drivers for windoze loonix and Mac, nothing boot able on it.
the HDs are all empty, not formatted in any usable mode.

So it would need me to buy a win11-DVD which I wont ever do.
any suggestion ? I'd need a boot able formatting tool first.

Next demand would be a tool which can create folders.
And then such a tool must be able to copy my OS-boot-image
into a bootx64.efi perhaps at a certain offset dunno yet how
.efi files were organized (I may find some info on the net)
but the hex-dumps below show that you created M$ PE-files.

one more problem: my OS-images incl. boot-part are just a bunch of
consecutive sectors (can be seen and stored as .bin files)
no header, no redirection, very own checksum algo.

> Here is some assembler code:

thanks for trying

> C:\devel\pdos\pdpclib\xxx3>type efi64.asm
> # Written by Paul Edwards
> # Released to the public domain
> .code64
> .intel_syntax noprefix
> .globl efimain
> efimain:
> # ret is 1 byte, jmp is 2 bytes
> # So for testing, comment out the jmp and add 2 rets

dup 64 ret ;wouldn't one be enough?
;where would this return go to ?

so I assume the first 64 bytes are special purpose ?

[...]there is no assembler :) and rare ever will be.

OK I'll keep the trail for reference (2K PE format).
__
wolfgang

Rick C. Hodgin

unread,
Mar 23, 2023, 2:17:15 PMMar 23
to
On Thursday, March 23, 2023 at 1:37:40 PM UTC-4, wolfgang kern wrote:
> here I have my first problem:
> with a new assembled PC I get a main-board with a CD that contains only
> a few drivers for windoze loonix and Mac, nothing boot able on it.
> the HDs are all empty, not formatted in any usable mode.

I have this thought, and then I'll bow out:

For a custom OS, it's enough to support the 1990s-based 80386 and/or 80486 systems and later up through probably the AMD-based Pentium equivalents, and even those systems with just a few MB of RAM. We forget what powerful software we had back in those days with limited resources. They just weren't GUI, or didn't use complex classes and objects, but more programming in C or assembly.

Those custom OSes will need only basic drivers for basic motherboard devices, floppy, hard disk, keyboard, mouse, video, and most importantly: networking. USB would be nice, as would things like SD cards and more modern storage as they're easy to transport. But I think it would be fine to stick with even older technologies as those are fairly easy to cobble together and get up and running with limited resources / labs / equipment.

IMO, for the world that's coming, having the ability to do any type of basic computation, and to be able to communicate with others using even very basic software, will be sufficient in that environment. Using DOS 6.x and QEMM would probably be best, along with old Novell networking, because many drivers for many compatible hardware devices existed into the late 90s.

A new era is almost upon us. It's time to prepare for it. Stock up on Ethernet cables, old compatible network cards, old PCs, etc.

And most importantly, I advise making preparations at the foot of the cross before doing any of this, and then concerning yourselves with all these other places after that.

If any of you wish to contact me, feel free to do so.

--
Rick C. Hodgin

Dan Cross

unread,
Mar 23, 2023, 3:49:33 PMMar 23
to
In article <yIZSL.1988479$vBI8....@fx15.iad>,
Scott Lurndal <sl...@pacbell.net> wrote:
>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>Oh cool. I always thought that MIPS would be hard to virtualize
>>because of the ksegs and soft-TLBs.
>
>Indeed, it took another decade and a half before MIPS added
>virtualization support to the architecture, IIRC; Cavium
>was also a MIPS shop (until 2012, when we started the switch
>to ARM64) and we had looked at the MIPS virtualization extensions around
>that time.

Same with x86, of course: how long after VMWare did their
binary-rewriting thing before Intel introduced VMX?

>The SGI skunkworks project used a 2 processor HP Kayak with
>Pentium II (IIRC) processors; we had an instance of windows
>running alongside an instance of linux. Microsoft had
>given us the source for NT4 - this was about the time
>that SGI was looking to move the graphics workstations
>to intel/microsoft based boxen.

Ah, very interesting; this was roughly the same era as VMWare's
initial offerings: I'm guessing you pulled the same incrememntal
rewriting trick they did?

>> It was never clear to me
>>how a hypervisor could, in general, know the format of the guest
>>page tables. I know the Disco folks had to make some changes to
>>Irix to get it to work.
>
>When I was working on IRIX, I was not fond of either the software
>managed TLB, coloring or the Kseg stuff; the MIPS project I worked on was called
>Teak and was a distributed version of Irix (eventually cancelled)
>for networks of R10k boxes.

I get it from a hardware perspective: fewer transistors with a
software-managed TLB, but man...so many drawbacks.

- Dan C.