DOS ain't dead

> > So the first constraint - can it be a FAT12 1.44
> > MB floppy image on USB stick instead of a real
> > physical floppy?
>
> A bootable USB is more realistic, but I'm trying not to go too far where
> everything is AMD64 or ARM64 with gigs of RAM and terabytes of disk space.

Absolutely.

BTW, since you are talking about challenges, I remembered
that I actually have two explicit "university challenges" -
one for 8086 and one for 80386 at pdos.org. They are both
40 MB images currently, but the 8086 used to be 20 MB
and can be returned to that if necessary (that was more
realistic back in 1983).

> > I was thinking of having a Youtube channel or similar
> > showing the construction of the OS from scratch.
>
> Good idea.

Ok, if you think that is a good idea, can you elaborate
on what you'd like to see? I downloaded the Sol-86 you
referenced and got it to boot (after zapping the last
2 bytes of the first sector), but after it said "done"
it seemed to freeze.

I thought that was a good idea - it is an independent
public domain OS as a starting point, and I do have
real hardware with a BIOS. I was thinking that I want
to quickly move to real hardware with UEFI though.
That would be 64-bit, but I was thinking I could
continue to run 32-bit software under 64-bit UEFI.
While staying in 64-bit mode. Things like push eax
would not be available, so I would need to manipulate
the stack manually.

The desire to switch from the old hardware to the new
hardware is because it is easier to replace. The new
computers I have bought in the last couple of years
don't have BIOS/CSM. Not working, anyway.

> There have been various Forth OSes over the years. Take a look at Nils
> (nmh)'s Sol-86. "Forth" is an OS, a compiler, an interpreter, an editor, a
> debugger, a calculator, etc.

Is there a reason why this is more viable in Forth
instead of C?

> There's something very limiting about the modern Linux mindset. Everything
> has to use GNU Make, Bash, Python, GCC, etc. I'd like it if we weren't so
> tied to our specific architectures or OSes or even tools.

Well you do need to pick a language. I picked C in
the late 1980s after a discussion with someone at
my workplace.

And if the language is standardized (C90 works on
both MSDOS and IBM mainframes), you should be set.

And for an OS you also need to pick a file system.

And you need to pick an API to manipulate that file
system for things that aren't part of C90, like
creating a directory.

So PDOS-generic has all this (and basically no more).

So I sort of know where I want to end up.

And I like the idea of starting from a floppy.

But even back in 1983 you could use the floppy
to format a hard disk so that you have more
space.

And there's one more thing I know about.

The IBM S360/67 had physical switches that allowed
you to zap physical memory. So you should be able
to IPL (boot) just from that.

Or you can IPL from punched cards (which could be
hand-punched).

And although they didn't have it at the time, I have
proven (via a modified Hercules), that you can IPL
from a terminal.

Basically the PC MBR code could be entered as hex
digits on a terminal. And there is no BIOS. The
hardware does support "read a block" and "write a
block" though, so it's not really much different
from a BIOS function to do that.

So maybe the floppy should contain a program that
doesn't do any more than front-end read and write
blocks. Or even simply write a single block. Just
write an MBR and if you want anything more than
that, you need to code it yourself in code to be
put onto the MBR. The program on floppy would
perhaps just be a boot sector, allowing the input
of hex up to 512 bytes and writing it to the MBR.

But yeah, we'd need to restrict it to a computer
that has a BIOS.

And you zap a program into existence that allows
writing to more than just sector 0.

And this would allow a FAT-16/32 disk to be created,
to get 64-bit UEFI (bootx64.efi) started.

Note that I have real hardware that can boot a floppy
image from a CD (El Torito) and a hard disk that can be
trashed and a bios.

To burn a CD I would use Windows though.

Perhaps better would be if I can boot Freedos
and use debug to write a floppy disk boot
sector to USB stick. I've never tried booting
a floppy disk image on USB stick. Let me test
that now.

Yep, it works! I can have a floppy image on USB
stick.

Although I got a strange result at first. I was
getting two hard disks, even though one was my
floppy disk. But I don't know how to reproduce
that problem. It might have been because it used
to hold a hard disk image, and this PC knew about
it, and I needed to exclude the "USB key" from
the boot order so that it would forget about it,
and then add it back in.

So how about I wipe the hard disk, including NULing
LBA 0, then boot freedos, then run debug and create
a floppy disk sector on an otherwise null floppy
disk image (not sure what my PC is looking for to
detect that it is a floppy).

Or I could use PDOS/386 to do all the above, and
zap bytes on the floppy disk boot sector, to then
begin the process.

And if I am missing any assembler knowledge, I'll
have to go off-screen to my Windows computer, print
out some documentation, and then pick it up again
the next day, forcing a delay.

Something like that?

Or how about using a Chromebook to print the
documentation so that Windows is not involved
in any step?

Or a phone call to someone who knows the answer
and I write it down on paper?

That sounds pretty clean-room to me.

The process can be independently filmed on an
Android phone, and uploaded to Youtube using
Chrome OS?

And I can call a lay person in the Philippines
to do google searches for the required information.

Or multiple lay people? A bit like "phone a friend"
in "who wants to be a millionaire?".

> > > Maybe I just want to reinvent Minix (aka "mini-UNIX").
> >
> > Why not mini-DOS, given that you're here?
>
> Dumb question from me, but isn't UEFI just a modern DOS?

UEFI has an API very different from MSDOS, so
it's a bit like saying that Linux is modern DOS.

If you wrap either of those with a C90 layer
(as I have done with UEFI), then everything looks
the same. You would notice a difference in
filenames though.

> Or should a modern
> DOS just be a UEFI app? Realistically, QEMU (or even DOSBox) is considered
> "good enough" by most people.

I'm not sure, but I can tell you that I first made
a "pseudo BIOS" as a UEFI app (and then named that
app bootx64.efi). And then the pseudo bios loads
pdos.exe which is a 64-bit PE executable that does
API calls into the pseudo-bios. It doesn't do its
own interrupts. Nor do further apps that it loads.

> I'm not sure I believe the future is x64 or even ARM64. It's probably going
> to be something else entirely.

pdos-generic and any apps can be rebuilt for any
processor (ie just by recompilation).

The pseudo-bios is designed to be changed though.

BFN. Paul.

> > What I'm wondering is whether there is an "implied
> > right" in any copyrighted OS that their OS shouldn't
> > be used to develop a competitor, thus invalidating
> > my work.
>
> No, this has never been a thing.

Many things have never been a thing.

It was never a thing that the Australian constitution
was "deemed" to have an "implied" right to freedom of
speech until some judges didn't like some legislation
and just made crap up.

One thing our constitution DOES say is that the
Governor General controls the navy.

And THAT is complete crap. The PM controls all the
armed forces.

Note - I'm Australian but currently in the Philippines.

> You can wholly develop whatever programs
> you want (including an operating system) using another operating system as
> a development platform. What you create is yours.

Sure, that's the way it SHOULD be.

> What you can't do is re-use any components from that operating system to
> create yours. For example, let's say someone wanted to create a new version
> of Windows95. You can't use the icons and other graphics from Windows95 to
> create "WinChicago" or whatever. The icons are copyrighted, so you can't
> use them elsewhere without permission (and Microsoft is unlikely to grant
> permission to do that with any of their icons).

Sure, I wouldn't touch anything like that.

BFN. Paul.