Installing Adobe Reader in the 32 bit part of 64 bit win7

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

A 32-bit program in Win7 64-bit, by default, installs in \Program Files
(x86) and a 64-bit program install in \Program Files

As there is only a 32-bit verion of Adobe Reader presently available it is
installing in the correct location.

"T.Wahl" <> wrote in message
news:OK$U%...
>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

On Thu, 17 Jun 2010 21:21:02 +0200, "T.Wahl" <> wrote:

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

You've got it backwards - When running Win7/64-bit, 32-bit programs get
installed into the Program Files (x86) folder; Program Files is for
64-bit programs. Adober Reader is being installed correctly for your
system.

See Fixes for 64-bit Adobe Reader preview handler and thumbnails
@ http://www.pretentiousname.com/adobe...dex.html#downl

On 2010-06-17 15:21, T.Wahl wrote:
> 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

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

Microsoft Windows MVP
Windows Live Mail 2009 (14.0.8089.0726) in Win7 Ultimate x64)

"T.Wahl" <> wrote in message
news:OK$U#...
> 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

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
>
> Microsoft Windows MVP
> Windows Live Mail 2009 (14.0.8089.0726) in Win7 Ultimate x64)
>
> "T.Wahl" <> wrote in message
> news:OK$U#...
> > 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
>

In message <0FFD5FCD-2CA0-43F7-BF03-> "R. C.
White" <> 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.

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

Microsoft Windows MVP
Windows Live Mail 2009 (14.0.8089.0726) in Win7 Ultimate x64)

"Dave Warren" <dave-> wrote in message
news:...
> In message <0FFD5FCD-2CA0-43F7-BF03-> "R. C.
> White" <> 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.

"R. C. White" <> wrote in message
news:0FFD5FCD-2CA0-43F7-BF03-...
> 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.


---

On Fri, 18 Jun 2010 09:23:37 -0500, "R. C. White" <>
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...