Warlord wrote:

Don't forget 7.1 another feature is LFNs.

I don't think they are actually supported in pure DOS mode.

Warlord wrote:

Don't forget 7.1 another feature is LFNs.

Is this really an improvement? The wave does its work... Doesn't it?

dr_st wrote:

Warlord wrote:

Don't forget 7.1 another feature is LFNs.

I don't think they are actually supported in pure DOS mode.

they are

maxtherabbit wrote:

dr_st wrote:

Warlord wrote:

Don't forget 7.1 another feature is LFNs.

I don't think they are actually supported in pure DOS mode.

they are

only in the sense it knows not to mess them up. dir will only display ~1 shortnames, etc. copy etc dont work with them. in pure 7.1 "LFN" dont exist in that true sense.

BloodyCactus wrote:

maxtherabbit wrote:

dr_st wrote:

I don't think they are actually supported in pure DOS mode.

they are

only in the sense it knows not to mess them up. dir will only display ~1 shortnames, etc. copy etc dont work with them. in pure 7.1 "LFN" dont exist in that true sense.

That's not the case, you must not be loading the lfn driver.

What is this LFN driver you are talking about? Is it among the DOS drivers that ship with Win9x? If not, then I wouldn't call it a "DOS 7.1 feature". Unless you are talking about some non-Microsoft version.

dr_st wrote:

What is this LFN driver you are talking about? Is it among the DOS drivers that ship with Win9x? If not, then I wouldn't call it a "DOS 7.1 feature". Unless you are talking about some non-Microsoft version.

I'm talking about the CDU DOS 7.1 release

In a true sense LFNs are stored in VFAT, using utlites that support VFAT will enable LFNS to be preserved and used under DOS 7.1. VFAT is an integral part of DOS 7.1,
DJGPP is a complete 32-bit C/C++ development system for 386+ PCs running DOS. One of the main features is that it and most of its compiled programs are completely compatible with LFN. Because of its features, functionality and ease of use, an increasing number of modern DOS programs are compiled by DJGPP, namely, the DJGPP programs. For the time being, a large part of DOS LFN-aware programs are in fact DJGPP programs. Note that they are all 32-bit protected mode DOS programs which require a DPMI provider (e.g. CWSDPMI.EXE or HDPMI32.EXE). Examples:

Of course, there are also a plenty of DOS LFN-aware programs that are not compiled by DJGPP and are compatible with LFNs. These programs can be either real-mode DOS programs or protected mode DOS programs. Examples:

Volkov commander on dos 7.1 with LFNDOS loaded=LFN
PKZIP / PKUNZIP 2.50
RAR 3.30
4DOS 7.50/8.00

Since it is possible to launch most Win32 console applications and some Win32 GUI applications under pure DOS using HX DOS Extender, and HX DOS Extender fully supports long file names whenever available and will provide LFN APIs to all compatible Win32 applications, this adds a wide range of applications that can be run under DOS and are LFN compatible; in most cases you can simply load HXLDR32.EXE from HX DOS Extender once and then run any compatible Win32 applications you want in real DOS as if they are native DOS applications. Examples:

Source:
http://www.cn-dos.net/msdos71/doslfns.htm

TLDR: I fundamentally disagree with anyone that says 7.1 does not support LFNs because there is a mountain of evidence that supports my argument.

The point is that the actual, "proper" MS-DOS 7.1 (which is the DOS layer of Windows 98) does not support LFN in its pure DOS mode without a third-party driver. The "China DOS Union" release is an unofficial, and not strictly legal, bundle, which has quite a few additional stuff, as far as I know.

FAT32 support is built in in "DOS 7.1" - even if you boot without a single driver, it will see (and work off) a FAT32 partition. This is not the case for LFN support.

DOS 7.1 is more useful and functional than 6.22. I remember posts on usenet talking about DOS 6.22 vs the forgotten DOS 7.0 in late 95-1996, then later DOS7.1. Still In 20+ years other than MS deliberately breaking WIN3.1 and creative's PNP CTCM driver I have not come across a game/app that works on 6.22 but not on 7/ 7.1. In streams of old usenet posts the games that people said don't work on DOS7.1 were caused by TSRs that also stopped them working in DOS 6.22

LFN are also handy combined with doskey tab file completion. Almost no one uses this in dos but a passive utility like http://lfntools.sourceforge.net is just an app, no driver or TSR. Much easier to get around when you have a lot of games on a single huge fat32 drive and have organised the dirs using LFN in W98 or a newer OS. It comes close to replicating XP and newer command prompt.

AvalonH wrote:

Still In 20+ years other than MS deliberately breaking WIN3.1 and creative's PNP CTCM driver I have not come across a game/app that works on 6.22 but not on 7/ 7.1.

Cannot confirm. Have been using the Creative CTCM PNP driver since forever under Win95 and Win98's DOS (7.0 and 7.1). The installer might wine about you running it in a "dos window" even if you're not, but this doesnt hinder you from installing it yourselves by copying a few files and adding a few entries in to the startup files...

dr_st wrote:

The point is that the actual, "proper" MS-DOS 7.1 (which is the DOS layer of Windows 98) does not support LFN in its pure DOS mode without a third-party driver. The "China DOS Union" release is an unofficial, and not strictly legal, bundle, which has quite a few additional stuff, as far as I know.

FAT32 support is built in in "DOS 7.1" - even if you boot without a single driver, it will see (and work off) a FAT32 partition. This is not the case for LFN support.

ok, I'm still going to continue to use and recommend the CDU release

windows 98 is trash

dr_st wrote:

The point is that the actual, "proper" MS-DOS 7.1 (which is the DOS layer of Windows 98) does not support LFN in its pure DOS mode without a third-party driver. The "China DOS Union" release is an unofficial, and not strictly legal, bundle, which has quite a few additional stuff, as far as I know.

FAT32 support is built in in "DOS 7.1" - even if you boot without a single driver, it will see (and work off) a FAT32 partition. This is not the case for LFN support.

🤣 it is widely known in many circles since weiger hacked win 3.11 to run on dos 7.11 that CDU dos is the same as dos 7.1 from 98se that has just been hex edited so that it doesn't say windows 98 on it. 🤣 Its not an unofficial version it is exactly the same. Its simply been hex edited so that it says DOS 7.11 instead of windows 98. It's not a different version or have added capabilities.

Your argument is kinda not so solid you are saying becasue you need a driver or a program specifically written to take advantage of underlying code that in doing so invalidates the existence of such features.

That is like saying, I am a windows 2000 user (dos 6.22) and I prefer 2000 over XP (dos 7.11) becasue I do not see some benefit that XP has. Yes the differnce between NT 5.0 and NT 5.1 is very small almost negligible. So when you say XP is better becasue it supports some feature that 2000 doesn't I will say but it didn't officially ship with XP even though that driver and program runs on XP and not 2000 you argument is invalid 🤣

Please do not put words in my mouth.

You can argue whatever you want. CDU DOS is not an official product by Microsoft, as you well know. And if you don't know that, then you should know.

Microsoft never released any product officially called "DOS 7" or "DOS 7.1" actually, but the only 'official' releases, shipped with Windows 95, 98, 98SE, as far as I know do not support long filenames in pure DOS, out of the box, in the sense that the driver which enables it is not included.

Please feel free to correct me if I'm wrong. Better yet - please share with us the name of the LFN driver that CDU DOS uses. This way folks interested in enabling this feature can install this driver in whatever release of "DOS 7.x" they have, even if it did not originally come with it.

Henrik Haftmann wrote DOSLFN originally, it's a TSR not a driver. it uses microsofts LFN-API
https://www-user.tu-chemnitz.de/~heha/hs/what_lfn.en.htm

https://www-user.tu-chemnitz.de/~heha/hs/

So meanwhile I played around with jemmex, jemm386, qemm97, HIMEMX and of course the originals. So I ended up with following settings

In DOS 6.22
HimemX + EMM386 (original 6.22)
VIDECDD + MSCDEX
SHELLMAX/ENVIMAX + COMMAND.COM
USBUHCI + USBMOUSE + USBKEYB + KEYBOARD.SYS + CTMOUSE
DOSKEY
it results in 619K (with EMS and NOEMS) - 26K (EMS) / 78 (NOEMS) upper memory left for other drivers
it appears to be stable and the Games that are important for me are running well.

In DOS 7.1
HIMEM + EMM386
VIDECDD + MSCDEX
USBUHCI + USBMOUSE + USBKEYB + KEYBOARD.SYS + CTMOUSE
DOSKEY
it results in 625K (with EMS and NOEMS) - 17K (EMS) / 69K (NOEMS) upper memory left for other drivers
it appears to be stable and the Games that are important for me are running well.

So I am back at my entry question 😀 - don't know what system to prefer... but maybe this isn't that important. As long as everything runs smooth ... I am sure I will encounter some roadblocks sooner or later.

Edit: I exchanged HIMEM in 6.22 becua6the original caused problems with Beneath a steel sky. With HIMEMX it works fine - if someone has a solution that includes the original HIMEM i am willing to switch back again.

@Lazar81, what is the extra 6kB used by 6.22?
"mem /c/a/p" would show. If you want to send content to file, write "mem /c/a > myfile.txt" for easy comparison later. (And maybe post the contents here as well?)

Well... Correction: I'm getting 625K free conventional in 6.22 after adding DOSMAX to config.sys. And at the moment it looks stable in tested games.

1Module, die den Speicher unterhalb 1 MB verwenden:
2
3    Name       Insgesamt     = Konventioneller  +  Hoher Speicher
4  --------  ----------------   ----------------    ---------------
5  MSDOS        9,517    (9K)      9,517    (9K)          0    (0K)
6  HIMEMX       2,128    (2K)      2,128    (2K)          0    (0K)
7  EMM386       3,280    (3K)      3,280    (3K)          0    (0K)
8  DOSMAX         256    (0K)          0    (0K)        256    (0K)
9  FILES        3,280    (3K)          0    (0K)      3,280    (3K)
10  FCBS           272    (0K)          0    (0K)        272    (0K)
11  WKBUFFER       528    (1K)          0    (0K)        528    (1K)
12  LASTDRIV       464    (0K)          0    (0K)        464    (0K)
13  STACKS       1,888    (2K)          0    (0K)      1,888    (2K)
14  INSTALL        160    (0K)          0    (0K)        160    (0K)
15  USBMOUSE     7,888    (8K)          0    (0K)      7,888    (8K)
16  USBKEYB      9,184    (9K)          0    (0K)      9,184    (9K)
17  COMMAND      4,320    (4K)          0    (0K)      4,320    (4K)
18  VIDECDD      5,056    (5K)          0    (0K)      5,056    (5K)
19  MSCDEX      16,000   (16K)          0    (0K)     16,000   (16K)
20  USBUHCI     42,592   (42K)          0    (0K)     42,592   (42K)
21  KEYB         6,944    (7K)          0    (0K)      6,944    (7K)
22  DOSKEY       4,144    (4K)          0    (0K)      4,144    (4K)
23  CTMOUSE      3,328    (3K)          0    (0K)      3,328    (3K)
24  Frei       659,440  (644K)    640,224  (625K)     19,216   (19K)
25
26Speicher-Zusammenfassung:
27
28  Speichertyp         Insgesamt =  Verwendet +     Frei
29  -----------------   ---------    ---------    ---------
30  Konventioneller       655,360       15,136      640,224
31  Hoher                 125,520      106,304       19,216
32  Reserviert                  0            0            0
33  Erweiterung (XMS)  66,917,808   4,294,777,   67,107,840
34  -----------------   ---------    ---------    ---------
35  Insg. Speicher     67,698,688   4,294,898,   67,767,280
36
37  Insg. unter 1 MB      780,880      121,440      659,440
38
39  Insgesamter Expansionsspeicher (EMS)             33,947,648 (33,152K
40  Freier Expansionsspeicher (EMS)                  33,505,280 (32,720K
41
42    EMM386 verwendet XMS-Speicher, um EMS-Speicher zu simulieren.
43    Freier EMS-Speicher kann sich „ändern, wenn sich freier XMS-Speicher „ändert.
44
45  Maximale Größe fr ausführbares Programm            640,208   (625K)
46  Größter freier Block im hohen Speicherblock          12,288    (12K)
47  Freier Speicher im oberen Speicherbereich            16,784    (16K)
48  MS-DOS ist resident im oberen Speicherbereich (High Memory Area).

But there is something that I don't understand:
I added the the unhook switches for interrupts or stacks... This seems to be right. But I don't understand it. What is DOSMAX doing when unhooking these Interrupts?

Referring to 6.22vs7.1 i hope to put it correct when saying preferring 7.1 over 6.22 only makes sense when I have a program that needs more then 64Mb Extended memory and fat32 means a noticeable performance boost... This is just hypothesizing... Don't know if this is correct. Tell me if I am on the right way.

In my opinion, Win98SE DOS (aka DOS 7.1) is a better DOS overall because it supports more DOS internal components in UMB out-of-the-box. DOSMAX is a hack, by the way. However, FAT32 is the most critical feature for most to reducing disk slack space. Even if you don't use partition over 2GB, the smaller cluster size would make lesser disk slack. FAT32 does not improve disk performance, on the contrary it will incur slight performance hit for smaller cluster size in exchange for better disk utilization.

The rest would simply be just cosmetics. LFN support is not something I would desire to have in DOS primitive 80x25 dumb console, just my $0.02.

kjliew wrote:

In my opinion, Win98SE DOS (aka DOS 7.1) is a better DOS overall because it supports more DOS internal components in UMB out-of-the-box. DOSMAX is a hack, by the way. However, FAT32 is the most critical feature for most to reducing disk slack space. Even if you don't use partition over 2GB, the smaller cluster size would make lesser disk slack. FAT32 does not improve disk performance, on the contrary it will incur slight performance hit for smaller cluster size in exchange for better disk utilization.

The rest would simply be just cosmetics. LFN support is not something I would desire to have in DOS primitive 80x25 dumb console, just my $0.02.

True.. 7.1 provides what must be added through a hack in DOS 6.22 - OK. As long as 6.22 and desired programs are running stable I don't see the point of prefering 7.1. I am getting the same amount of free conventional memory. OK Data is stored more efficient on a FAT32 partition - that is for sure a good point. But must it be a priority? I don't want to argue .. it is just my lack of understanding. 😀