Link to home
Start Free TrialLog in
Avatar of shawn857
shawn857

asked on

trouble installing a Windows\System32 file to Windows\sysWOW64

Hi Experts, I guess this is a follow-up to my question from a week or so ago -
"My application's installation does not write files to \Windows\System32".
    In that question, I was having trouble installing files to a Windows 7 64-bit system using my old defunct installation software (www.install-us.de). I was informed about the free NSIS opensource installation software by Joe Winograd, so I've been learning that lately and thought I had created a successful installation script. I used the script here:

http://nsis.sourceforge.net/A_simple_installer_with_start_menu_shortcut_and_uninstaller

... as a template and it seemed to work fine - at least on my other 32-bit Win XP test desktop computer. I don't have a 64-bit machine here to test it on (my 32-bit XP laptop is my development computer), but I had a chance in the last couple of days to sign in to a user's 64-bit machine to test my script out and I ran into an error. Among other things, my app needs to install 3 files in the target user's System32 folder (or sysWOW64 for 64-bit machines):

mfc42.dll
msvcrt.dll
oleaut32.dll

But during installation on the 64-bit system, it generated this error window:

---------------------------
MyApp Setup
---------------------------
Error opening file for writing:

C:\Windows\System32\oleaut32.dll

Click Abort to stop the installation,
Retry to try again, or
Ignore to skip this file.
---------------------------
Abort   Retry   Ignore  
---------------------------


... when I checked his sysWOW64 folder, these files were there, but they may have already been there from before, as apparently they are fairly standard system files. Also, all my app's files were copied to the user's $INSTDIR folder correctly. Anyway, overall the installation failed as my app wouldn't run - I would assume because of this error message in one way or another. Would someone who is good with NSIS be able to help me out? I thought I did pretty much everything right - I have the requisite:

RequestExecutionLevel admin

...command, which allows privileges to Administrator-type systems.

And here's the relevant "install" section of my NSIS script:

section "install"
	# Files for the install directory - to build the installer, these should be in the same directory as the install script (this file)
	setOutPath $INSTDIR
	SetOverwrite on
	# Files added here should be removed by the uninstaller (see section "uninstall")
	file "MyApp.exe"
	file "MyApp.ini"
        file "testdata.txt"
        file "MyApp.ico"


	# Add any other files for the install directory (license files, app data, etc) here

        # Add Windows\System32 files here, these should NOT be removed by the Uninstaller
        SetOutPath "$WINDIR\System32"
        SetOverwrite ifnewer
        File "C:\WINDOWS\system32\mfc42.dll"
        File "C:\WINDOWS\system32\msvcrt.dll"
        File "C:\WINDOWS\system32\oleaut32.dll"
        SetOverwrite on
        File "C:\WINDOWS\system32\sortsol.dll"
        File "C:\WINDOWS\system32\SortSolX.ocx"
        ExecWait 'regsvr32.exe /s "$WINDIR\System32\SortSolX.ocx"'
        File "C:\Code-lock\Code-Lock.ocx"
        ExecWait 'regsvr32.exe /s "$WINDIR\System32\Code-Lock.ocx"'
        File "C:\Code-lock\zlib.dll"

 
	# Uninstaller - See function un.onInit and section "uninstall" for configuration
	writeUninstaller "$INSTDIR\uninstall.exe"
 
	# Start Menu
	createDirectory "$SMPROGRAMS\${APPNAME}"
	createShortCut "$SMPROGRAMS\${APPNAME}\MyApp.lnk" "$INSTDIR\MyApp.exe" "" "$INSTDIR\MyApp.ico"
        createShortCut "$SMPROGRAMS\${APPNAME}\Uninstall.lnk" "$INSTDIR\uninstall.exe"

	# Registry information for add/remove programs
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "DisplayName" "${APPNAME}"
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "UninstallString" "$\"$INSTDIR\uninstall.exe$\""
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "QuietUninstallString" "$\"$INSTDIR\uninstall.exe$\" /S"
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "InstallLocation" "$\"$INSTDIR$\""
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "DisplayIcon" "$\"$INSTDIR\MyApp.ico$\""
	WriteRegStr HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "DisplayVersion" "$\"${PRODUCT_VERSION}$\""
	# There is no option for modifying or repairing the install
	WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "NoModify" 1
	WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "NoRepair" 1
	# Set the INSTALLSIZE constant (!defined at the top of this script) so Add/Remove Programs can accurately report the size
	WriteRegDWORD HKLM "Software\Microsoft\Windows\CurrentVersion\Uninstall\${APPNAME}" "EstimatedSize" ${INSTALLSIZE}

        MessageBox MB_OK "Click OK to reboot please"
          Reboot
sectionEnd

Open in new window



Thanks!
    Shawn
SOLUTION
Avatar of David Johnson, CD
David Johnson, CD
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of shawn857
shawn857

ASKER

oh okay, so no need to even install those file then eh? They will always be there, on any types of Windows systems, for both 32-bit and 64-bit?

Also, I'm afraid I didn't really follow what you wrote here:

"You should be using %programdata% vice c:\windows\system32 or put your .dll's in to %ProgramFiles(x86)% if you test and it is a 64 bit operating system if a 32 bit O/S then put it in %ProgramFiles%\yourcompanyname\yourappname "


What is "vice"? Is that a reserved word of some type in NSIS script language?

   I don't think I can put my DLL's (code-lock ocx, sortsolx.ocx, sortsol.dll, zlib.dll) into %programfiles% - the makers of these products say they must go in the Windows\System32 folder.

   Also, I'm a total newbie with NSIS - I don't know how to test if the target computer is 32 bit or 64 bit.

Thanks!
    Shawn
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Hi again Joe, thanks for the reply. OK, so I guess there's no need of trying to install mfc42.dll, msvcrt.dll, and oleaut32.dll.... I'll just take those right out of my script altogether. That should make things a bit simpler. yes, the author of the security module I use does say his OCX should be installed to System32. In previous tests using my old "Install-Us" installer software on the 64-bit machine it got automatically redirected to sysWOW64 and that's fine - it worked from there. So I think I'm okay with letting my OCX files and sortsol.dll file install to sysWOW64. I think my problem now is trying to get NSIS to install correctly using Administrator privileges, as evidenced by the error I got :

Error opening file for writing:

C:\Windows\System32\oleaut32.dll

Click Abort to stop the installation,
Retry to try again, or
Ignore to skip this file.


Thanks for the suggestion for the x64 macro, but I don't think I should be installing my ocx/dll files to the System32 folder on 64-bit machines - I think it's doing the right thing by automatically redirecting them to the sysWOW64 folder... no?

Thanks
    Shawn
I think my problem now is trying to get NSIS to install correctly using Administrator privileges, as evidenced by the error I got :

Error opening file for writing:

C:\Windows\System32\oleaut32.dll

Click Abort to stop the installation, Retry to try again, or Ignore to skip this file.
I'm hoping that will go away when you stop trying to write to System32. All of my NSIS installers require admin rights when UAC is turned on, via this statement:

RequestExecutionLevel admin

I've never seen it fail.
I think it's doing the right thing by automatically redirecting them to the sysWOW64 folder
Yes, agreed.
Yep, I'm using that same statement too:

RequestExecutionLevel admin

Here's hoping getting rid of trying to install those C++ dll's will fix it.

Joe, is there a way to get NSIS to write out a "log" of what it does when it goes through an installation procedure - which files get written, which don't, what happens behind the scenes, etc ?

Also, I noticed on my user's 64-bit Win 7 system that those C++ dll's were present in BOTH his Windows\System32 AND Windows\SysWOW64 folders. Is that okay? Shouldn't they be in only SysWOW64?

Thanks!
   Shawn
> write out a "log" of what it does

There's no automatic logging of what it does, but there is a LogText command that your install script may execute:
http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.12

Also, take a look at these macros:
http://nsis.sourceforge.net/Logging:Enable_Logs_Quickly

> C++ dll's were present in BOTH his Windows\System32 AND Windows\SysWOW64 folders. Is that okay?

Yes, it's OK that they're in both. If you take a look at them, you'll see that they are different files. For example, in the W7 Pro 64-bit system that I'm writing this post on, the <mfc42.dll> in System32 is 1,359,872 bytes and dated 3/11/2011, while the <mfc42.dll> in sysWOW64 is 1,137,664 bytes and dated 3/10/2011.

Btw, since you're a software developer, and considering how important the 64-bit environment is these days, I strongly recommend getting an inexpensive W7 or W8 64-bit system on which you can test, perhaps even a refurbished machine to keep costs down (I suspect you can get something in the $200 range). Your 32-bit XP laptop is at the end of the road as a development computer and many of the prospective customers for your software are likely to be on W7 and W8 64-bit systems. Regards, Joe
OK Joe, tried another test on my user's Win 7 64-bit system.  The good news is that I didn't get that error anymore:

--------------------------
Error opening file for writing:

C:\Windows\System32\oleaut32.dll

Click Abort to stop the installation,
Retry to try again, or
Ignore to skip this file.

.... so *that's* fixed, but the bad news is that it looks like my script didn't register my ocx files. cause my app would not run right when I launched it. I had "ShowInstDetails" set to  "show" in my NSIS script so I could see the installation's progress and it didn't show any error or anything on these lines:

ExecWait 'regsvr32.exe /s "$WINDIR\System32\SortSolX.ocx"'
ExecWait 'regsvr32.exe /s "$WINDIR\System32\Code-Lock.ocx"'

it showed:

Execute: regsvr32.exe /s "\Windows\System32\SortSolX.ocx"'
Execute: regsvr32.exe /s "\Windows\System32\Code-Lock.ocx"'

but it looks like my script is trying to run regsvr32 in Windows\System32, when in fact my OCX files aren't in the System32 folder at all - they're in the SysWOW64 folder. But it didn't show an error that the files weren't found.  Strange...

So I went into DOS mode and went into the SysWOW64 folder and tried manually executing regsvr32 on both ocx files, but for both I got this error message:

[Window Title]
RegSvr32

[Content]
The module "Code-lock.ocx" was loaded but the call to DllRegisterServer failed with error code 0x80004005.

For more information about this problem, search online using the error code as a search term.

[OK]


So it appears my NSIS script is not registering my OCX files correctly - that's the culprit. Any thoughts?

Thanks!
   Shawn
> So I went into DOS mode and went into the SysWOW64 folder and tried manually executing regsvr32 on both ocx files, but for both I got this error message

The fact that it failed when you tried to do it manually says that NSIS is not the culprit. When you say, "I went into DOS mode", I'm guessing you mean that you opened a command prompt in W7/64-bit (if that's not what you mean, let me know what you do mean). Instead of a normal command prompt, try doing the regsvr32 commands in an elevated command prompt. There are numerous ways to open an elevated command prompt. One is Start>All Programs>Accessories, then right-click on Command Prompt and select "Run as administrator". Regards, Joe
OK Joe, I'll try that tomorrow... I've been away for a few days.

Thanks
   Shawn
OK Joe, I followed your suggestion and the OCX files successfully installed! How can I do this within my NSIS script?

Thanks!
   Shawn
vice means instead of singular of versus (vs).  As for the software requiring to be in Systrem32 that is an OLD programming practice that is outmoded and against Microsoft best practices.. To keep things organized, place the .OCX into the same folder as the software executable.
I understand, thanks David. I use a 3rd party anti-cracking module that the author says should be installed to the System32 folder (or syswow64 on Win64, I guess). He doesn't mention if it would be possible to install to the application installation folder - worth a try, it'll either work or it won't.
    I also install a 3rd party sort routine (a DLL file and a OCX file). The author of this says it can be installed to the System32 folder, or any folder in the search path - so I suppose it would be okay to install this to the application folder.

Shawn
David,
Thanks for the explanation of "vice". I had never heard it defined as "instead of", but I did find that definition ("in place of", actually) in the dictionary, although it does not say that it is a singular form of "versus", which it defines as "in opposition to". In any case, thanks for adding a new word to my vocabulary!

Shawn,
I'm glad you were able to register the files in an elevated command prompt. As far as doing this in NSIS, I have never run an elevated command prompt in an NSIS installer (I have also never written files to System32 or sysWOW64 in an NSIS installer). I would have thought that running the entire installer with the "RequestExecutionLevel admin" statement would suffice, but if that's not the case, you could try ExecShell (since ExecWait is not working for you):

ExecShell "runas" 'regsvr32.exe /s "$WINDIR\System32\SortSolX.ocx"'
ExecShell "runas" 'regsvr32.exe /s "$WINDIR\System32\Code-Lock.ocx"'

I've never used ExecShell in an NSIS installer and I don't know if the above will do what you want. Some web research indicates that the "runas" action won't work if UAC is turned off. Can't hurt to try it, but I really think you should contact the vendor of your security module to see if those files can be stored in %ProgramFiles% rather than System32/sysWOW64. If you can't contact the vendor or they don't respond, give it a try — see if they'll work when stored in %ProgramFiles%. Regards, Joe
if the file has setup in the name or is a msi then windows elevates it sometimes silently.  Usually you get the UAC prompt right away.
David - so if I simply rename my installer file to "MyAppSetup.exe", that might elevate it?

Thanks
   Shawn
Hi Shawn,
I realize you addressed that question to David, but I wanted to make it clear that the NSIS statement "RequestExecutionLevel admin" will give you admin rights when UAC is turned on, whether or not "setup" is in the installer file name. Are you not getting the UAC prompt? It should look something like this (if your installer is not code-signed):

User generated imageThis raises another point. As a software dev, it's a good idea to get a code-signing certificate. You would then put this statement at the end of your NSIS installer:

!finalize 'sign.bat "%1"'

The contents of <sign.bat> depends on whose code-signing cert you buy (mine is Verisign, but there are many others out there). Btw, the <!finalize> statement exists only in NSIS 3 Alpha — it is not in NSIS 2 (current production). With a code-signed installer, the UAC prompt will indicate a verified publisher and your customer will be able to view your certificate:

User generated imageRegards, Joe
Thanks Joe - yes, the "User Account Control" window prompting the user does indeed appear.

Thanks for the suggestion about Verisign certification, but that's a $500 expense I can't really afford right now... :-(

When I get access to my tester's Win 7 64-bit machine I'll try these further suggestions and get back to you with how I made out!

Cheers
    Shawn
Hi Shawn,
I agree that spending $500 on a cert is not the right way to go under your circumstances. You could actually buy a decent W7/64-bit machine for that, which would really be good for your software dev work. In fact, you could probably get something for around $300 so you wouldn't have to slow down your dev by getting access to your tester's W7/64-bit system every time you need to try something. That said, I paid only $99 for a Symantec/Verisign code-signing cert for one year. Regards, Joe
Hi guys, OK here is my current status with this: When I used my old "Install-Us" installation software, my app mostly installed correctly on 64-bit systems and all it's OCX files were registered properly - only problem was that files written to my app's installation folder didn't have full read/write access. On the other side of the coin when I used NSIS full read/write access was no problem, but my app wouldn't run correctly after installation (I don't think NSIS was registering my OCX files correctly). Anyway, to make a long story short, I reverted back to my old Install-Us installation software and used the "icacls" command within that and it solved my read/write access problems... so now my app installs and runs perfectly. So I guess (for now), I'll be sticking with my old Install-Us installation software instead of using NSIS.

Thanks
   Shawn
Shawn,
Thanks for the update — very interesting! It's always helpful to know what works and what doesn't work. Thanks for posting. Regards, Joe
Thanks guys!

Cheers
   Shawn
Pleasure! It was a very interesting thread! Regards, Joe
Thank you Joe.