It’s quite amazing really but you can get an error message saying “(something).exe is not a valid Win32 application” when it is. Here’s the story
Firstly some background. After I released ver 2.02 of CmdTwain I started getting some strange support calls. They went along the lines of “CmdTwain.exe is not a valid Win32 application yet it runs fine on Windows 7 or 8.” To be honest, that sort of statement doesn’t make a lot of sense. A program either is or isn’t a Win32 application. It can’t change its mind when you run it somewhere else.
Of course if it runs on later OSes (Win 7 / 8 …) there’s a chance that it isn’t a valid Win32 application but a 64 bit one instead. If it were 64 bit then it wouldn’t run on 32 bit operating systems and the error message would be right: it isn’t a Win32 app at all. The fly in that ointment is, the program installs on 64 bit machines in the “Program Files (x86)” directory which is reserved for Win32 applications.
A common cause of the error used to be an interrupted download. You get part of the file, try to run it, and it says (quite sensibly) “not a valid …”. Of course, that sort of thing gives you a corrupt file that won’t run on any computer; not one with all the right errors to make it work on Win 7/8 ones. What’s more, though I didn’t realize it at the time, the installer ran just fine. A corrupt file means you get the error when you try to install what you got; instead of what you should have got. It just doesn’t install. These guys were getting a smooth install and then it just wouldn’t run.
When I was finally able to build a matching test environment and see for myself, this is what it looked like:
The hint here is later OSes are Win 7 and 8. What it wouldn’t run on was Windows XP.
There’s nothing wrong with wanting to run CmdTwain on WinXP. There are good reasons for upgrading XP and Microsoft did a mammoth job of supporting an old version for way longer than most people do. Microsoft needed to move on and needed most users to move on too. However, my users had equally valid reasons for needing to stick with XP. Old software never really wears out and if it works, or works really well, it seems at least wasteful, if not totally foolhardy, to replace it. What one of them had was software that worked in MSDOS and he’d simply moved it as far along as he could whenever the operating system changed. Apparently MSDOS support becomes a bit flakey after WinXP. I don’t know what the other person was trying to run but he had similar issues.
There were a lot of red herrings once I heard at least one of them was using MSDOS. There are 16 bit / 32 bit issues, early versus later “.exe” formats, and two different command prompt programs. None of which led anywhere.
Apparently, if there is any problem linking parts of a program together, the computer says “(something).exe is not a valid Win32 application”. It’s a lie because (something).exe can be a perfectly valid Win32 application and no amount of looking at or in “(something).exe” is going to identify anything that is not valid. As is often the case, the problem isn’t where you’re looking. The problem is a bit – or bits – missing in the operating system. Microsoft’s VC 2012 compiles apps to call parts of the operating system that aren’t present in Windows XP. Their earlier compiler, VC 2010, created programs that would run on Win XP.
Probably there is a setting somewhere that I’ve failed to set in the later compiler which enables programs to run on older OSes. I did see an article that said including VC 2010 runtimes allows VC 2012 programs to run on XP but that didn’t work when I tried that for CmdTwain. It’s likely to require some “magic” (behind the scenes setup) that the Microsoft installer automatically does for you but which isn’t in the non-Microsoft installer that I use. I did hear one person say that installing “.net” is required to get VC 2012 programs to run. It shouldn’t be required for programs compiled to “native code” (= “not using .net”) but perhaps it is.
What to do
The easy answer is “it no longer runs on XP” – but I don’t think that’s fair to those users.
The correct answer is usually to persevere and find the right combinations of settings needed to make it work. Then determine what the Microsoft installer is doing and mimic that with the other installer.
Another option is to “roll back” to VC 2010. That might be possible. They are “over the net” installs these days so I don’t have a DVD I can reinstall the earlier version with. It might still be available as a download from MS and CmdTwain ran successfully on XP when compiled with VC 2010. Despite the risk of not being able to download the compiler at some point in future, it might be an effective option for now.
The better option, from my perspective, is to move it to a compiler that is: likely to be around long term, works with Windows XP and later, and doesn’t require “and then things happen” (magic). The drawback is Windows is an MS product so the most accurate / up-to-date / valid / etc compilers for it will often be the MS Visual Studio ones.
I’ve spent quite some time trying to get this running on XP through the latest MS compiler; but I haven’t succeeded. I’m sure it’s a failing on my part for giving up too soon and that others, more familiar with “the Microsoft way” would get there. I’ve chosen instead to move CmdTwain to a different but well-established and non-MS compiler. It was easier for me to port the entire application than to adjust the settings in the original compiler.
The Solution
If you’re trying to run CmdTwain 2.01 or 2.02 on Windows XP, get CmdTwain 2.03 instead. If you already have an email with a download link, click on the link again to download the latest version. If you don’t have an email already, here’s a link to download CmdTwain.
CmdTwain 2.03 has been compiled using the GNU C++ compiler and it has been tested on Win 2003, Win 7 (32), Win XP SP2, Win XP SP3 and Win 10. I’m pretty confident that it’ll also work on other Win Servers and on 8 and 8.1. It has less dependencies on new OS functions so it should be runnable on more versions of the OS.
I’ve been told that most cmd.exe’s and even command.com’s these days understand modern Win32 applications so there’s a good chance CmdTwain can even be run from inside an MSDOS program (but I haven’t tried it, yet).
If you’re a programmer trying to solve this problem for some other program, check the usuals like: corrupt download, over-zealous antivirus, that you’ve marked the program as a Windows app, and the rc file or equivalent uses the correct Windows version. After that, if you’re using VC 2012 or 2013, start looking for settings and how the Windows installer manages to redirect calls to certain DLLs into older versions.
If you’re interested in more on the topic, I found the following useful:
http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx
http://stackoverflow.com/questions/11305633/xxxxxx-exe-is-not-a-valid-win32-application
