Thanks. I will add this exclusion for your board automatically into next build of HWiNFO, so there should be no manual tweaking required.

Mumak wrote on 2025-04-29, 05:23:

Thanks. I will add this exclusion for your board automatically into next build of HWiNFO, so there should be no manual tweaking required.

Perfect! Thanks!

lost interest

Most issues reported recently should be fixed in new v8.25-5720 Beta.

lost interest

Auto-update notification is only working on Windows 7 and later, I guess due to server/certificate constraints. This is known.

I suppose that HWINFO could be modified to only check if running on those OS versions.

However I do think it would be nice to include a "check for updates" option in the dropdown help menu, and if clicked, and it isn't supported, it would say so and why.

lost interest

HWiNFO doesn't use HTTPS connection on systems prior to Win7 but since today's requirement for web sites are massively shifting to HTTPS or even HSTS, servers are required to automatically redirect traffic to secure channels.
So to support this feature, we'd have to host a plain http server for updates. This isn't something I'm eager to do...

lost interest

It will be fixed. However, your reactions are often sub-optimal.

lost interest

red-ray wrote on 2025-05-12, 07:04:

Mumak wrote on 2025-05-12, 06:35:

It will be fixed. However, your reactions are often sub-optimal.

None of us like having bugs in out software, when bugs are reported in SIV I always thank whoever found and reported the issue, I don't ever recall "shooting the messenger".

You are just acting like an entitled child. No one is obligated to respond to your reports let alone fix them. If you expect the developer to appease you out of his good will, you should try showing some of your own. This is not a product you paid for and if you don't like it you can very well just stop using it, I'm pretty sure no tears would be shed.

appiah4 wrote on 2025-05-12, 14:04:

[…]
Show full quote

1. You are just acting like an entitled child.
2. No one is obligated to respond to your reports let alone fix them.
3. If you expect the developer to appease you out of his good will, you should try showing some of your own.
4. This is not a product you paid for and if you don't like it you can very well just stop using it
5. I'm pretty sure no tears would be shed.

1. There are aspects I doubt you are aware of, when I see bugs and/or poor design I feel the professional thing to do is make the developer aware of them, this all used to happen off-line 'till the aspects I doubt you are aware of.
2. As all of AIDA64 + CPUZ + HWiNFO + SIV + etc. all need to co-operate by using the same locking semantics when accessing hardware the developers all need to work together to do this.
3. When HWiNFO causes issues for other programs I feel they need be fixed.
4. For me not testing with HWiNFO is not a sensible option as over the years there have been locking issues that needed to be addressed, the last one was when HWiNFO added lock timeouts earlier this year and there were race conditions in the HWiNFO design that I had to explain and get addressed. I just generated both the HWiNFO and SIV popups and leave it to you to decide who is the "entitled child". The HWiNFO panel is another one that fails to provide useful information, it does not even specify what the the lock timeout is!
5. For me the easy option is to only report HWiNFO issues that are likely to impact AIDA64 + CPUZ + SIV + etc., the only loser will be HWiNFO.

Lol.
Anyway, I have something to report. Just tried the latest version of HWINFO16 on my XT.

My system configuration:
-IBM PC/XT 5160
-IBM EGA with RAM expansion (256KB total)
-IBM Async serial card on COM1
-IBM floppy controller
-IBM Fixed Disk Adapter (Xebec 20MB MFM controller)
-3C509 Ethernet
-Creative Sound Blaster 1.5
-Monotech XT-IDE with 256MB CF

Two things:

1. The IBM EGA is detected as "EGA Color" with 256KB of RAM, but otherwise lots of "Unknown". Maybe it is not really possible, but maybe the original IBM EGA BIOS could at least be detected?
2. Attempting to get info on the ISA bus in the mainboard info section results in a system hard lock - presumably because it is looking for a "NE1000/2000" card on port 220, where there is a Sound Blaster 1.5 present instead.

1. Well, there isn't much to detect on such old EGA cards. Usually they don't have any special registers that could be used to test and the VBIOS doesn't contain any special marks. If you have an image of the VBIOS, I could look at that.
2. Does the system freeze with that "NE1000/2000" detecting message?

Mumak wrote on 2025-05-13, 06:13:

1. Well, there isn't much to detect on such old EGA cards. Usually they don't have any special registers that could be used to test and the VBIOS doesn't contain any special marks. If you have an image of the VBIOS, I could look at that.
2. Does the system freeze with that "NE1000/2000" detecting message?

1. That's what I figured. I do obviously have the BIOS chip, and I have an EEPROM programmer... so maybe I could image it. However, you might check the website known as "minuszerodegrees"... not sure if I should say much more since that is probably "copyrighted material" that may violate the rules of this website or something.
2. Yes, it does. It stays at that message and doesn't leave it, at least for several minutes, as long as I could stand watching it do nothing. The fact that it said "at port 220" was what convinced me it was truly stuck, as I figured it must be confused at something it got back from the Sound Blaster.

You can try to read the BIOS images including VBIOS using the getbios.com tool here: https://www.hwinfo.com/files/old/

Oh interesting. Okay, I'll give that a shot tomorrow.

red-ray wrote on 2025-05-12, 15:12:

https://www.vogons.org/download/file.php?id=219107 […]
Show full quote

appiah4 wrote on 2025-05-12, 14:04:

[…]
Show full quote

1. You are just acting like an entitled child.
2. No one is obligated to respond to your reports let alone fix them.
3. If you expect the developer to appease you out of his good will, you should try showing some of your own.
4. This is not a product you paid for and if you don't like it you can very well just stop using it
5. I'm pretty sure no tears would be shed.

1. There are aspects I doubt you are aware of, when I see bugs and/or poor design I feel the professional thing to do is make the developer aware of them, this all used to happen off-line 'till the aspects I doubt you are aware of.
2. As all of AIDA64 + CPUZ + HWiNFO + SIV + etc. all need to co-operate by using the same locking semantics when accessing hardware the developers all need to work together to do this.
3. When HWiNFO causes issues for other programs I feel they need be fixed.
4. For me not testing with HWiNFO is not a sensible option as over the years there have been locking issues that needed to be addressed, the last one was when HWiNFO added lock timeouts earlier this year and there were race conditions in the HWiNFO design that I had to explain and get addressed. I just generated both the HWiNFO and SIV popups and leave it to you to decide who is the "entitled child". The HWiNFO panel is another one that fails to provide useful information, it does not even specify what the the lock timeout is!
5. For me the easy option is to only report HWiNFO issues that are likely to impact AIDA64 + CPUZ + SIV + etc., the only loser will be HWiNFO.

This entire wall of text can be summarized as "the developer should have more respect for my contribution than I have for his project" which basically equates "I am entitled" so I have no idea how any of this invalidates my point.

I have multiple soundcard setups:
Gus detected but with wrong ram amount
Awe32 not detected next to it.

Sorry i do not remember, which version was it.