aha2940 wrote on 2020-04-08, 02:28:

Hi! I attached the log generated by hwinfo on my PC. Strange things I noticed: […]
Show full quote

Mumak wrote on 2020-04-04, 15:30:

aha2940 wrote on 2020-04-04, 14:17:

Hi, I think that's the issue, the NIC is manually configured (PnP disabled) to 0x210 IIRC. I'll generate the log and see how to get it out the machine, since it has no working floppy drive and no CD burner...I'll have to use the NIC, 🤣.

Sorry, I was a bit wrong with the statement. The 3Com EtherLink III uses 2 sets of ports: 200-3E0 is the standard port, but it also uses an ID port, which is in the 1x0 range. Can you determine which one is your card using? I have double-checked the code and it should work and properly detect the card.. unless the card would be somehow else configured...

Hi! I attached the log generated by hwinfo on my PC. Strange things I noticed:

- The voodoo 3 card is detected as having only 4MB of RAM, when in fact it has 16MB.
- It says the voodoo card has SGRAM, but it has SDRAM.
- It says my soundcard is an ESS688, but it's an ESS1688F.

On a positive note, the 3Com Etherlink III card got detected correctly, I think it had issues before because the packet driver was not working correctly.

Thanks for the report!
I think I found and fixed the bug for Voodoo3 and I also improved detection of ESS sound cards. Unfortunately I wasn't able to find the full ESS1688F data sheet (only some ES18xx series), so for this chip the detection is currently experimental.
Could you please run this build and attach a new report? [removed as newer version available]

zyzzle wrote on 2020-04-08, 04:13:

@Mumak […]
Show full quote

@Mumak

Thanks for resurrecting HWiNFO for DOS! I registered just to say "thank you", but also to ask a vexing question:

Please, please re-enable Sensor support. That was always the most useful feature of Hwinfo for me. As well as the "Benchmark" section. These were fantastic features. Removing support for "modern" systems seems to also cripple the program greatly. There *are* a few of us still using DOS on the latest 9th and 10th generation i5, i7, and i9 systems!

Over at DOS Ain't Dead forum, there is a post about your reanimation of the program. That's how I was directed to your thread at Vogons.

"If you run out of conventional memory, why not create seperate modules as adjuncts to the main .exe file? I quote from a relevant post over at Dos Ain't Dead:

The idea is restore the funtion by an external sensor status module of the program, or an auxiliary program of HWInfo.

Similar to what happens in Norton Commander: ncedit.exe, term95.exe, packer.exe.."

I've been using it since the beginning, so please don't consider me ungrateful! This is just a question that perhaps you can answer if I am not too far out of line.

I'm afraid I cannot fulfill all wishes. Some are asking me for a 286 version, others for support of latest Core systems like Ice Lake, etc. 😁 This is a really huge difference!
Modern systems have several features that are difficult to implement in DOS. For example many components (CPUs, chipsets, GPUs) support memory mapped registers, which are not accessible from real mode and would require switching to protected mode. This would be a huge effort to implement, not mentioning the potential issues caused by this on some systems. Other features require access via dedicated drivers or APIs that are not available in DOS.
Moreover, sensor support in the DOS version was very early and to improve that would require a complete re-write + porting of thousands of lines of code back into DOS. This would mean either porting the entire tool under a DOS extender or using overlays. The amount of code that would have to be ported back is really huge and I think some portions wouldn't even fit into one overlay and would have to be fragmented into several parts. Sorry, but considering the relatively small benefit of such effort plus inability to provide a lot of other information due to the lack of underlying interfaces/drivers/APIs, etc. anyway, this is not something I'm planning to go thru.

I'm sure appreciative of the response, and for your taking the time to explain how backporting code to DOS would not be an easy task.

Interestingly, I am running on a Lenovo laptop, i7-5500, 8 GB RAM, MS-DOS 7.10, and version 6.03 runs fine, but 6.04 locks up upon startup. Once I press OK at title screen, the system freezes, supposedly on the hardware detection. I can't select any menus, etc. My free DOS memory is 616,244 bytes, so it doesn't appear to be memory related, but who knows?

This hard freeze doesn't happen in 6.03, which runs fine and detects most of the hardware on this lenovo g50-80 laptop.

zyzzle wrote on 2020-04-08, 13:00:

I'm sure appreciative of the response, and for your taking the time to explain how backporting code to DOS would not be an easy task.

Interestingly, I am running on a Lenovo laptop, i7-5500, 8 GB RAM, MS-DOS 7.10, and version 6.03 runs fine, but 6.04 locks up upon startup. Once I press OK at title screen, the system freezes, supposedly on the hardware detection. I can't select any menus, etc. My free DOS memory is 616,244 bytes, so it doesn't appear to be memory related, but who knows?

This hard freeze doesn't happen in 6.03, which runs fine and detects most of the hardware on this lenovo g50-80 laptop.

This might be due to some recent changes where I removed support of some later systems. Anyway such a hard-lock should not happen even if it would not properly identify the system. Can you try the version I just posted above (Re: HWiNFO for DOS resurrected !) ?

Mumak wrote on 2020-04-08, 13:14:

zyzzle wrote on 2020-04-08, 13:00:

I'm sure appreciative of the response, and for your taking the time to explain how backporting code to DOS would not be an easy task.

Interestingly, I am running on a Lenovo laptop, i7-5500, 8 GB RAM, MS-DOS 7.10, and version 6.03 runs fine, but 6.04 locks up upon startup. Once I press OK at title screen, the system freezes, supposedly on the hardware detection. I can't select any menus, etc. My free DOS memory is 616,244 bytes, so it doesn't appear to be memory related, but who knows?

This hard freeze doesn't happen in 6.03, which runs fine and detects most of the hardware on this lenovo g50-80 laptop.

This might be due to some recent changes where I removed support of some later systems. Anyway such a hard-lock should not happen even if it would not properly identify the system. Can you try the version I just posted above (Re: HWiNFO for DOS resurrected !) ?

OK this works again in QEMU, thanks.

I had the same hang problem on my PC with earlier 6.04 but the latest from 8.4. works well 😀

The posted v. 6.04 from 8th April also works well on my i7-5500 notebook now. I peeked in the code and it seems the latest Core i3/i5/i7 detected is Ivy Lake. Later revisons being undected or deleted. I ought to test this on older and / or less common PCs, but the oldest I have now is a Core2 Desktop from 2008 or so.

Astra v. 6.7 does detect the more modern hardware, but the big difference is that program is not free, while HWiNFO, thanks to the generosity of its author is FREE!

Once again, glad to see the new version, and that it works well on my somewhat modern system.

zyzzle wrote on 2020-04-12, 14:37:

The posted v. 6.04 from 8th April also works well on my i7-5500 notebook now. I peeked in the code and it seems the latest Core i3/i5/i7 detected is Ivy Lake. Later revisons being undected or deleted. I ought to test this on older and / or less common PCs, but the oldest I have now is a Core2 Desktop from 2008 or so.

Astra v. 6.7 does detect the more modern hardware, but the big difference is that program is not free, while HWiNFO, thanks to the generosity of its author is FREE!

Once again, glad to see the new version, and that it works well on my somewhat modern system.

Thanks for the feedback.
I found a way how to improve detection of later Intel CPUs without spending additional conventional memory, so the next build will contain this enhancement.

Version 6.0.5 released. Fixes and improves support of newer CPUs, enhanced support of ESS sound cards, reduced memory requirements.

Sandy Bridge detected OK, didn't find other problem 😀

Mumak wrote on 2020-04-13, 14:51:

Version 6.0.5 released. Fixes and improves support of newer CPUs, enhanced support of ESS sound cards, reduced memory requirements.

Awesome! Just found out about this a few days ago, the best so far, will download the new version later today!
I remember this app, I mean, the name at least. So you are the same guy that created this app back in the day? What year was that?

Dusko wrote on 2020-04-13, 15:35:

Mumak wrote on 2020-04-13, 14:51:

Version 6.0.5 released. Fixes and improves support of newer CPUs, enhanced support of ESS sound cards, reduced memory requirements.

Awesome! Just found out about this a few days ago, the best so far, will download the new version later today!
I remember this app, I mean, the name at least. So you are the same guy that created this app back in the day? What year was that?

Yes, still the same guy, but much older 😁 First DOS version happened sometime in 1995...

Wow! Incredible! Great to know you are still updating it. I know I used it years ago.
Yes, WE are much older now! Nice to (VOGONS) meet you!

Mumak wrote on 2020-04-08, 09:16:

Thanks for the report! I think I found and fixed the bug for Voodoo3 and I also improved detection of ESS sound cards. Unfortuna […]
Show full quote

aha2940 wrote on 2020-04-08, 02:28:

Hi! I attached the log generated by hwinfo on my PC. Strange things I noticed: […]
Show full quote

Mumak wrote on 2020-04-04, 15:30:

Sorry, I was a bit wrong with the statement. The 3Com EtherLink III uses 2 sets of ports: 200-3E0 is the standard port, but it also uses an ID port, which is in the 1x0 range. Can you determine which one is your card using? I have double-checked the code and it should work and properly detect the card.. unless the card would be somehow else configured...

Hi! I attached the log generated by hwinfo on my PC. Strange things I noticed:

- The voodoo 3 card is detected as having only 4MB of RAM, when in fact it has 16MB.
- It says the voodoo card has SGRAM, but it has SDRAM.
- It says my soundcard is an ESS688, but it's an ESS1688F.

On a positive note, the 3Com Etherlink III card got detected correctly, I think it had issues before because the packet driver was not working correctly.

Thanks for the report!
I think I found and fixed the bug for Voodoo3 and I also improved detection of ESS sound cards. Unfortunately I wasn't able to find the full ESS1688F data sheet (only some ES18xx series), so for this chip the detection is currently experimental.
Could you please run this build and attach a new report? [removed as newer version available]

Sorry about the delay, I just tested version 6.05 and everything seems to be reported OK (the ESS soundcard, the 16MB of video RAM and the type of memory SDRAM on the voodoo). I'm attaching the log.

aha2940 wrote on 2020-04-14, 01:07:

Mumak wrote on 2020-04-08, 09:16:

Thanks for the report! I think I found and fixed the bug for Voodoo3 and I also improved detection of ESS sound cards. Unfortuna […]
Show full quote

aha2940 wrote on 2020-04-08, 02:28:

Hi! I attached the log generated by hwinfo on my PC. Strange things I noticed: […]
Show full quote

Hi! I attached the log generated by hwinfo on my PC. Strange things I noticed:

- The voodoo 3 card is detected as having only 4MB of RAM, when in fact it has 16MB.
- It says the voodoo card has SGRAM, but it has SDRAM.
- It says my soundcard is an ESS688, but it's an ESS1688F.

On a positive note, the 3Com Etherlink III card got detected correctly, I think it had issues before because the packet driver was not working correctly.

Thanks for the report!
I think I found and fixed the bug for Voodoo3 and I also improved detection of ESS sound cards. Unfortunately I wasn't able to find the full ESS1688F data sheet (only some ES18xx series), so for this chip the detection is currently experimental.
Could you please run this build and attach a new report? [removed as newer version available]

Sorry about the delay, I just tested version 6.05 and everything seems to be reported OK (the ESS soundcard, the 16MB of video RAM and the type of memory SDRAM on the voodoo). I'm attaching the log.

Thanks for the feedback. I'm happy that everything is OK now, especially the ESS card detection as this required a special method 😀

I've ran the latest hwinfo for DOS, v6.05, but had to bypass all my DOS startup files to avoid the memory error. Screenshot attached. Is 558,672 KB free of conventional memory sufficient? I ask because I encounted problems when using the software.

1) Creating the report file using hwingo.exe -r hangs the system. It has been sitting on this page for 10 minutes now. Pressing ESC does nothing. Upon reboot, I checked for a report file in the HWINFO directory, but none exists.

2) I am able to load the program and certain features work, namely,

3) But when I try to run the IRQ Assignment, DMA info, Mainboard info, etc, the system locks up and I must hit the reset button on the case.

4) I was able to save the system configuration file, hwinfo.ini, and it contains,

1[Configuration]
2UseCPUIDmethod1=1
3UseCPUIDmethod2=0
4UseCPUIDmethod3=1
5UseTSC=1
6Check3ComELinkIII=1
7CheckTulipNCC16=1
8CheckPCMCIA=1
9CheckVideoRAMDAC=1
10Check8042=1
11FlushDiskCaches=1
12CheckFlash=0
13SkipAdvATAPI=0
14SkipPnPBIOS=0

So I'm left wondering if 558.6 KB of free conventional memory is sufficient to run all features of the program? If not, I don't know how to get more free without creating a boot disk for perhaps a lower version of DOS. The system contains a DTK PKM-0033s motherboard and sports a Cyrix 5x86-133/4x CPU. Hopefully I'll have better luck with the Windows version of HWINFO.

feipoa wrote on 2020-04-14, 07:48:

I've ran the latest hwinfo for DOS, v6.05, but had to bypass all my DOS startup files to avoid the memory error. Screenshot att […]
Show full quote

I've ran the latest hwinfo for DOS, v6.05, but had to bypass all my DOS startup files to avoid the memory error. Screenshot attached. Is 558,672 KB free of conventional memory sufficient? I ask because I encounted problems when using the software.
HWINFO605_on_Cx5x86-133-4x_page_0.jpg

1) Creating the report file using hwingo.exe -r hangs the system. It has been sitting on this page for 10 minutes now. Pressing ESC does nothing. Upon reboot, I checked for a report file in the HWINFO directory, but none exists.
HWINFO605_on_Cx5x86-133-4x_page_4.jpg

2) I am able to load the program and certain features work, namely,
HWINFO605_on_Cx5x86-133-4x_page_2.jpg
HWINFO605_on_Cx5x86-133-4x_page_3.jpg

3) But when I try to run the IRQ Assignment, DMA info, Mainboard info, etc, the system locks up and I must hit the reset button on the case.
HWINFO605_on_Cx5x86-133-4x_page_1.jpg

4) I was able to save the system configuration file, hwinfo.ini, and it contains,

Copy code to clipboard

1[Configuration]
2UseCPUIDmethod1=1
3UseCPUIDmethod2=0
4UseCPUIDmethod3=1
5UseTSC=1
6Check3ComELinkIII=1
7CheckTulipNCC16=1
8CheckPCMCIA=1
9CheckVideoRAMDAC=1
10Check8042=1
11FlushDiskCaches=1
12CheckFlash=0
13SkipAdvATAPI=0
14SkipPnPBIOS=0

So I'm left wondering if 558.6 KB of free conventional memory is sufficient to run all features of the program? If not, I don't know how to get more free without creating a boot disk for perhaps a lower version of DOS. The system contains a DTK PKM-0033s motherboard and sports a Cyrix 5x86-133/4x CPU. Hopefully I'll have better luck with the Windows version of HWINFO.

558 KB should be enough, but it also depends on system type and how much information is retrieved as memory is allocated dynamically. Anyway, if there would be a memory problem, then you'd get such a message from HWiNFO. So the hang here is something else..
Can you please try to run without -r parameter, manually open the Mainboard info page and take a picture where exactly it hangs?
You might also try to disable Method 1 and 3 to Reset the CPU if that will help.

Here's the screenshots you requested.

Just before running Mainboard Info

During the run of Mainboard Info

And the resulting error

The additional combinations I tried for the ini file were to set them all to 0, as in,
UseCPUIDmethod1=0
UseCPUIDmethod2=0
UseCPUIDmethod3=0

And to set just method 2 to 1, as in,
UseCPUIDmethod1=0
UseCPUIDmethod2=1
UseCPUIDmethod3=0

When just setting method 2 to 1, I was able to hit Q for Quit, and it appeared as if it was going to quit, but hangs on a blinking cursor on a black screen.

Note that the CPUID feature was not completely implemented in the Cyrix 5x86 series.

Wow, this is really puzzling! It should work w/o CPUID too, just like in Win95 where it passed the CPU checks, so scratching my head....

Have other users tested DOS HWINFO using a Cyrix 5x86?