Tony
Wed Oct 05 04:24:37 CDT 2005
Thanks, Darrell - Chuck; from pure curiosity, and because some few people
here seem to be affected by side-effects to this (default Program Files
aliasing), if you create a '..\Program Files(86)\Test' directory and make a
call to get your current directory from there, and it returns 'Program
Files\Test', you are bound to wonder:
"where is the aliasing taking place?"
Disregarding the fact that the procedure to do so would be improper, and
that other proper ways of acheiving the objective exist, I think it might be
productive to learn a bit of the gory internals. Realizing, of course, that
it could be a lenghty matter not ideally discussed here. Darrell, usually
knows how to distribute a few 'golden words'?
And I realize that, what I call 'aliasing', may technically be something
quite 'other'. But it do look like that, to me. Will this peculiarity
disappear if you use a Windows Installer, for instance?
Tony. . .
""Darrell Gorter[MSFT]"" <Darrellg@online.microsoft.com> wrote in message
news:yhNsLNEyFHA.3920@TK2MSFTNGXA01.phx.gbl...
> Hello,
> Checking up on this, it looks like this is the how it is intended to work.
> For many legacy apps returning %windir%\syswow64 or \Program File (x86)
> would break the applications.
>
> Thanks,
> Darrell Gorter[MSFT]
>
> This posting is provided "AS IS" with no warranties, and confers no rights
> --------------------
> <From: "Tony Sperling" <tony.sperling@dbREMOVEmail.dk>
> <References: <8031A8F6-33D2-4181-B320-E1E25D7F45C7@microsoft.com>
> <uoWvEapxFHA.3860@TK2MSFTNGP09.phx.gbl>
> <6B1D496F-8C3C-4589-8A48-EF040947127E@microsoft.com>
> <Subject: Re: GetCurrentDirectory() returns non-redirected path
> <Date: Sat, 1 Oct 2005 21:41:21 +0200
> <Lines: 81
> <X-Priority: 3
> <X-MSMail-Priority: Normal
> <X-Newsreader: Microsoft Outlook Express 6.00.3790.1830
> <X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
> <X-RFC2646: Format=Flowed; Original
> <X-Antivirus: avast! (VPS 0539-3, 30-09-2005), Outbound message
> <X-Antivirus-Status: Clean
> <Message-ID: <OGybeAsxFHA.3000@TK2MSFTNGP12.phx.gbl>
> <Newsgroups: microsoft.public.windows.64bit.general
> <NNTP-Posting-Host: 82.143.202.21
> <Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP12.phx.gbl
> <Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.64bit.general:18533
> <X-Tomcat-NG: microsoft.public.windows.64bit.general
> <
> <Ah, well that is unusual - I agree, that would have raised a few eyebrows
> <here as well. The only explanation I can come up with is that the
> <re-direction is performed as a form of 'aliasing', and I still think it
> may
> <all be controlled by some sort of pre-compiler directive or macro or
> <something. Clearly, it works fine in a forward fashion, but not
> backwards!
> <If it is a 'C' language, it could be that there are similarly named
> <functions both in the Class Library and the old Standard 'C' Function
> <Library, and maybe you should venture to make a direct call to whatever
> <other library you didn't use? 'C++' makes provisions for you specifially
> to
> <do that!
> <
> <But then again, maybe this 'aliasing' isn't supposed to work backwards.
> <Maybe you are allright. Perhaps both these locations are 'C:\Program
> Files',
> <seen from inside? I mean, providing you didn't actually create a
> 'C:\Program
> <Files\Test' directory your self, because that is the oddest thing, don't
> you
> <agree?
> <
> <Whatever it is, I would certainly expect something like that to be in the
> <documentation, although it may be an effort to find it. I would turn to a
> <programmers group for quality advice.
> <
> <Greetings, Tony. . .
> <
> <
> <"Rafael Rivera [Extended64.com]"
> <<RafaelRiveraExtended64com@discussions.microsoft.com> wrote in message
> <news:6B1D496F-8C3C-4589-8A48-EF040947127E@microsoft.com...
> <> The language is irrelevant really... On x64, if one tries to write to
> <> C:\Program Files using a 32-bit process, it gets redirected to
> C:\Program
> <> Files (x86). That's fine. The use of GetCurrentDirectory() should pick
> up
> <> the
> <> redirected path but it doesn't, therefore my 32-bit application tries
> to
> <> look
> <> for files in the wrong Program Files directory.
> <>
> <> Here's an alternate explanation:
> <>
> <> * Application resides in C:\Program Files (x86)\Test
> <> * GetCurrentDirectory() incorrectly returns C:\Program Files\Test
> <>
> <> --
> <> Rafael Rivera
> <> Extended64 |
http://www.extended64.com
> <>
> <>
> <> "Tony Sperling" wrote:
> <>
> <>> I am not sure how to interpret this. . .it returns your 'current
> <>> directory',
> <>> you should not expect it to re-direct anywhere - or, where would you
> want
> <>> it
> <>> re-directed to?
> <>>
> <>> If you are referring to the default 'programs' directory - I would
> assume
> <>> that to depend on compiler directives. Otherwise, the question of
> where
> a
> <>> certain program belongs, would be totally ambiguous - and that
> wouldn't
> <>> be
> <>> returned from that function anyhow, I think.
> <>>
> <>> Regards, Tony. . .
> <>>
> <>> P.S. - Ahem, what language?
> <>>
> <>>
> <>> "Rafael Rivera [Extended64.com]"
> <>> <RafaelRiveraExtended64com@discussions.microsoft.com> wrote in message
> <>> news:8031A8F6-33D2-4181-B320-E1E25D7F45C7@microsoft.com...
> <>> > Can someone verify this? The use of the GetCurrentDirectory()
> function
> <>> > returns the non-redirected path (e.g. C:\Program Files) on x64
> <>> > platforms.
> <>> > I
> <>> > had to add new code just to accommodate for this case...
> <>> >
> <>> > --
> <>> > Rafael Rivera
> <>> > Extended64 |
http://www.extended64.com
> <>>
> <>>
> <>>
> <
> <
> <
>