IMHO, the real deal breaker is integration, and Microsoft exploited this extremely well to this day to keep market share hostage. When you got to buy Win95 you already got DOS included. The same happened with Internet Explorer vs Netscape or MS-Office vs Lotus. Pragmatism beats technically superior products for most users.

I am on the bizarre group: my DOS is weird and uniquely modified solution: I use DR-DOS 7.05 kernel and MS-DOS 6.22 command interpreter in order to have more conventional memory available on an 8088 cpu. My kinky taste requires me to manually modify these components for them to coexist. And I harvested an ecosystem where I can genuinely get more advantage of this unholy marriage. You wont get many idiots like me doing this sort of things. But still happy doing it.

That would be really interesting to see but if it didn't get released or leaked there's not much chance we will ever see it. I wonder how hard would it be to make the same TSR. They couldn't spend too much time on it.

Just like igully I also run a "FrankenDOS". That's the nicest part that you can mix parts from different DOSes, tools.

What did you change? Only command.com version check? Or something else more?

igully wrote on 2025-12-03, 03:32:

IMHO, the real deal breaker is integration, and Microsoft exploited this extremely well to this day to keep market share hostage. When you got to buy Win95 you already got DOS included. The same happened with Internet Explorer vs Netscape or MS-Office vs Lotus. Pragmatism beats technically superior products for most users.

I am on the bizarre group: my DOS is weird and uniquely modified solution: I use DR-DOS 7.05 kernel and MS-DOS 6.22 command interpreter in order to have more conventional memory available on an 8088 cpu. My kinky taste requires me to manually modify these components for them to coexist. And I harvested an ecosystem where I can genuinely get more advantage of this unholy marriage. You wont get many idiots like me doing this sort of things. But still happy doing it.

AM_PM wrote on 2025-12-03, 02:00:

To remind us: Windows 95 does not officially run on MS-DOS 6 and earlier (or other DOS), and setup isn't possible. Unlike Windows 3.x, 95 only runs on and boots with its combined MS-DOS 7.

You could sort of dual boot MS-DOS 6.22 and Win95, at least with the original retail version (before OSR2.x). The option was called "Boot into previous version of MS-DOS" or something.

I vaguely remember this from back in the day, but there's more detailed info here: Re: DOS 6.22 / Windows 95 dual boot.

Cyberdyne wrote on 2025-12-03, 10:19:

What did you change? Only command.com version check? Or something else more?

You need to bypass both COMMAND.COM and IMBIO.COM version check, which are different. Then it would make sense to fix the rename bug in IBMDOS.COM. Another thing if you are at it, is just to patch name text strings and messages to distinguish this mutant creation from its original material, so that no one gets confused. I did this to get the kernel + shell to only use 52 KB on an 8088 which is even less than DOS 3.31 uses. And in this way I also obtained a 6.22+ API with FAT32 support. Then you need to properly pick a compatible ecosystem for it to work. But that is just another different story, too off-topic to share right here. I acknowledge I am weirdo in that I enjoy this type of nonsense challenges.

igully wrote on 2025-12-03, 12:24:

I acknowledge I am weirdo in that I enjoy this type of nonsense challenges.

It's cool, though! 😎 Reminds me a bit of the good old days I was trying to use XDOS' command interpreter on MS-DOS. I was 7 back then, I think.
Using weird DOSes/weird DOS combos makes things interesting, I think. 🥳

I usually use hacked compressed MS-DOS 7.1 io.sys and then PTS-DOS minicmd command.com in some of boot flopies to really squeeze maximum free space.

Cyberdyne wrote on 2025-12-03, 14:21:

I usually use hacked compressed MS-DOS 7.1 io.sys and then PTS-DOS minicmd command.com in some of boot flopies to really squeeze maximum free space.

Your probably meant compressed MS-DOS 7.1 io.sys and ROM-DOS minicmd.com. I like minicmd.com's size, but not its lack of features that are commonly used, like pipes, redirection, and depending on the build, it may even lack elemental internal commands like MD/MKDIR between others.

PTS-DOS 's command.com on the other hand, is great in that it has extra built-in commands, but has its own issues as it calls propietary PTS kernel calls, which ultimately ends in bugs when using it with other kernels (the CLS and CTTY bug to start with, and depending on version/variant the lack of %errorlevel% and the miss-management of pipe generated files).

eM-!3 wrote on 2025-12-03, 10:09:

That would be really interesting to see but if it didn't get released or leaked there's not much chance we will ever see it. I wonder how hard would it be to make the same TSR. They couldn't spend too much time on it.

My thoughts exactly. Let's not forget its size of 600 bytes, clearly something that made a few modifications to files or calls. I really think this is something untapped in the retro community that is yet to be uncovered, but I'm looking forward to the day someone who knows their stuff is able to implement this and get W95 installing on DR-DOS.

Yep ROM DOS minicmd. I usually use compressed Volkov Commander for file operations. And if you do not use elaborate batch files then missing commands is no problem.

igully wrote on 2025-12-03, 16:14:

Your probably meant compressed MS-DOS 7.1 io.sys and ROM-DOS minicmd.com. I like minicmd.com's size, but not its lack of features that are commonly used, like pipes, redirection, and depending on the build, it may even lack elemental internal commands like MD/MKDIR between others.

^On 386+ systems it would be possible to "outsource" large parts of DOS using Helix' cloaking technology.
It was used for BIOSes and DOS devices drivers back in the 90s.
If a custom DOS was written for it, most parts of DOS could run past the 1MB barrier.
Without limiting all the functionality that power users would miss.

Edit: But since this is about DR-DOS, DPMS is a more realistic alternative.
It was part of Novell DOS 7 and serves a similar purpose.
No need to more and more castr*te DOS, extending it is the way to go! ^^

Edit: There's also 4DOS, of course. It's the better CLI, needs little RAM.

Links fixed.

Cyberdyne wrote on 2025-12-03, 16:53:

Yep ROM DOS minicmd. I usually use compressed Volkov Commander for file operations. And if you do not use elaborate batch files then missing commands is no problem.

igully wrote on 2025-12-03, 16:14:

Your probably meant compressed MS-DOS 7.1 io.sys and ROM-DOS minicmd.com. I like minicmd.com's size, but not its lack of features that are commonly used, like pipes, redirection, and depending on the build, it may even lack elemental internal commands like MD/MKDIR between others.

ROM-DOS minicmd is too barebone, a better alternative could be SvarDOS' SVARCOM.COM.

Here's my small overview about DOS versions and their conventional memory consumption.
Conventional Memory consumption of various DOSes

Novell DOS 7 consumes about 52 KB (Kibibyte), it seems, which is low.
On top of that, MS-DOS 2.11 (slow) merely requires 31 KB (Kibibyte).

But that's without off-loading things into HMA or UMA.

On an XT with the HiCard installed, it might be possible to gain more conventional memory on an XT, even.
But since this is about DR-DOS running Windows 95 this idea can be negleted, probably.

Last but not least, there's this ranking of 23 DOS kernals.. It's worth a look!
Memory ranking - 23 DOS KERNELS

Edit: What comes to mind: Windows 95 supports long file names (LFNs).
So the underlying DOS somehow should support LFNs, too.

MS-DOS 7.x has LFN support, although it's disabled when not run on Windows and requires an utility to enable it on plain DOS.
Still, support is inside. To use another DOS on Windows 95, it should be able to support LFNs, too.

That's also something that differs between Windows 9x and the NT line, btw.:
The NTVDM used on NT line is stuck on MS-DOS 5 level in terms of features, whereas Windows 95/98 were more advanced here.

For example, what comes to mind:
On Windows 9x, running a copy of command.com will make it use the current path being used by the Windows Explorer.

Then, there are external commands that weren't part of DOS 5 yet, but MS-DOS 6.2x/7.
They're thus missing in Windows NT line, of course.

Edit: I'm just thinking out loud here, but what I think would be neat would be building a truely "tiny" DOS. A Tiny DOS, so to say.
Something that fits into same space as, say, CP/M 2.2.

A ROM-compatible DOS that fits into 32 KB or less,
but leaving a bit of spare space for executing a COM file and having a tiny RAM DISK.

So it can be modified to be used in an 8080 homecomputer by replacing the the 8080 or 8085 by a daugthercard that has a NEC V20 (has 8080 emulation mode),
with a ROM that contains a custom build of Tiny DOS.

In principle, something like this existed already.
The Tandy 1000 series and the Atari Portfolio had DOS in ROM, for example.
But they probably used ROM DOS to cheap out on RAM, simply.
If DOS is in ROM, the machine could leave the factory with less RAM being installed.

But again, I'm just thinking out loud here. It simply came to mind.
Please ignore my post and go on, I don't mean to derail this thread.

roytam1 wrote on 2025-12-04, 02:56:

Cyberdyne wrote on 2025-12-03, 16:53:

Yep ROM DOS minicmd. I usually use compressed Volkov Commander for file operations. And if you do not use elaborate batch files then missing commands is no problem.

igully wrote on 2025-12-03, 16:14:

Your probably meant compressed MS-DOS 7.1 io.sys and ROM-DOS minicmd.com. I like minicmd.com's size, but not its lack of features that are commonly used, like pipes, redirection, and depending on the build, it may even lack elemental internal commands like MD/MKDIR between others.

ROM-DOS minicmd is too barebone, a better alternative could be SvarDOS' SVARCOM.COM.

I have to agree that SVARCOM.COM is much more feature complete than minicmd. It is miles away away compared to it, with a relatively small size and very low memory footprint. Still not compatible enough though, lacking CTTY command implementation and having a few bugs here and there. But that hopefully can only improve looking into the future.

Back to the original topic:
It seems that the DR-DOS version that was modified to run Windows 95 was a development in between Novell and Caldera transition. Since Caldera could not entirely recover all Novell developments, the code must be gathering dust on a backup of the developers that worked for the Microsoft trial. The best bet would be to contact them. They are named in DR-DOS Wikipedia's article.

IMHO it would be interesting to see what they did, and for historical purposes, but probably not that much for any practical use. In any case, trial depositions, should contain more technical details about this code (You would be lucky to get the records, and not so happy to have to read through all of them to get some clues).

igully wrote on 2025-12-04, 12:50:

I have to agree that SVARCOM.COM is much more feature complete than minicmd. It is miles away away compared to it, with a relati […]
Show full quote

roytam1 wrote on 2025-12-04, 02:56:

Cyberdyne wrote on 2025-12-03, 16:53:

Yep ROM DOS minicmd. I usually use compressed Volkov Commander for file operations. And if you do not use elaborate batch files then missing commands is no problem.

ROM-DOS minicmd is too barebone, a better alternative could be SvarDOS' SVARCOM.COM.

I have to agree that SVARCOM.COM is much more feature complete than minicmd. It is miles away away compared to it, with a relatively small size and very low memory footprint. Still not compatible enough though, lacking CTTY command implementation and having a few bugs here and there. But that hopefully can only improve looking into the future.

Back to the original topic:
It seems that the DR-DOS version that was modified to run Windows 95 was a development in between Novell and Caldera transition. Since Caldera could not entirely recover all Novell developments, the code must be gathering dust on a backup of the developers that worked for the Microsoft trial. The best bet would be to contact them. They are named in DR-DOS Wikipedia's article.

IMHO it would be interesting to see what they did, and for historical purposes, but probably not that much for any practical use. In any case, trial depositions, should contain more technical details about this code (You would be lucky to get the records, and not so happy to have to read through all of them to get some clues).

yeah CTTY issue leaves open in the moment, don't know when it can be resolved. https://github.com/SvarDOS/bugz/issues/101

Jo22 wrote on 2025-12-04, 07:35:

But again, I'm just thinking out loud here. It simply came to mind.
Please ignore my post and go on, I don't mean to derail this thread.

I do like how detailed your posts are, you clearly know your thing when it comes to the DOS era!

igully wrote on 2025-12-04, 12:50:

Back to the original topic:
It seems that the DR-DOS version that was modified to run Windows 95 was a development in between Novell and Caldera transition. Since Caldera could not entirely recover all Novell developments, the code must be gathering dust on a backup of the developers that worked for the Microsoft trial. The best bet would be to contact them. They are named in DR-DOS Wikipedia's article.

IMHO it would be interesting to see what they did, and for historical purposes, but probably not that much for any practical use. In any case, trial depositions, should contain more technical details about this code (You would be lucky to get the records, and not so happy to have to read through all of them to get some clues).

Hmm your point does make sense as a possible explanation why the code was not released by Caldera as promised. And yes, I agree that it would be useful for history and preservation, but also possibly to learn from it.

I do doubt that one of the devs would want to share the TSR, if even they have still preserved it.

Thanks for suggesting the names in the Wikipedia article. A look into them led me to this 2007 MSFN post https://msfn.org/board/topic/109018-windows-98-in-dr-dos (scroll to the bottom) by the "original author" of the program, Matthias Paul, and the program seems to have been called WinGlue. He actually goes into detail about how the program did its thing, so take a look!

That post looks like the only detailed info on the web directly from the developer himself about the program.

Usually setteling out of court for millions has some preemtive clauses. Like destroying conflicting source code.