Prev: ATI Catalyst 10.6 released
Next: seven ultimate x86-64 don't go S4
From: Carlos on 18 Jun 2010 12:34
R.C.,
The Program Files naming makes sense.
But using \windows\system32 for all the 64-bit stuff...
Still trying to find any logic there.
:)
Carlos

"R. C. White" wrote:

> Hi, Trond.
>
> As Jeff said, you've got it backwards. Actually, in my opinion, it is
> Microsoft who "got it backwards"! :>(
>
> When 64-bit Windows XP arrived - about 5 years ago - I installed it on my
> new 64-bit CPU/mobo. I saw this NEW "Program Files (x86)" folder. Like
> you, I assumed that, since this folder did not exist in my 32-bit WinXP,
> then it MUST be for 64-bit apps. All my apps at that time were 32-bit, of
> course, so I forced them all into the original Program Files folder. It
> took several months for me to learn that I was 180 degrees out of sync! :>(
>
> I was multi-booting WinXP, Win2K and Win98 before WinXP X64, and installing
> each app multiple times into a single Program Files folder on a "neutral"
> drive (one with no OS on it), letting each setup file write
> platform-specific information into each Registry, but saving disk space by
> having them all use the single copy of the .exe, .dll etc. files. This
> worked well - until X64. Before I learned how to use that x86 folder, I had
> hopelessly tangled multiple installations of Excel (for example) in
> E:\Program Files. WinXP Pro correctly recognized it as a 32-bit app, but
> WinXP X64 thought it was a 64-bit app. I'm not a techie, but my
> understanding is that the problem is not just with the .exe file itself, but
> with the many .dll and other support files that need to be in the proper
> folder so that the 64-bit OS can find them and match them up.
>
> Since learning that "x86" refers to the Intel x86 family of 32-bit CPUs
> (8086, 80286, etc.), I've accepted Microsoft's backwards naming. And since
> disk space is much cheaper now, I no longer try to share app installations
> between Windows versions. All 32-bit apps go into PF86 (my own
> abbreviation) and all 64-bit apps into PF. But I still think that if MS had
> created a new Program Files (x64), rather than what they did, it would have
> been a lot less confusing for us users.
>
> RC
> --
> R. C. White, CPA
> San Marcos, TX
> rc(a)grandecom.net
> Microsoft Windows MVP
> Windows Live Mail 2009 (14.0.8089.0726) in Win7 Ultimate x64)
>
> "T.Wahl" <twahl(a)getmail.no> wrote in message
> news:OK$U#IlDLHA.4636(a)TK2MSFTNGP02.phx.gbl...
> > I am running 64 bit Win7.
> > Adobe Reader is automatically installing in C:/Programfiles (x86). (64
> > bit, I think)
> > I would like to install the program in C:/Programfiles (32bit part, I
> > presume).
> > The reason is that I want Adobe Reader to show PDF documents as a
> > thumbnail in Explorer instead of the anonymous PDF icon.
> > As you may know,there is no 64 bit driver for Adobe Reader, only a "Win7
> > driver"
> > I am using Win7 32 bit at work and PDF files are shown as thumbnails
> > (showing the first page of the document)
> >
> > Is there any way of forcing a program (Adobe Reader) to be installed as a
> > "32 bit program" in C:/Programfiles?
> >
> > Best regards
> > Trond W
>
From: Dave Warren on 18 Jun 2010 12:37
In message <0FFD5FCD-2CA0-43F7-BF03-84A28BDBEB4A(a)microsoft.com> "R. C.
White" <rc(a)grandecom.net> was claimed to have wrote:

>Since learning that "x86" refers to the Intel x86 family of 32-bit CPUs
>(8086, 80286, etc.), I've accepted Microsoft's backwards naming. And since
>disk space is much cheaper now, I no longer try to share app installations
>between Windows versions. All 32-bit apps go into PF86 (my own
>abbreviation) and all 64-bit apps into PF. But I still think that if MS had
>created a new Program Files (x64), rather than what they did, it would have
>been a lot less confusing for us users.

MS' mistake was omitting the architecture at all. This is a much older
problem than XP, going back to when NT ran on multiple architectures it
was decided that "Program Files" would be the default location for any
native application, and non-native applications would get tossed into
"Program Files (architecture type)"

This causes a small amount of confusion for people first running a
non-typical architecture, especially since no one has seen a non-native
application in a very long time.
From: R. C. White on 18 Jun 2010 15:20
Hi, Dave.

Thanks for that history and background!

I'm not techie enough to understand it completely, but that is the first
explanation I've heard that made any sense to me.

RC
--
R. C. White, CPA
San Marcos, TX
rc(a)grandecom.net
Microsoft Windows MVP
Windows Live Mail 2009 (14.0.8089.0726) in Win7 Ultimate x64)

"Dave Warren" <dave-usenet(a)djwcomputers.com> wrote in message
news:hm7n169hvrcbjuu51i8i9970ndpr7r5mq9(a)4ax.com...
> In message <0FFD5FCD-2CA0-43F7-BF03-84A28BDBEB4A(a)microsoft.com> "R. C.
> White" <rc(a)grandecom.net> was claimed to have wrote:
>
>>Since learning that "x86" refers to the Intel x86 family of 32-bit CPUs
>>(8086, 80286, etc.), I've accepted Microsoft's backwards naming. And
>>since
>>disk space is much cheaper now, I no longer try to share app installations
>>between Windows versions. All 32-bit apps go into PF86 (my own
>>abbreviation) and all 64-bit apps into PF. But I still think that if MS
>>had
>>created a new Program Files (x64), rather than what they did, it would
>>have
>>been a lot less confusing for us users.
>
> MS' mistake was omitting the architecture at all. This is a much older
> problem than XP, going back to when NT ran on multiple architectures it
> was decided that "Program Files" would be the default location for any
> native application, and non-native applications would get tossed into
> "Program Files (architecture type)"
>
> This causes a small amount of confusion for people first running a
> non-typical architecture, especially since no one has seen a non-native
> application in a very long time.

From: Robert Aldwinckle on 19 Jun 2010 00:15


"R. C. White" <rc(a)grandecom.net> wrote in message
news:0FFD5FCD-2CA0-43F7-BF03-84A28BDBEB4A(a)microsoft.com...
> Hi, Trond.
>
> As Jeff said, you've got it backwards. Actually, in my opinion, it is
> Microsoft who "got it backwards"! :>(


They got it backwards the first time and now they seem to be trying to avoid
the same error. E.g. when Win32 first happened it could have happened in
System and System16 created for running old apps. If that had happened
then there would be clear reason to have X64 in System and System32
available if necessary. Notice that 16-bit support has been dropped in W7
but we still have an empty System folder! I think the problem then was
that things weren't as parameterized as they are now, so if that logical
change had been made too much 16-bit stuff would not have worked without
having to be rewritten.


---

From: Jeff Zeitlin on 19 Jun 2010 14:14
On Fri, 18 Jun 2010 09:23:37 -0500, "R. C. White" <rc(a)grandecom.net>
wrote:

>Since learning that "x86" refers to the Intel x86 family of 32-bit CPUs
>(8086, 80286, etc.), I've accepted Microsoft's backwards naming. And since
>disk space is much cheaper now, I no longer try to share app installations
>between Windows versions. All 32-bit apps go into PF86 (my own
>abbreviation) and all 64-bit apps into PF. But I still think that if MS had
>created a new Program Files (x64), rather than what they did, it would have
>been a lot less confusing for us users.

An even better choice on MS's part would have been that with the advent
of 64-bit version of the OS, drop the un-modified "Program Files"
directory/folder entirely; put 32-bit executables into "Program Files
(32-bit)" and 64-bit executables into "Program Files (64-bit)". That
way, there'd have been no confusion whatsoever. Similarly for the
Windows/System directory/folder; ...System32 and ...System64 would have
been the better choice - and in fact, consistent with what they
apparently intended to do with the advent of 32-bit Windows, when
"System" and "System32" were created; System was 16-bit supporting files
(e.g., DLLs), while the new System32 was for the new 32-bit supporting
files.

That's all in the past, now, and we have to live with what MS /actually/
did instead of what they /should/ have done...
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: ATI Catalyst 10.6 released
Next: seven ultimate x86-64 don't go S4