VOGONS


HWiNFO support of vintage hardware

Topic actions

Reply 620 of 677, by leonardo

User metadata
Rank Member
Rank
Member
kennyPENTIUMpowers wrote on 2022-10-20, 03:47:
leonardo wrote on 2022-10-19, 20:50:

I've also attached said files to this message for your convenience. These are direct from my OSR2 install CD.

thanks for that ..
ive put the win95b WININET AND SHLWAPI you supplied in the same folder as hwinfo32, but it still doing the same thing (nothing except accessing the HDD for 30 seconds)..

The last one I downloaded was version 7.20 and that runs on my system without major issues. Which version are you trying to run?

[Install Win95 like you were born in 1985!] on systems like this or this.

Reply 621 of 677, by kennyPENTIUMpowers

User metadata
Rank Newbie
Rank
Newbie
leonardo wrote on 2022-10-20, 07:34:

The last one I downloaded was version 7.20 and that runs on my system without major issues. Which version are you trying to run?

v7.31-4885

Reply 622 of 677, by leonardo

User metadata
Rank Member
Rank
Member
kennyPENTIUMpowers wrote on 2022-10-20, 09:24:
leonardo wrote on 2022-10-20, 07:34:

The last one I downloaded was version 7.20 and that runs on my system without major issues. Which version are you trying to run?

v7.31-4885

OK, I tried it and it runs just fine on my comps with W95. However, I'm running OSR2 with the latest updates and you're running the original release or OSR1. AFAIK you cannot use the update-rollup I recommend in my guide and may have to install some relevant updates manually.

The first few updates that spring to mind are the Common Controls Update, Windows Sockets 2 Update, and DCOM - all of which should be available separately.

A lot of applications for Windows 95 depend on these, so while it's a bit of a scattershot you may want to try installing them just to see if that helps.

If I recall, the proper order would be 1) 401comupd.exe, 2) W95ws2setup.exe 3) DCom95.exe - at least between these three.

Attachments

  • Filename
    DCom95.exe
    File size
    1.17 MiB
    Downloads
    55 downloads
    File comment
    DCOM for Windows 95
    File license
    Fair use/fair dealing exception
  • Filename
    401comupd.exe
    File size
    427.27 KiB
    Downloads
    55 downloads
    File comment
    Common Controls Update for Win95
    File license
    Fair use/fair dealing exception
  • Filename
    W95ws2setup.exe
    File size
    963.28 KiB
    Downloads
    49 downloads
    File comment
    WinSock 2 for Windows 95
    File license
    Fair use/fair dealing exception

[Install Win95 like you were born in 1985!] on systems like this or this.

Reply 623 of 677, by kennyPENTIUMpowers

User metadata
Rank Newbie
Rank
Newbie

ah ok .. not sure about a few things you are refering to ..
"the update-rollup I recommend in my guide" ... im not sure what update-rollup is and i havent read your guide nor do i know of it..

Reply 624 of 677, by leonardo

User metadata
Rank Member
Rank
Member
kennyPENTIUMpowers wrote on 2022-10-20, 15:00:

ah ok .. not sure about a few things you are refering to ..
"the update-rollup I recommend in my guide" ... im not sure what update-rollup is and i havent read your guide nor do i know of it..

Sorry, was too lazy to link: Windows 95 setup guide for the 2020's.

An update-rollup also sometimes more officially referred to as a "Service Pack" is a collection of updates bundled together for more effective application.

For example, Windows 95 and -98 saw tens if not hundreds of updates during their lifecycle. Trying to install the updates individually and in the right order is an absolute nightmare. Microsoft only released one service pack for Windows 95, leaving a bunch of updates up to the user, or including them in separate releases:

  1. Windows 95 OSR1 (OSR1=OEM Service Release 1) - basically the original Windows 95 + Service Pack 1
  2. Windows 95 OSR2 (OSR2=OEM Service Release 2) - an enhanced release that includes updates one cannot download anywhere 🙁
  3. Windows 95 OSR2.1 (OSR2.1=OEM Service Release 2.1) - same as OSR2, but with further updates included - however the follow-up updates are downloadable
  4. Windows 95 OSR2.5 (OSR2.5=OEM Service Release 2.5) - basically OSR 2.1 but with Internet Explorer 4 included on disk

Anyway, it would seem that you are using OSR1 which cannot install all the latest updates, some of which require at least OSR2 version of Windows 95. There is no upgrade path from the original release or OSR1 to OSR2, it can only be obtained on disc. If you had at least OSR2, you could then install the Unofficial Service Pack 1.05 for OSR2, which basically includes all the important updates Microsoft ever released.

The updates I linked in my previous post may be enough to satisfy HWiNFO, and should also work on the original/OSR1 release of Win95.

[Install Win95 like you were born in 1985!] on systems like this or this.

Reply 625 of 677, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie

I'm sorry but currently HWiNFO32 requires at least OSR2. To make it work with the original Win95 install would require extensive changes as you have already seen.
For such systems it might sometimes be better to use HWiNFO for DOS.

Reply 626 of 677, by leonardo

User metadata
Rank Member
Rank
Member
Mumak wrote on 2022-10-21, 06:37:

I'm sorry but currently HWiNFO32 requires at least OSR2. To make it work with the original Win95 install would require extensive changes as you have already seen.
For such systems it might sometimes be better to use HWiNFO for DOS.

Can you go into any detail on what OSR2 adds that is relevant to HWiNFO that is lacking in older versions of Win 95? Just for curiosity's sake.

edit:
I know that Microsoft very intentionally made their new user interface libraries on Windows 98 interdependent on Internet Explorer. When devs adopted Microsoft's new tools, it resulted in a bunch of really bloated apps that would require one to have Internet Explorer installed - even if the application had no internet functionality or any browser-features built-in.

Basically the divide was "apps that would run on Windows 95 and 98, regardless of IE" vs. "apps that ran on Windows 95 and 98 as long as IE v.xx was installed" vs. "apps that won't run on Win95, even with IE". Have not run into many apps that wouldn't run on all tiers of Windows 95 if it didn't have something to do with this dichotomy.

[Install Win95 like you were born in 1985!] on systems like this or this.

Reply 627 of 677, by Am386DX-40

User metadata
Rank Member
Rank
Member

I'm trying to catalog all my ram sticks and I'm seeing different values on fields like Serial Number and Date between CPU-Z and HWInfo32. Which one should I trust? Why are they showing different values?

Here's an example of 2 Kingston dimms (DDR 400).

Here's Dimm 1 with CPU-Z

dimm1.png
Filename
dimm1.png
File size
15.98 KiB
Views
1501 views
File license
CC-BY-4.0

Same Dimm with HWInfo32

dimm1b.png
Filename
dimm1b.png
File size
65.56 KiB
Views
1501 views
File license
CC-BY-4.0

Dimm 2 with CPU-Z

dimm2.png
Filename
dimm2.png
File size
16.08 KiB
Views
1501 views
File license
CC-BY-4.0

Dimm 2 with HWInfo32

dimm2b.png
Filename
dimm2b.png
File size
65.08 KiB
Views
1501 views
File license
CC-BY-4.0

Reply 628 of 677, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
Am386DX-40 wrote on 2022-11-30, 18:30:
I'm trying to catalog all my ram sticks and I'm seeing different values on fields like Serial Number and Date between CPU-Z and […]
Show full quote

I'm trying to catalog all my ram sticks and I'm seeing different values on fields like Serial Number and Date between CPU-Z and HWInfo32. Which one should I trust? Why are they showing different values?

Here's an example of 2 Kingston dimms (DDR 400).

Here's Dimm 1 with CPU-Z dimm1.png

Same Dimm with HWInfo32 dimm1b.png

Dimm 2 with CPU-Z dimm2.png

Dimm 2 with HWInfo32 dimm2b.png

Encoding of serial numbers is not standardized so vendors are free to use their own encoding and tools don't know how to interpret the data.
Both tools show the same values, but CPU-Z displays it in Hex (big-endian) while HWiNFO in Decimal (little-endian) format.

Reply 629 of 677, by Am386DX-40

User metadata
Rank Member
Rank
Member
Mumak wrote on 2022-11-30, 18:37:

Encoding of serial numbers is not standardized so vendors are free to use their own encoding and tools don't know how to interpret the data.
Both tools show the same values, but CPU-Z displays it in Hex (big-endian) while HWiNFO in Decimal (little-endian) format.

Ahhh interesting! What about the manufacture date? The year matches, but the week does not. Is it the same cause?

Reply 631 of 677, by Am386DX-40

User metadata
Rank Member
Rank
Member

Ok I see, but I think it's the other way around. HWInfo shows the date (week) in HEX and CPU-Z in decimal. I even have one dimm that HWInfo shows the week value 1a. If you make the conversion, they match.

But the serial number is a different case, I make the conversion (in both directions) and the values don't match at all. I'm probably doing something wrong.

Reply 632 of 677, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie

We try to guess the date encoding because manufacturers use many different formats, however this doesn't work always properly.
Try to convert the number in HWiNFO from Dec to Hex and you'll see it 😉

Reply 633 of 677, by Nexxen

User metadata
Rank Oldbie
Rank
Oldbie
Mumak wrote on 2022-11-30, 18:58:

Yes

We had a little business involving data from a Gxm processor. The FSB would go up and down (12 to 33) but never still at 33mhz.

I was wondering, a real time reading of the FSB could be wrong because some oscillator is malfunctioning? I don't know how clock is generated.
They were budget motherboards, maybe bad cheap components going bad?

The question is in general for reading the FSB.

PC#1 Pentium 233 MMX - 98SE
PC#2 PIII-1Ghz - 98SE/W2K

Reply 634 of 677, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
Nexxen wrote on 2022-11-30, 19:20:
We had a little business involving data from a Gxm processor. The FSB would go up and down (12 to 33) but never still at 33mhz. […]
Show full quote
Mumak wrote on 2022-11-30, 18:58:

Yes

We had a little business involving data from a Gxm processor. The FSB would go up and down (12 to 33) but never still at 33mhz.

I was wondering, a real time reading of the FSB could be wrong because some oscillator is malfunctioning? I don't know how clock is generated.
They were budget motherboards, maybe bad cheap components going bad?

The question is in general for reading the FSB.

For such legacy CPUs the FSB is deduced as FSB = current clock / ratio

Reply 635 of 677, by Am386DX-40

User metadata
Rank Member
Rank
Member
Mumak wrote on 2022-11-30, 19:19:

Try to convert the number in HWiNFO from Dec to Hex and you'll see it 😉

But HWiNFO is showing Hex, not Dec... "1a" is not dec.

Captura.PNG
Filename
Captura.PNG
File size
16.06 KiB
Views
1447 views
File license
Public domain

This is a different module btw

Reply 636 of 677, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
Am386DX-40 wrote on 2022-11-30, 21:06:
But HWiNFO is showing Hex, not Dec... "1a" is not dec. Captura.PNG […]
Show full quote
Mumak wrote on 2022-11-30, 19:19:

Try to convert the number in HWiNFO from Dec to Hex and you'll see it 😉

But HWiNFO is showing Hex, not Dec... "1a" is not dec.
Captura.PNG

This is a different module btw

Yes. For date a different conversion is used. Some vendors used hex representation and HWiNFO assumed it's this case. That didn't work well, it's not possible to come up with a reliable method.

Reply 638 of 677, by ultra_code

User metadata
Rank Oldbie
Rank
Oldbie

So, I'm having a bit of a... unique time with my Asus K7M.

The board is a Slot A board with an AMD-751 northbridge and a VIA VT82C686A southbridge (personally before this board I have never seen a solution like this). The board uses an Asus-branded chip for sensors I believe (AS61256-8 / 9942S0701).

When I went to install XP SP3, it did not automatically determine it to be a board that supported APM, even though the BIOS itself has APM options and after manually-enabling APM support in the OS, it works as intended (although "sleep" is not an option; I have APM enabled but basically all of the individual options disabled in the BIOS, so that might be why, since I will be overclocking with this board). This comes off as strange to me, since my Super Socket 7 Soyo SY-5EMA+ v1.1 has perfectly normal APM support under Win2K and XP.

Anywho, moving on.

Whenever I open up HWINFO's "sensors" window, while it does seem to work just fine, it disables both the PS/2 keyboard and mouse ports in the process, as well as breaking how XP shuts down the machine (XP itself will "shut down," but then the board will still run and provide power to everything as if it were on). It does not affect USB peripherals plugged into the board, and opening the main report window does not cause any issues.

XP has been manually fully-updated (not via Legacy Update, but semi-automated installation of individual updates I organized a few years ago).

Let me know if you require anything else.

Attachments

  • Filename
    Asus K7M.zip
    File size
    34.58 KiB
    Downloads
    44 downloads
    File license
    Public domain

Builds
ttgwnt-6.png
kcxlg9-6.png

Reply 639 of 677, by Mumak

User metadata
Rank Oldbie
Rank
Oldbie
ultra_code wrote on 2023-01-18, 02:45:
So, I'm having a bit of a... unique time with my Asus K7M. […]
Show full quote

So, I'm having a bit of a... unique time with my Asus K7M.

The board is a Slot A board with an AMD-751 northbridge and a VIA VT82C686A southbridge (personally before this board I have never seen a solution like this). The board uses an Asus-branded chip for sensors I believe (AS61256-8 / 9942S0701).

When I went to install XP SP3, it did not automatically determine it to be a board that supported APM, even though the BIOS itself has APM options and after manually-enabling APM support in the OS, it works as intended (although "sleep" is not an option; I have APM enabled but basically all of the individual options disabled in the BIOS, so that might be why, since I will be overclocking with this board). This comes off as strange to me, since my Super Socket 7 Soyo SY-5EMA+ v1.1 has perfectly normal APM support under Win2K and XP.

Anywho, moving on.

Whenever I open up HWINFO's "sensors" window, while it does seem to work just fine, it disables both the PS/2 keyboard and mouse ports in the process, as well as breaking how XP shuts down the machine (XP itself will "shut down," but then the board will still run and provide power to everything as if it were on). It does not affect USB peripherals plugged into the board, and opening the main report window does not cause any issues.

XP has been manually fully-updated (not via Legacy Update, but semi-automated installation of individual updates I organized a few years ago).

Let me know if you require anything else.

Try to put the following settings in the [Settings] section of HWiNFO32.INI file if that will help:

[Settings]
LPC1=0
LPC2=0