I am attempting to rename a dll that was incorrectly placed into the System32 directory by AdvancedInstaller ("Advanced" is not the word I would use; there's a reason I switched to NSIS). I have no problems with the renaming if I launch a command line manually. If I use the Rename command in NSIS I have no success. So I tried using either "Exec" "ExecWait" or "nsExec::Exec" in order to run the command 'ren' (eg nsExec::Exec '"ren" file file.old'). Again nothing happens.
Therefore I ran the following
ReadEnvStr $R0 COMSPEC
Exec '"$R0" start cmd.exe'
so that I could interact with the command prompt spawned by the installer. If I search for the dll in the System32 directory, it can't find it even though in Windows Explorer it is clearly there. Doing a directory list in the command prompt doesn't show the dll in the list. This gives the impression that the command prompt being launched from the installer is not launching as a normal command prompt does if launched manually.
For the heck of it I tried running 'setshellvarcontext' to 'current' (which is admin in my case) with no success. Are there any ideas as to why I can't rename the dll from the installer but have no problems when launching a command prompt normally? They should behave the same right? Thanks in advance for any input.
ExecWait runs in wrong context?
6 posts
Exec* runs child process in the same context as the installer.
Are you on x64?
Are you on x64?
Oh I see what you are saying. Yes I am on an x64 machine. Is there a way to get around the 32-bit 64-bit issue when launching the command or running Exec?
If Rename isn't working then you probably forgot to disable WOW64 file system redirection. Use DisableX64FSRedirection from x64.nsh.
Stu
Stu
Thank you very much Afrow, that was what I needed. The 32-bit 64-bit issue that Anders was eluding to is still a question for me, however, that is likely a can of worms.
There's a 32-bit version of cmd.exe too. You would have executed that instead.
Stu
Stu