
If there's no 16-bit layer in 64-bit Windows, how come 16-bit installers run? - luu
http://blogs.msdn.com/b/oldnewthing/archive/2013/10/31/10461992.aspx
======
btilly
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.

~~~
mikeash
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.

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

~~~
0x0
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.

~~~
ateeqs
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.

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

~~~
mickeyp
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?

~~~
Lagged2Death
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_.

~~~
anonymfus
_> 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._

This is how it works in most cases, but it's different with access to
directories inside "Program Files" folder: because it was a common behaviour
in the past, there is a such feature as UAC virtualisation:

[http://msdn.microsoft.com/en-
us/library/bb756960.aspx](http://msdn.microsoft.com/en-
us/library/bb756960.aspx)

 _> Prior to Windows Vista, many applications were typically run by
administrators. As a result, applications could freely read and write system
files and registry keys. If standard users ran these applications, they would
fail due to insufficient access. Windows Vista improves application
compatibility for standard users by redirecting writes (and subsequent file or
registry operations) to a per-user location within the user’s profile. For
example, if an application attempts to write to C:\Program
Files\Contoso\Settings.ini, and the user does not have permissions to write to
that directory, the write will get redirected to
C:\Users\Username\AppData\Local\VirtualStore\Program
Files\contoso\settings.ini. For the registry, if an application attempts to
write to HKEY_LOCAL_MACHINE\Software\Contoso\ it will automatically get
redirected to
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or
HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso._

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

~~~
city41
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...](http://ianmurdock.com/platforms/on-the-importance-of-backward-
compatibility/)

------
dreen
"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
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
In fact a merge happened, windows kernel now is mostly NT based but has DOS
era artifacts on it.

~~~
kabdib
When I had access, I decided one afternoon to read the source to the CMD
interpreter.

It was about as bad as I thought it would be.

About an hour into using my Mac Pro's shell, I wanted to weep in relief.
Microsoft _does not get it_. (Or if they do, it gets perverted into something
like PowerShell, which I recently wasted a week on).

~~~
manojlds
What is Mac Pro's shell? You mean your shell on OS X? And what did you find so
bad with Powershell?

~~~
kabdib
The "terminal" on MacOS X. It has:

\- tabs

\- cut and paste that actually works

\- various ways to focus windows

\- hey, search!

... and a bunch of other stuff. While CMD.EXE has its feet firmly rooted in
1982 or so.

Yeah, I know you can buy more whizzy shells. But MS really has no excuse for
letting the NT console system rot as much as it has. Given that their
programmers use it /all the time/, I find it hard to believe that someone
hasn't written something better. (PowerShell overshot the mark, and wound up
being unusable).

~~~
manojlds
So all your complaints are against the terminal emulator, which everyone
agrees is bad. Use something like ConEmu. Here's Scott Hanselman on ConEmu -
[http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol...](http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsolePromptWeveBeenWaitingFor.aspx)

> PowerShell overshot the mark, and wound up being unusable

You haven't still any points against Powershell and continue to pile up on it.

~~~
eropple
ConEmu can't fully replicate the CSRSS terminal behavior. It breaks pretty
grossly when using advanced console functionality that works correctly in
CSRSS's own terminal.

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

~~~
nknighthb
I don't know what mechanisms they use, but VMware's various products run
16-bit code just fine on x86-64 chips. Are you saying they added a full 286
emulator to their virtualization products?

~~~
pgeorgi
Essentially yes. But I guess they simply kept their virtualization code from
pre-hardware virtualization times around. 286 shouldn't require much
maintenance :-)

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

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

~~~
ateeqs
Don't laugh, but there is "PowerShell." :) ( _laughs_ )

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

~~~
elehack
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.

~~~
annnnd
Actually MS broke HTTP protocol on that one and it lead to some very
interesting exploits. Malicious user could upload a GIF to some site which
allowed image uploads. Image would appear normal to a casual observer, except
that it was specially crafted so that IE thought it was actually a JavaScript
file (because it guessed the file type on its contents and didn't obey server-
side set MIME types) and executed it -> XSS.

I don't think Linux does anything remotely like this. It does allow you to use
"file" utility to guess the contents of the file, but it doesn't act on it.

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

