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.
For extra fun, give a runnable file (any EXE, or CMD or BAT file) "install" or "setup" (I think that a prefix also works). You'll get a "do you want to run this setup program" dialog unless you have UAC turned off.
This is hard-coded in some horrible place. It cost me a day once. I mentioned it to a guy next to me at work (random sample ex-MS dev) and said the same thing.
The Windows kernel is (for the most part) a pretty good piece of engineering. The stuff on top of it, not so much.
Of course it's hardcoded. In Vista and above you have to include a manifest file telling the OS whether you require elevation or not. In order to support old applications written pre-Vista, and to protect users against developers who don't care to learn how installers are supposed to work, Windows will force UAC if the file name sounds like something a setup program would call itself, particularly when most installers will install or modify things that require Admin privileges -- such as writing to Program Files.
This seems perfectly sane and reasonable to me. What's the alternative? That manifest-less installers should fail because a user forgot to manually elevate a program by shift-right clicking it and selecting "Run as Administrator", all because they upgraded their OS and now their installers won't run any more?
This is a good example of the straightjacked of backwards compatibility. Not too long, not too short, a fun display both of people who know what they're talking about vs just complaining.
Also a good example of inside the box thinking. The reason you need to run a 16 bit installer is the software isn't free or open source therefore a simple recompile with a newer version of debhelper or whatever isn't going to bring it up to modern packaging standards.
> The reason you need to run a 16 bit installer is the software isn't free or open source therefore a simple recompile with a newer version of debhelper or whatever isn't going to bring it up to modern packaging standards.
On the other hand, the old windows software in question will most likely actually run. Debhelper is irrelevant: confronted with a package of comparable age on Linux, you'll be digging up the source code and trying to make it build, not merely tweaking the package, with all its ancient dependencies.
"The reason you need to run a 16 bit installer" is to display a nice "Tough luck, you need a 32-bit computer to install this" message to the user, instead of an ugly Windows error message.
This was important at the time. And the whole point of backward compatibility is to allowed old applications (written, compiled and packaged at that time) to work.
Even if the software is open-source and has been repackaged in the meantime, the old version you found on a long-forgotten CD rotting away in your basement doesn't have that. The Windows philosophy is to make sure that this one still works (which is a crazy goal IMO, but an interesting one).
There's no point in thinking outside the box when the box was built twenty years ago and your entire job is to make the stuff inside it keep working for another OS release.
"Windows: A 64-bit extension to a 32-bit patch for a 16-bit GUI shell running on top of an 8-bit operating system written for a 4-bit processor by a 2-bit company who cannot stand 1 bit of competition."
Unfortunately, no longer really true since they switched from the DOS based Windows to the Windows NT branch. (At least I think so.)
The snide about competition has also become somewhat hollow. Microsoft would love to go back to the monopoly days of the late nineties. But those days are gone.
Ah, my favorite problem with Win9x in fact was how Caldera was able to continue to sue MS based on the fact that it was based on DOS. I mentioned it in my blog article on the MS OS/2 2.0 fiasco and it should be obvious why.
People speculate in the comments that Microsoft could provide a 16bit emulator in Windows for DOS applications. In fact they have an x86 emulator in Windows, but not for DOS.
It's used to run int10h calls (VGABIOS) on early initialization, funnily even on UEFI.
I don't understand why they gave up on DOS compatibility for 64-bit Windows.. the effort could not have been all that much for them (either with an emulator or x86 tricks). The benefit is huge: they can continue the lock-in of ancient DOS programs. For example, I can report that OrCAD for DOS works better in 32-bit Windows XP better than it ever did in MS-DOS.
Likewise, I don't understand why vm86 mode can not run directly from 64-bit mode in x86. This seems very like an architectural mistake to me.
It's worth pointing out that, while 64-bit Windows has dropped its 16-bit layer, 64-bit Wine has not. You can happily run your original 16-bit version of Chip's Challenge on an out of the box 64-bit Linux/Wine install these days.
All this is exactly why I've stopped buying PCs and use Windows. Silly inconsistencies like shell not supporting > 260 file paths (I know that some Win32 APIs and NT itself limits file paths to 32,768 or so Unicode characters), but it's all those patches, inconsistencies, limited shell (cmd.exe), drive letters which drive me crazy. With Mac OS X and Linux all that is gone, and the world seems a better place now.
The idea to do something like that is just plain... ugly. It's almost like guessing MIME type based on the file content (hint: IE). I wonder how long it will take until someone finds a security exploit of this "feature"?
> I wonder how long it will take until someone finds a security exploit of this "feature"
I'm not sure what exactly crafting a 16-bit installer file to exploit some bug in the bundled installshield to get it to execute code of your choosing (when the user tries to run your installer) would achieve.
You've got the user to run an installer that you've made. They've just double-clicked on your program. Forget crafting dodgy installer data files, you can run whatever code you like just by... running it.
Moreover, given the user is trying to install your program, they'll be happy to elevate its privileges, too (through UAC). So your arbitrary code is running as admin - what more could a security flaw in the bundled installshield get you? (And if the user doesn't think your program's an installer, they're not going to be any less confused by the appcompat installshield's UAC prompt than if your program just tries to elevate by UAC by itself. It's not like the bundled one is setuid root (or the windows equivalent)).
[+] [-] btilly|12 years ago|reply
"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.
[+] [-] mikeash|12 years ago|reply
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.
[+] [-] kabdib|12 years ago|reply
This is hard-coded in some horrible place. It cost me a day once. I mentioned it to a guy next to me at work (random sample ex-MS dev) and said the same thing.
The Windows kernel is (for the most part) a pretty good piece of engineering. The stuff on top of it, not so much.
[+] [-] mickeyp|12 years ago|reply
This seems perfectly sane and reasonable to me. What's the alternative? That manifest-less installers should fail because a user forgot to manually elevate a program by shift-right clicking it and selecting "Run as Administrator", all because they upgraded their OS and now their installers won't run any more?
[+] [-] VLM|12 years ago|reply
Also a good example of inside the box thinking. The reason you need to run a 16 bit installer is the software isn't free or open source therefore a simple recompile with a newer version of debhelper or whatever isn't going to bring it up to modern packaging standards.
[+] [-] justin66|12 years ago|reply
On the other hand, the old windows software in question will most likely actually run. Debhelper is irrelevant: confronted with a package of comparable age on Linux, you'll be digging up the source code and trying to make it build, not merely tweaking the package, with all its ancient dependencies.
[+] [-] gourlaysama|12 years ago|reply
This was important at the time. And the whole point of backward compatibility is to allowed old applications (written, compiled and packaged at that time) to work.
Even if the software is open-source and has been repackaged in the meantime, the old version you found on a long-forgotten CD rotting away in your basement doesn't have that. The Windows philosophy is to make sure that this one still works (which is a crazy goal IMO, but an interesting one).
[+] [-] mikeash|12 years ago|reply
[+] [-] dreen|12 years ago|reply
[+] [-] eru|12 years ago|reply
The snide about competition has also become somewhat hollow. Microsoft would love to go back to the monopoly days of the late nineties. But those days are gone.
[+] [-] yuhong|12 years ago|reply
[+] [-] pgeorgi|12 years ago|reply
It's used to run int10h calls (VGABIOS) on early initialization, funnily even on UEFI.
[+] [-] jhallenworld|12 years ago|reply
Likewise, I don't understand why vm86 mode can not run directly from 64-bit mode in x86. This seems very like an architectural mistake to me.
[+] [-] quasque|12 years ago|reply
[+] [-] YokoZar|12 years ago|reply
[+] [-] amaks|12 years ago|reply
[+] [-] ateeqs|12 years ago|reply
[+] [-] amenod|12 years ago|reply
[+] [-] SEMW|12 years ago|reply
I'm not sure what exactly crafting a 16-bit installer file to exploit some bug in the bundled installshield to get it to execute code of your choosing (when the user tries to run your installer) would achieve.
You've got the user to run an installer that you've made. They've just double-clicked on your program. Forget crafting dodgy installer data files, you can run whatever code you like just by... running it.
Moreover, given the user is trying to install your program, they'll be happy to elevate its privileges, too (through UAC). So your arbitrary code is running as admin - what more could a security flaw in the bundled installshield get you? (And if the user doesn't think your program's an installer, they're not going to be any less confused by the appcompat installshield's UAC prompt than if your program just tries to elevate by UAC by itself. It's not like the bundled one is setuid root (or the windows equivalent)).
See also: http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...
[+] [-] TeMPOraL|12 years ago|reply
Hint: Linux? It does something similar pretty much on the OS level.
[+] [-] Theodores|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] losethos|12 years ago|reply
[deleted]