• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
LoneCrusader

Modified SYSDM.CPL 4.90.3001 for 98SE

116 posts in this topic

Haha, hex-editing is even trivial. I read some hesitation here because it's a .cpl file. Somebody said it could be renamed to .dll, which is the correct way to do (identical structure). Then you can work with it with your tool of choice.

No, a .CPL is not completely "identical" to a .DLL. And in any case, the problem here is that we do not know WHAT to fix, even if we had a tool to fix it.

0

Share this post


Link to post
Share on other sites

Moreover, 16-bit .exe, .dll, .cpl and .drv usually are NE executables, not PE executables. NE executables are totoally different animals. The best way to add resources to them is to use the MS Resource Compiler (rc.exe). To remove/edit a resource is another problem entirely. Sometimes MS VS 6.0 can do it right. Sometimes the (non-free) eXescope can do it. Sometimes nothing seems to work right. Go figure! :blink:

0

Share this post


Link to post
Share on other sites

Well, I have some good news and some bad news. The good news is SYSDM.CPL 4.90.0.3001 is now working on my system. The icon bug is gone :thumbup The bad news is, I don't know what I did to get rid of it. Look at the screenshot for proof. You'll see the Disable System Restore option which is not present on Win98 along with no buggy icon in device manager. BTW, the link to the none System Restore version is broke.

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

I found the bug. :thumbup It is NOT the file SYSDM.CPL 4.90.0.3001.

In order for USB drivers to silently install you need these keys, and they do NOT work on the Win98 version of SYSDM.CPL

1. HKLM,System\CurrentControlSet\Services\Class\USB,"SilentInstall",,"1"

2. HKLM,System\CurrentControlSet\Services\Class\USB,"SilentInstallNotify",,"1"

but wait, registry key (2) is the culprit. When that key is removed, the icon bug disappear, but wait, when that key is removed the icon bug is gone and everything installs silently and you don't get the New Hardware Found box that shows the USB drivers installing because everything installs in the background. This only happens when updating the .SYS drivers. USB flash drives devices shows the New Hardware Found box. This is not a bug since the whole purpose is to let drivers detect silently without the users input. If users are using NUSB 3.6, just remove key (2) up above, remove all drivers in safemode.

0

Share this post


Link to post
Share on other sites

Well, I have some good news and some bad news. The good news is SYSDM.CPL 4.90.0.3001 is now working on my system. The icon bug is gone :thumbup The bad news is, I don't know what I did to get rid of it. Look at the screenshot for proof. You'll see the Disable System Restore option which is not present on Win98 along with no buggy icon in device manager. BTW, the link to the none System Restore version is broke.

Hmm... Sounds interesting. I will have to experiment with this.

Link in previous post fixed, and here again for reference:

SYSDMCPL.ZIP - 156.9 Kb

Of course it comes with the same disclaimer I've said before - this file is experimental and MAY cause unexpected behavior, especially regarding CONFIG.SYS if you have any special settings specified there. It has not been tested under such conditions.

Edited by LoneCrusader
0

Share this post


Link to post
Share on other sites

That is some really good info !

0

Share this post


Link to post
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.

0

Share this post


Link to post
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).

0

Share this post


Link to post
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
0

Share this post


Link to post
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
0

Share this post


Link to post
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
0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
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...

0

Share this post


Link to post
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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
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.