I just use a stand-alone version of MS-DOS from 98SE for FAT32 support . Edited MS-DOS.SYS to remove the windows-loading bits and it behaves like a "normal" DOS install.
I had no idea PC-DOS 7.1 can be loaded into UMBs, 98SE-DOS cannot do that in any of the machines I have (from 386 to p1) but if you have UMBs you end up with ~620kb of free conventional ram so it's not an issue...
It goes without saying that I have a \UTILS\ directory with all sorts of goodies inside - but no stock-dos-stuff borrowed from other versions, there is no need.
I do use 98SE's EDIT.COM with older DOS installs like 6.22 because it's just great and it will work with anything V20+

IIRC there are some more PC-DOS versions? like 7.3 and 2000?

PC-DOS 2000 is actually older than 7.1 - it's 7.0 Rev 1, patched for Y2K support. 7.1 was never officially released, but IBM still makes it available as part of a scripting toolkit. The DOSDATA=UMB bit works in PC-DOS 7.0 and 2000, as well.

jade_angel wrote:

1) QBASIC. BASICA was cool, but QBASIC is better.

QuickBASIC would be my preference, primarily due to the ability to build executables. QBasic is like a 'lite' stripped version of QuickBASIC.

Also, call me strange, but my 'dreamDOS' would include vim. might even skip EDIT.COM altogether. o.0

Hmm, I didn't really think of those because they're generally separate, but at some point, when you're rolling a "distro", that distinction becomes kinda academic. So, with that caveat, yeah, QuickBASIC would be better - the resulting compiled code is way faster anyway. And I second your suggestion of vim, but vim is a little heavy as editors go on very old machines, so I'd still want EDIT around for the 286 and 386SX-class boxen.

I'm not actually sure how well vim would run on a 486, though. Under NetBSD it seems a little slow to start on a K6-III+/500, though not intolerably so. I suppose if you left out all the extras it'd be pretty zoomy!

I'm not clear as to what exactly you would do with QBASIC. I mean, it's fine for dabbling in programming, but for that purpose I'd rather use Python. But EDIT.COM requires QBASIC.EXE, so you'd need to have it around anyway if you're using EDIT.COM.

There's probably a better alternative to EDIT.COM out there (opening multiple files can be mighty handy), though I don't know what that would be offhand. It's a bit irritating that the default for the Open dialog box is *.TXT instead of *.*, but at least it's trivial to open the binary and change that.

QBASIC has built--in graphics primitives. They're really, err, primitive, but it doesn't require you to learn Allegro or SDL or similar. Also there's a fair number of old homebrew games and demos and similar that are floating around written in QBASIC, and it's cool to be able to monkey with those. Also, it can be handy for quick-and-dirty math.

EDIT is mostly there for quick-and-dirty jobs, though. Any kind of serious editing and I'd rather have something like vim or xemacs, but both of those are a bit heavy.

I mostly use Windows 98 SE and MS-DOS mode these days. I have put together my own FreeDOS based boot floppy, replacing the memory managers and CD drivers, but that was the only "mix and match" activitiy I remember.

And installing MS-DOS 7.1 without Windows, that might count also. But as I mostly work with fast machines these days, Windows 98 SE and MS-DOS mode does everything I need 😀

I once created a frankenWindows by accident (no it wasn't a bolt of lightning 🤣) by using a Dutch ME as a base and then trying out that ME unofficial SP. I ended up with ME which had dialog windows which were half in Dutch and half in English and I actually lolled when it seemed to work just fine 😁

I also use the Win98SE DOS when I need support for larger disks/partitions. The only thing it's missing from it it's a defrag program (for example norton's speedisk isn't suitable for FAT32) so I'm using FreeDOS' version. This is usually my only "external" addition.

spiroyster wrote:

QuickBASIC would be my preference, primarily due to the ability to build executables. QBasic is like a 'lite' stripped version of QuickBASIC.

Agreed. And VisualBasic for DOS isn't bad, either. 😉

Jo22 wrote:

spiroyster wrote:

QuickBASIC would be my preference, primarily due to the ability to build executables. QBasic is like a 'lite' stripped version of QuickBASIC.

Agreed. And VisualBasic for DOS isn't bad, either. 😉

When you can find it! It does give some interesting capabilities, though, and IIRC, you can use it to compile most programs written for QBasic.

Jade Angel, can you make your version of FrankenDOS available?

Also, what's the deal with PC-DOS 7.1 FAT32 support? Does it support LFN?

Anonymous Coward wrote:

Also, what's the deal with PC-DOS 7.1 FAT32 support? Does it support LFN?

I don't believe I've heard of anything that has FAT32 support that does not support LFN at least in some capacity.

Actually, PC-DOS 7.1 doesn't seem to grok LFNs at all. You can use the DOSLFN driver from FreeDOS, though, but it only works with apps that are otherwise LFN-aware (just like under Win95, in fact) - which would be a good reason to import Win95/98's EDIT.COM. The FAT32 support seems to be limited to supporting larger partitions and more efficient cluster sizes. Same story with the various FAT32 drivers on OS/2 (which is downright weird, since it does support LFNs on HPFS or JFS). Incidentally, there seem to be drivers for HPFS and NTFS available for DOS, but I haven't tried either one.

As for packaging up my franken-distro, sure, but it'll take me a bit to spin it into a useful format. (It's all kinda ad-hoc and scattered around for now)

jade_angel wrote:

Actually, PC-DOS 7.1 doesn't seem to grok LFNs at all.

So, for example, if you have a file named "This is a test.txt" and try to copy it in PC-DOS 7.1 (as "thisis~1.txt"), does the copy not retain the long file name?

Hmm. I actually haven't tested that. I'll try that tonight and let you know.

Have you had a chance to test it yet?

FAT32 does not give you long file names by itself (LFNs are supported since Windows 95 or with DOSLFN in the same hacky way as in FAT16).
What FAT32 does it gives you smaller clusters on the same partition size (so less wasted space if you have lots of small files) and partitions larger than 2 GB.

Checked it, yeah, it doesn't have any idea about VFAT at all, LFNs get munged.