Yeah, I know. It's daft. You got FreeDOS, RxDOS, PDOS, PC-MOS, and
there's probably other clones of MS-DOS out there. And I haven't even
started doing anything *kernel*-wise.

But over the past not quite year, I've been pushing myself to try to
rewrite all the DOS utilities I can, keeping in mind that I'm not very
well-versed in low-level coding, and to make them as small as possible
without removing any key documented functionality as far as MS-DOS 5 or 6.

I *am* having difficulties because I know I'm a terrible programmer.
Sometimes I'll spend days wracking my brain over something, and never
quite figure it out.

Here's the premise...

I've noticed that a lot of the time, when it comes to running DOS on a
really old computer (such as my PS/2 model 30/286) the question ends up
being, 3.3 and more RAM, or 6.22 and more functionality? And I didn't
want that to have to be a question. Many of the commands I have
implemented - either in NASM or Watcom C - are extremely lightweight, and
would easily provide MS-DOS 6.2x function on 3.3.

If I could, I would expand the project myself to include most if not all
of the MS-DOS 6.21 functionality, designed to be as compact as possible.

So far I've implemented ATTRIB, CHOICE, DELTREE, FIND, LABEL, MORE and
SORT. (MORE does utilize Microsoft's officially released source code.)
The bulk of the code is released under the UIUC license, MORE as of
necessity being the exception. I've been working on other commands, but
certain ones are eluding me.

My goals are different from FreeDOS, in that I'm looking for size rather
than functionality, and have a more 8088/80286-specific focus. Because I
prefer to limit licenses to "university" type licenses like BSD, MIT,
UIUC, ISC/OpenBSD or similar, the FreeDOS code is off-limits to me anyway.

I plan to make a more public release if and when I have more to release.

Currently, all C will roll with OpenWatcom 1.9 and all ASM will roll with
NASM 2.15.5. I use this combination because I can easily cross-compile
from Linux. (OpenWatcom is a less than ideal solution, but it's probably
the best choice I've got right now.)

https://6.buric.co/doslite/

(These are just source dumps, unversioned but stamped YYMMDDHH in local
time.)

Before calling it DOSLITE, I had referred to it as Project Theseus,
because I intend it to replace MS-DOS one "plank" at a time until it has
completely replaced it.

If anyone has something that may be of use, I am willing to use it
provided it more or less implements an existing MS-DOS command, can serve
as a drop-in replacement for it, and is compatible with my licensing and
compiler requirements.

I understand this is about tilting at windmills, given that even 20 years
ago I was a failure at attempting this - and I wanted to make sure I had
at least something to show for my idea, and not just philosophical "sperg"
rambling.

-uso.

On Sat, 9 Jul 2022 16:29:57 -0400
Steve Nickolas <usotsuki@buric.co> wrote:

> Yeah, I know. It's daft. You got FreeDOS, RxDOS, PDOS, PC-MOS, and
> there's probably other clones of MS-DOS out there. And I haven't even
> started doing anything *kernel*-wise.
>
> But over the past not quite year, I've been pushing myself to try to
> rewrite all the DOS utilities I can, keeping in mind that I'm not very
> well-versed in low-level coding, and to make them as small as possible
> without removing any key documented functionality as far as MS-DOS 5 or 6.
>
> I *am* having difficulties because I know I'm a terrible programmer.
> Sometimes I'll spend days wracking my brain over something, and never
> quite figure it out.
[]

Very bold. Have fun!

I'm keen on small 8086 asm, in general, but I've not attempted to
replace any DOS commands. I'd be happy to just see if I could help
FreeDOS to slim down some of their commands, but I see you want to use a
different licence.

--
Bah, and indeed Humbug.

On Sat, 9 Jul 2022, Kerr-Mudd, John wrote:

> Very bold. Have fun!

I am, even though it gets frustrating at times. :D

> I'm keen on small 8086 asm, in general, but I've not attempted to
> replace any DOS commands. I'd be happy to just see if I could help
> FreeDOS to slim down some of their commands, but I see you want to use a
> different licence.

Yeah, I favor BSD-type instead of GPL. (Got turned off to GPL after an
interaction with a GNU fanboy on the FreeDOS mailing list.)

FreeDOS does feel a bit bloaty. Not really a big problem for 486 and
later, but it's not a very good fit for my own 286/10.

I've actually been trying to translate some of the MS-DOS 2.11 code to
NASM, without success, because EDLIN is probably fine as it is or with
minor tweaks, and DEBUG just needs the addition of EMS support to be on
par with the final version. (Or, I could actually try tweaking the
FreeDOS version; ironically I think it's got exactly the same license as
the MS-DOS 2.11 version.)

I'm also considering using Robert Nordier's format.com, but I think it
would be better to translate it to ASM to get the size down. (Also I'm
not sure how well the C code would work in Watcom, since it was explicitly
written for Borland.)

I wish Ziff-Davis would relicense their old PC Magazine stuff - I'd
absolutely use ANSI.COM and the core of their defragger.

-uso.

On 2022-07-09, Steve Nickolas <usotsuki@buric.co> wrote:
> Yeah, I know. It's daft.

So long as you are having fun, keep it up! :-)

I like seeing cross-polination between these kinds of efforts.

That is an interesting observation about FreeDOS being bloaty. I'll
have to tinker with it in PCem some day and see how it does on
emulated 16-bit hardware.

-Ben

On Sun, 10 Jul 2022, Ben Collver wrote:

> On 2022-07-09, Steve Nickolas <usotsuki@buric.co> wrote:
>> Yeah, I know. It's daft.
>
> So long as you are having fun, keep it up! :-)
>
> I like seeing cross-polination between these kinds of efforts.
>
> That is an interesting observation about FreeDOS being bloaty. I'll
> have to tinker with it in PCem some day and see how it does on
> emulated 16-bit hardware.
>
> -Ben
>

One of my tests was to boot the kernel, with no drivers, to a normal
command.com, with no TSRs, and run MEM.

It's certainly a lot heavier than DOS 5, MS-DOS 6.22 or PC DOS 7.
Probably because the bulk of the kernel was written in C. (I'm not
exactly well-versed in x86 ASM and some of the stuff in DOSLITE is my
literal first steps. CHOICE in particular reads like 6502 code.)

I mean, I can't exactly fault FreeDOS for being what it is; the kernel
*is* called "DOS-C" for a reason.

-uso.

Steve Nickolas <usotsuki@buric.co> wrote:
> Yeah, I know. It's daft. You got FreeDOS, RxDOS, PDOS, PC-MOS, and
> there's probably other clones of MS-DOS out there. And I haven't even
> started doing anything *kernel*-wise.
>
> But over the past not quite year, I've been pushing myself to try to
> rewrite all the DOS utilities I can, keeping in mind that I'm not very
> well-versed in low-level coding, and to make them as small as possible
> without removing any key documented functionality as far as MS-DOS 5 or 6.
>

Best way to learn, and can be a lot ot fun!
Enjoy

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

2022-07-09 at 16:29 -0400, Steve Nickolas wrote:
> My goals are different from FreeDOS, in that I'm looking for size
> rather than functionality, and have a more 8088/80286-specific focus.

That's pretty much my motivation as well. http://svardos.org

Mateusz

Welp.

I was going to wait until I had some other important commands finished,
before uploading it to GitHub, because I didn't want it to be Yet Another
Abandoned Project®™© on the site. But since in the course of bashing away
I had implemented a significant chunk of COMMAND.COM functionality, I
figured that was evidence enough that I was serious. Certainly I've
implemented a few more commands although some of them are buggy or
incomplete.

https://github.com/buricco/doslite

I hope that the various readme files scattered around the tree will
explain my intentions better than I've done here, because I'm terrible
(can't blame it ALL on the autism). The main readme is almost a
manifesto.

(The phrase "use, share and improve in any combination" specifically
refers to the PINE/MANA fiasco, which is the reason I picked the license I
did instead of the regular BSD license.)

A few things I didn't mention elsewhere:

1. The C code is generally more sparsely commented than the ASM code.

For the most part, it's easy to make C code relatively self-explanatory.
With ASM, you really have to get into the mindset of the computer, and not
commenting stuff can easily lead you to lose your train of thought - at
least this is my personal experience. So my ASM code usually has heavy
comments to show what I intend, at least, the code to be doing.

2. The low-level stuff is implemented with inline assembly; stdio.h is
avoided like the plague, and neither int86() nor int86x() is used.

This is all a matter of size optimization. int86() and int86x() introduce
a lot of unnecessary overhead. The method I adopt here, while awkward,
works in both Borland C++ 3.1 (my compiler of choice) and OpenWatcom C/C++
1.9 (the compiler I actually *use* for DOSLITE, so that I don't have to
open an emulator just to build my code).

3. I tried to make a clear delineation between what I think is ready for
primetime and what is not. That is why there is an "exper" folder.

If a program becomes good enough, I will promote it (if you trace the
commits, you can see I did this with COMP). But if it's in "exper", that
means it's not done.

4. I am neither bound by existing code, nor by my own.

Originally, FIND was based on MS-DOS 2.11 source code. Later, after being
unable to patch a feature into the original code, I simply rewrote it from
the ground up and integrated the feature from the beginning.

I started writing DELTREE in ASM. It became a buggy nightmare and I
ported it to C to make it easier to get working. (The same is true of
COMP, though the unfinished ASM version never made it into revision
control.)

-uso.