DOS ain't dead

Apparently there was work done on an open-source CP/M 2.2 clone called CP/Mish by David Given.

He talked about it on his website with an interesting YouTube video of his Amstrad NC200 laptop. So a Z80 laptop with 720 kb floppy drive and 128 kb of RAM in 1993!

Long story short, he put seven programming languages on the 720 kb floppy.

* BDS C
* MS FORTRAN-80
* MS COBOL-80
* Turbo Pascal
* MS BASIC
* BBC BASIC
* FIG Forth

As pointless as some people consider it, I've long wondered what (in theory) to put on a 1.44 MB 3.5" programming floppy for FreeDOS.

However, my criteria are that it must be Free/Libre (i.e. redistributable) and must actually be used by someone! So no toys or hacks that no one will ever use. (Auxiliary programming tools are also welcome, e.g. vi or ctags or make.)

Any suggestions? (There has to be at least one tool that we can all agree upon.)

MAWK, miniSed, P5 Pascal, Alice Pascal, SmallerC, SubC, PicoC, DX Forth, NASM16 or TinyAsm, FASMD, a72, BWBASIC, SmallAda, ???

> As pointless as some people consider it, I've long wondered what (in
> theory) to put on a 1.44 MB 3.5" programming floppy for FreeDOS.
>
> However, my criteria are that it must be Free/Libre (i.e. redistributable)
> and must actually be used by someone!

I am interested in this proposal, but can you elaborate on what the situation might be?

Because you've specified "must actually be used".

Can you give me a theoretical use case where someone would be using a 1.44 MB floppy?

Would this be on a real computer after a nuclear holocaust and civilization is being rebuilt? Or perhaps if you lock someone in a basement with that real or emulated hardware and told them that was the only thing available - it was either that or watch ants?

> MAWK, miniSed, P5 Pascal, Alice Pascal, SmallerC, SubC, PicoC, DX Forth,
> NASM16 or TinyAsm, FASMD, a72, BWBASIC, SmallAda, ???

Enhancing SubC using SubC would be a worthy project that may come close to fitting on a floppy.

Especially if you're allowed to distribute the source as a zip and unzip onto a hard disk.

Below is something from the PDOS documentation. Switching to Freedos will save some space. But you will hit another problem - SubC is so big that it no longer fits into small memory model, so you need to switch it to medium, large or huge first. But you can probably overcome that problem if you use a DOS extender. But then I think you will lose the supporting tools.

Anyway, that's why I ship both an older SubC that is self-compiling and an enhanced SubC built with Watcom large memory model on the PDOS/86 distribution. Theoretically it might just be enough so that you don't have to zap machine code, and can instead do all your programming in a subset of C (and that subset can be lifted if you spend effort).

BFN. Paul.



If your hard disk breaks, it is touch-and-go whether you can continue
to develop SubC on the single 1.2 MB floppy disk. Here are some rough
technical specs of the "state of play":

Line of code:

pdpclib (C library) 20k
pdos (operating system) 30k
pdmake (build program) 1k
pdcc (C preprocessor) 7k
subc (C compiler) 6k
pdas (80386 assembler) 4k
pdar (a.out archiver) 800
pdld (a.out linker) 800
msged (editor) 25k

Executable size:

pdos 119k (kernel) plus 77k (shell, which includes pdpclib, about 37k),
plus 39k (msvcrt.dll C library), plus 37k (kernel32.dll Win32 interface)
pdmake 11k
pdcc 53k
subc 66k
pdas 27k
pdar 11k
pdld 11k
msged 194k (includes statically linked pdpclib, about 32k)

Main SubC source code is about 130k in size, 119k for the object code.
The archive is 125k, plus you will need two copies of the executable at
138k each. All of this, plus the above executables, comes to around
1165k, so may squeeze onto a 1.2 MB floppy.

Note that PDOS-generic would save space by having only one copy of the
C library in the OS and the shell, msged and SubC would all be using
that, thus saving about 4 * 30k = 120k.

> > As pointless as some people consider it, I've long wondered what (in
> > theory) to put on a 1.44 MB 3.5" programming floppy for FreeDOS.
> >
> > However, my criteria are that it must be Free/Libre (i.e.
> redistributable)
> > and must actually be used by someone!
>
> I am interested in this proposal, but can you elaborate on what the
> situation might be?

It's purely hypothetical, but I want to try to be practical.

> Because you've specified "must actually be used".

Things like PL/0 are certified toys that nobody uses. I want something useful (e.g. AWK, but even Sed is also good albeit not Turing complete).

> Can you give me a theoretical use case where someone would be using a 1.44
> MB floppy?

10 MB hard disk image? 20? 50? 2 GB? When is it enough to do "something" useful?

> Would this be on a real computer after a nuclear holocaust and civilization
> is being rebuilt? Or perhaps if you lock someone in a basement with that
> real or emulated hardware and told them that was the only thing available -
> it was either that or watch ants?

I was thinking more like: "Let's tell news://comp.lang.misc or news://comp.lang.asm.x86 and see what they come up with (in a year)." You know, give them a limited environment to develop something useful (that doesn't require ten bazillion gigs).

> > MAWK, miniSed, P5 Pascal, Alice Pascal, SmallerC, SubC, PicoC, DX Forth,
> > NASM16 or TinyAsm, FASMD, a72, BWBASIC, SmallAda, ???
>
> Enhancing SubC using SubC would be a worthy project that may come close to
> fitting on a floppy.
>
> Anyway, that's why I ship both an older SubC that is self-compiling and an
> enhanced SubC built with Watcom large memory model on the PDOS/86
> distribution. Theoretically it might just be enough so that you don't have
> to zap machine code, and can instead do all your programming in a subset of
> C (and that subset can be lifted if you spend effort).

It's not that assembly is impossible or that C is so perfect, but a little structure and portability go a long way.

Maybe I just want to reinvent Minix (aka "mini-UNIX"). Or even FreeBSD with Ports. Or Gentoo for DOS.

I'm also thinking of bootstrapping like what is done with Guix.

> GNU Mes is a Scheme interpreter and C compiler for bootstrapping
> the GNU System. Since version 0.22 it has again helped to halve
> the size of opaque, uninspectable binary seeds that are currently
> being used in the Further Reduced Binary Seed bootstrap of GNU Guix.
> The final goal is to help create a full-source bootstrap as part of
> the bootstrappable builds effort for UNIX-like operating systems.

> > Can you give me a theoretical use case where someone would be using a
> 1.44
> > MB floppy?
>
> 10 MB hard disk image? 20? 50? 2 GB? When is it enough to do "something"
> useful?

Useful historically or useful today?

Either way, I could do something useful today with a
1.44 MB floppy. I could have written this message,
and then taken it to a different machine to post
on this board.

And something recently cropped up (since my previous
message), that gave me a new interest.

Starting from a blank floppy disk, but with a genuine
IBM PC with ROM BASIC, I could develop an OS from
scratch (by writing a disk editor in BASIC).

And on a modern machine I could do the same with
Tianocore potentially. ie flash a disk editor
and then start using it.

There is a practical use - I don't trust courts.
I am used to them completely making stuff up.
The High Court of Australia decided that there
was an "implied" right to freedom of speech in
the Australian constitution (I've read it - that's
bullshit), to strike down legislation they
personally didn't like. Rather than doing the hard
work required to actually get the constituion
changed to what they personally want.

A similar thing happened in the 2000 US election.

And a similar thing happens with Roe vs Wade -
the only reason that is even up for discussion
again is because a person died while the "other
side" was in power, instead of carefully resigning
while "their side" was in power, to provide
continuity, when they got too old.

So I developed (not single-handedly) PDOS/386,
a rival OS to Windows, using Windows.

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.

So I'm looking to develop an OS without an OS.

It is unclear whether they will say that I also
can't use the IBM PC ROM BIOS because one of my
OSes (z/PDOS) will be/is a competitor to IBM z/OS.

Tianocore may be considered an OS because it can
load a program, so I might instead need to
replace Tianocore with a mere disk editor.

After building a bootx64.efi using a disk editor I
could then take it to another machine to boot.

I can't possibly know what every judge in the world
will say (perhaps they will say the fact that I used
Windows ever in my life means that I can't ever
create an OS of any sort ever), but I at least want
to have the maximum possible distance between me
and judges.

But first - I know that a FAT12 MBR disk image (with
a bootx64.efi) on a USB stick will boot fine on all
my modern UEFI computers. I haven't tried a FAT12
floppy image.

So the first constraint - can it be a FAT12 1.44
MB floppy image on USB stick instead of a real
physical floppy?

If I start zapping a bootx64.efi into existence,
it will take a long time before I exceed the limits
of a 1.44 MB floppy.

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

Note that the "final" design of PDOS-generic was only
done a few weeks ago or something, and only exists as
proof of concept - it hasn't been fleshed out.

So I don't have a problem with rewriting it, and I
am semi-willing to write in machine code.

The thing is - Linux was written with existing tools
available (GNU toolchain). So it may be legitimate
to have my tools (built on Windows) sitting on a
floppy/hard disk, with no OS to boot them.

And if that is legitimate, I could have a single app
that does editing, compiling and linking, and name
it bootx64.efi, and it's technically not an OS, but
it would allow me to develop an OS in C from day 1,
instead of machine code. And developing tools in
machine code too, at least potentially. It depends
what is "allowed" by random judges worldwide.

> > Would this be on a real computer after a nuclear holocaust and
> civilization
> > is being rebuilt? Or perhaps if you lock someone in a basement with that
> > real or emulated hardware and told them that was the only thing available
> -
> > it was either that or watch ants?
>
> I was thinking more like: "Let's tell news://comp.lang.misc or
> news://comp.lang.asm.x86 and see what they come up with (in a year)." You
> know, give them a limited environment to develop something useful (that
> doesn't require ten bazillion gigs).

There are probably not many people interested in doing
challenges, and it is probably best to ask them "anyone
here interested in a challenge - if so, let's thrash
out the details".

Aren't those strange places for a challenge? I have
heard of people entering coding challenges, but they
don't get them from those newsgroups.

> Maybe I just want to reinvent Minix (aka "mini-UNIX").

Why not mini-DOS, given that you're here?

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.

I'm not a lawyer, but people are VERY litigious.

* https://en.wikipedia.org/wiki/IBM_PC_DOS#History
* https://en.wikipedia.org/wiki/CP/M-86#History
* https://en.wikipedia.org/wiki/DR-DOS#After_Novell
* https://www.itprotoday.com/compute-engines/windows-nt-and-vms-rest-story
* https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc._v._Berkeley_Software_Design,_Inc.
* https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes

Do your best to avoid any obvious problems, but don't worry beyond that.

> I can't possibly know what every judge in the world
> will say

It's impossible to please everyone. Some people don't even want to play fair.

> (perhaps they will say the fact that I used
> Windows ever in my life means that I can't ever
> create an OS of any sort ever)

That would be a stretch too far.

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

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

Good idea.

> I could have a single app
> that does editing, compiling and linking, and name
> it bootx64.efi, and it's technically not an OS

Sounds like Turbo Pascal.

> but it would allow me to develop an OS in C from day 1,
> instead of machine code. And developing tools in
> machine code too, at least potentially. It depends
> what is "allowed" by random judges worldwide.

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.

* https://en.wikipedia.org/wiki/Open_Firmware

> There are probably not many people interested in doing
> challenges, and it is probably best to ask them "anyone
> here interested in a challenge - if so, let's thrash
> out the details".
>
> Aren't those strange places for a challenge? I have
> heard of people entering coding challenges, but they
> don't get them from those newsgroups.

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.

> > 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? 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 I believe the future is x64 or even ARM64. It's probably going to be something else entirely.

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

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

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

> > > 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 haven't booted it, only wanted to show an example of Forth as an OS. There are certainly others, e.g. Chuck Moore's colorForth. (In the old days, Forth used raw blocks as files and had a very simple built-in text editor.)

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

I think most people consider 32-bit dead. Windows 11 doesn't support 32-bit anymore (as host system, only in userland).

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

Intel killed CSM for whatever reasons. I vaguely suspect it had to do with power management, but it's probably also due to costs or disinterest.

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

I never learned Forth, but I was always fascinated by it. I'm mostly sympathetic to ISO C but probably prefer Pascal (or derivatives).

* https://en.wikipedia.org/wiki/PForth (public domain, written in C)

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

The BIOS and DOS (which some people call a glorified boot loader) are closely connected in history. UEFI runs PE/EXE atop FAT with GOP (?) for graphics. In other words, the old days of doing diagnostics in DOS are gone because they rewrote it (with networking, Unicode [UTF-16], GUI, new apps, etc). My old 2010 Dell laptop had a diagnostics partition running Dell Real Mode Kernel (DRMK), aka a modified DR-DOS. (Infuriating that it wasn't available for users, but that was probably for "security". In fairness, there's a lot of ransomware these days, ugh.)

Seeing things like POSIX-UEFI makes me think it's yet another mini OS. (Somebody built a UEFI app of Python 2.7, but I can't find it. Probably because 2.x is dead/obsolete.)

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

Just for comparison, look at this:

* Slackware 11 (PACKAGES.TXT; Fri Feb 23 04:51:07 UTC 2007)
* Slackware 15 (PACKAGES.TXT; Wed Feb 2 08:23:14 UTC 2022)

> (2007)
> PACKAGE NAME: gcc-3.4.6-i486-1.tgz
> PACKAGE LOCATION: ./slackware/d
> PACKAGE SIZE (compressed): 3962 K
> PACKAGE SIZE (uncompressed): 9170 K
> PACKAGE DESCRIPTION:
> gcc: gcc (Base GCC package with C support)

> (2022)
> PACKAGE NAME: gcc-11.2.0-i586-2.txz
> PACKAGE LOCATION: ./slackware/d
> PACKAGE SIZE (compressed): 21388 K
> PACKAGE SIZE (uncompressed): 133720 K
> PACKAGE DESCRIPTION:
> gcc: gcc (Base GCC package with C support)

I know some people will make all kinds of excuses for things like this. And I get it, things change, development isn't cheap, time is always short, and things improve at a cost.

BUT ... do we really need 14x the bloat? Do we do 14x the tasks? (Don't say yes, it's not true. People choose to change requirements, yes, but that's not because life demands 14x more work than it used to. Although if you take improved compression into account, it's only 5x worse.)

I'm not saying nobody has tried to fix, improve, or avoid such problems (Busybox?). I know it's not easy. I know there are alternatives (TCC or PCC or SmallerC or OpenWatcom).

(quoting colorForth's Rationale):
> Megabytes of software may be required for historical compatibility, but
> sometimes we need a fresh start. ColorForth provides the necessary capability
> with kilobytes of code. At boot, it copies disk into RAM. Then compiles the
> macros that emulate the stack machine that Forth expects. As applications are
> requested, they are compiled.
>
> A Forth application can take 1% the code employed by the same application
> written in C.

What I'm resisting is the idea that everything must be "-O2 -finline-functions -falign-functions -funroll-loops" (not specific to Slackware, just making a point). They say premature optimization is the root of all evil. I don't think most .C files need to be heavily optimized. It's a very simplistic and flawed idea that "everything" must be optimized at "-O3" or that all code paths are widely used. And 20% smaller (but slower) for something that only takes 5 seconds isn't worth increasing anyways. People assume it's faster (without proof), but it's not. So 5% increase in speed for 20% increased size isn't worth it for short runs.

But most people aren't engineers writing their own OSes and compilers, so compatibility is important. I'm not saying throw everything away. BUT I'm sure it could be much smaller (and use less RAM) without being terminally slow. In other words, there's no reason to totally ditch C just to use more efficient code generation.

In some ways, the answer is scripting languages (e.g. AWK) that (usually) don't generate (byte)code. One interpreter with ten scripts is probably smaller than ten compiled binaries. But that's not always feasible because of third-party libraries.

> But most people aren't engineers writing their own OSes and compilers, so
> compatibility is important. I'm not saying throw everything away. BUT I'm
> sure it could be much smaller (and use less RAM) without being terminally
> slow. In other words, there's no reason to totally ditch C just to use more
> efficient code generation.
>
> In some ways, the answer is scripting languages (e.g. AWK) that (usually)
> don't generate (byte)code. One interpreter with ten scripts is probably
> smaller than ten compiled binaries. But that's not always feasible because
> of third-party libraries.

I agree with what you say about bloat, but I'm a bit confused about this proposal.

AWK is a different language. If you prefer that language fine, but you have now compared interpretation to compilation.

There are C interpreters. And the Forth thing you quoted said it compiled just in time too I think.

So - what's wrong with either a C interpreter or something that compiles your C program before running it?

Also what's wrong with putting the C library in either the OS or in a DLL like msvcrt.dll? That will produce a small executable too.

If you don't like even a few k for a hello world because of the executable overhead, then even that can be changed with a simpler executable format.

Here is a hello world that runs under PDOS-generic:

C:\devel\pdos\generic>hexdump pcomm.exe
000000 07016400 50000000 00000000 10000000 ..d.P...........
000010 00000000 00000000 20000000 00000000 ........ .......
000020 5589E583 EC148B45 088B5014 C7023000 U......E..P...0.
000030 0000A350 0000006A 00FF10C9 C3909090 ...P...j........
000040 68656C6C 6F2C2077 6F726C64 0A0089F6 hello, world....
000050 5589E583 EC0883E4 F083EC0C 68200000 U...........h ..
000060 00A15000 0000FF50 1031C0C9 C3909090 ..P....P.1......
000070 0E000000 04000004 13000000 08000004 ................
000080 3D000000 04000004 42000000 08000004 =.......B.......

144 bytes.

BFN. Paul.

> I agree with what you say about bloat, but I'm a bit confused about this
> proposal.

It's not a proposal, just me thinking aloud about it. I'm just saying that some things are less than ideal. There's a reason I want to keep it small.

> AWK is a different language. If you prefer that language fine, but you have
> now compared interpretation to compilation.

I did not mean to imply that AWK (usually written in C) is overall better than C. (There's also REXX, TCL, and others.)

> There are C interpreters. And the Forth thing you quoted said it compiled
> just in time too I think.

I already mentioned PicoC (which I compiled with DJGPP in 2012), which I have sometimes used. It's imperfect but still better than nothing. (Detlef Reimers built a DJGPP version of EiC, which is more compatible with C89.)

> So - what's wrong with either a C interpreter or something that compiles
> your C program before running it?

Nothing's wrong with it. I'm just saying modern GCC isn't quite simple enough for what I want. (Older versions were smaller, e.g. 2.95.3, which I often use.)

TinyC has the -run option. The Win32 version relies on MSVCRT (same as MinGW).

> Also what's wrong with putting the C library in either the OS or in a DLL
> like msvcrt.dll? That will produce a small executable too.

BC-Fortran77 (for DOS, circa 1990) used a TSR for its runtime (needed by both the compiler and .EXEs it produced).

> If you don't like even a few k for a hello world because of the executable
> overhead, then even that can be changed with a simpler executable format.

I'm just saying that a lot of compiled C programs are inefficient for various reasons. (And it's not only C, but C is more popular.)

You know Microsoft got their start with their BASIC. They were well-known for their compilers (and MS-DOS, which was mainly for them to keep selling their compilers to IBM). In some ways I'm comparing languages, but overall it's more just an idea for a good base collection of programming tools, better than the generic "just use GCC" nonsense.

I don't think including DEBUG is enough. I don't think including SubC is enough. I don't think including P5 Pascal is enough. We need good tools, and just one or two won't cut it. (But 130 MB is probably too much.) Look how much cool stuff was done back in the day in (limited) QBASIC. Why can no one do that anymore? Is Python the new BASIC? What happened to Perl? Why are they better than AWK? Turbo C or Turbo Pascal were insanely popular. Why can nothing good be written with them anymore?

Look at Menuet64. Look how much they crammed on their floppy. Look at the QEMU Advent Calendar(s). Look how many cool things work.

> I don't think including DEBUG is enough. I don't think including SubC is
> enough. I don't think including P5 Pascal is enough. We need good tools,
> and just one or two won't cut it. (But 130 MB is probably too much.) Look
> how much cool stuff was done back in the day in (limited) QBASIC. Why can
> no one do that anymore? Is Python the new BASIC? What happened to Perl? Why
> are they better than AWK? Turbo C or Turbo Pascal were insanely popular.
> Why can nothing good be written with them anymore?

I agree with that sentiment.

But you stipulated that you want it used.

So you either need to find someone who wants to do a "challenge" for no purpose, or find someone that has a minimal environment (size of floppy) for some reason.

I fit the latter category on two fronts.

One is the "start from debug only" or possibly from switches (or on mainframes, a card reader with hand-punched cards) and then start entering machine code to build up an OS. Either using hex printouts, or not even that.

The other is starting with just public domain material. With that restriction there's not a lot available to put on the floppy.

BTW, do you care if the processor is not x86?

Because I now have an interest in this:

https://cod5.com/citizen-computer.html

Putting pdos-generic on the only PD processor (which implements MIPS).

I'm still trying to come to grips with the concept.

I am familiar with the PC BIOS, and I am familiar with mainframes which have intelligent devices such that there is no BIOS.

I don't know what this is.

PDOS-generic assumes the presence of a pseudo-BIOS. I don't know what that would look like (specifically lines of code) on that proposed machine.

> I never learned Forth, but I was always fascinated by it. I'm mostly
> sympathetic to ISO C but probably prefer Pascal (or derivatives).
>
> * https://en.wikipedia.org/wiki/PForth (public domain, written in C)

Sorry, a little bit "self-advertising". ITSY Forth by John Metcalf, ported to most 86/386 platforms:

Original article(s):
http://www.retroprogramming.com/2012/03/itsy-forth-1k-tiny-compiler.html
Collection of ports (i am made port for win32 and dpmi):
https://github.com/DosWorld/itsy32

(may be somebody care?)

Also, PDOS/386 can run .RDF, so it should work in PDOS/386.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> There are C interpreters. And the Forth thing you quoted said it compiled
> just in time too I think.

> So - what's wrong with either a C interpreter or something that compiles
> your C program before running it?

Does it actually reach the goal? IOW is the sourcecode (+ whatever you do with the libs) smaller than the compiled binary? My gut says that C is not expressive enough to make it a space efficient scripting language

> Also what's wrong with putting the C library in either the OS or in a DLL
> like msvcrt.dll? That will produce a small executable too.

Yes, but a single deployment (exe+dll) will be larger. Only multiple compiled files will actually save something. This due to unused code (by this program) in the DLL, and the DLL glue code itself.

Same goes for memory. If the DLL can't be shared in memory (and page out unused sections), the memory footprint of running multiple binaries will be larger in the memory.

> If you don't like even a few k for a hello world because of the executable
> overhead, then even that can be changed with a simpler executable format.

Small hello world is pointless in a dos forum, as there is always the hard to beat "echo" in the command interpreter. @echo<space> has 6 bytes overhead.

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

Like I said, I never really learned Forth, but I was fascinated by it for many years. (I didn't even have a PC until 1994, and I was way too young to understand much.)

I found a few copies of F83 Forth v2 for DOS, which was public domain (circa 1984). This was the quasi-standard at the time (after figFORTH or FORTH-79) until ANS Forth '94. (T3XForth is standalone or hosted atop DOS, and it bootstraps with its S86 assembler written in T3X. BTW, DXForth is public domain but uses TASM to bootstrap. Apparently FreeDOS doesn't have the latest version of DX 4.53.)

Since "Forth" usually meant its own "OS", it often used raw blocks to store data (as if in files). But F83 is an executable .COM hosted atop DOS but uses "block files" for sources. Each "screen" is 16 lines of 64 chars totaling 1024 bytes (no CR+LF). It also had a rudimentary line editor. (There's an old 1981 book called Starting Forth online for free nowadays that probably shows better how it was used back then.)

So that's what many people used back in 1984 (and prior). When you think bootstrapping compilers, you usually think Forth.

Oh, what I really found fascinating was that they apparently used their own Forth Huffman compression routines to compress the files back then. Then I found another distribution of F83 v2 where someone was using the at-the-time-ubiquitous SQ (Squeeze) compression which was both smaller and faster (but no sources). Before ARC and PKZIP it was basically LBR+SQ (see Simtel /starter/).

There are also Forths that have their own built-in assembler, and usually they can also meta-compile (headless via turnkey), and rarely there are even compilers to native code (instead of "threaded", which I guess is roughly bytecode).

> BTW, do you care if the processor is not x86?
>
> Because I now have an interest in this:
>
> https://cod5.com/citizen-computer.html
>
> Putting pdos-generic on the only PD processor (which implements MIPS).
>
> I'm still trying to come to grips with the concept.
>
> I am familiar with the PC BIOS, and I am familiar with mainframes which
> have intelligent devices such that there is no BIOS.
>
> I don't know what this is.
>
> PDOS-generic assumes the presence of a pseudo-BIOS. I don't know what that
> would look like (specifically lines of code) on that proposed machine.

The Forth people are best at bootstrapping from scratch, see this:

http://mynor.org/my4th.htm

> I was fascinated by it for many years

+1. Not so much modern languages, which allow add own keywords or intrude into code-generation (i am talk about "immediate" forth-word).

> Since "Forth" usually meant its own "OS"

IMHO, it was good when computer have no any OS (or for learning reasons). But in all other cases it will be mistake the same as Oberon-OS.

> Each "screen" is 16 lines of 64 chars totaling 1024 bytes (no CR+LF).
> It also had a rudimentary line editor.

Nobody care about this "screens", now.

> When you think bootstrapping compilers, you usually think Forth.

1. Each fort'er must have OWN forth
1.1. ... with OOP extensions.
2. Forth looks like good point as cross-platform "assembler" (or "intermidiat representation"): your HLL compiler -> forth -> native code (or your vm bytecode). But... does not allow use register-allocation (and other) features, so i am reject this idea, with time.

Forth suggest have two stacks, it is not 1:1 to modern hardware and need do more tricks then need.

Also, i hear opinion some fort'ers about jvm internals (they investigate jvm assembler): "i find nothing new here".

> The Forth people are best at bootstrapping from scratch, see this:

Forth in UEFI

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> https://cod5.com/citizen-computer.html

1. "Total price of a Public Domain computer: USD $314"

Sounds... mad khm... too expensive . I'll play in a sort of this game, but with $7 development board with RISC-V cpu. (not exactly the same challenge, - try to create small cross-toolchain, not full OS)

2. Why you don't look to RISC-V based hardware? They can have a big future, in China.

Tablet or motherboard.

3. "We don't need a Management Engine."

(sad joke) Minix is more wide used OS on desktop then Windows and Linux.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> 2. Why you don't look to RISC-V based hardware? They can have a big future,
> in China.

The only reason (that I am aware of) we are trying to move away from x86/ARM to MIPS is because Plasma is the only public domain CPU we know of. So RISC-V doesn't buy anything we are after.

> The Forth people are best at bootstrapping from scratch

I haven't yet investigated deep enough to find out if
this is some sort of late April Fool's joke, but I'll
provide the link regardless:

https://github.com/xorvoid/sectorc

If it's real, I envisage stepping stones all the way
from this to the x64 in C code.

I will switch it to masm syntax though.

I can't remember if I mentioned here that as86 is now
good enough to build all of the code in PDOS/386, and
it has all been switched to masm format and coff, and
thus can be built with Watcom and Visual Studio too.

BFN. Paul.

> https://github.com/xorvoid/sectorc
>
> If it's real, I envisage stepping stones all the way
> from this to the x64 in C code.

Nils, the author of SubC, says:

It is real, but -- unsurprisingly -- it implements a *very* limited
subset of C:

- only int variables
- only void functions of no arguments
- no local variables
- no else in if
- only one level of indirection through int: *(int*)x
- no unary operators except for &
- no operator precedence
- no preprocessor

Bootstrapping something more useful from that will be very
challenging.


But I don't think this is the right thing to put on the
boot sector, and I don't think input should come from
the serial port (which more-or-less requires another
computer to exist).

There were mainframe computers (S360/67) that allowed
you to toggle switches to zap memory, and there were
micros that did it too, like this one:

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

So it had switches and a floppy disk.

Now it is difficult to get the appropriate hardware,
so I think I would like a boot sector that doesn't
do much more than allow you to write a hex value to
memory and then execute it.

And the first thing I would do is have a routine to
zap bytes on sector 0 of the hard disk, so that I
never have to "flick switches" again to get that
boot sector. And after a bit more disk zapping I
could then start entering the hex for the 1-sector
C compiler.

I guess the goal would be that the only data ever
to go ONTO the PC would be that one single flick
switching boot sector, on a floppy image on a
CDROM in El Torito format, but if the code has
been written to do so, you can make a backup
onto another hard disk or whatever for safekeeping.

Try to keep yourself honest.

One more possibility would be to leave the switch
flicking for someone else to do, rewrite Sector C
in Sector C, and then carry that bootstrapping
forward from there.

BFN. Paul.

> https://github.com/xorvoid/sectorc

For me it is looks like PL/0, 1:1, but in C and the same useless language.

But... nice try!

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > https://github.com/xorvoid/sectorc
>
> For me it is looks like PL/0, 1:1, but in C and the same useless
> language.
>
> But... nice try!

I'm not sure it is useless.

And it inspired me to write a C90 version
and port it to the mainframe

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/util/multisc.c


and write a mainframe emulator.

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/util/mfemul.c


and make the mainframe support ".com" files:

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

and made me realize that the 80386 should be able
to support .com files too.

And that I should be able to write an 80386 version
that can run in LM64 mode (manipulate the stack
instead of using push/pop and call) as proof of
concept, and huge memory model as proof of concept
too.

And provide a purely public domain mainframe
distribution as a "University Challenge" (see
pdos.org).

What is unclear to me at the moment is the limits
of this subset of C. Basically is it Turing complete
or whatever the correct terminology is?

Basically Sector C has changed my life.

BFN. Paul.

> I'm not sure it is useless.

Yes, you can write some tools, but... too hard.
I saw family of "integer languages" and they have no big success.
To become more successful need char (byte) and pointer (char *, int *) datatype, IMHO. (like in a Small C)

1. Tiny Basic
2. First
3. PL/0, Oberon-0
4. B (funny, but B is more advanced then SectorC)

+SectorC

We can count Pascal-S (char/boolean/integer has same width), but, imho, this is next level language (because have records and arrays).

Also, my expiriment - selfhosted PL/2 - something like turbo basic but with integers. I dug this idea as useless.

PS: Try this (imho this is right way - "like Small C, but smaller"). Just need add static/global arrays and then will be excellent.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > I'm not sure it is useless.
>
> Yes, you can write some tools, but... too hard.
> I saw family of "integer languages" and they have no big success.
> To become more successful need char (byte) and pointer (char *, int *)
> datatype, IMHO. (like in a Small C)

Pointer? You mean "address"?

No, there is rarely a consensus on what features are minimally useful: strings, modules, exceptions, objects, generics.

> 1. Tiny Basic

What about p2c's Chipmunk BASIC?

EDIT:
> 2. Watcom Team - "does not auto-reject discussion" if somebody came with new frontend.

I'm able to (also) build p2c with OpenWatcom (atop DOS host). Better than nothing.

> 2.
> First

Seen it before. Forth had a lot of good ideas.

> 3. PL/0, Oberon-0

Interesting, I'll have to look closer again, but I recall Oberon/0 being fairly incomplete (but better than PL/0).

> We can count Pascal-S (char/boolean/integer has same width), but, imho,
> this is next level language (because have records and arrays).

P4 Pascal is good, P5 is better, but it still lacks things (e.g. good string support, modules). Even the so-called "SmallAda" (Pascal subset) is probably too minimal.

These days you could call AWK a pretty small language that does its job fairly well. Or REXX.

> The only reason (that I am aware of) we are trying to move away from
> x86/ARM to MIPS is because Plasma is the only public domain CPU we know of.
> So RISC-V doesn't buy anything we are after.

Wikipedia calls PC532 "public domain", but it's old (using National Semiconductor's 32k) and NetBSD stopped supporting it in 2008 when GCC 4 also dropped support. There were also apparently ports of Minix 1.3 (1990) and Mach 3.0 (1992). N.B. Wirth's Ceres Oberon machines used a similar cpu.