Re: FW: Certain files in the system32 directory are not listed

[Brian Dessent <brian at dessent dot net>]

Dave Korn wrote:

> "  On 64-bit systems, Windows system files for 64-bit applications are stored
> in the $WINDIR/System32 directory. To avoid confusion, the system files for
> 32-bit applications are stored in the $WINDIR/SysWOW64 directory.  "
> 
>   For crying out loud!  <headdesk>  Did you all get that?  To "avoid
> confusion", 64-bit executables live in a directory that ends in "32", and
> 32-bit executables live in a directory that ends in "64".
> 
>   Obvious really, I can't imagine *why* I didn't think of that myself.
> 
>   Well, "to avoid confusion", I'm now going to break all five of Bill Gates'
> fingers.  Meaning all ten.

I know it's hugely out of character to defend Microsoft but I'm going to
do it anyway.

I'm am 100% sure they could have made the sane choice in this matter
(and many other past matters) if they were willing to make porting
existing apps harder.  If you look at it from the standpoint of
"millions of lines of existing code expect to find the directory named
$current_value" (where current_value=%WINDIR%\system32) then it makes a
little more sense.  No matter whether you are compiled as a 32 bit or 64
bit app, you don't have to use any #defines or make any calls to the
win32 API, the system dir is still always accessed as just
%WINDIR%\system32.

For WOW64 (that is, running 32 bit apps in Windows X64) I'm pretty sure
there are already thunks for most API functions, so it wouldn't be too
hard to add a shim to redirect 32 bit calls for %WINDIR%\system32 to a
different physical location, but for native 64 bit apps without thunks I
think you'd have a lot harder time selectively redirecting parts of the
filesystem like that without hurting performance, thus the outcome that
32 bit stuff is under WOW64 and "native" 64 bit stuff is under the
legacy name.

Microsoft really does get taken out to the pasture about things like
this, but at the same time the billions of people that have written
commercial code for Windows (and who get really antsy when their
precious little income pony starts to look sick) pat Microsoft on the
back for these little things that make the porting process easier, or
just general binary backwards compatibility.

I could be wrong but I think this is also the logic behind the 32IL/64P
decision, in that structs have the same size/layout as long as they
don't contain pointers, and are thus backwards compatible for file
formats or whatever.

Another example: It's always a party on free software mailing lists when
the antiquated PE format gets slandered when compared to all the neat
stuff in ELF.  "Oh, this dllexport/dllimport stuff really sucks."  "God,
why can't I have lazy binding?"  "Why should link order matter?"  And so
on.  [ Some even call it Woe32 for these reasons, a name I find quite
immature and childish -- you can either use and develop for the OS or
not, it's your choice; if you don't like it then stop using it, but
don't bitch that it causes you woe. ]  But anyway my point was that
while PE may have millions of warts and truly is The Suck compared to
ELF, it is still binary backwards-compatible to ancient software from
the early/mid 90s.  If you have a look at a linux distro from that
vintage you'll see a.out, which was indeed quite barbaric compared to
modern ELF.

Now you might say that you can still enable a.out format capability in a
modern linux kernel, and thus it's possible to introduce new features
without breaking backwards compatibility.  But again that works fine in
the case of free software, but if Microsoft did that they'd have a huge
mess on their hands: no commercial software vendor would ship "PE-new"
versions of their binaries because only customers using the latest
version of Windows could run them.  They would have to ship two
versions, or MS would have to come up with some kind of "fat" format. 
And the pain would just multiply for shared code in libraries.

It's all been done in the past by Apple and I don't think anyone would
call it particularly pleasant, but at least in that case there was a
justifiably good reason (hardware architecture) and not just "we really
are tired of supporting this binary format from the dark ages that has
some inconveniences."  So this "PE-new" really would not get much
traction from vendors, and would probably end up a failure.  I can't
fault Microsoft for refusing to do something that can easily be foreseen
as a total spectacular failure.

Brian