Foxbat

That message comes to mind every time I ask someone to backup, only to see them return later saying that they haven't and all hell has broken loose. I think I should change my suggestive tone to a stern, raw and uncut mandatory order, that, if not followed, will cause the Earth to implode. Hey, it worked for hard drives and magnets. But joking aside, loblo's right that is will certainly lessen the service pack's user base at a time when the OS has lost most of its users. At the very least, this should raise a few eyebrows and spotlight a common problem, until the post becomes buried inside the biggest thread of the 9x forum.

Maybe we can stress this part a little more so even if everything else is ignored, just reading only the words in red will hopefully reduce the most frequently reoccurring problem. Before installing the Unofficial Windows 98SE service pack, please BACKUP YOUR DATA. This is not a suggestion. THIS IS MANDATORY. If you have not backed up and verified your data, DO NOT PROCEED UNTIL YOU BACKUP YOUR DATA. But, somehow, somewhere, someone will still ignore even this simple message. Edited for better fit.

No KernelEX. I have Revolutions Pack 9.7.2.

I did not experience any crashing in either scenario when starting ProcExp where IrfanView and RegCompact were already open or where IrfanView was already open. Version tested: RegCompact dated 2000-12-01 IrfanView 4.28 ProcExp 11.11

I also have a Sound Blaster Live! Value Gen II. When I tested the "Main Driver Set", I found that using the installer would cause installation problems. To avoid that, I simply went to Device Manager and pointed the sound card to the directory when I have the drivers extracted. I've examined a number of files from that MDGx's Sound Blaster page, but not all of them. I can tell you that you don't need either of those "Value" ISOs as they're the original CDs which are very outdated, and may be card specific (there are multiple SBLive! Values). There is a better way if you're looking to get full functionality from your card. Download the much more recent SB_Live!Ware_3.0_CD_ISO from that page. This is not card specific, so it should work with Gen I and Gen II cards, just not the Gen III 5.1 series. It will install the complete line of apps and drivers. You do not need the update that comes with it. After that, install RetroOS's package to update the core drivers using the method I mentioned above. If you decide to try this, report back if it worked for you.

Hu$tle, please lighten up. You're looking for problems where there isn't any. rloew posted this temporary solution at the request of PROBLEMCHYLD. It is complex, and he doesn't have to post it, yet he did in order to help those who can't wait for a better solution. Nowhere does it mention the purchase of his software. He is only making sure that users of his patches don't run into any issues. Those who have his patch will follow the indicated steps, and those who do not will skip it. If you do not like the current solution, give him more time to test and produce a better one.

I have not found the exact size where scanreg /opt will fail. Over the years, my occasional tests of system.dat of around 8MB or less optimizes successfully, and system.dat of around 12MB or more fails. By default, the registry automatically gets /opt'ed whenever scanreg detects 500KB of excess space (until it hits the size limit), so it looks like it's pretty well-tested.

Driver Cleaner Pro 1.5

Yes, scanreg /opt fails when the registry is around 8MB. RegCon also fails at this size. RegCompact seem to be only registry compressor that works where the other tools fail. Regdat can compare a live registry to individual .dat files. However, my attempts to check the compressed registries if there are any (unintentional) changes made by RegCompact in the previous thread failed. When compressing the registry, RegCompact flushes any pending registry changes to the compressed files, which makes sense since Windows is intended to be shut down after the compression. The very act of compressing the registry will modify it. Because of this, I could not get an unmodified compacted registry to compare to the original.

I did not encounter any problems when I tested the Italian version under US Win98SE. The localization only effects the UI text, although I think one should use a localized version only if it is in their native tongue. EDIT: My apologies, I did not see CharlotteTheHarlot's post #139 until my post went through.

I made an attempt to retest RegCompact by grabbing the files from C:\WINDOWS\TEMP this time instead of restarting. Using the CTRL+ALT+DEL task manager to end the task would cause RegCompact to restart the system. Process Explorer was able to end the task without restarting. RegShot can only compare live registry files or hiv files saved from a previous live registry, so Regdat was used instead, which can compare individual registry files to the live registry. Comparison of the compacted registry to the original showed that RegCompact saves all pending registry modifications prior to compacting (this is a good thing, just bad for comparison purposes). Without a pristine unmodified compacted registry (even the live registry periodically updates itself), file comparison is of little value. What is notable is the duplicate rename entry exists in WININIT.INI for the following four versions: RegCompact.exe dated 2000-10-18 [rename] C:\WINDOWS\SYSTEM\..\USER.DAT=C:\WINDOWS\TEMP\RC6356.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RC6355.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RC6355.TMP RegCompact.exe dated 2000-10-28 [rename] C:\WINDOWS\SYSTEM\..\USER.DAT=C:\WINDOWS\TEMP\RCA2A4.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RCA2A3.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RCA2A3.TMP RegCompact.exe dated 2000-11-18 [rename] C:\WINDOWS\SYSTEM\..\USER.DAT=C:\WINDOWS\TEMP\RCA0B2.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RCA0B1.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RCA0B1.TMP RegCompact.exe dated 2001-05-28 [rename] C:\WINDOWS\SYSTEM\..\USER.DAT=C:\WINDOWS\TEMP\RCF354.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RCF353.TMP C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RCF353.TMP This bug (if it is a bug) has not been fixed in these versions. EDIT: I was only able to test the four versions which have links available. The other two were not tested.

SpeedFan View SMART status, your system's temperatures, and control your fans. DriveSMART For IDE drives only. HDD Health Version 3 is reported to mess up a 98 system, even though 9x is listed as supported. I have not tested it, so I cannot confirm this. It is currently at version 4.2. DTemp This is the smallest, lightest and fastest of them all. Completely portable. Development stopped a decade ago.

i have tested RegCompact.exe dated 2000-11-18, and the most recent one, dated 2001-05-28. Windows normally make changes to the registry upon every startup, which complicates the test. This makes it difficult to determine if modifications were the actions of Windows or RegCompact. The important thing is that no keys were removed during the entire process, which helps preserve much of the structure. >> RegCompact.exe dated 2000-11-18 Before compacting: SYSTEM.DAT is 9,240,608 bytes USER.DAT is 1,736,736 bytes Within the UI, RegCompact reports the current registry size and predicted size after compacting: SYSTEM.DAT 9024KB --> 8628KB USER.DAT 1696KB --> 1200KB After compacting: SYSTEM.DAT is 8,835,104 bytes USER.DAT is 1,228,832 bytes Using RegShot 1.8.2 to compare the compacted registry to the original, there were a number of modifications, but no keys were removed. >> Original registry is restored for the next test, but startup modifies it as normal, so it is not the same registry as the first original, but structurally is very similar, and size is identical. >> RegCompact.exe dated 2001-05-28 Before compacting: SYSTEM.DAT is 9,240,608 bytes USER.DAT is 1,736,736 bytes Within the UI, RegCompact reports the current registry size and predicted size after compacting: SYSTEM.DAT 9024KB --> 8628KB USER.DAT 1696KB --> 1204KB After compacting: SYSTEM.DAT is 8,835,104 bytes USER.DAT is 1,237,024 bytes Using RegShot 1.8.2 to compare the compacted registry to the original, there were a number of modifications, but no keys were removed. >> Other than the compacted size of USER.DAT, I cannot determine if there were any functional differences between the two versions. What I can conclude is they both did their job without breaking the registry.

I ran the 2001 version of RegCompact.exe file without performing the compaction. It is also localized in Italian. The update could just be the localization, but we'll see. I will try to test and compare the results of two different versions tomorrow.

My controller card has arrived and I've been watching for data corruption this past week. The card has IDE, SATA, and eSATA ports (to take anything I can throw at it), with no BIOS (no boot delay). My SATA III 6Gb/s drive is connected to it and is running well so far. The SATA Caivar Black on the card has slower transfer rates (average ~20MB/s less) than the IDE Caivar Blue that is directly connected to my mobo. The loss in speed is probably due to PCI bus overhead, although this is much more preferable to USB2 any day. A drawback is I will have to baby the flimsy SATA connectors now since they're rated for 50 insertion/removal cycles (http://wdc.com/en/products/resources/drivecompatibility/). I often swap drives, so one of my SATA drives that I've bought just a few months ago is already 1/5 into the cycle count. This wasn't a problem when IDE was the standard. 512 byte sector drives are still widely available, but you're right. It will be a matter of time until all hard drives transition to 4K sectors. And here I am still dealing with Win9x... but I like it!

AAJB is Western Digital's current line of Caviar Blue IDE hard drives.

Keeping things simple would be the best option, so I tend to stick to lower capacity drives. Besides, I don't like having large FATs, or partitioning volumes that go all the way up to Z. Ah, I've read these threads back then, but forgotten about them as I was not considering SATA drives at that time. Thanks for the reminder. These days, theoretical speeds seem to double every time a new standard is announced, even though actual performance is still not much better than UATA. It required a paradigm shift to SSD to finally see a significant jump in speeds, yet it still hasn't fully utilized the available bandwidth.I double checked the SATA II 3Gb/s controller cards. It turned out to be sloppy data entry. They're not compatible with Win98SE. However, my limited experience in testing a SATA III 6Gb/s hard drive connected to a SATA I 1Gb/s port did not result in any problems. Googling around, I was able to pull up some anecdotal reports that it might have been the early SATA I 1Gb/s controllers that has this compatibility problem. It may still depend on the controller though.

Do you have any boot drives running with the card?

I found this entry on Wikipedia under the SATA article: "... The Force 150 switch is also useful when attaching SATA 300 hard drives on SATA controllers on PCI cards, since many of these controllers (such as the Silicon Images chips) will run at SATA300 even though the PCI bus cannot even reach SATA150 speeds. This can cause data corruption in operating systems that do not specifically test for this condition and limit the disk transfer speed." This is pretty disconcerting as would like to to jumper my SATA III 6Gb/s drive to work with a SATA II 3Gb/s card. Moving to a SATA I 1.5Gb/s card will mean no SATA III 6Gb/s drive support. It seems I may have to buy older SATA II 3Gb/s drives which oddly cost more than than their SATA III 6Gb/s counterparts probably due to the beginning of the phase out stage. I can no longer find any Caviar Black SATA II 3Gb/s drives, and the Blues and Greens are reducing in number, for example. However, there are no sources cited to support the Wikipedia statement. Certainly doesn't make it any easier though.

I am planning to buy new hard drives and a controller card, but I haven't decided on whether to go with a used Promise IDE controller card, or one of those IDE/SATA combo cards that claim to have Windows 98SE driver support. Newegg is currently having a sale on controller cards and Western Digital hard drives, so it looks like a good time to buy. Here is a list of cards using the search term "Windows 98SE": http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100007607&IsNodeId=1&srchInDesc=windows%2098se&page=1&bop=And&ActiveSearchResult=True&Order=PRICE&PageSize=20 Here is a list of cards using the search term "Windows 98": http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100007607&IsNodeId=1&srchInDesc=windows%2098&page=1&bop=And&ActiveSearchResult=True&Order=PRICE&PageSize=20 I had to search twice to show all available supported cards. In these results, there are IDE cards, SATA cards, and IDE/SATA combos. Some of these are so cheap that they do not contain a BIOS (I won't be booting from the card). Maybe these cards do not cause a boot delay? I am surprised to see eSATA and SATAII 3Gb/s supporting Win98SE (running at 133MB/s PCI speeds of course). I though these didn't exist for Win98SE? The SATAII 3Gb/s cards may be useful as I have a SATAIII 6Gb/s hard drive and I'd like to use that with my Win98SE system (it's currently in a slow USB2 external enclosure). Now which route should I go? Going the IDE route would be safer, and staying with all IDE drives will allow me to also have the option of plugging them into my mobo. There's a cost though. IDE drives are close to being phased out; it won't be long until reliable sources run out. Additionally, I could be stuck with many legacy drives when I move on. Going IDE/SATA route would allow me to use both (or just go with SATA only), and I can continue to use the SATA drives when I migrate to a new system. Of course, the slightly faster SATA speeds will not be realized as the the interface is still PCI. Also, SATA seem to be spotty from what I've read around here, so there may problems down the road. Are there caveats to using SATA hard drives on controller cards with Win98SE driver support? Edited for typo

PROBLEMCHYLD's Unofficial Windows 98 Second Edition Service Pack 3.4 (formerly Gape's) is what you need. This is the most recent, and the most complete. It is configurable. Just check off only what you want. Make sure you do some reading and understand the service pack before installing. And as always, BACKUP your data first.

The slot setup presents some very unique airflow characteristics, peferct for tweaking around. It seems you weren't with satisfied with the thermal performance. Now using the drive cage as a duct, and isolating the fan with foam. Have you isolated the exaust and PSU fan as well? The large intake grill holes look very airflow friendly, and certainly helps with the appearance than a complete open front. Let's examine the top portion of the case. Generally, straight-through airflow would be ideal, but under this challenging setup there are many twists and turns. Airflow from the front may take the following paths: -hit the RAM and the pocket of air from the HSF. -flow through above the HS and meet with the vertically moving air along the slotcket wall, then turn towards the PSU, but contributing to cooling for the slotcket. -flow around the HS, get sucked into the HS cooling the CPU, hit the motherboard and RAM, cooling a part of it, with some of that moving towards the slotcket wall, and others becoming recirculated air. With half the HS overhanging the mobo, air from that half would hit the case wall and wires, ending up as a pocket of air that impedes some incoming air from the front. Your latest modification brings in some ambient air to the CPU, but it has to make many 90º turns along the way with Lots of back pressure. The high static pressure fan will certainly help to push air around those obstacles. Now this is interesting. I've vaguely heard of mounting a cone to a fan before. This is the first time I've seen it in use. It could help reduce some back pressure. What is the thermal performance so far? Does the cone mod contribute to any perceivable improvement?

I see the thermal performance of the case is much improved. You've cut out the rear grill, modded a hole towards the bottom front of the case, added vented drive covers, and pointed the CPU heatsink fan to blow into the motherboard. All the fans appear to be moderately slow fans though. The slotcket looks like a solid windproof wall, preventing horizontal airflow and creating a pocket of heated air underneath the heastsink fan. The PSU should help facilitate vertical airflow along the wall, but on the other side of it, the exhaust fan could be fighting with the PSU fan, perhaps breaking up the flow. I wouldn't imagine an overclocked 440BX producing much heat, unlike todays systems where TDP can exceed 400 watts or more, so it's probably running comfortably. I'm amazed that a slot board with a slotcket and a Tualatin can outperform a P4 running natively. Makes me wonder if I should try to find an FCPGA2 Tualatin adapter for my 815 board... but then I might as well buy a whole mobo instead.

Wow. You managed to run a Tualatin on an old 440BX. Not even my newer 815 can do that. Coppermine is as far as it can go. How much performance overhead is lost to the slotcket? Does it actually run as fast as a native 1GHz Coppermine or better?

Your Processor is 200 MHz, but your FSB (Front Side Bus) is probably 66 MHz. As of now, there are two possibilities. You are using the wrong speed RAM, or your motherboard is busted. You will need PC66 or PC100 RAM. What speed RAM are you using?