dencorso

Whatever card you decide upon, don't buy any having more than 256 MiB of RAM or you'll run into trouble with VCache and the DOS Boxes. Read posts #160 to #179 from this thread:NVidia drivers 82.69 for more info. HTH

Sorry to have taken so long to reply. Got far too many chestnuts in my plate to chew... All you need is to make sure you have ATTRIB.EXE (14.89 KiB) present in the floppy. I guess you've just shown it does I've done some tests with two different 500 MB external USB drives, a SAMSUNG HD501LJ (inside a Conceptronic Grab'n'Go CSM3PL500) and a IOMEGA HDS72505, both formatted as FAT-32, with 32 KiB clusters (15.2 million clusters). The FORMAT, FDISK, SCANDISK and SCANDSKW/DISKMAINT recomended in this thread work flawlessly. So does NDD (2002) for DOS. XXCOPY (32-bit, v. 2.96.5) also did a nice job in copying the contents of one of them (full to the brink) to the other, although it took just over 8h to finish. On the other hand ndd32.exe (v. 18.0.0.62, from NSW 2005) gives a nasty BSOD quite fast on either. It isn't able to tackle 15.2 millions of clusters. This is to add one more result to the excellent info provided by 98 Guy in the links in post #37.

Sure. Here.

You should use ViaSraid, not ViaMraid... Read these posts here ang grab it here. HTH

Yes, thats the version I have - is that the problem? I don't think so, sorry... It was a long shot, but if you hadn't it, then it might be the solution, after all Q310695 was entitled: DVD Player Program Cannot Access Data... Well, anyway, now we cannot have any more details about it anymore, not even through the WayBack Machine, so the name of the MSKB article is all that remains.Found a little more, so I reproduce it here, before it also disappears in the ether forever: It seems the hang mentioned above is a BSOD.So, it really doesn't resemble your problem, after all... Later edit: Found a way to retrieve the MS KB310695! The WayBackMachine had it all along, all right! Turns out I wasn't as through in my searching as I intended to be... But no, definitely your problem is not what's described there.

Are you using UDF.VxD 4.10.2223 (Q310695)?

Probably you can get your drive recognized by using NUSB. Do backup first. As for the file you're seaching, never heard of it, sorry. But don't do it because I said so. Read about NUSB first. It usually works with most mass storage devices, but I don't know for a fact that it specificaly works with your Iomega drive. YMMV.

Yes, you can. Even maybe a little higher. Read this carefully. The record at present is at 1173 MiB (RetroOS). Only by testing you'll know how far yo can go. But be prepared to reboot in plain DOS and change back the values in system.ini to the last know to work for you when the system begins to through errors or refuses to start windows.

I didn't know it also existed for Win 95... but I knew of Q216641 for Win 98FE. Turns out they are both versions of the same update. Win 98SE and ME don't have this issue... But, yes, of course you're right: they do mean 9x/ME can run for at least 50 days straight!

I don't usually let the system on. The longest I tried was 41 h, with a perfect shut-down at the end.

Hi, Fredledingue! Sorry, it's my bad... I forgot to mention that you need to change IO.SYS attributes before being able to replace it in DOS mode, AND did not recheck your batch file for it. So, let's spell it here: 1) run ATTRIB IO.SYS from the root directory and you'll see: SHR IO.SYS C:\IO.SYS ...this means that IO.SYS has the System, Hidden and Read-only attributes 2) now run ATTRIB -s -h -r IO.SYS from the root directory 3) run again ATTRIB IO.SYS from the root directory and you'll see: IO.SYS C:\IO.SYS ...this means that IO.SYS now has no attributes 4) replace IO.SYS 5) now run ATTRIB +s +h +r IO.SYS from the root directory 6) run again ATTRIB IO.SYS from the root directory and you'll see: SHR IO.SYS C:\IO.SYS ...this means that IO.SYS has again the System, Hidden and Read-only attributes Of course, you only need to add to the batch file step (2) before replacing IO.SYS and step (5) after it. It also means that you need to have ATTRIB.EXE present in the directory from which the batch file is run. Sorry. I've performed the substitution of IO.SYS from plain DOS so many times already that I forgot to mention you need to change the attributes, and then change them back... But it can be done from DOS, and it can be done with a batch file. Windows Explorer doesn't care much about the DOS file-attributes, but DOE does care. In what regards the attribution of the drive letters, DOS will give C: to the active primary partition in the first physical disk, then D: to the active primary partition in the second physical disk, then give the next letters to all drives in the extended partition of the first physical drive, then to those in the second physical drive (and then give letters to any inactive additonal primary partitions present in the first, then the second physical drives, in this order, when they exist).

I know that Vista SP1 uses Riched20.dll v. 5.31.23.1227 (467456 bytes). And that it comes from KB938194, to be specific. But all my searches were to no avail, when I tried to find out the version and size of Riched20.dll from the original Vista Gold (that is, without SP1). Can any of you help me please? And, BTW, do any of you know where to find any complete filelists from either Vista Gold or Vista SP1? Even if just with sizes and dates/times, but preferably with file versions? I always thought this ought to be an easy search, until I tried!

See the top post in the updates sticky... it's findable at MDGx's now.

There's useful info findable by folowwing the links in this post. HTH

You've got it: look at this post... HTH

OK. So much for that. Now I've got three different questions: 0)I understood you told us the problem only occurred with all 4 slots in use. Why not use 3 x 8 MiB? 1) If that works, using just the first three slots, can you use indifferently either two old sticks plus one newer stick, or one old stick and two newer? If so the problem is not the timings. If not, then it definitely is the timmings. 2) Using only the old sticks, can you work with any of these configurations: slots 1 used, 2 used, 3 free and 4 used or slots 1 used, 2 free, 3 used and 4 used, or else slots 1 free, 2 used, 3 used and 4 used? If all three cause you problems, it is the 4th slot that is defective...

Try using HIMEMX.EXE instead of HIMEM.SYS. If that doesn't solve your problem, try to use HIMEMX.EXE /MAX=20480 and see if it works (if it does, the problem is really too much memory, if not it may lie elsewhere...). For more on this idea, see also xRayeR on HIMEMX HTH

After you locate all of them, rename all but the one in %windir%\system to riched20.old and every program will use the newer version. The renaming is best done in DOS mode, from real DOS. Then again, any .dll that is not in use can be renamed from inside Windows, so, just after starting the system, you may search all the duplicate files and rename most of them from windows (right in the Find Files result window) and just go to DOS to rename the few, if any, that refuses to be renamed because of being in use. HTH

It can be demonstrated that Scandskw.exe depends on Dskmaint.dll, Shell.dll, KRNL386.EXE and USER.EXE, while Dskmaint.dll itself depends on Shell.dll, KRNL386.EXE, KEYBOARD.DRV and USER.EXE. All these dependencies can be satisfied with Win 98, Win 98SE or Win ME files. Of them, the only ones that you need to have from Win ME are Scandskw.exe and Dskmaint.dll, which are much improved form the 98SE ones. BTW, I've been discussing similar things also in this topic, which might be of interest to you all. I've used the DOS version of NDD.EXE (2002) since 2002, and it never gave me grief. Before that I had the 2000 version. I cannot say anything about the 2001 version, because I've never had it. I'm also very paranoid about backups, so that when things get really bad (cross-linked files, for instance) I usually delete the files and get them from the most up-to-date existing backup. Things too new to be in a backup can be gotten again from the same source I got them the first time, or were mine own, which I can always recreate. If I have no choice but to try to recover some file I first create a forensically sound image of the disk where the damaged file is, and then can try the recovery in as many ways as I can think of, because I can always restore the image and start again. For simpler tasks both SCANDISK and NDD are adequate, and NDD is usually faster and smarter, although I do remember that Marius'95's 1 TiB RAID was too much for NDD.

@jaclaz: PARTCOPY and GSAR! I didn't know either... great findings, jaclaz, great findings! Thanks a lot! @Fredledingue: I think the SCANFRAG update adds too much things to the system, in addition to the needed SCANDISK.EXE, so I seached some more and I just found an alternative source for it: the Win ME OEM bootdisk available at bootdisk.com (link)... instead of applying SCANFRAG just create the boot diskette and open the EBD.CAB it contains and extract the Win ME DOS SCANDISK.EXE from inside it. If, however, you decide to apply SCANFRAG, do it first and then apply BHDD30, in this order, just to remain on the safe side, because the dskmaint.dll in SCANFRAG is from Win 98, while the dskmaint.dll in BHDD30 is from Win ME (the one that must be used). You both rock!

NDD is far smarter than SCANDISK... See this comment by Joep van Steen (author of DiskPatch) in this page reprinted from the October 2003 issue of PC Update (link)... Of course, DiskPatch may also be an alternative (but is not for free). While NDD is not for free either, I know you already have it. Of course, in the quoted text, Joep is making his case as to why DiskPatch is more reliable than NDD, and in the process also tells why NDD is better than SCANDISK.It is also noteworthy that Symantec actually recomends using the DOS version of NDD, instead of the Win version, to perform the most low-level repairs:

Yes, it is! There are two versions of Win 98SE IO.SYS:IO.SYS 222390 04/23/1999 22:22 (Win 98SE original) IO.SYS 222670 12/01/2001 09:37 (Win 98SE Q311561) In fact, a short time ago, jaclaz found out there exists a further (unofficial) patch to the Q311561 IO.SYS, but for the moment I'm not recomending it, until I can give a closer look into it, to convince myself it's safe and works OK, which I'm meaning to do as soon as I get enough time for it. You can find out more about it here: Patched-IOSYS-for-98SE-and-ME As for extracting individual files from Q311561 (and from Q239696) you can do it simply by opening them inside WinRAR or 7-Zip. It's easier than what jaclaz proposed above, but requires that you have access to a second machine, already running any Windows, from 95A to Vista (or Linux). I don't know any DOS program able to do it directly, however, sorry! My idea was simply to start the batch using previously extracted files... BTW, provided you have booted the system from a different disk from the one in which you intend to replece the IO.SYS, I'm positive it is safe to do it in DOS mode. You can rename IO.SYS to, say, IO.OLD and add the new IO.SYS. It'll work fine, from Win 95 up to Win ME (DOS 7.00 to 8.00). This is not true, however, for DOS 6.22 or any earlier version (they required that IO.SYS and MSDOS.SYS be physically the first and second files in the disk, respectively, and also that their directory entries be the first and second entries, respectively, or else would refuse to boot... but that's in the past already, isn't it?).

Info on disk imaging programs (link)... The part of most interest to you now is "Partition Imagers"... HTH

Yes. Two. I'm sure you know this already, but just for the sake of future readers of this topic: (1) The IOS.VXD one should use is 4.10.2225 and is findable inside Gape's Unofficial Service Pack or inside Q239696. (2) The LLXX's patched ESDI_506.PDR that one should use is 4.10.2225, unless one has an IBM Laptop. And, BTW, great post: I'm sure it'll be of help for many users. You rock! PS: It's also a good idea to remind the reader that the IO.SYS from Q311561 (which you alreadey had given a pointer to) must be installed also to the HDD, not just to the floppy bootdisk. Of course it'll end there if the floppy is used to format/s the HDD. But perhaps your batch might install it to both the root dir and c:\windows\command\EBD, just in case. And since it is named winboot.98s inside Q311561, you'll need to rename it to IO.SYS, before doing the copies.

You'll have to grab the DOS version of scandisk.exe from Win ME from inside MDGx's package SCANFRAG (link), because only the windows version is present in BHDD30e.ZIP. But, of course, you don't need to actually install the SCANFRAG package (myself, I don't like both Win ME meconfig and regenv32, and stick to the older Win 98 msconfig), get it just to grab scandisk.exe from inside it. Update: SCANFRAG is no longer needed, get just BHDD31e.ZIP here, because it has everything needed inside. You can also run the DOS Norton Disk Doctor (from Norton Utilities 2002 rev..10E), findable in your Norton System Works 2004 disk. If you decide to make it run instead of SCANDISK.EXE on reboot after a crash, just copy NDD.EXE to \WINDOWS\COMMAND\ and rename it to SCANDISK.ALT (this is the official Microsoft way of doing it!) and that's it. I believe that both Win ME SCANDISK.EXE and NDD.EXE (2002 rev..10E), will work OK with all your partitions. I also think you'll find much interesting reading in this thread, too, although some of what is said there has already been said here: Problems-with-1-TB-RAID I think this is clear to you, Multibooter, but for the sake of those for whom this is still a confused issue, I think it's advisable to state this fact once more: SCANDISK, DEFRAG, CVT, NDD and (Norton) Speed Disk depend on partition size and their limit is the maximum FAT-32 size they can represent internally. LLXX's patched ESDI_506.PDR and VIASRAID.MPD deal with 48-bit access, and are dependent on total disk size: if all your PATA and SATA disks are smaller than 137 GB (=128 GiB), then you're on the safe side, if not you need them, regardless of the size of the partitions you use. For USB and Firewire disks, this problem doesn't exist.