This is the mail archive of the cygwin-talk mailing list for the cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]