Jump to content

naaloh

Member
  • Posts

    33
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Belarus

About naaloh

Profile Information

  • OS
    ME

Recent Profile Visitors

1,215 profile views

naaloh's Achievements

0

Reputation

  1. OK, I now understand that after you enter the OS Ver parameters and use CompatSave in fcwin2k you can run the executable from anywhere with any command-line options, but it still doesn't help, as after setting the parameters to Windows VIsta, I still get the same "This program does not support the version of Windows your computer is running" and the installation log file still reports "Windows version: 5.1.2600 SP3 (NT platform: Yes)". UPDATE: It looks like fcwin2k is not able to emulate for a file named Setup.exe (perhaps because there's a system file of the same name). After I renamed the installation file and set it up in fcwin2k, the installation started to crash just like with Application Verifier. I wonder what's causing it to crash and if it's possible to fix it... I attached the archived log of the Process Monitor, which list the file system and registry calls of the temporary Setup executable, to this message in case anyone want to research it. Logfile.7z
  2. Thanks a lot (wonder why nobody mentioned this application before). So I installed the Microsoft Application Verifier version 4.0.0665, which seems to be the last one to support Windows XP (correct me if I'm wrong), but when I added the temporary Setup executable and enabled the HighVersionLie test, the executable just crashed when I tried to run it. Are there any specific values I should have entered as Properties for the HighVersionLie test (see the attached screenshot) to simulate Vista? When I looked up Application Verifier here, I also saw fcwin2k (Force Compatibler For Windows 2000) mentioned. I got that one to try and was able to run the temporary Setup executable, but apparently, fcwin2k does not allow to specify the command line parameters for the executable (when I enter them into the "File" field, all the relevant buttons become inactive). I tried executing the original Setup.exe with fcwin2k (see the second screenshot attached), repeating all steps described in the first post, but I just got the usual "This program does not support the version of Windows your computer is running". Since I cannot enable logging without command line parameters, I don't know which OS version was passes to the child process Setup.tmp that gives the error message. Any advice?
  3. The issue is, apparently, with the installation script that requests Windows version 6.0 at least. The question is, can the script be edited without recompiling the whole installation package? Or, is there any way to make Windows report a higher version than it actually is (kind of like the compatibility mode does, even though it reports a lower one)?
  4. Can the manifest be edited? Anyway, I doubt the manifest plays any part here because, as I have said, the manifest in this case is the same as on the older version, which does run on XP, and I do have the Microsoft .NET Framework 1.1 to 4.0 installed. The files are in the original Setup.exe (links to download multiple-part archive: 1 2 3 4), which contains the installation script and other installer files. It has to be modified somehow to allow installation on Windows XP. There's also an InnoSetup archive next to it (400+ MB), which contains some of the program files, and the rest are in the directory structure on the DVD.
  5. The parts 1 to 5 are attached to the first post in this topic; like I said, I had to split due to the size limit. No, the Setup.tmp file cannot be read with Innounp Repackage with what, the Inno Setup installation builder?
  6. It might indeed be the install script (the archive with which I attached to this message, after extracting it with innounp). Every entry under the [Files] section contains the "MinVersion: 0.0,6.0" parameter, which according to https://jrsoftware.org/ishelp/index.php?topic=setup_minversion means that it would require Windows to report at least version 6.0 and XP is, obviously, below that. Only question is, what can be done about it? install_script.7z
  7. Apparently it is, at least it looks similar (and supports Inno Setup command line). I attached the first volumes of the archive with it (unmodified) to the first message and the last to this one (I had to split due to the size limit). I also attached the installation log to this message. The manifest in this case is the same as on the older version, which does run on XP, so I don't think it's the case. The install script - maybe, but it's not possible to modify it, is it? That is unless it can be done directly in the operating memory. What is this script supposed to look like? Setup.tmp.part06.rar Setup.tmp.part07.rar Setup.tmp.part08.rar Setup.tmp.part09.rar Setup Log 2020-09-08 #002.txt
  8. Facing the same problem as many other people on this forum, namely trying to install software that would most likely work on Windows XP, but being hindered by the Inno Setup installer that would not run, I was, it seems, able to get farther than other people who posted, but still unable to install. When I first ran the Setup.exe file, the "Setup.exe is not a valid Win32 application" message popped up. As advised on this forum, I changed the vaules of "OS Major Version" and "SubSys Major Version" in the executable from 06 to 05 (there are many tools that can do it and in fact it can be done with any hex editor, as the values seem to always be at 148 and 150 hexadecimal respectively). That still didn't help much because running the patched executable just caused the box with the lines "Unable to execute file in the temporary directory. Setup aborted." and "Error 193: %1 is not a valid Win32 application." to appear. Using Process Monitor, it's possible see how the original Inno Setup executable creates a temporary executable in the temporary directory and using a file undelete tool (I used R-Studio, but I think any other would perform equally well), it's possible to recover the file after it's deleted when the setup is aborted. That Setup.tmp file, too, needs to have the "OS Major Version" and "SubSys Major Version" changed to 05, but even after patching you cannot just run it without any command line, as it gives the "Messages file "...\Setup.msg" is missing. Please correct the problem or obtain a new copy of the program." error. The temporary setup file, I believe, is assembled from the data stored (in compressed form) inside the original setup file, so you cannot just patch the original setup file to fix the temporary one. The best thing I could do to work around it was to suspend the process of the original Setup.exe before the temporary Setup.tmp is executed with the AutoIt script given at https://www.autoitscript.com/forum/topic/180996-set-application-in-idle-state/?tab=comments#comment-1299592 (obviously, modified to run the Setup.exe executable and leave it suspended until commanded to resume it, see in the attachment) and then, using WinHex, open the Entire memory of the Setup.exe process and then modify the "OS Major Version" and "SubSys Major Version" values of the temporary file while it's still in RAM (it has to be done in two places). That still brought no joy because the original Setup.exe, apparently, verifies the checksum of the temporary Setup.tmp after extracting it to RAM and before it's written to disk, so after resuming the patched process I just got "The setup files are corrupted. Please obtain a new copy of the program.". That still didn't cause me to give up, as I began searching for the checksum of the unmodified Setup.tmp in the original Setup.exe and to my joy was able to find out that it's stored as CRC32 in the "inverted" form (e. g. 05975E97 as 975E9705). So I patched that value in memory as well (it, obviously, can also be done on the Setup.exe file itself), changing it to the CRC32 of the modified Setup.tmp and it caused the CRC check to succeed. You'd think that after all that effort I would be rewarded with the install wizard, but alas... The temporary temporary Setup.tmp did finally execute, but only to display "This program does not support the version of Windows your computer is running.". Having executed it once, it was no longer necessary for me to go through all the initial steps to do it again, as I could now see the command line with which it ran (I used Advanced Process Termination for that, but I think Process Explorer would do as well), in my case it was Setup.tmp /SL5="$360218,804352,0,O:\Install\Setup.exe" so I could simply rename Setup.tmp to Setup.exe and run it manually, but I couldn't make any further progress and I feel that I have to give up now. If anyone can figure out a way past that (probably last) obstacle, I'd be extremely grateful, as I do need the software. I think it's some value stored somewhere in the original Setup.exe that can be modified, or perhaps there's a way to get Windows XP to report a higher version than it normally does, as one can certainly get it to report a lower version by setting it in the Compatibility tab or an executable's properties, so any advice would be appreciated. Setup.exe.au3 Setup.tmp.part01.rar Setup.tmp.part02.rar Setup.tmp.part03.rar Setup.tmp.part04.rar Setup.tmp.part05.rar
  9. Something shall happen if you just find enough patience to wait... or at least to read this thread.
  10. The bottom line is if you just wait long enough you'll get your list of updates and when you install them the trouble will be gone, so there's zero need to install anything unofficial. Patience is a virtue.
  11. Well, I tried it and, not surprisingly, it didn't work. There is an exclamation mark on top of the adapter sign in the device manager and a massage that says "This device is either not present, not working properly, or does not have all the drivers installed. (Code 10.) Try upgrading the device drivers for this device." The .inf is, probably, OK, but the modem needs newer versions of drivers, which are available only for Windows XP and above.
  12. I'd say... If your primary concern is being able run relatively recent applications, use Win2000. If you have some applications that require real-mode DOS (most DOS apps do not require it and can be safely run from Windows) and you need to run them often, use Win98. In other cases use WinME, you can still run DOS apps that require real-mode, but you'll have to reboot your machine before and after that, which is much less than convenient. In all other aspects working under WinME will most likely be far more rewarding than under Win98, unless you want to run it on a machine with 32 MB of memory.
  13. I can answer that question now, as I found that I did save this information, it's USB\Vid_12d1&Pid_14db\5&1f8fd7d0&0&1 I have rewritten the INF file to the best of my abilities in order to make it work under WinME (and Win98, too). I am attaching the rewritten INF to this message, if anyone with a substantial knowledge of Microsoft INF files can check it for mistakes, I would appreciate it, because soon I'm going to borrow the modem again and try to make it work under Windows Millenium Edition. It's very frustrating that so few modern USB devices have drivers for the legacy OSes even when it doesn't cost anything for the manufacturer to provide them (all that's needed in case of this modem is a properly written INF, since the drivers themselves are from Microsoft). I imagine having a working WinME driver for such modems would help a lot of people, e. g. those who would like to use an old notebook that can't handle XP as a netbook. In case anyone is interested, I used Microsoft INF template for USB Remote NDIS Device for Win98/ME, Microsoft INF template for USB Remote NDIS Device for Win2000/XP, ZyXEL USB ADSL Modem INF for Win98/ME and ZyXEL USB ADSL Modem INF for Win2000/XP as a reference. The Microsoft templates are in the packages submix8c much helpfully pointed me to: RNDIS-USB-Kit_05.exe and rndisusb1-1.exe. WceIS.inf
  14. It's nice to see so many replies with so much information, I do appreciate this Upon examining the contents of the "HKEY_LOCAL_MACHINE/Enum/PCI" key I came to the same conclusion as CharlotteTheHarlot, i. e. that the number of the slot can be determined by the hex digit subkey. In my case there are the following subkeys. 000800 - Video Card , both the one present at the time of the backup and the one installed before that, they were actually in the AGP slot, not PCI 30F000 - DVB Card 38F000 - Sound Card 48F000 - Network Card, it was removed before backup 48F000, 49F000, 4AF000 - USB2.0 Controller, to the best of my recollection, it was indeed installed in place of the removed network card 50F000 - Modem 58F000 - IEEE 1394 Controller This could be translated into AGP - Video Card PCI1 - DVB Card PCI2 - Sound Card PCI3 - USB2.0 Controller, previously Network Card PCI4 - Modem PCI5 - IEEE 1394 Controller Which is plausible, because as far as I remember, IEEE 1394 Controller was, indeed at the bottom, however, it's strange that there is no 40F000 subkey and the USB2.0 Controller has three different subkeys. The latter is probably due to the controller being a composite device, but I see no explanation for the former. I do have access to it, but it's running under WinXP now. To ensure I was right in my interpretation, I could place devices in the order I deduced, install WinME and see it the results are the same.
  15. I have a registry backup from a WinME machine. I want to know which PCI device was in which slot at the time of the backup being made. Would anyone be so kind as to tell me which keys I should examine to determine this? Thanks in advance.
×
×
  • Create New...