Jump to content

Modified SYSDM.CPL 4.90.3001 for 98SE


Recommended Posts

  • 2 months later...

Is it possible to patch the Win98 version SYSDM.CPL to act like the Windows ME version? I know the Windows ME versions keep the CPU info which is broken in Win98. Maybe one can dump the CPU info and add it to the Win98 version. IDK, just a thought.

Link to comment
Share on other sites

Is it possible to patch the Win98 version SYSDM.CPL to act like the Windows ME version? I know the Windows ME versions keep the CPU info which is broken in Win98. Maybe one can dump the CPU info and add it to the Win98 version. IDK, just a thought.

Can you post a screenshot of what you're talking about? I'm actually working on a different issue, but there may be a correlation.

Normally the CPU information works fine on my 98SE, however, if the Windows ME UPDATE.SYS or Petr's patched UPDATE.SYS files are used on a 98SE system during installation, no CPU information will be displayed (or properly created in the Registry).

Link to comment
Share on other sites

The missing CPU info is not cause by UPDATE.SYS but SYSDM.CPL from all Win98SE updates except the original Win98 SE file. There is a screenshot in post 103 that displays the CPU info using the Windows ME version. When using the Win98 SE updated versions, it is missing.

Edited by PROBLEMCHYLD
Link to comment
Share on other sites

Are you running your experiments in a VM? I HAVE seen the CPU info be missing when running under VMware, regardless of the SYSDM.CPL or UPDATE.SYS version.

The missing info in the situations you are encountering may not be caused by UPDATE.SYS, but it IS caused by UPDATE.SYS in the situations I am working on.

The 98SE HotFix version of SYSDM.CPL does not have any issues displaying the CPU info. I know this, because I have that version in my slipstreamed build, and it works fine. The problem is elsewhere.

EDIT: Some "not entirely correct" information struck through.

Edited by LoneCrusader
Link to comment
Share on other sites

Here is what I'm talking about. It has been discussed many times in the Win9x forumshttp://www.msfn.org/board/topic/49045-201-system-properties/

This seems to be quite a mystery. blink.gif

I set up an unmodified 98SE installation, and then installed ONLY the SYSDM.CPL HotFix. The CPU info on the System Properties tab does indeed disappear under these conditions.

However, if one extracts the HotFix SYSDM.CPL to the \WIN98 folder before installation, therefore causing the HotFix version to be used during the original SETUP, then the CPU info is displayed properly. wacko.gif

So, the 98SE HotFix files are NOT broken, but they must be used in the original SETUP to work properly. There must be some other "link" between SYSDM.CPL and the registry entries it uses to get the CPU information.

Edited by LoneCrusader
Link to comment
Share on other sites

  • 4 months later...

However, if one extracts the HotFix SYSDM.CPL to the \WIN98 folder before installation, therefore causing the HotFix version to be used during the original SETUP, then the CPU info is displayed properly. wacko.gif

So, the 98SE HotFix files are NOT broken, but they must be used in the original SETUP to work properly. There must be some other "link" between SYSDM.CPL and the registry entries it uses to get the CPU information.

Update...This issue only seems to get stranger the more I work on it.wacko.gifwacko.gifwacko.gif

The 98SE HotFix version of SYSDM.CPL that I tested in the quoted experiment worked fine for displaying the CPU info - on an AMD system during a clean installation ONLY. It is broken on an Intel system under ALL conditions.

Edited by LoneCrusader
Link to comment
Share on other sites

Apologies for my fuzzy memory, but I vaguely recall something about CPU microcode update - an inf file, a dll or something like that. Maybe the new .cpl requires a newer version of that microcode file or a registry key would have to be created beforehand. A comparison between a vanilla 98SE and an updated one (with the Hotfix or ME .cpl installed, maybe with uSP3 too) might reveal the differences between files and/or registry keys (and their locations).

I really don't recall what I did, but my old system that suffered so many updates and whatnot and now has a modded version of the ME SYSDM.CPL, does display CPU information fine (GenuineIntel x86 Family 6 Model 8 Stepping 3). Not sure if activating OEM information (OEMINFO.INI and OEMLOGO.BMP) has anything to do with this, but I do have those files in the SYSTEM folder.

Here's the registry keys on my 98SE system:

[HKEY_LOCAL_MACHINE\Hardware\Description\System\CentralProcessor\0]"VendorIdentifier"="GenuineIntel""Identifier"="x86 Family 6 Model 8 Stepping 3""Update Status"=dword:00000000"Update Signature"=hex:00,00,00,00,13,00,00,00"Previous Update Signature"=hex:00,00,00,00,0c,00,00,00

Apparently unrelated but maybe not so: can anyone point me to detailed information on (re)creation and structure of SYSTEM.1ST, located in the root of the bootable drive? Mine got corrupted a year or so ago and since then boot time increased very much. I wonder if the lack of this file triggers some hardware/software redetection at boot time and if this could help in creating/updating the CPU info displayed by SYSDM.CPL...

Link to comment
Share on other sites

Apologies for my fuzzy memory, but I vaguely recall something about CPU microcode update - an inf file, a dll or something like that. Maybe the new .cpl requires a newer version of that microcode file or a registry key would have to be created beforehand. A comparison between a vanilla 98SE and an updated one (with the Hotfix or ME .cpl installed, maybe with uSP3 too) might reveal the differences between files and/or registry keys (and their locations).

I really don't recall what I did, but my old system that suffered so many updates and whatnot and now has a modded version of the ME SYSDM.CPL, does display CPU information fine (GenuineIntel x86 Family 6 Model 8 Stepping 3). Not sure if activating OEM information (OEMINFO.INI and OEMLOGO.BMP) has anything to do with this, but I do have those files in the SYSTEM folder.

Here's the registry keys on my 98SE system:

[HKEY_LOCAL_MACHINE\Hardware\Description\System\CentralProcessor\0]"VendorIdentifier"="GenuineIntel""Identifier"="x86 Family 6 Model 8 Stepping 3""Update Status"=dword:00000000"Update Signature"=hex:00,00,00,00,13,00,00,00"Previous Update Signature"=hex:00,00,00,00,0c,00,00,00

Apparently unrelated but maybe not so: can anyone point me to detailed information on (re)creation and structure of SYSTEM.1ST, located in the root of the bootable drive? Mine got corrupted a year or so ago and since then boot time increased very much. I wonder if the lack of this file triggers some hardware/software redetection at boot time and if this could help in creating/updating the CPU info displayed by SYSDM.CPL...

I originally thought that the Microcode update/UPDATE.SYS had something do do with identifying the CPU as well, but it doesn't. For some reason I have yet to determine, changing UPDATE.SYS can cause no CPU Info to be displayed at all, but it does not actually create the CPU info displayed on the System Properties tab. It is only responsible for the "Update" related entries in the corresponding Registry key.

From what I have been able to determine so far, when Microsoft issued SYSDM.CPL 4.10.2223 for Q216204, they actually completely broke the CPU ID function rather than properly fixing it. The KB article refers to "incorrectly identified Intel CPUs," but it appears their solution was to have NO identification of Intel CPUs at all rather than fix the bug.

Since HotFixes are cumulative, the botched changes in 2223 that were only intended for Intel systems got carried over into 4.10.2224 for Q272620, which is a "good" HotFix that fixes a bug common to all systems. This probably explains why all CPU info disappears when this HotFix is installed to an existing system.

The "Stepping Data" string is actually NOT correct for identifying an Intel CPU. It SHOULD print a friendly ID string, similar to the one displayed by the BIOS during POST. This "Stepping Data" sting is what Microsoft described in Q216204, and rather than fixing SYSDM.CPL to print the "friendly ID" they broke the ID entirely.

Link to comment
Share on other sites

  • 2 weeks later...

Admittedly the Family/Model/Stepping string is not of much help but it's better than nothing anyway. I once was interested in the CPUID function and its proper usage but when I saw all that mess I quickly left it for dead. :)

Maybe at some point I'll take on it again and at least build an external tool to fix that string. But for now that's just wishful thinking.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...