Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

This newsgroup.

231 views
Skip to first unread message

Dan Cross

unread,
Mar 21, 2023, 8:14:40 PM3/21/23
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 PM3/21/23
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 PM3/21/23
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 PM3/21/23
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 AM3/22/23
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 AM3/22/23
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 AM3/22/23
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 AM3/22/23
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 AM3/22/23
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 AM3/22/23
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 AM3/22/23
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 AM3/22/23
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 AM3/22/23
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 AM3/22/23
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 PM3/22/23
to
easy answer: it is C, aka limited+bloated+weird HLL-stuff.
__
wolfgang

wolfgang kern

unread,
Mar 22, 2023, 12:52:11 PM3/22/23
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 PM3/22/23
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 PM3/22/23
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 PM3/22/23
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 PM3/22/23
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 PM3/22/23
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 PM3/22/23
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 PM3/22/23
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 AM3/23/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 AM3/23/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 AM3/23/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 AM3/23/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 AM3/23/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 AM3/23/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 AM3/23/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 PM3/23/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 PM3/23/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 PM3/23/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 PM3/23/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.

Scott Lurndal

unread,
Mar 23, 2023, 4:09:10 PM3/23/23
to
cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>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?

AMD implemented SVM before Intel did VMX. It was
generally available circa 2005, so a few years after VMware.

>
>>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's been a while now, but the initial take was more paravirtualization
a la xen.

>
>>> 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.

True. I'm quite grateful that we can now squeeze a hundred
billion transistors on a single SoC :-).

Dan Cross

unread,
Mar 23, 2023, 4:31:44 PM3/23/23
to
In article <Dl2TL.317457$5S78....@fx48.iad>,
Scott Lurndal <sl...@pacbell.net> wrote:
>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>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?
>
>AMD implemented SVM before Intel did VMX. It was
>generally available circa 2005, so a few years after VMware.

Other way around, wasn't it? Intel released VMX in late 2005
while AMD released SVM in mid 2006.

>>>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's been a while now, but the initial take was more paravirtualization
>a la xen.

That makes sense.

>>>> 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.
>
>True. I'm quite grateful that we can now squeeze a hundred
>billion transistors on a single SoC :-).

All running at multi-gigahertz speeds. Quite the times we live
in.

- Dan C.

Scott Lurndal

unread,
Mar 23, 2023, 4:55:06 PM3/23/23
to
cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <Dl2TL.317457$5S78....@fx48.iad>,
>Scott Lurndal <sl...@pacbell.net> wrote:
>>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>>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?
>>
>>AMD implemented SVM before Intel did VMX. It was
>>generally available circa 2005, so a few years after VMware.
>
>Other way around, wasn't it? Intel released VMX in late 2005
>while AMD released SVM in mid 2006.

Yes, you're correct.

We had an early Pacifica (SVM) spec before it was released publically
in 2005.

I was thinking of the nested page table feature (which we relied
on heavily) which came before Intel's EPT. These were the features
that VMware and Xen really wanted to avoid the need to trap page
table updates by the guest (or paravirt them).

muta...@gmail.com

unread,
Mar 23, 2023, 6:27:19 PM3/23/23
to
On Friday, March 24, 2023 at 1:37:40 AM 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 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.

You have an existing PC, right?

So ignore the CD that came with the new PC.

On your old PC create a FAT-formatted USB stick,
or Joliet CD.

With the bootx64.ef on it.

And then boot from CD or USB stick (you may need to go
into the BIOS settings to choose to allow booting from
those devices).

> 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.

What do you currently use?

If you want to use someone else's OS that is capable of
formatting a disk and also capable of booting on UEFI,
and it can't be Windows, and it can't be Linux, I am not
familiar with that market. FreeBSD? PDOS/386 only
works with a BIOS system currently. PDOS-generic will
do UEFI but it is still proof-of-concept. It will basically
reuse the existing code though, so it shouldn't be a
big deal. The big deal is me trying to get it to do
unusual things like running 32-bit code in 64-bit mode
before taking it out of POC.

> Next demand would be a tool which can create folders.

That tool is normally called an OS, but there are some
tools called "mtools", and a fairly recent public domain
version too, that do that to a disk image.

On PDOS/386 I can make that disk image an actual
raw disk, which is what I use for formatting.

The tools are included on the PDOS/386 image.

They're written in C90 so you can run them on any other
system you can find (after recompilation).

> 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.

Yes, there is no choice. You need to create a PE executable.

It's just a normal PE executable, with the sole exception that
the subsystem number is set to 10. So that's one byte that
needs to change (plus the checksum, as that byte is included).

The linker will do this for you.

It's unclear to me what restrictions you are introducing,
or why, but I know of two linkers that produce 64-bit
PE files, both running under Windows, and neither
supplied with any version of PDOS. But if you just
want a single binary with 100k of "ret" or "nop" or x'00',
I can provide that for you.

> 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.

That can be embedded in the PE file. It's just code.

But you would need to take care of relocation yourself
if you are just zapping bytes instead of using a linker.

> > # So for testing, comment out the jmp and add 2 rets
> dup 64 ret ;wouldn't one be enough?

I didn't know the syntax.

> ;where would this return go to ?

The BIOS.

That above code is entered (from UEFI) via a call.

There will be 2 parameters (in registers, not on the
stack - that's the Microsoft 64-bit calling convention).

You would normally never return.

I returned just for illustration purposes.

And looped for illustration purposes too.

> so I assume the first 64 bytes are special purpose ?

No. If it was 64 bytes, that was just an accident. I just
typed in ret and then used micro-emacs and did ctrl-y
a large number of times so that you had some space
to zap.

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

You want to enter machine code, right?

So all I did was make space for testing purposes.
I used serial port as an example. I am guessing you
can send a single byte to the serial port in that
amount of space.

BFN. Paul.

T. Ment

unread,
Mar 23, 2023, 6:32:42 PM3/23/23
to
On Thu, 23 Mar 2023 11:17:14 -0700 (PDT), Rick C. Hodgin wrote:

> Using DOS 6.x and QEMM would probably be best,

I use QEMM but it's unstable. MS himem.sys is better. Maybe that's why
QDK went out of business and MS carried on.


> along with old Novell networking,

They went out of business too.

DOS Client32 with TCPIP.NLM is stable for me, provided I keep the config
simple. Trying to add extra protcols crashes it.

You need their developer TCP libs to write any TCP apps. Try and find
them now. Good luck.


muta...@gmail.com

unread,
Mar 23, 2023, 6:48:37 PM3/23/23
to
On Friday, March 24, 2023 at 2:17:15 AM UTC+8, Rick C. Hodgin wrote:

> FWIW, I miss this group.

No-one asked you to leave - people just asked you to
stop posting religious stuff.

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

Alternatively, you can answer questions people ask,
and refrain from posting religious stuff that no-one
at all asked for. (with the possible exception of
this post).

> 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.

What do you mean "enough"? You can't easily buy
such computers.

> 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.

Absolutely. And commercial enterprises ran on
mainframes with limited memory too. They weren't
mere toys. It was an entire industry.

Planes were developed with just a few K of memory
before that too. Not so much "before that" as "in the
beginning".

> 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.

Older technologies like floppy disks? Is the media still sold?

> 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.

Ok, in the past I have postulated nuclear war and time travel
and some asshole locking you up in the basement as potential
reasons you might be forced to work with limited memory.

And the guy who wrote "Collapse OS" thinks that is a realistic
situation too.

Can you explain the situation you apparently believe in, that
attracts you to DOS 6? You already mentioned 80386. Why
not a 32-bit OS (early Linux or anything else)?

Please limit any mention of God or Jesus to less than 100
words. But I'm interested in what technology remains after
God and Jesus have combined forces to unleash their
wrath.

> 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.

It's fantastic to see a real live computer "prepper".

Actually maybe I'm one of those too. I have bought a
lot of computers, but that's for testing, not really
for prepping hardware. I've been prepping software.

> And most importantly, I advise making preparations at the
> foot of the cross before doing any of this,

That I'm not interested in doing.

I'm happy to go to Hell. But before I do, I'm interested
in helping those who go to wherever you're going have
some suitable software for their journey. Which is what
PDOS is.

> and then concerning yourselves with all these other places after that.

What other places?

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

Consider yourself contacted and on-topic.

BFN. Paul.

muta...@gmail.com

unread,
Mar 23, 2023, 6:51:20 PM3/23/23
to
On Friday, March 24, 2023 at 6:32:42 AM UTC+8, T. Ment wrote:

> > Using DOS 6.x and QEMM would probably be best,

> I use QEMM but it's unstable. MS himem.sys is better. Maybe that's why
> QDK went out of business and MS carried on.

> > along with old Novell networking,
> They went out of business too.
>
> DOS Client32 with TCPIP.NLM is stable for me, provided I keep the config
> simple. Trying to add extra protcols crashes it.
>
> You need their developer TCP libs to write any TCP apps. Try and find
> them now. Good luck.

Good to see you back too.

Does Freedos not have everything you need?

What's the advantage of Microsoft and scrounging for
old software?

BFN. Paul.

Dan Cross

unread,
Mar 23, 2023, 7:37:15 PM3/23/23
to
In article <H03TL.1157078$gGD7....@fx11.iad>,
Scott Lurndal <sl...@pacbell.net> wrote:
>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <Dl2TL.317457$5S78....@fx48.iad>,
>>Scott Lurndal <sl...@pacbell.net> wrote:
>>>cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>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?
>>>
>>>AMD implemented SVM before Intel did VMX. It was
>>>generally available circa 2005, so a few years after VMware.
>>
>>Other way around, wasn't it? Intel released VMX in late 2005
>>while AMD released SVM in mid 2006.
>
>Yes, you're correct.
>
>We had an early Pacifica (SVM) spec before it was released publically
>in 2005.

Ah, cool.

>I was thinking of the nested page table feature (which we relied
>on heavily) which came before Intel's EPT. These were the features
>that VMware and Xen really wanted to avoid the need to trap page
>table updates by the guest (or paravirt them).

Ah, yes, absolutely. Shadow paging to multiplex the guest's
address space on the host virtual address space is not fun.

- Dan C.

T. Ment

unread,
Mar 23, 2023, 7:38:56 PM3/23/23
to
On Thu, 23 Mar 2023 15:51:18 -0700 (PDT), muta...@gmail.com wrote:

> Does Freedos not have everything you need?

It's more than I need.


> What's the advantage of Microsoft and scrounging for
> old software?

Installing MSDOS 6.22 and Windows 3.1 is quick and easy. I don't have
any agenda about licensing. It's just a hobby for me.


Grant Taylor

unread,
Mar 23, 2023, 8:29:24 PM3/23/23
to
On 3/23/23 5:38 PM, T. Ment wrote:
> Installing MSDOS 6.22 and Windows 3.1 is quick and easy. I don't have
> any agenda about licensing. It's just a hobby for me.

You might not have an agenda about the licensing. But that doesn't
change the fact that both MS-DOS and Microsoft Windows 3.1 were ~> still
are licensed products.

/Technically/ you should have a license to use them.



--
Grant. . . .
unix || die

T. Ment

unread,
Mar 23, 2023, 8:38:22 PM3/23/23
to
On Thu, 23 Mar 2023 18:29:05 -0600, Grant Taylor wrote:

> You might not have an agenda about the licensing. But that doesn't
> change the fact that both MS-DOS and Microsoft Windows 3.1 were ~> still
> are licensed products.

> /Technically/ you should have a license to use them.

Who said I don't?


muta...@gmail.com

unread,
Mar 23, 2023, 8:53:15 PM3/23/23
to
On Friday, March 24, 2023 at 8:38:22 AM UTC+8, T. Ment wrote:

> > You might not have an agenda about the licensing. But that doesn't
> > change the fact that both MS-DOS and Microsoft Windows 3.1 were ~> still
> > are licensed products.
>
> > /Technically/ you should have a license to use them.

> Who said I don't?

It's not a good solution if e.g. your house burns down so you
lose any evidence you had a license and need to buy a new
PC.

Or if you want to help a friend set up a PC.

Or start a business.

If Freedos is more than you need, why not create a trimmed-down
installation of it?

Incidentally, I have such a trimmed down installation myself.

Along with what is apparently the only surviving copy of
Open Watcom 1.6 on the net.

BFN. Paul.