severach

You don't need to run SFC /SCANNOW. Simply delete one of the files out of the SYSTEM32 folder. WFP will either replace it with the one in dllcache or it will consider both bad and beg for the CD. An easier way is to use KeyUpdateTool.EXE from Microsoft. You don't need to change the key, you only need to watch to see that the files don't fail WinTrust. KeyUpdateTool.1.3.278.1 KeyUpdateTool.1.5.530.0 KeyUpdateTool.1.5.707.0 Current Version I'd like to see OEMSCAN report only, and copy the files from user confirmation.

Google "NtLockRegistryKey Inside the WPA-CALL" You'll need to read it out of the Google cache unless you can find the current AntiWPA site.

One reason is that OEMBIOS.BIN is the only of the 4 files that contains no information at all. It is the only one that is easily made all the same if there was a need. It is unfortunate that I chose it simply because it was the largest hoping it would be the most valuable. This project is still in it's infancy so the base CRC is still easy to change.

We have company! Can we get a link, text improvements, and updates to the new CRC's? It's best if we all stick to the same CRC scheme. http://forums.onforce.com/viewtopic.php?t=9997

Many of your DEBUG lines won't provide valid results. Command 'S' is case sensitive. The SLP string 'HP PAVILION' may be in all caps but the BIOS contents is not. You'll do much better with: S F000:0000 FFFF "HP Pavilion"

The SLP key embedded in the CD will only preactivate if the OEMBIOS set matches. It will never activate over the Internet or by phone. If you see the activation keys, the activation screen, the key screen, or the Genuine Star, you've messed up somewhere. The key affixed to the case will activate but only after you beg Microsoft with a phone call. If you do everything right, you'll never use either key nor will you ever see any activation or key screens. Not every manufacturer uses WINNT.SIF but Dell does. This means you can construct a Home OEM cd for another Royalty system by changing the key in WINNT.SIF and overwrite the OEMBIOS.* files. The only drawback is that the Dell disk will include a few Dell only drivers that won't apply to your target system. For your convenience, you should obtain a trustable n-in-1 XP CD, find the complete OEM distributions on them, and learn which and how to modify the remaining non OEM distributions to make them OEM. The SLP strings are not the least bit similar. There are many indications that HP is an OEM that does nothing more than insert the SLP String into Manufacturer field of the DMI so there's no reason to believe that they would always sprinkle Hewlett, Packard, or Compaq anywhere else. This is also the OEMBIOS set that HP & Compaq are using for all their Desktops and some laptops from 2005-.

You lose any bundled OEM drivers when you build your own OEM install disk from the Microsoft Original. If you want the same install convenience without suffering with outdated crap drivers, you should check this project out. http://forum.driverpacks.net/

When it's done. It will get done faster if you help. You can do this right now. There is a similar MSFN thread that shows how to make proper SLP CD's from stuff you already have that will install as good and better than factory. Reread here until you find it. When you get good at building and applying those install CD's, you can help this project along.

This looks good for validating OEMBIOS.BIN files but it's not doing a very good job at producing the Manufacturer strings that are known to work.

This may be true on occasion but is not true in general. Dell has at least 3 OEMBIOS packs. This is how I name them with the CRC-32 of the OEMBIOS.BIN file in the name. Any CD's I generate also have both the SLP and the CRC32 printed on them. Noobs use the SLP+Nickname and I use the CRC32 to know what the coverage is. Dell-0C706A10-Inspiron1000(SiS-2200Mhz) Dell-263CE3FB-Common Dell-5D93572F-New Common covers most systems up to Pentium 4 2.5Ghz. New covers most systems from 2.0Ghz and beyond. Neither New nor Common would preactivate on the Inspiron and there are many >2.0Ghz machines that will preactivate with New but not not with Common. The two on RapidShare are. Putting the CRC32 or MD5 in the name or description would allow you and all the rest of us to identify the dups. I'm using CRC32 myself because it keeps the names shorter and is sufficient until MS decides to generate OEMBIOS.BIN files that have different contents but the same CRC's. They won't do that even when baited because the switch to MD5 or better is trivial.

Did you use the HEDY Pro Key instead of the Home Key? Did you install Pro and Home on two different computers? The reason is that up to 2005, most manufacturers had a single OEMBIOS.* file set for their entire line, and perhaps an extra one here or there for a wierdo model. Now some manufacturers are intentionally creating new OEMBIOS.* sets to distinguish XP product lines. You may be mistakenly thinking that your HEDY OEMBIOS set is good for all HEDY's when in it may only cover a limited set. Check the PIDs of your Product Keys to ensure they are HEDY's Royalty OEM? Hedy: XXXXX-OEM-0011903-00166

>discountpc: Sry, I was under the impression that it wasn't legit to use say a HP SLP Key on a Non-HP System... or maybe I'm mistaken..... We can't be certain whether or not it's legit but I'd say not because every Royalty OEM including HP and Compaq is given different key even though it wasn't ever necessary. Mismatch keys as desired for personal experimentation but I wouldn't deploy anything wide scale or Microsoft will catch on and WGA them.

I had found Mr Loew's patch to enable 48 bit LBA in Windows 98 but I had a suspicion that Mr Loew was not a person I would want anything to do with. Mr Loew's hostile posts here affirm my suspicion and I anxiously await an independant solution from a more amicable author. I eventually solved the 48 bit LBA problem in my own crude way. All I did was to remove ESDI_506.PDR from IOSUBSYS which puts C: into compatibility mode paging then 48 bit LBA support gets inherited from the BIOS. The performance is low but I get long file name support on 48 bit LBA drives. I wasn't trying to win any speed races, I just wanted the ability to move, rename, and perform minimal data recovery on big FAT32 drives from Windows 98. USB drives are not limited by Windows 9x to 137GB. >137GB drives will not function properly in in older non 48 bit LBA compatible enclosures. Enclosures that are 48 bit LBA compatible are usually labeled as compatible with the largest shipping drive size at the time the advertizing is printed, some size far above 137GB. 48 bit LBA detection has not been perfected between drive manufacturers and chipsets. In rare cases, the enclosure or motherboard chipset will fail to detect more than 137GB. When this occurs you'll expect to see some folders and files scrambled. Any use of SCANDISK or AUTOCHK or CHKDSK in this condition will promptly trash much data. This has been noted with: Western Digital PATA + ALI Enclosure Western Digital PATA + VIA based Motherboard In Windows 2000 & XP, the big drive patch solves this problem. If the motherboard fails to detect >137GB, the 2K/XP PATA IDE driver will do so instead. AUTOCHK runs after the IDE driver detects 48 bit LBA. Misbehaving external drive enclosures need to be powered off and on until 48 bit LBA gets detected properly. I enable the big drive patch on ALL systems so I no longer see this problem in motherboard chipsets. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters] "EnableBigLba"=dword:00000001 Rumor has it that XP SP2 slipstream is the first Windows installer that is 48 bit LBA ready. You may install a lower OS as long as the drive is empty so that the initial CHKDSK has no files above 137GB to destroy and all the install files are certain to show up below 137GB until the big drive patch can be enabled after which your system will function properly no matter where most files are placed. This also means that you can't reinstall a lower OS on a partly filled drive because the risk is too great that files will be allocated above 137GB during the install. Due to much data loss, I have found it best to stick with 120GB or less drives for booting. Installers will not damage >137GB data drives as long as you don't try to install to them. Windows 2000 SP4 slipstream is NOT 48 bit LBA ready. If the Win98 Unofficial SP2 team is able to come up with a 48 bit LBA ESDI driver, it will need to be integrated into the CAB files to allow Windows 98 to be installed to >137GB drives. It's not a feature I require but it would make Windows 98 the second OS that will install to >137GB drives.