dencorso

I doubt that Windows 9X SATA-Raid drivers are available for many of the newer motherboards. I also found that in at least one motherboard, using SATA-Raid mode disabled my Adaptec SCSI Card from booting. I agree that IDE Compatability mode is more complicated. I had to write a Patch and .INF file to make it work properly, but it works on my newest motherboards. I'm not sure what VIA Driver you are using, but the 2003 Miniport Driver has a bug in it. You wouldn't see it since you are using a WD Drive. What .mpd are you referring to? Is it this one:http://downloads.viaarena.com/drivers/RAID...alATA_V220E.zip? If so, can you describe the bug in more detail, please? Why does it depend on the HDD manufacturer to manifest itself?And, yes, I do agree that most of today's boards don't have any SATA drivers. I think, BTW, that the chipset in wsxedcrfv's board is the very last VIA chipset that works with the .mpd I've just pointed to. Also BTW, does your SATA patch to esdi_506.pdr work with the LLXX patched .pdrs? It'd be nice if it did. You've mentioned before your SATA.INF alone suffices for the ECS GeForce6100SM-M2. Is it true for all nForce4 boards or just a special case?

It's possible to send me this file?Here is a direct download Microsoft link for v. 1.5.723.1, which is older but should also work OK: GenuineCheck

@Tihiy: Supposedly, you can also go to HKEY_CURRENT_USER/Control Panel/Desktop/ and create the string value USERMaxHeapSize there, to control the max 32-bit USER heap size. While USERMaxHeapSize indeed exists inside USER.EXE, what I always found strange is: (i) why the control for USER is inside the registry, while the one for GDI is at WIN.INI?; (ii) why is it a string and not a DWORD or binary value? (iii) why WIN.INI instead of SYSTEM.INI? It occurs to me that they may be alternative places, and that using both in the indicated place at the resgistry or both in WIN.INI would work the same, but, if so, why? Moreover, why, before you mentioned it, I'd only found these settings in french sites, which apparently cite one another (this one, for instance)? I know, I know... that's too many questions! But I just wasn't able to resist posing you them since you wrote about GDIMaxHeapSize. And, yes, yes, yes! You can count on me too to alpha/beta test, whenever you want it. @Drugwash: Have you given Miranda up? I see you've purged it from your sinature too! What happened?

Dave, you're right: VWin32.VxD is packed inside the VMM32.VxD. Since you use Win 98SE, it can only be v. 4.10.2222, there is no other choice, becuse the versions for 98FE and for ME would not work with the 98SE VMM.VxD. So, no, there is no need to check. I studied the motherboard manual and mused about it for a long time, and I see no feasible way to underclock the RAM without also underclocking the processor, in your particular case. So, my initial suggestion is not a viable potential solution to pursue. Sorry! As for the MSKB solution, it's quite easy to do and undo, so you might explore it more than I did. I checked my records and my cooment at the time was "cripples DirectDraw". But I had set Hardware Acceleration to "None", as per Microsoft's advice. Yet, the setting is a slider so, perhaps, there may be an intermediate setting that does not affect DirectDraw and stops the BSODs. I think it's worth investigating. You can easily test DirectDraw, using the DXDiag.exe utility included in DirectX, after each new setting. Good luck!

I've done some tests with SCANDKSW (the SCANDISK from Win ME) and reported here that it works OK with 26.4 million clusters (26,389,392 clusters), but throws the infamous "ScanDisk could not continue because your computer does not have enough available memory. If any other programs are running, quit one or more of them, and then try running ScanDisk again." message with 26.6 million clusters (26,588,648 clusters). You are the first, AFAIK, to determine the limits For the DOS SCANDISK. Thanks for the great info! BTW, from the way you wrote it it seems to me that the limit for SCANDSKW and DEFRAG are one and the same, what makes me think it must lie inside DISKMAINT.DLL. Is that right?

Bug: CDFS DVD Appears to be 2,147,450,880 Bytes if the True Size is Over 2 GiB, *Solved at Last*! This Win 9x/ME bug has been with us since the begining and Microsoft never took the time to fix it: there is no official hotfix for it and it's not even mentioned in MSKB. If you don't know what I'm talking about, just put any CDFS DVD having more than 2 GiB data into your DVD drive and, after the drive becomes ready, go to Windows Explorer, highlight that drive, right-click on the Properties tab and look at the reported DVD size. But the issue is not limited to Windows Explorer, you can see it in Total Commander, too... in fact any program using the GetDiskFreeSpaceEX API will display the same bug. Last year, Drugwash started a sub-thread about it, inside the 98SE2ME thread, and we discussed it in depth (to read it all, start at posts #923-931, then proceed through #940-948 to posts #952-955). These posts led RLoew to devise a patch, which he decided to release as freeware (many thanks, you rock! ), which fixes that bug for good. And the patcher he created for applying the patch is an inteligent one, able to recognize and patch correctly CDFS.VXD v. 4.10.1998; v. 4.10.1999; v. 4.90.3000; v. 4.90.3001 and v. 4.90.3002! So all possible variants for Win 98FE, Win 98SE and Win ME are covered by his patch. At that point, Drugwash and RetroOS (thanks to both of you, too, you rock! ) agreed to join me in testing the experimental patch for three months, and we found out it works perfectly and is harmless to the system. Now RLoew has released it, so it's available for all! To get it, go to RLoew's Homepage, then to the "Prerelease and Beta Software" page, and there you'll find the CDFS Patch download link. After downloading the package, unzip it and follow intructions in the Readme.txt to apply the patch. One more Win 98/ME bug bites the ground!

Sfor, try to use eeectl and set the fan to 100%, while connected to AC power (or else it'll consume the battery charge quite fast). It may help. As far as I can establish, there are no missing dependencies for eeectl, so it probably run on Win 9x/ME, although it is not documented. Don't forget to set the fan back to native, before going back to battery power, though.

In case NUSB 3.3 doesn't work for you (but did you give it a try?), you have the Wintricks driver pack (the download link is on page #6) or RLoew's pack (the download link is on the Prerelease and Beta Software page), both free and both derived from the same Lexar drives. And there is the Win 2k USB 2.0 drivers for 9x/ME (direct download). I'd install USB 3.3 and if it gave me grief, just uninstall its (Win ME) USB 2.0 drivers from the Add/Remove software dialog and then add the Win 2k drivers. If that also doesn't work I'd restore a previously saved full system image to remove all traces of this installation and install one of the lexar derived drivers with the Win 2k USB 2.0 stack. Only if even that doesn't work I'd then just use either NUSB 3.3 without the USB 2.0 stack or one of the Lexar derived drivers stand alone. But without a USB 2.0 stack USB is not very useful, is it?

Those files are from NSW Premier 2005. What I do is a custom, very trimmed, install of NSW 2003 and then update the files related to Windoctor and NDD32 by hand up to v. 18. Queue has shown that up to v. 19 NU files work with 9x/ME, but neither he nor I do know whether the installer actually also works because he also updates by hand from a lower version. The premier 2005 is the highest version I own, so I'm meaning to install it on one of my XP machines as soon as I have time, to be able to apply the updates pointed to by RetroOS, so I can get up to v. 18.0.3.11. Read more about all this here (it's the selfsame thread I had already pointed to in my previous post, read it all, it's worth it). BTW, to decide which files I must update for Windoctor and NDD32, what I do is to trace them with Dependency Walker v. 2.2.6000 and jot down the list of dependencies found. Incidentally, Symantec Ghost 11.0.2.1573 is the latest version able to work with 9x/ME, but also has to be installed by hand (it has the downside that you can't buy less than 5 licences, because it's part of the corporate Symantec Ghost Solution Suite 2.0, but I do have 5 computers under my daily care, so it serves me just right).

Since you asked, Dave, I do know what the numbers mean... they mean the error occurred at Object #5 in VWin32.VxD, at offset 0x119E from the start of that object's segment. Now, looking at the VWin32.VxD Object Table we can determine that Object #5 is a PCOD Segment, that is, it contains Pageable Code. At that point in the code a Call to the service #1 of "device 0002" (and here the word device means just another .VxD). Now, "device 0002" is Debug.VxD (cf. here), which naturally is not linked (that's why the call failed) because you are not running a debug version of Win 98SE. VWin32.VxD v. 4.10.2222 is a solid .VxD and has no known bugs. So something very unusual happened for it to call Debug. That something is probably a transient memory failure. I have experienced that precise haphazard BSOD in my system, from the time I upgraded my motherboard's memory from 2 GiB to 3 GiB, to the day I underclocked the RAM some more. The RAM underclocking solved that issue permanently. And yes, I just looked up the manual for the X5DAE and there seems to be no seeting in the BIOS to control the RAM FSB frequency. Unless it's bundled to the Processor "Frequency Ratio". Get in BIOS and change no settings for now, but look up what options exactly are offered under "Advanced" -> "Advanced Processor Options" -> "Frequency Ratio" and tell me. It may be hidden there, but it's quite a long shot. On the other hand, if you set the Hardware Acceleration slider to the None setting as recommended in the MSKB I pointed to in my previous post, you'll also get rid of that BSOD, but, if I remember right, part of DirectX also stops working. I fear there may be no solution to that issue for your specific board, however. Sorry! BTW, how did you get the screenshot of the BSOD? Did you take a digital picture of it?

Of course it'll work, but much slower, since you've not got DMA. What CharlotteTheHarlot is saying amounts to this: there are 5 PCI slots and you're using just two cards, so move both cards out of their present slots to any of the now unused slots, taking care to let both the presently used slots unused, and see whether this solves your issue.

Hi, Dave! It's a video memory problem, see Q302824 or, in my experience, can mean also FSB too high (no matter what the manufacturer of the mobo or the RAM claims). I suggest you lower the memory frequency (say from DDR2 800 to 667) in BIOS, while allowing the processor to remain at the same frequency (i.e.: set the FSB at the RAM side to less than 1:1). Many boards allow you to do this. If you indicate to me which board you're using (is it the one on the list?) I can look its manual up and give you more specific instructions. It is a RAM related BSOD, nevertheless. And, yes, I'm suggesting to underclock the RAM. Lowering the Video RAM acceleration prevents you from using DirectX to its full extent, while lowering the RAM FSB has no perceptible overall perfoemance penalty, no matter what people say to the contrary. Win 9x/ME is more sensitive to this than are the NT-family OSes. And it only happens to people with lots of RAM onboard. Good luck!

Well, the main reason for it is that, at some point in time, Microsoft determined that 2,097.152 (a.k.a. 2 MiB) clusters is the best compromise between wasted slack-space build-up and speed. With 32 kiB clusters this means 64 GiB. Yet, in the present, our hardware is much better than that used back then, so the size of the FAT-32 array or the number of clusters are of much less concern now, in what regards speed. So the real limit is where the software tools we're used to work with break. The DOS programs NDD (from NU 2002), SCANDISK, FORMAT & FDISK (from DOS 8, i. e. the DOS part of Win ME) are known to work ok with FAT-32 disks up to 500 GB. The Windows programs are the limit, IMHO: SCANDKSW (from Win ME) works OK up to 26.4 million clusters (26,389,392 clusters), while NDD32 (v. 18.0.0.62, from NSW 2005, or higher) works OK up to 7.8 million clusters (7,813,813 clusters). That's where I set my personal limit: 7,813,813 * 32 KiB = 238 GiB. With smaller partitions I usually use the (NT-family only) fat32format.exe to change the default cluster to a smaller value, usually half the default, while keeping the total number of clusters at 6 million or less. I have been doing this since I found about fat32format (in 2007), and never had any problem because of this, neither on Win 98Se nor on Win XP. For a more extensive discussion of the numbers I used here one may refer to the hdd size limits? thread and the links provided therein. While I'm fully aware that this is a matter where YMMV, 32 GiB is way too little for FAT-32, whatever arguments one might wish to use to defend it. Microsoft did that to push people into its proprietary, extensively undocumented, NTFS (which is a good file system also, but is far from being *THE SOLUTION* ). BTW, I've never had any success with using the undocumented /Z switch to force the DOS FORMAT to use the cluster size I wanted it to use. So I think that if someone has the time for it, a port of fat32format (which is open source) to Win 9x/ME is quite welcome and timely.

Try this link: ftp://files.3dnews.ru/pub/drivers/DCProSetup_15.zip I've just downloaded the file from this Russian ftp and confirmed it's identical to the one I have in my back-ups. So it's the same file from which I've installed the copy still present in my system. It is 2,817,354 bytes long and has fc700ec7523754fbfaed4291945a05f0 as its MD5 hash.

You're right! The shutdown issue with the 82.69 drivers is a well-known bug of the driver itself, and cannot be related to your patch in any way, because it happens for many users of that driver, even for older boards with much less RAM. Your beta tester should try the nVidia drivers 77.72. Multibooter says it's the latest bug-free driver for 9x/ME. And he uses it with a nVIDIA 7800 GS OC (256 MiB; AGP 8x). But tell your beta tester not to remove the nVidia drivers with add/remove or unistall, but, instead, using the great freeware Driver Cleaner Pro Version 1.5 (*NOT* Driver Cleaner .NET !!!). Version 1.5 supports Win 9x/ME, despite that not being explicit in the on-site information. The Add/Remove applet or nVidia's own uninstallers don't do quite a perfect job in removing previous nVidia drivers, only Driver Cleaner Pro is able to remove them completely. I consider this the safest way to test nVidia drivers.

Well, Kwibus, I glad you agreed to start this topic! What you learned in the process of getting your system to work is precious and ought to be shared with all Win 9x/ME users. You rock! Moreover, your experience with the Win 2k drivers in Win 98SE can very well result in some much needed Unofficial drivers for nForce4 motherbords, which can be of help for many other users. Some of our members are very skilled in the creation of automated installers, so that once those drivers that work are known, and what is needed to do to install them is described, an unofficial pack can be created. And we help extend some more the life of our beloved 9x/ME systems. I hope to be able to contribute more effectively to it in the next few months, because I have an ECS GeForce6100M-M2 V. 1.0A motherboard (which heart is a MCP61S, a combined GeForce6100/nForce405 in one chipset) which I'm meaning to install for a long time, now, and I believe I'll find time to do it, at last, in the next few months. This can be easily established for sure, without ever opening the case! Download and install the latest CPU-Z and run it. It will tell you how much memory the system has, how many sticks are in it, how big each stick is and (sometimes) even the stick's brand name. I have two comments here:i)You've used a much more complicated procedure than need be to solve this issue. You could instead have simply edited the config.sys with edit, in dos mode, at the time you edited the system.ini It would be enough to add a "REM " to the beginning of the offending line, so that it became: REM device=C:\WINDOWS\COMMAND\display.sys con=(ega,,1) and the line will be ignored, during IO.SYS processing of the config.sys. ii)To understand what that command was meant to do, in case it worked right, you should consult the great MS-Dos7 Commands online manual (now only available thanks to the good old Wayback Machine!). It's the best command reference for DOS to ever be available on the net, and yet it is very little known.

I agree with duffy98 and gkar. I only wish to add that after the three MDCUs I always also add NUSB. While not exacly an update, it's a must. After that I, too, create a Ghost image and that's that.

Then you're on the safe side. You are using LLXX original mod. The one by Maximus-Decim in BHDD31e is the same (v. 4.10.2225) with the version number changed. The reason for it is a long old story, better forgotten, but both solve the > 137 GB issue all right. Yes, if you have time for it, a step by step guide can be of help to many users, especially nowadays, when almost every board has no Win 9x/ME drivers anymore. It'd be a start-point even for those using different motherboards, because the concept of how to do it is genaral. You should open a new thread for your tutorial, for it to have the right visibility, too. Keep on the great work! You rock!

For those who have at least 512 MiB or more RAM to spare, setting up a RAM disk and then pointing TEMP; TMP; Temporary Internet Files; Cookies; History and the java temporary files to the RAM disk is a good and reliable way to get rid of the junk resulting from Internet navigation with every reboot. The only downside is if and when one decides to download files bigger than the RAM disk, because then IE will fail silently, pretending it finished the download, but, of course, yielding a truncated file. There are several workarounds for this problem, ranging from temporarily setting the Temporary Internet Files elsewhwere, just for that download, and then setting it back to the RAM disk, to using FlashGet or some other download manager for the files bigger than the RAM disk. With plenty of RAM to spare, a 1.5 GiB RAM disk (my current option) makes even this small annoyance quite rare. It's painless, it's transparent and works like clockwork, provided one reboots regularly, as in shuting down the machine every day, at least during the time one'll be asleep. Of course, it's not as useful for a machine that will be running P2P all the time, but, even then, a reboot usually is required every 48h or less, and that will do fine. And anyone who is able to spend the money needed to get 1.5 GiB or more RAM needed to adopt this strategy should consider spending US$10 more to get the excellent RLoew's non-XMS RAM disk, which is invisible to Win 9x/ME and leads to the most stable possible configuration with a RAM disk (for more on problems arrising from using very big RAM disks esp. with XMSDSK, refer to my > 1 GiB thread, for which there is a link on my signature).

300GiB PATA HDD with the default generic ide disk type 47??? You **NEED** to install LLXX's patched esdi_506.pdr, post haste, else you're heading towards a **BIG** HDD crash! Follow the link for > 137 GB HDD in my signature, get and install BHDD31e, before it's too late! BTW, congratulations: you've solved some pretty difficult driver problems by using Win 2k drivers. How did you install them? By hand, using the .infs grabbed from a Win 2k installation, perhaps? P.S.: Are you running Win98FE or Win98SE?

Try substituting the normal ntdetect.com by Dietmar's patched version. You can find it here or here. And just for you to be sure everything is OK, Dietmar's ntdetect.com MD5 is 42e5d3d11ef0d8ce52175727d581bc14

You're using the wrong keboard setting. Your system must be set to "United States - International", whereas it ought to be just "US". Right-click on the Language Band, but not over the "EN" and select "Settings...": you'll see a window called "Task Services and Input Languages". Inside it highlight "United States - International", under "Keyboard", select "Add", scroll the listbox, select "US" and click "OK". A second keybord will have been added, but it is not the default just yet. Now highlight again "United States - International" and click "Remove". Not only "United States - International" is removed, but also the "US" you just added changes to bold type, because now it has become the default (and only) keyboard for the "EN" language. Now click "OK", and the "Task Services and Input Languages" window will close. At this point your problem should be solved. Good luck!

If such a board exists, I'd select an AM2 board having a Via chipset, because, then, there wouldn't be any driver problem, as all needed VIA drivers, including SATA and LAN, are well known and available. The big question is: does such a board exist?

Well, while not AM2+, RLoew (1) at the Day-to-day running Win 9x/ME with more than 1 GiB RAM thread, post #2, is a Socket AM2 machine with nVidia chipset, which is almost, although not quite, the same thing. And it already lacked drivers, but does run Win 98SE. For a multiboot machine I think it's good enough.

Read this carefully: Ngine.de - How to install and run a FULL Windows XP from a USB drive