I'll report to upstream that 7.7 is faulty. But upstream faulty version displays a clear error window. The portable version just disappears.
The details are:
On XP SP3:
KchmViewerPortable 7.7 displays its small logo window and disappears.
7.5 seem to run fine.
7.7 occupies 50% more disk space, compared to 7.5. As if 7.7 has lots of new features, or something.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
It's working here - Win 7 Enterprise, x86.
The difference in size is due to the fact that we are no longer compressing the application before packaging.
Perhaps the application no longer supports XP correctly?
Version 7.7 was compiled by the publisher without XP compatibility. They are using v12 of the C runtime which can be configured to allow XP to work if you update it to the patched version and configure it. The publisher may or may not choose to do it.
The portable version isn't set to disallow running on Windows XP. This will be changed in an upcoming release. The app's homepage has been updated to list that it requires Vista and up.
The reason an error doesn't show is running one app from another will hide a Windows-level runtime error in the second app.
Note that we don't check individual releases for XP compatibility any longer. Apps are dropping XP support with new releases and without announcing as they update to modern compilers. Firing up a Windows XP virtual machine to test if every release of every app still works in XP would take a lot of time for not much benefit given how far Windows XP has fallen in usage.
Sometimes, the impossible can become possible, if you're awesome!
There is no tool like that to my knowledge. It's not determining 32-bit vs 64-bit, it's determining what specific functions of the kernel it's utilizing as well as what C runtime and how it's called and then determining the same for all included DLLs and helper EXEs. LibreOffice, for instance, had an issue tracking down SSE2 requirements in all its DLLs due to the fact that many very old XP machines have very old processors that lack SSE2 support. I'm not sure if they ended up fully solving it offhand.
Expect issues like this with more and more apps. While we won't switch compilers for our own platform, launcher, installers, utilities, etc to one that doesn't support XP, individual apps can and will and nearly always do so without warning or official announcement.
Sometimes, the impossible can become possible, if you're awesome!