I think there are a bunch of programs missing from 7 by default? Maybe memory management stuff?

DOS7 is not intended to be a stand-alone OS, just the layer beneath Win95, but you can make it so if you want.

kolderman wrote on 2021-10-15, 01:59:

I think there are a bunch of programs missing from 7 by default? Maybe memory management stuff?

HIMEM.SYS and EMM386.EXE are included on a normal Windows 9x installation. Some of the missing programs can be grabbed from the OLDMSDOS directory from the Windows CD.

DOS7 is not intended to be a stand-alone OS, just the layer beneath Win95, but you can make it so if you want.

True, but most of the issues are mainly centered around DOS version check on some utilities and in the case of FAT32 partitions: direct disk access (the program supporting this requires FAT32 support) and lack of FCBS support.

At least for Windows 3.x one could try the following: Making Windows 3.11 work in DOS7.10 (patches inside), but I don't recommend that and prefer sticking to the Windows 9x GUI instead.

kolderman wrote on 2021-10-15, 01:59:

I think there are a bunch of programs missing from 7 by default? Maybe memory management stuff?

DOS7 is not intended to be a stand-alone OS, just the layer beneath Win95, but you can make it so if you want.

Gmlb256 wrote on 2021-10-15, 02:08:

HIMEM.SYS and EMM386.EXE are included on a normal Windows 9x installation. Some of the missing programs can be grabbed from the […]
Show full quote

kolderman wrote on 2021-10-15, 01:59:

I think there are a bunch of programs missing from 7 by default? Maybe memory management stuff?

HIMEM.SYS and EMM386.EXE are included on a normal Windows 9x installation. Some of the missing programs can be grabbed from the OLDMSDOS directory from the Windows CD.

DOS7 is not intended to be a stand-alone OS, just the layer beneath Win95, but you can make it so if you want.

True, but most of the issues are mainly centered around DOS version check on some utilities and in the case of FAT32 partitions: direct disk access (the program supporting this requires FAT32 support) and lack of FCBS support.

At least for Windows 3.x one could try the following: Making Windows 3.11 work in DOS7.10 (patches inside), but I don't recommend that and prefer sticking to the Windows 9x GUI instead.

+1

That sums it up pretty well, IMHO.

MS-DOS 7.x was often used as a MS-DOS 6.2x alternative in the 1990s.
People often dedicated books to DOS 7, without focusing on Windows 9x.

Tinkerers and video game fans often used DOS 7 for their hobby, also.
The arcade/emulator scene (primarily on DOS till the mid-2000s) even sort of embraced it or supported things like long file names.

- Without breaking DOS 5/6 compatibility, of course.
But FAT32 was required for serious working, anyway, so DOS 7 made sense.

The hardware of the time was past than what DOS 6.22 could fully take advantage of, anyway.
CPUs of several hundred MHz, HDDs larger than 10 gigs, 16/24/48/64/96 MB of RAM, VBE 3 gfx cards with 8MB and up..

By comparison, MS-DOS 6.2x was released when 386/486 PCs with 40MHz, 120MB HDD, 4MB RAM, 512K VGA were still sold as lower end machines.

Dos 7.1 - Still have not come across any game compatibility problems in two decades. I remember on Usenet in late 90's early 2000's(the win98 years), literally thousands of posts about dos 7.1 breaking games, they all were resolved after lots of replies by config.sys/autoexec.bat problems (that also stopped the game working on 6.22). Only problems are applications that are coded to check for dos7.1 and stop running like creative CTCM,CTCU (because they think you are running it from win9x).

Non-aware FAT32 programs from 6.22 and below are also safe to run because the 'lock' command in dos7.1 will stop any if they try direct disk access.
Also beware there is also the forgotten Dos 7.0, from original win95, which is fat16 only and more like an updated Dos 6.22.

Riikcakirds wrote on 2021-10-16, 18:39:

Only problems are applications that are coded to check for dos7.1 and stop running like creative CTCM,CTCU (because they think you are running it from win9x).

SETVER (included on a normal Windows 9x installation) can be used to get around the version check of several programs and for CTCM/CTCU there is a workaround by removing the winbootdir environment variable check.

Also beware there is also the forgotten Dos 7.0, from original win95, which is fat16 only and more like an updated Dos 6.22.

Yep, that version of MS-DOS is overlooked due to the lack of FAT32 support. Like 7.1 it also has long file name capability thru a LFN driver or within Windows 95 and LOCK/UNLOCK command for direct disk access.

+As mentioned in my other post 😀

From programs.txt:

"
Share.exe no longer works in MS-DOS mode
To support FAT32, SHARE support has been disabled in the real-mode MS-DOS kernel (sharing support is still provided under protected-mode Windows 98).
"

In the whole world, I'm almost the only person who has a problem with this 😀

melbourne wrote on 2021-10-19, 00:24:

+As mentioned in my other post :) […]
Show full quote

+As mentioned in my other post 😀

From programs.txt:

"
Share.exe no longer works in MS-DOS mode
To support FAT32, SHARE support has been disabled in the real-mode MS-DOS kernel (sharing support is still provided under protected-mode Windows 98).
"

In the whole world, I'm almost the only person who has a problem with this 😀

You need to find one that is compatible that is compatible with FAT32 partitions but that's out of scope for this forum. BTW, for what you need SHARE.EXE? If it's for just transferring files between computers you're better off with mTCP and a packet driver.

Hm, not sure. I vaguely remember VSHARE from WfW 3.11. Wasn't SHARE required if multiple productivity programs worked with the same set of files?
So that all can read them, but only one can modify them? MS Works, Word etc?

Jo22 wrote on 2021-10-19, 02:14:

Hm, not sure. I vaguely remember VSHARE from WfW 3.11.

The same problem applies to VSHARE because it doesn't work on MS-DOS 7.1 due to kernel incompatibility according to the W3XSTART readme, that's one of the reasons why I don't recommend Windows 3.x in that case. Finding an implementation of SHARE that is capable of working with FAT32 partitions is the only solution.

Wasn't SHARE required if multiple productivity programs worked with the same set of files?
So that all can read them, but only one can modify them? MS Works, Word etc?

Yep, I've seen that a certain version of Microsoft Word for DOS requiring SHARE.

For a games rig 7 is fine, maybe even preferred as it's bit more lightweight as it's not a true standalone OS
Where as Dos 6 and below include additional programs not needed on a gaming rig.

That said if I'm installing Win3x I'll install Dos 6.22 as it just feels correct.

One of the utilities that DOS 6.22 has but 7.1 doesn't is MEMMAKER.EXE. Using that, I was able to achieve much better results with conventional memory than via my own tinkering.

On the flip side, DOS 7.1 is more lightweight, since its able to load more things high by default. So it's not a huge difference in the end.

Gmlb256 wrote on 2021-10-19, 02:39:

Yep, I've seen that a certain version of Microsoft Word for DOS requiring SHARE.

If I remember correctly, I think back then I was able to load SHARE using SETVER on DOS 7 (resp. W9x).

Joseph_Joestar wrote on 2021-10-19, 11:42:

... MEMMAKER.EXE. Using that, I was able to achieve much better results with conventional memory than with my own tinkering.

I tried MEMMAKER back then, but I didn't like it because of its poor results.
Background is that one has to find out which programs need how much memory to initialize, and find the optimal distribution on HMA and the various UMB blocks.
Memmaker tries to do this well, but its results are not always the optimum, leaving large unused gaps of UMB memory and filling up conventional memory instead.

retardware wrote on 2021-10-19, 11:49:

I tried MEMMAKER back then, but I didn't like it because of its poor results.

I took the suggested approach and removed all of my own tweaks (basically got rid the LH and DEVICEHIGH lines) before running MEMMAKER and it worked out fine for me. It got me to 614 KB free conventional memory which is more than enough for all the games that I normally play.

Obviously, everyone's system is different, so your mileage may vary. And there are some edge cases where you need even more free memory for one of those highly demanding games, but 95% of the time, I'm fine with what I got.

Joseph_Joestar wrote on 2021-10-19, 11:59:

I took the suggested approach and removed all of my own tweaks (basically got rid the LH and DEVICEHIGH lines) before running MEMMAKER and it worked out fine for me. It got me to 614 KB free conventional memory which is more than enough for all the games that I normally play.

Obviously, everyone's system is different, so your mileage may vary. And there are some edge cases where you need even more free memory for one of those highly demanding games, but 95% of the time, I'm fine with what I got.

Never used MEMMAKER and managed to get 625KB of free conventional memory with MS-DOS 7.1. 😁

1Memory Type        Total       Used       Free
2----------------  --------   --------   --------
3Conventional          640K        15K       625K
4Upper                 160K       149K        11K
5Reserved              384K       384K         0K
6Extended (XMS)     64,352K     8,371K    55,981K
7----------------  --------   --------   --------
8Total memory       65,536K     8,920K    56,616K
9
10Total under 1 MB      800K       165K       635K
11
12Largest executable program size       625K (639,568 bytes)  
13Largest free upper memory block         6K   (6,288 bytes)  
14MS-DOS is resident in the high memory area.

That's on a configuration with out expanded memory manager (using UMBPCI and handling it's tradeoffs), with it I get 622KB and uses a slightly different configuration. 614KB is good enough for many stuff though.

Gmlb256 wrote on 2021-10-15, 02:08:

HIMEM.SYS and EMM386.EXE are included on a normal Windows 9x installation. Some of the missing programs can be grabbed from the […]
Show full quote

kolderman wrote on 2021-10-15, 01:59:

I think there are a bunch of programs missing from 7 by default? Maybe memory management stuff?

HIMEM.SYS and EMM386.EXE are included on a normal Windows 9x installation. Some of the missing programs can be grabbed from the OLDMSDOS directory from the Windows CD.

DOS7 is not intended to be a stand-alone OS, just the layer beneath Win95, but you can make it so if you want.

True, but most of the issues are mainly centered around DOS version check on some utilities and in the case of FAT32 partitions: direct disk access (the program supporting this requires FAT32 support) and lack of FCBS support.

At least for Windows 3.x one could try the following: Making Windows 3.11 work in DOS7.10 (patches inside), but I don't recommend that and prefer sticking to the Windows 9x GUI instead.

So this is interesting. I actually installed Dos 7.1 off a community made install cd hosted on WinWorldPC. Archive.org's backup of it's old homepage claims it's 100% compatible with Win3.11, no patches required. Thus far, that's been true for me. I just installed Dos 7.1 off that cd, installed Win 3.11, and thus far haven't noticed anything amiss at all. Though I did turn off LFN support just because I don't like it in a pure dos environment, apparently that's required to get Win 3.11 working properly.

Namrok wrote on 2021-10-19, 12:18:

So this is interesting. I actually installed Dos 7.1 off a community made install cd hosted on WinWorldPC. Archive.org's backup of it's old homepage claims it's 100% compatible with Win3.11, no patches required. Thus far, that's been true for me. I just installed Dos 7.1 off that cd, installed Win 3.11, and thus far haven't noticed anything amiss at all.

One thing that you can miss is the permanent swap file and "32-bit file access" which doesn't work with FAT32 partitions, without them the I/O performance will suffer. I have witnessed this first hand and verified with some benchmarks that could test the hard disk performance.

Though I did turn off LFN support just because I don't like it in a pure dos environment, apparently that's required to get Win 3.11 working properly.

Windows 3.x never required LFN but there the Calmira LFN shell and the LFNXLAT.386 hack.

Gmlb256 wrote on 2021-10-19, 12:12:

Never used MEMMAKER and managed to get 625KB of free conventional memory with MS-DOS 7.1. 😁

That is an excellent result, kudos!

In my view, the main benefit of MEMMAKER is that it provides an easy way to free up a decent amount of conventional memory for people like myself who aren't that versed with memory tweaks. With a finely tuned setup it's certainly possible to do better than MEMMAKER, especially in DOS 7.1 since it takes up less conventional memory by default. Personally, I stick with good old MS-DOS 6.22 with its stock memory management utilities for purely nostalgic reasons.

Some programs are said to have issues when the MSDOS.SYS is smaller than 1024 bytes (which is the case with the 7.1 delivered version.)

1541 wrote on 2021-10-19, 20:42:

Some programs are said to have issues when the MSDOS.SYS is smaller than 1024 bytes (which is the case with the 7.1 delivered version.)

A normal Windows 9x installation adds filler bytes for this reason, there was a KB article from Microsoft mentioning this if you used SYS or FORMAT /S for a hard drive partition.