I have some issue: I have an installscipr project type installer. In one place in installscript it uses WINDIR static variable to get to ADAM component, which gets installed to c:\Windows\ADAM with typical configuration.
Everything used to work fine.
Now I have one customer reporting errors with installation. From the installation log it appears that the path constructed with
WINDIR ^ "ADAM"
gets the folloowing value: c:\Documents and Settings\\WINDOWS\ADAM Initially I thought that the user has some unusual security setup that changes value of %windir% environment variable and I was sure that this is the source of the InstallScript value. Well - apparently it is not.
Even after explicitly setting %windir% value to C:\WINDOWS (by default it redirects to %SystemRoot%) the issue is still present.
So:
How is the WINDIR variable in InstallScript constructed? Installshield help says:
InstallShield initializes the system variable WINDIR by assigning to it the name of the folder that contains the main operating environment, for example C:\Windows.
which is not very helpful about telling where it gets it from.
ChandanOmkar wrote: use WindowsFolder in place of WINDIR. Hope this will help.
Well, I haven't claimed I don't know how to resolve the bug in installer... I'd rather take into consideration that ADAM component indeed can be deployed somewhere else and read its location from registry. But that's the whole different issue. I have a released product at customer site. The question is - how do I make the installation pass at customer machine with the current stata and I can't do it without knowing the answer to WINDIR origin question.
Fixing and releasing a new set of deployment packages takes around a week including whole approval process...
WINDIR is obtained through a call to the Win32 API GetSystemWindowsDirectory. Normally this will return a path such as C:\Windows, but if the installation process is running through Terminal Services/Remote Desktop, a user specific Windows folder may be returned. Logging on to the machine directly should allow WINDIR to resolve to C:\Windows.
joshstechnij wrote: WINDIR is obtained through a call to the Win32 API GetSystemWindowsDirectory. Normally this will return a path such as C:\Windows, but if the installation process is running through Terminal Services/Remote Desktop, a user specific Windows folder may be returned. Logging on to the machine directly should allow WINDIR to resolve to C:\Windows.
Thanks for the relpy, that really helped. However, seems like you'd have to use GetWindowsDirectory for this issue to appear not the one you've mentioned - see MSDN documentation for both functions...
