2

Similar to this issue.

I've being using IExpress (included with Windows) for years to package up my bootstrapper EXE and .NET application MSI into a self-extracting installer file. (My app is 32-bit, so I've used the version of iexpress.exe in %windir%/SysWOW64)

I recently moved from Windows 8.1 to Windows 10.

Without changing anything about my code, using IExpress on Windows 10 is resulting in an EXE that won't run on Windows XP (getting "[FileName].exe is not a valid Win32 application").

Using IExpress on Windows 8.1, 8 or 7, it works fine.

Can anyone shed some light or provide a solution??

(I tried copying the iexpress.exe from Windows 8 (file version 11.0.9600.17416) into Windows 10 and using it instead but the same thing happens.)

Community
  • 1
  • 1
Ross
  • 4,460
  • 2
  • 32
  • 59
  • I can't reproduce the problem on my Windows 10 box (building from Windows 10's %windir%\SysWOW64). Do you have a reproducing exe or something that helps? – Simon Mourier Mar 28 '16 at 13:25

1 Answers1

3

Yes another reminder that XP is truly over and done with. When I run dumpbin.exe /headers on the EXE file that IExpress generates, I see:

  OPTIONAL HEADER VALUES
       ....
       10.00 operating system version
       10.00 image version
        6.00 subsystem version
       ....

The subsystem version number is the first show-stopper, 6.00 is the version number of Vista. That is fixable, you can run Editbin.exe to change it with the /SUBSYSTEM option, XP is 5.01

The operating system and image version is the bigger problem, can't fix that with Editbin.exe. Not actually sure how much attention XP pays to its value, getting 10.00 is very new. I don't have a machine with XP anymore, just try it.

Copying the old version of IExpress.exe is not enough. It uses c:\windows\syswow64\makecab.exe to actually get the job done. I see some cursory evidence that it is the actual source of the EXE header content. Don't just blindly copy that EXE into the windows directory, that's too risky. Keep it separate.

The sane way to go about this is otherwise to keep a bootable copy of XP around, either on its own machine or a VM. You need it anyway to troubleshoot customer problems that are specific to XP. Pay the hassle of still having to support XP forward to the customer and they tend to do the wise and necessary thing a lot quicker. Can't help you with that.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks for the info - I never knew about dumpbin.exe. Force changing the subsystem version does not work unfortunately - I instead receive the message "The procedure entry point _except_handler4_common could not be located in the dynamic link library msvcrt.dll". And trying to alleviate that error causes even further issues. I think I'll have to continue to do the iexpress.exe step of my build on Windows 8, and think about killing XP support for a future version of my application (which I'm keen to do anyway as XP support is holding me back at .NET 4.0). – Ross Mar 29 '16 at 08:23