Sign in to follow this  
Followers 0
Shark007

@AppDataCommonDir & Windows 7

15 posts in this topic

#1 ·  Posted (edited)

One of my users, McoreD, performs an unattended installation of Windows 7 where he creates an Autounattend.xml as documented by Microsoft here: http://technet.microsoft.com/en-us/library/cc749415%28WS.10%29.aspx

contents of Autounattend.xml

<component name="Microsoft-Windows-Shell-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="amd64">
            <FolderLocations>
                <ProfilesDirectory>D:\Users</ProfilesDirectory>
                <ProgramData>D:\ProgramData</ProgramData>
            </FolderLocations>
        </component>

He chooses to move the ProgramData folder to 'D' as documented by Microsoft.

My AutoIt executable, using @AppDataCommonDir, continues to try to write to C instead of D

any assistance you could offer would be greatly appreciated.

Edited by Shark007

Share this post


Link to post
Share on other sites



Ask you program user what does s/he see when s/he run the following few commands from AutoIt or the command prompt.

Opt("ExpandEnvStrings", 1)

MsgBox(0, '1', '%programdata%')
MsgBox(0, '2', RegRead('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\Shell Folders', 'Common AppData'))

echo %programdata%

...

If everything is pointing to "C:\ProgramData" then I guess that AutoIt is actually right, if it's a mixed of "C:\..." and "D:\..." (or E...) then something is wrong with this "unattended installation"...

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

Thanks for the prompt reply. :)

AutoIt:

Results from the EXE are below:

---------------------------
1
---------------------------
G:\ProgramData   <-- CORRECT
---------------------------
OK

---------------------------
2
---------------------------
C:\ProgramData  <-- INCORRECT
---------------------------
OK

Command Prompt:

Posted Image

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

G:\Users\Mike>echo %programdata%
G:\ProgramData  <-- CORRECT

G:\Users\Mike>

Microsoft Visual C#:

MessageBox.Show(Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData), "Sample C# app", MessageBoxButtons.OK, MessageBoxIcon.Information);

Posted Image

---------------------------
Sample C# app
---------------------------
G:\ProgramData   <-- CORRECT
---------------------------
OK
---------------------------

In conclusion, Command Prompt's %programdata% and Microsoft Visual C#'s ProgramData location is consistent with the installation. It is just in AutoIt, when you do the #2 option, it gives a wrong result.

Edited by McoreD

Share this post


Link to post
Share on other sites

I think that AutoIt reads the registry key or the SHGetFolderPath API function or what not. In my opinion. It's actually, Microsoft's registry acting as a graveyard of keys and not AutoIt's fault. I think that because you're dealing with this kind of system you should read from sources the system is reading from. For example the environment variables are used by the system. Your decision.

Share this post


Link to post
Share on other sites

Apparently MS has not yet setup the install of Win 7 for unattended modes yet although I'm not sure why it should be so different from XP or Vista. One thing you might try is changimg the xml file line

<ProgramData>D:\ProgramData</ProgramData>

to

<ProgramData>%systemdrive%\ProgramData</ProgramData>


George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites

I think that AutoIt reads the registry key or the SHGetFolderPath API function or what not. In my opinion. It's actually, Microsoft's registry acting as a graveyard of keys and not AutoIt's fault. I think that because you're dealing with this kind of system you should read from sources the system is reading from. For example the environment variables are used by the system. Your decision.

Perhaps it is a change in Windows 7 the registry is not updated. I don't have access to windows 7 so I cannot verify what AutoIt can do if MS as change the way to handle %programdata% when you relocate it

Share this post


Link to post
Share on other sites

Apparently MS has not yet setup the install of Win 7 for unattended modes yet although I'm not sure why it should be so different from XP or Vista. One thing you might try is changimg the xml file line

<ProgramData>D:\ProgramData</ProgramData>

to

<ProgramData>%systemdrive%\ProgramData</ProgramData>

Things to make note of, however, is that:

ECHO %programdata%

works fine as shown above and D:\ProgramData was not set by accident.

Settings %SystemDrive%\ProgramData might make it go to C:\ProgramData which is not my intention.

I will try this in Vista and see what happens...

I agree that it is not AutoIt's fault.

http://mcored.zscreen.net/SS-2009.10.11-14.47.58.png shows that Microsoft incorrectly put C:\ instead of G:\ despite what was set in Autounattend.xml however,

I repeat,

ECHO %programdata%

works fine so that means the values are read from somewhere else. Furthermore, C# reads it from somewhere else too...

MessageBox.Show(Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData), "Sample C# app", MessageBoxButtons.OK, MessageBoxIcon.Information);

gives the correct path.

Share this post


Link to post
Share on other sites

I am now replying using Windows Vista.

AutoIt Script:

---------------------------
1
---------------------------
D:\ProgramData
---------------------------
OK   
---------------------------

---------------------------
2
---------------------------
C:\ProgramData
---------------------------
OK   
---------------------------

Command Prompt:

Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

D:\Users\Administrator>echo %programdata%
D:\ProgramData

D:\Users\Administrator>

So the problem exists in Vista too.

Like jpm pointed out, the Registry is not updated. This is not new to Windows 7. Therefore, I believe it is recommended/safe to use option 1 in the AutoIt script to determine the accurate ProgramData folder.

Share this post


Link to post
Share on other sites

Try to follow this link parameters description and see if you can come up with a dll call that results in the correct path. I've never used this function but I guess that it's a simple function call, maybe you'll even find AutoIt examples specific to this function. After all, the name of the function is the same as C#'s equivalent + the SH prefix (shell32.dll).

Share this post


Link to post
Share on other sites

Yashied recently posted a little function that reliably return the correct location for any of widows special folders such as as these. It might be worth having a look at it.

Yashied function


"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning."- Rick Cook

Share this post


Link to post
Share on other sites

Try to follow this link parameters description and see if you can come up with a dll call that results in the correct path. I've never used this function but I guess that it's a simple function call, maybe you'll even find AutoIt examples specific to this function. After all, the name of the function is the same as C#'s equivalent + the SH prefix (shell32.dll).

Thanks,

I use it to fix I hope next beta :)

Share this post


Link to post
Share on other sites

Thanks,

I use it to fix I hope next beta :)

Thanks jpm. Shark007, I and many more will be very pleased to see this. :)

Share this post


Link to post
Share on other sites

#13 ·  Posted (edited)

McoreD, thank you very much for signing up to these forums and for jumping into thread.

jpm, I eagerly await the next beta release.

To all, especially Yashied,

I have replaced the @AppDataCommonDir AutoIt variable with the Yashied function which seems to work great.

I will pass a new version of my compiled script to McoreD for further verification.

Thanks Yashied.

UPDATE: McoreD has verified that using the Yashied function corrects the issue.

Edited by Shark007

Share this post


Link to post
Share on other sites

Thanks jpm. Shark007, I and many more will be very pleased to see this. :)

In fact I change all registry to SHGET...() function. No more registry access :)

Share this post


Link to post
Share on other sites

#15 ·  Posted (edited)

In fact I change all registry to SHGET...() function. No more registry access :)

On Windows 7 . . .

just a word of caution, @AppDataDir resolves to: C:\Users\MyUserName\AppData\Roaming

@AppDataDir is resolving correctly.

but there is no SHGET equivelent.

The SHGET resolves to:

C:\Users\MyUserName\AppData\local

__________________________________

from this link

FOLDERID_RoamingAppData

GUID {3EB685DB-65F9-4CF6-A03A-E3EF65729F3D}

Display Name Roaming

Folder Type PERUSER

Default Path %APPDATA% (%USERPROFILE%\AppData\Roaming)

CSIDL Equivalent CSIDL_APPDATA

Legacy Display Name Application Data

Legacy Default Path %APPDATA% (%USERPROFILE%\Application Data)

but CSIDL_APPDATA resolves to C:\Users\MyUserName\AppData\local

Edited by Shark007

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0