If there's no 16-bit layer in 64-bit Windows, how come 16-bit installers run?

http://blogs.msdn.com/b/oldnewthing/archive/2013/10/31/10461992.aspx

by luu • 13 years ago

138 79 13 years ago

blogs.msdn.com

dreen• 13 years ago

"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."

eru• 13 years ago

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.

speeder• 13 years ago

In fact a merge happened, windows kernel now is mostly NT based but has DOS era artifacts on it.

rsynnott• 13 years ago

Modern Windows (NT stream) carries a lot of baggage from Win16, however; Win32 wasn't a green-field effort.

yuhong2• 13 years ago

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.

VLM• 13 years ago

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.

gourlaysama• 13 years ago

"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).

johnchristopher• 13 years ago

Crazy ? Well, that was one of the most important selling point of MS.

I wish I could run any old software under current Ubuntu. IE: gwibber.

alecdbrooks• 13 years ago

The reason for this hack is that 32-bit software used 16-bit installers long after the switch to 32-bit. [0] This isn't a matter of supporting Windows 3.11-era software, more like Windows 9x or even XP.

[0]: Like this guy: http://www.tomshardware.com/forum/107534-13-trying-install-g....

city41• 13 years ago

MS has gone to great lengths to reach that goal. There is even special code in Windows to ensure the DOS version of SimCity works: http://ianmurdock.com/platforms/on-the-importance-of-backwar...

bluedino• 13 years ago

> The Windows philosophy is to make sure that this one still works (which is a crazy goal IMO, but an interesting one)

It's a requirement. Imagine how many people would have never upgraded to Windows 95 if their Windows 3.x programs didn't work.

Each program Microsoft 'fixes' is additional sales.

mikeash2• 13 years ago

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.

justin662• 13 years ago

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.

derleth4• 13 years ago

Actually, no: I've had a lot more luck getting old Linux software working than old Windows software, as the Windows software inevitably has DLL Hell written all over it.

thwarted2• 13 years ago

You make your linux binary executables future-proof by statically linking them. It's a rare event that it happens, but I've no problems with 15 year old a.out binaries on 64-bit systems.

ateeqs4• 13 years ago

Yeah, I am having the same issue trying to compile gcc on an emulated old MIPS. :-/

pgeorgi3• 13 years ago

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.

jhallenworld• 13 years ago

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.

MBCook• 13 years ago

As I remember, when an x86-64 chip is running in 64 bit mode, it can run 32 bit code, but the option necessary to run in 16 bit mode was removed. To run DOS they'd basically have to have a full emulator for a 286, like a limited version of bochs.

ateeqs4• 13 years ago

Mmmm, I think it's just not profitable for them to do this any more.

quasque• 13 years ago

That's interesting, do you mean early initialisation of Windows or the VDM?

pbsd• 13 years ago

This has nothing to do with VDM; the emulator is only accessible from kernel mode (it's in HAL.dll) and is not meant to be used by usermode applications. See [1,2].

[1] http://x86asm.net/articles/calling-bios-from-driver-in-windo...

[2] http://www.geoffchappell.com/studies/windows/km/hal/api/x86b...

kabdib6• 13 years ago

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.

mickeyp2• 13 years ago

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?

kabdib6• 13 years ago

It's a problem that simply naming a file 'install' or 'setup' would cause extra, unwanted behavior.

I guess it's similar to naming files PRN or NUL. You learn not to do that. It doesn't make it okay.

bcoates• 13 years ago

One of the problems with it is there's no "don't run as administrator" right click option. Developers can add a manifest, there's some crazy sysadmin tools that aren't even installed with windows to suppress it, but ordinary users don't have an out--changing the filename doesn't help, the resources in the file still identify it as "setup.exe".

This is one of the things that makes user separation hard on windows, as anyone who wants to do anything vaguely useful with the computer still needs Administrator access.

Lagged2Death• 13 years ago

I think the objection is not "old installers shouldn't be elevated" but that making the OS decide this based on the filename of the EXE is a disappointingly kludgey (but sadly unsurprising) way to do the job.

One alternative might be to have a security framework that offered the UAC prompt when a program actually attempted to do something that required elevation. I had thought that was the way UAC actually worked.

I wouldn't be surprised, given all the details, to learn that this "check the filename" approach really was the most sensible and appropriate thing to do at the time. We could call it a matter of "path dependency" if we're feeling charitable or a matter of "painting oneself into a corner" if we're not.

What I find so fascinating and irritating at the same time, every time I hear about some bit of Windows internals like this, is that MS seems to need an exit from a corner they've painted themselves into all the time.

amenod• 13 years ago

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"?

TeMPOraL• 13 years ago

It's almost like guessing MIME type based on the file content (hint: IE).

Hint: Linux? It does something similar pretty much on the OS level.

elehack2• 13 years ago

That's on your file system.

The HTTP protocol specifies that, if the server says a document is 'text/plain', the client must not attempt to second-guess it based on content.

IE second-guesses it based on content, so you cannot serve up something that looks like HTML as text/plain to get it to display.

Substantially worse, IMO.

That said, it'd be better to actually save content types in extended attributes or something. And make all applications magically save and respect these attributes.

Theriac25• 13 years ago

What the fuck are you talking about?

derleth4• 13 years ago

This is a lot more involved than magic numbers, and magic numbers are configurable.

SEMW• 13 years ago

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)).

doug11235• 13 years ago

So your arbitrary code is running as admin - what more could a security flaw in the bundled installshield get you?

In the days of Antivirus products and executable whitelists, the "elevation of privilege" may be getting arbitrary execution as any user. Of course trustedinstaller.exe or whatever that has a valid Microsoft signature can run, why shouldn't it? No need to ship that file back home either for further analysis (as AV products like to do with unknown files), its a standard OS thing. Therefore my rootkit isn't burned either.

btilly• 13 years ago

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.

mikeash2• 13 years ago

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.

Alphasite_• 13 years ago

I've always had the issue the other way round, but i guess it depends on the market.

pavlov• 13 years ago

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.)

derefr• 13 years ago

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.)

amaks• 13 years ago

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.

ateeqs4• 13 years ago

Don't laugh, but there is "PowerShell." :) (laughs)

Theodores• 13 years ago

So we are still a long way off having sensible Linux style repositories then...

YokoZar• 13 years ago

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.

If there's no 16-bit layer in 64-bit Windows, how come 16-bit installers run?

Related Stories