Five Additional Win ME VxDs Patched to Work with Win 98SE

I've been testing them for a long time (from Dec 2007 to the present), and so has RetroOS (from Apr 2008 to the present; thanks RetroOS, you rock! ), so I'm quite sure they work as intended with Win 98SE.

CDTSD.VxD, CDFS.VxD, SMARTVSD.VxD SCSI1HLP.VXD and VOLTRACK.VXD

Warning: Read carefully the instructions below and only proceed if you are 100% sure you know what you're doing. These instructions do work, but a single small mistake can cripple your system!!! If your system stops booting, you have only yourself to blame. You have been warned!

In case you are interested in using them in your system, here's what you have to do:

*** BACKUP YOUR SYSTEM!!! ***

Create a temporary folder and name it, say, NEWPAT

Using 7-zip, WinRAR, WinZip or whatever your favorite file unpacker may be:

1. Extract CDTSD.VxD, SMARTVSD.VxD SCSI1HLP.VXD and VOLTRACK.VXD from WIN_20.CAB, from your Win ME distribution disk and drop these files into NEWPAT;
2. Extract CDFS.VxD from ME274175.EXE, which you have to download from MDGx's site, and drop it into NEWPAT;
3. Extract all patch patterns from New_VxDs_PATs.7z, which is attached to this post, and drop it in NEWPAT;
4. Extract PATCH.EXE from utils.zip, which you have to download from kanastacorp's site, and drop it into NEWPAT;
5. If you don't already have it, extract GETVER.EXE from CmdLine.zip, which you have to download from lbrisar's site, and drop it into \%windir%\command\ folder (or just into NEWPAT if you don't intend to keep it);

Open a DOS box, go to NEWPAT and run at the command prompt
getver *.VXD
It must show you all the .VxDs you've collected are version 4.90.0.3000, except for CDFS.VxD, which must be v. 4.90.0.3001 (if not, the something went wrong, recheck your previous steps).
Now let's do the actual patching (it must be done as described, because PATCH.EXE does not accept, say, *.VXD) so, at the command prompt run:
PATCH -p CDFS.VxD CDFS.PAT CDFS.NEW
When the prompt reapears, run:
PATCH -p CDTSD.VxD CDTSD.PAT CDTSD.NEW
When the prompt reapears, run:
PATCH -p SMARTVSD.VxD SMARTVSD.PAT SMARTVSD.NEW
When the prompt reapears, run:
PATCH -p SCSI1HLP.VxD SCSI1HLP.PAT SCSI1HLP.NEW
When the prompt reapears, run:
PATCH -p VOLTRACK.VxD VOLTRACK.PAT VOLTRACK.NEW
When the prompt reapears, run:
getver *.NEW
It must show you all the .NEWs PATCH created are version 4.90.0.3001, except for CDFS.VxD, which must be v. 4.90.0.3002 (if not, the something went wrong, recheck your previous steps).
When the prompt reapears, run:
Copy *.NEW %windir%\system\iosubsys /b /v
When the prompt reapears, close the DOS box.

*** This is the hazardous part! Be careful. ***
Restart in MS-DOS mode or boot into DOS from a BOOT diskette.
Go to %windir%\system\iosubsys.
Run a "dir *.NEW" command just to get the list of new files.
Rename to .OLD each of the 5 old .VxDs, one at a time (e. g. "ren CDFS.VXD *.OLD)
Run a "dir *.OLD" command just to check you now have 5 .OLD files corresponding to the 5 .NEW files you had as you started.
Run "ren *.NEW *.VXD"
Run a "dir *.NEW" command and now no file must be found, if everything went as it should.
Restart windows.

*** If windows doesn't start: Rename the five updated .VXDs back to .NEW and the files .OLD back to .VXD
Now windows must boot again. Once back in windows, recheck your steps and try again. ***

Once you're satisfied everything is working as it should, then you may delete the NEWPAT folder and all files inside it.

Of course, as always, the standard disclaimer applies: It works great for me, but YMMV and I can guarantee nothing whatsoever about these patches, and about the use you make of them. So, by deciding to apply them you fully accept that anything you do is of YOUR SOLE RESPONSIBILITY... Hence, if after adding these files your pc morphs into a purple mushroom and explodes, causing a 10-day worldwide blackout in the process, you know you can't blame me for it! You have been warned.

Kanastacorp's site is returning error #509 (= "Bandwidth Limit Exceeded") so I've uploaded their fundamental package here: utils.zip, for you to be able to get PATCH.EXE from it.

A further warning: in case you have a third party SMARTVSD.VXD in your system, like the one installed with the PROMISE add-on PATA or SATA controllers, you must keep the third party SMARTVSD.VXD. So you should do all of the above procedure just for the other four files, and skip replacing SMARTVSD.VXD.

This post has been edited by dencorso: Dec 30 2008, 09:16 PM

Thank you for your work. A couple of small issues though:
1. What are those files responsible for, within the system? Why should one go through all this hassle, is it worth?
2. Is it possible to find another patching system that would not involve so many steps? An AutoHotkey script, maybe, that'd take care of CD files extraction + backup + binary patching of all of the files, at once?
3. Can the patched files be used without 98SE2ME installed or is the latter mandatory (considering we're in its thread)?

Well, there's no hurry, it could wait until next year. Happy New Year everybody!

This post has been edited by Drugwash: Dec 31 2008, 06:33 AM

CDFS.VXD (CDFS driver): If a media player is installed on the system, e.g., Winamp or Windows Media Player, audio CD files are shown in Windows Explorer as supported media files with the applicable program icon. WIN9x uses this file and files CDTSD.VXD and CDVSD.VXD to manage CD/DVD drives.

CDTSD.VXD: A TSD is a type specific driver that handles the majority of drive calls for that class type(disk or cd) and then uses the spcific device adapter services to communicate with the hard disk. Primary responsibilities of a TSD include drive letter assignment and converting logical requests to physical requests so that the adapter driver can understand it.

SCSI1HLP.VXD (SCSI I): Used by WIN9X to play video CDs in IDE CD drives. It is a filter driver just for SCSI I and some proprietary CD-ROM drives. This driver loads on boot and is unloaded if it is not needed. It is not used when communicating with SCSI II or SCSI III CD-ROM or hard disks. It allows Win9x to implement the SCSI I command sets in use by SCSI I CD-ROM drive models.

VOLTRACK.VXD Volume Tracking Virtual Device Driver for I/O Devices (i.e. CD-Rom, Floppies, etc.).

SMARTVSD.VXD Implements S.M.A.R.T. monitoring for internal IDE HDDs (PATA only). A VSD is a vendor specific driver, and may be used by a hardware manufacturer to help make his/her product more compatible with the ideal hardware expected by WIN9X. However, Microsoft supplied some generic VSDs for some devices, such as CDVSD.VXD, DISKVSD.VXD and this one. They usually are enough for most hardware, but in this specific case, if add-on HDD controllers are added to the system, the SMARTVSD.VXD should be substituted by another, customized to detect both the add-on card and the onboard controller(s).

To have the most up-to-date code-base available. I think it's worth the effort, but that's just my opinion.

Sure. I know my release method is complicated, but it was the best I was able to do. Now that the files are available, let's hope someone can come up with an automated patcher for them. I'm no good at creating installers, sorry!

Yes, they can. 98SE2ME is not mandatory. But they fit well in 98SE2ME, so I think this is the proper thread for releasing them.

Happy New Year to you all!

This post has been edited by dencorso: Jan 23 2009, 12:59 PM

Thank you for replying, now things are a lot more clear in regard to the above-mentioned files. I've stumbled into something else though - some of the related files on my system do not quite match:
CDFS.VXD 4.10.2222 (QFE)
CDTSD.VXD 4.10.1998
CDVSD.VXD 4.90.3004
DISKTSD.VXD 4.90.3001
DISKVSD.VXD 4.10.1998

Do you think this configuration is OK? I'm asking because I generally have no issues with the HDD or CD/DVDs, except for the fact that any DVD I read with my DVD-RW Samsung SH-S182D appears as a 2GB volume (2,097,120 bytes), not a 4.7GB one as it should. All data can safely and correctly be copied from them, though.

Do you have any idea who can be responsible for this? The COPY2GB patch, maybe, or any of the above-mentioned files?

Anyway, if I can wrap my head around these patches, I may try to create an automated patcher and a restore script (should anything go bad).

Hi dencorso,

Just a quick thanks for the newer vxd files. All installed and working well on my 98SE2ME box.

I did patch them all in a dos box as you described, however I chickened out working in dos at the hazardous bit.

Seeing as none of these files are in use when viewing the desktop I worked with File Manager to rename the new vxd's after checking the version numbers were correct and transferred them one by one, after backing up the original versions to a floppy.

Seemed less hazardous that way, for me at least.

As an afterthought it would be even easier to "right click" on the newer vxd's if you have "Rename" and "Copy to Folder" in the context menu and transfer them that way.

Thanks again,

This post has been edited by lightning slinger: Jan 1 2009, 01:54 PM

Hi, lightning slinger!
Way back when, Petr had found out that it's possible to substitute DISKTSD.VxD from the File Manager. Your report makes me think all the VxDs in /IOSUSYS may be substituted in this way. Nice to know it. It really helps make my procedure a little less scary. Nice find! However, the new VxDs will start working only after a system reboot, so it remains necessary to reboot asap after the new files are all in place.

Hi, Drugwash!
Check it again, I guess you read the product version, instead of the file version...
You surely are using v. 4.10.1999
If not, you've got a build I'm not aware of.

Well, this is a known DVD related bug that remains unsolved. My system does the same. But it gives the correct size for CDs. My guess is the problem lies either with CDFS.VxD or VolTrack.VxD. But nobody knows it for sure, afaik. And no, sorry, these new patches don't solve this particular bug... So, yes, your configuration is OK.
Later Edit: My guess turned out to be wrong! The problem is higher up, in the GUI part of windows, and affects anything treated as a "remote filesystem" (such as CDs, DVDs and remote shares)... See Q256576

Now, then, you can keep your configuration as it is, or you can fully upgrade it to the Win ME code base using the patches I just released and upgrading DiskVSD.VxD with the unofficial update available at MDGx's: Q271277.

Just in case, here is some more info, thanks to the Wayback Machine: Q271277 and Q274175. The latter MSKB shows CDFS.VxD 4.90.3001 (the base for my 4.90.3002) addresses the same issue than 4.10.1999, so, here also, the main advantage is to move to a newer (and hopefully better) code-base.

That would be great! Thanks! Perhaps the finding just reported by lightning slinger may be of help in creating the automated patcher, as it removes the need to go into true DOS and back, so its just one reboot instead of two.

Thanks a lot to you both for your interest and prompt feedback! You rock! And Happy New Year once more!

PS: I forgot to mention that these patched files should work with Win 98FE, 98FESP1 and 98SE (with or without 98SE2ME), afaik. I have conducted all my tests in a 98SE2ME system, and so did RetroOS, and that's why I didn't say this right away. But while the new patched files are still untested in Win 98FE and 98FESP1, all my previous patched VxDs from Win ME IOSUBSYS are already tested in the previous versions of 98 and do work in them OK.

This post has been edited by dencorso: Jan 1 2009, 11:24 PM

Dencorso, thanks for the detailed explanations. Indeed my CDFS.VXD has product version 4.10.2222 and file version 4.10.1999; quite strange numbering scheme, if you ask me, but I recall quite a debate on this issue somewhere around so I'm not gonna dive into it now.

Regarding Q256576, I'm afraid the issue may be related but it's definitely not the same, since the Properties panel would show the very same 2.147.450.880 bytes size.

However, right now while typing this, I found out something really weird. Inserting a dual-layer DVD trying to reproduce the issue, I had a shock: the unique file contained on this DVD (an ISO image), sized 7.957.301.248 bytes made drive size appear as 7.770.810kB (in Total Commander - I never use Explorer). This DVD was burnt on an XP machine. File system: UDF.

After that, I inserted a movie DVD containing 2 folders and (beside other smaller files) four 1.073.709.056 bytes VOB files and the drive size showed 4.287.114 kB in TotCmd. This is an original printed DVD made in Holland. File system: UDF.

Then I inserted a DVD containing 2 folders holding a total of 195 avi and MP3 files, all up to over 4.3 GB. Drive size showed 2.097.120 kB. This DVD was burnt on an XP machine. File system: CDFS.

And then I inserted another DVD containing 4 folders with lots of files and few subfolders that would sum up to over 4.3 GB. What do you know - drive size: 2.097.120 kB. This DVD was burnt on my Win98SE machine. File system: CDFS.

All this leads me to a sole logic conclusion: the CDFS driver is erroneously used when reading DVD media, possibly related to number (and most likely size) of the contained files. The CDFS driver has a drive limit of 2GB. I still have no idea which driver is used for reading the 7GB dual-layer and the printed movie DVDs.

As for the patcher... at first I wanted to make it strictly for this task only. While working on it, I realized it would be a waste of time so I decided to try a universal patching approach. However this requires a lot of thinking, failsafe fallbacks, etc so it will take a while before I can come up with a safe version. And it may become a little complicated in the mean time. Here's a preview:

Sure. I agree it's not the same issue, since it affects a ToolTip and not the Properties Tab. But it is the only mention in the MSKB to the peculiar number 2,147,450,880, which, BTW, can be written [(2^31) - (2^15)]. Now this number seems appear as the upper limit, in some MSVC, MSVB and .NET implementations, for the Int32 C data type, instead of the correct [(2^31) -1] = 2,147,483,647 limit, as defined in the C standard. What crossed my mind is that both bugs probably arrise from the overflow of (MS implemented) Int32 variables, and, just in this general sense, they have a common origin.
But I was also imagining the CD/DVD bug would be higher up, probably in KRNL386.EXE or in Kernel32.DLL. In this you've just proven me wrong. It must lie inside CDFS.VxD, as you have now convincingly demonstrated.
I do confirm your findings. I grabbed a random commercial printed DVD (Hell Freezes Over, by The Eagles) and put it in the tray. As soon as it was mounted, the Properties Tab in Windows Explorer showed "6,519,816,192 bytes (6.07GB)", and "File System: UDF", which is correct (it is a Dual Layer DVD).
BTW, UDF, in Win 9x/ME, is implemented rather unusually: its driver is not at ...\IOSUBSYS\ as might be expected. It is UDF.VxD, which is part of VMM32.VxD in a plain vanilla installation, so it's not usually findable by a system search. But users of fully up-to-date Win 98SE can find it in %windir%\system\VMM32\ as the hotfix v. 4.10.2223 of UDF.VxD, which is installed by Q310695 ("DVD Player Program Cannot Access Data"). There is an equivalent hotfix (v. 4.90.3001) for Win ME. The Win ME version of Q310695 works OK in Win ME and can be ported to Win 98SE, but it does not work as expected with Win 98SE, as is usual for .VxDs from ...\VMM32\.
Good luck with the patcher! It can be pretty handy to have a windows based, .PAT driven, generic patcher. Count on me to test it from your earliest working versions.

This post has been edited by dencorso: Jan 3 2009, 11:10 PM

Thank you for confirming my findings. I'm not sure where exactly the bug is, but the bug itself is loading the CD driver for a DVD media that is not UDF. I haven't tried removing CDFS.VXD or replacing it with UDF.VXD for testing purposes.

Unfortunately, both testing and work on Replatcher (Replacer + Patcher) will have to be delayed, since my father just died and I have a lot of papers to take care of. As soon as settle this up, I'll get back to our business. Sorry for any inconvenience.

My condolences, Drugwash.

Well, it's not quite the CD driver, but the CDFS driver. So, it's just right to use it for a CDFS medium, be it a CD or a DVD. But, when the original CDFS driver was written, the programmer assumed no CDFS medium would ever be greater than 2 GiB, and that unfortunate assumption became a bug when CDFS DVDs became available.

Thank you.

I wonder why a 4.7GB DVD with a few 1GB files is written as UDF while a similar 4.7GB DVD with many smaller files is written as UDF. Maybe I'm not very focused right now.

I don't remember making any changes to option 3 scripts in a while, so it should work properly.
If you have 2 different versions of 98SE2ME laying around, please PM me with the O3*.BAT files [zipped] from the older edition, and I'll see what I can do.

Thanks.

dencorso:

Many thanks for your hard work [and to RetroOS for testing].

I'll take a look at the VXD files , and probably add them to 98SE2ME [soon].
I'm also considering an exe installer [iexpress].


Best wishes.

This post has been edited by MDGx: Feb 14 2009, 07:52 PM

AbyssHunted:

Thanks to dencorso, I took a look at older 98SE2ME option 3 batch files [*.BAT + *.INF] from Frebruary 2008, and compared them with the newest ones you have.
The only difference was O3WEB.BAT did not contain quotes for LFN folder names so DOS boxes can recognize LFNs properly, which I've fixed later on. This file does not affect option 3 explorer.exe in any way.
All other files are identical.
Therefore if you have used 98SE2ME option 3 within the past 12 months, option 3 files have never changed, and they should work properly on your computer(s).

Maybe there is something else you or some software setup did that messed up 98SE2ME option 3 installation, perhaps explorer.exe WinME version was replaced with Win98 SE version?
Because if WinME explorer.exe had been replaced with Win98 SE version, then your Windows OS would definitely lock up, and would need to have explorer.exe from WinME reinstalled in %windir% [usually C:\WINDOWS] from native DOS mode.

HTH

The version I had before was either 7-18-2007 or 8-27-2007. Pretty sure it was the 8-27-2007 one.

This post has been edited by AbyssHunted: Jan 13 2009, 06:50 PM

Can you please PM me with these files:

O3.BAT
O3DOS.BAT
O3RES.BAT
O3RES.INF
O3WEB.BAT

from the version [8-27-2007] you had problems with?
I'll take a look and post here findings.
Thanks.

BTW:
To my knowledge, the current 98SE2ME edition and all older editions from 2008 install 98SE2ME option 3 properly.

Also, please make sure you are using current [newest] versions/editions of all packs/updates you install, older ones might have bugs.

HTH

98SE2ME · UPDATED · 1-14-2009
______________________

1-14-2009
* Options 1 + 2: added modded WinME CDFS.VXD 4.90.3002 [from Q274175 hotfix],
CDTSD.VXD 4.90.3001, SMARTVSD.VXD 4.90.3001, SCSI1HLP.VXD 4.90.3001 +
VOLTRACK.VXD 4.90.3001 [%windir%\SYSTEM\IOSUBSYS]:
http://www.msfn.org/board/index.php?showto...6349&st=919
[thank you dencorso]
* Options 1 + 2: replaced WinME PPPMAC.VXD 4.90.3000 from WinME WIN_20.CAB
with newer PPPMAC.VXD 4.90.3002 from Q301453 hotfix [%windir%\SYSTEM]:
http://support.microsoft.com/?id=301453
[suggested by PROBLEMCHYLD]
CAUTION:
WinME PPPMAC.VXD 4.90.3002 is experimental!
In case of errors/lockups you can restore your original PPPMAC.VXD from
PPPMAC.ORI backup [created by installing option 1 or 2] found in
%windir%\SYSTEM [usually C:\WINDOWS\SYSTEM].

Enjoy.

Many thanks for your continuing hard work in keeping us updated MDGx! Much appreciated.

You're welcome.

@Drugwash: Well, seeing you're back to the forum, I believe now is the time to resume our unfinished discussion... CDFS and UDF are just two alternative filesystems. They are not, in themselves, neither good nor bad, and the choice of using one instead of the other falls on the one who burns the media. The choice is similar to FAT vs. NTFS: one can line up endless arguments either pro or against each filesystem but the issue is intrinsically unresolvable because neither is clearly better or worse, they are just different, and each has its fortes and also has weak points.
Having said this, I'd like to point out that CDFS was originally devised for data storage in CDs (because DVDs and latter media did not exist at that time) and is very well suited for that use, even when applied to DVDs or possibly Blu-Rays.
The original standard music CDs (from 1980 up to the present) use almost no filesystem at all, the Red Book standard being more of a mapping of the mechanical LP concepts onto the (then) new media (the CD). On the other hand, UDF was devised both for data storage and for Video storage, but with this latter use as the main object for its definition. So, while retail music CDs have just an embryonic filesystem, video DVDs are (AFAIK always) recorded using UDF, so as to permit the multiple features a commercial DVD usually exhibit. And, in what regards CDFS, at least in my view, it is the best choice for data storage optical media for almost all uses because it has widespread compatibility and is simpler. Then again, be warned that I favor FAT over NTFS for almost all uses also. The exception being if one *insists* on using files bigger than (4 GiB - 1 byte). Bear in mind that FAT and NTFS were devised for random access media, so using them on optical media entails a lot of useless overhead because these media are squential access only, no matter how fast. If you look closely at it CDFS is even simpler than the venerable CP/M filesystem, although, at the end of the day, both are little more than just a root directory and its bunch of files. And, IMHO, that's the beauty of it.