My favorite comment in the thread is from John Ludlow who explained why you would want to package a 32 bit program with a 16 bit installer:
"The installer has to be the lowest common denominator in terms of bitness. This is because it needs to be able to check whether the application can run on that system and give an intelligent "um, you can't install Program X because your computer is 16-bit and doesn't support it" message rather than falling over in a big heap."
Exactly right. And the kind of detail that is easy to forget about.
That's really something the OS should be able to do. It ought to be able to examine the dependencies of the app and throw up a helpful alert if they're not met.
Of course, since the common case is newer apps on older OSes, that requires thinking ahead before such a problem actually happens, and that's tough. Even if you implement it, it's hard to get right because it's hard to really test. Apple does this, but the facility was broken in several Mac OS X releases, making it far less useful than it should have been.
In the case of 16-bit Windows, this would have been particularly difficult to foresee. Even when Windows 3.0 shipped, it was still planned that OS/2 would be the 32-bit successor to Windows, so there was no 32-bit Windows target even on the roadmap.
(According to the book Showstopper!, when Microsoft ditched OS/2, they created Win32 by taking the OS/2 API and fixing any divergences from Win16 to make it look as compatible as possible.)
If they had designed the win32 PE .exe format differently, they could have included a 16bit NE stub to throw up a messagebox with the message - in the same way the .exe files already include a 16bit MS-DOS MZ .exe stub with an equivalent message.
I believe this is the case. If you try to run a 16-bit executable on x64 Windows, you will receive a "not compatible" error MessageBox essentially saying WOW cannot help you.
> It ought to be able to examine the dependencies of the app and throw up a helpful alert if they're not met.
Very hard, since would require, say, a version of windows that only shipped with unmanaged executables (e.g. XP) to foresee, and properly assertion-fail, managed executables. Or any number of other bigger changes than "new API."
Nothing so smart need be done, though, I think. Just run the program, and let it crash if the dependencies aren't met. Give the crash-reporter a heuristic that detects that a program crash was dependency-based, and have it present a different UX in that instance. (This is basically the Erlang philosophy.)
"The installer has to be the lowest common denominator in terms of bitness. This is because it needs to be able to check whether the application can run on that system and give an intelligent "um, you can't install Program X because your computer is 16-bit and doesn't support it" message rather than falling over in a big heap."
Exactly right. And the kind of detail that is easy to forget about.