FW: Certain files in the system32 directory are not listed

FW: Certain files in the system32 directory are not listed

[Dave Korn]

On 07 June 2007 17:55, John Cooper wrote:

> It seems the MKS tools turn off this redirection by default, and
> provides an env variable (TK_WOW64FSREDIR_ON) for enabling it:
> http://www.mkssoftware.com/docs/man5/envvar.5.asp


  Why do I feel like I've been being beaten around the head with the
stupid-stick?  Some things are just so dumb they actually have negative IQ, if
you get too close to them they suck all the intelligence out of your brain.
This is one of those times:-


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

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

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

[Matthew Woehlke]

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

...what did you expect from the platform that brought us the 
ever-so-helpful sizeof(void*) != sizeof(long)? Microsoft's approach to 
64-bit was to make things look as much as possible like 32-bit, rather 
than making logical choices.

-- 
Matthew
Any sufficiently advanced bug is indistinguishable from a feature.
(...with apologies to Arthur C. Clarke)

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

[Dave Korn]

On 07 June 2007 18:26, Matthew Woehlke wrote:

> 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.  " 
> 
> ...what did you expect from the platform that brought us the
> ever-so-helpful sizeof(void*) != sizeof(long)?

  Actually there's nothing really wrong with that.  The C language spec makes
no such guarantee.  That's why we have things like [u]intptr_t, intmax_t and
ptrdiff_t.  Any code that assumes a relationship between the size of a pointer
and the size of a long int is just bogus.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

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

[Matthew Woehlke]

Dave Korn wrote:
> On 07 June 2007 18:26, Matthew Woehlke wrote:
>> 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.  " 
>> ...what did you expect from the platform that brought us the
>> ever-so-helpful sizeof(void*) != sizeof(long)?
> 
>   Actually there's nothing really wrong with that.  [snip]

True, but Microsoft is the /only/ platform I know of that decided to be 
different :-).

-- 
Matthew
Any sufficiently advanced bug is indistinguishable from a feature.
(...with apologies to Arthur C. Clarke)

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

[Christopher Faylor]

On Thu, Jun 07, 2007 at 02:05:43PM -0500, Matthew Woehlke wrote:
> Dave Korn wrote:
>> On 07 June 2007 18:26, Matthew Woehlke wrote:
>>> 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.  " 
>>> ...what did you expect from the platform that brought us the
>>> ever-so-helpful sizeof(void*) != sizeof(long)?
>>   Actually there's nothing really wrong with that.  [snip]
>
> True, but Microsoft is the /only/ platform I know of that decided to be 
> different :-).

There certainly were other platforms (Cray maybe?) where that was true.
I remember the pain of dealing with all of those assumptions my program
when we did that port.

cgf

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

[Brian Dessent]

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

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

[Gary R. Van Sickle]

> From: Matthew Woehlke
> Sent: Thursday, June 07, 2007 2:06 PM
> 
> Dave Korn wrote:
> > On 07 June 2007 18:26, Matthew Woehlke wrote:
> >> 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.  "
> >> ...what did you expect from the platform that brought us the 
> >> ever-so-helpful sizeof(void*) != sizeof(long)?
> > 
> >   Actually there's nothing really wrong with that.  [snip]
> 
> True, but Microsoft is the /only/ platform I know of that 
> decided to be different :-).

Tons (probably the vast majority) of compilers for embedded micros don't
have sizeof(void*) == sizeof(long).

-- 
Gary R. Van Sickle
 

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

[Corinna Vinschen]

On Jun  7 16:48, Brian Dessent wrote:
> 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.
> [...]

You're taking all the fun out of the discussion by saying that this
was a reasonable business-oriented decision.  Heck, since when are
we reasonable on cygwin-talk (or, FWIW, on any Cygwin list)?

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

Not quite.  This "PE-new" format could have been used for 64 bit
executables from the start and so it would have been automatically
adopted by vendors when porting to 64 bit. 

And even for 32 bit systems, supporting multiple binary formats would
have been possible.  I'm also sure it would have been adopted over
the time, given that a lot of software vendors stop supporting older
OSes rather quickly.


Corinna

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

[Brian Dessent]

Corinna Vinschen wrote:

> Not quite.  This "PE-new" format could have been used for 64 bit
> executables from the start and so it would have been automatically
> adopted by vendors when porting to 64 bit.

You're right, they did miss a fairly uncommon opportunity to right a lot
of wrongs.  It appears that their 64 bit implementation strategy was
more along the lines of "gentlemen, how can we fit 64 in this size 32
pair of pants?" than anything else.

Brian

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

[Igor Peshansky]

On Thu, 7 Jun 2007, Brian Dessent wrote:

> 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.
>
> [snip rational explanation uncharacteristic for this list]
>
> thus the outcome that 32 bit stuff is under WOW64 and "native" 64 bit
> stuff is under the legacy name.

So, what you're saying is that Microsoft is guilty of unfortunate
directory naming?  They should have named it "Legacy32forWOW64" or smth?

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

Isn't this already happening anyway?  Vendors ship apps that are
WinXP-only, or Win2k-only, and soon Vista-only.  With the API
incompatibilities, new apps will not run on older systems.  Having a
different executable format just makes it more explicit.

One possible (slight) advantage is that older apps run unchanged on newer
systems with the current scheme (modulo deprecated APIs).  But that effect
can also be achieved by an emulation layer in the case of a new executable
format.  This does not absolve Microsoft of the PE mess.

[insert obligatory hippo reference here]
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Freedom is just another word for "nothing left to lose"...  -- Janis Joplin

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

[Matthew Woehlke]

Gary R. Van Sickle wrote:
> From: Matthew Woehlke
>> True, but Microsoft is the /only/ platform I know of that 
>> decided to be different :-).
> 
> Tons (probably the vast majority) of compilers for embedded micros don't
> have sizeof(void*) == sizeof(long).

Hmm, I probably should have said sizeof(void*) <= sizeof(long), do those 
"tons of embedded micros" satisfy that, at least? (I can understand long 
being *bigger*, it's the P64 model I don't get.)

-- 
Matthew
"In the beginning was the word, and the word was
content-type: text/plain" -- Martin Schulze

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

[Matthew Woehlke]

Brian Dessent wrote:
> 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.

Ultimately, the problem from my perspective is it screwed over everyone 
that has been writing 64-bit safe code for POSIX platforms for years and 
years. IOW, it was a good decision for people that wrote bad code, and a 
bad decision for people that wrote portable code. (Anyone surprised? No? 
Good.)

When I had to do a port to Win64, the LP64 model being the "de facto 
standard" for 64-bit platforms was already well entrenched.

-- 
Matthew
"In the beginning was the word, and the word was
content-type: text/plain" -- Martin Schulze