gr8dude

Hi everyone, I am facing a tricky case and I hope I can get some advice on how to deal with it. Environment: Windows 7 x64, Windows XP x86 There is an installer that uses SetupAPI to install a program on a system. The program is a 32-bit application, it has an Explorer context menu plugin. It is a DLL that needs to be registered by creating a key in HKLM\Software\Classes\CLSID 2 versions of the DLL exist, a 32-bit one for x86 platforms, and a 64-bit one for x64 platforms (AMD64, to be more specific). This works as expected on 32-bit platforms, but on 64-bit platforms registry redirection kicks in, and instead the key is created in HKLM\Software\Classes\Wow6432Node\CLSID The context menu doesn't work, because Explorer.exe is a 64-bit process, hence it doesn't see that part of the registry. Unfortunately I failed to find any resource that would indicate whether actions performed by setupAPI are subject to registry redirection or not. However, the documentation states that one can use decorators in the sections of the INF file. I assume that if an action is performed from a section that was decorated as "ntamd64", it would be executed without being altered by the redirection magic. Unfortunately, my experiment brought me to the conclusion that the decorator is not having this effect; not only that - but it appears to be completely ignored (the key is not created in the "Wow6432Node" section either). Here's an outline of my INF [DefaultInstall.ntamd64] RequiredEngine = Setupapi CopyFiles = CopyFiles,CopyFiles.amd64 RunPreSetupCommands = Install_Certificate RunPostSetupCommands= RunPostSetup,RunPostSetupRegistry_ntamd64 UpdateInis = CreateStartMenuFolder CustomDestination = CustDestDir AddReg = RegAdd, RegAdd_register, RegAdd64test SmartReboot = N ;RegisterDlls = RegisterAddins [RegAdd64test] ; .SKF file extension association and icon HKLM, Software\Classes\CLSID\{A23zzzC51BC-5D02-45a2-A5F1-7775DB68FB84}, , ,"SKIntegr45 Class" I suspect the problem is in the incorrect use of decorators, because the actions specified in "CopyFiles.amd64" are not performed either. So, this boils it down to these questions: Is setupAPI subject to registry redirection? Why don't the decorators work as expected? Any ideas will be greatly appreciated.

Thank you for the quick response. I managed to make it work, but my feelings about it are still pretty mixed. The good news is that the shortcut is created and the spaces are there. There are several problems though: I cannot delete the shortcut It is not created with "working dir" pointing to the right folder I've tried twisting it in many ways, and have consulted other sources; I get the feeling that the entire world knows about ProfileItems, except me :-) From what I understand, a shortcut created with ProfileItems can be removed by providing its name and a special flag: [AddTest.DelShortcut] Name =ACME distorter,0x0000000A Another source proposes a different method, but I believe it is not applicable in my case because the path is not fixed (in the final product it is supposed to be a custom path entered by a person, so App_ProgramFolder at the end of this post is just a stub). I intend to test it this way (also tried copying installer.inf to \windows\inf, just to be sure it is not a problem with the path: RunDll32 advpack.dll,LaunchINFSection d:\test\installer\installer.inf, DefaultUninstall The shortcuts are still there. Here is the complete .inf: [Version] Signature = $Windows NT$ [DefaultInstall] ;UpdateInis=CreateStartMenuFolder AddReg = RegAddUninst ProfileItems = AddTest, AddTestEx [DefaultUnInstall] ProfileItems=AddTest.DelShortcut [AddTest.DelShortcut] Name =ACME distorter,0x0000000A, ;SubDir =Sub Directory [RegAddUninst] HKLM,%SMWCV%\Uninstall\%Soft_Name%,DisplayName,,"ACME" HKLM,%SMWCV%\Uninstall\%Soft_Name%,UninstallString,,"RunDll32 advpack.dll,LaunchINFSection d:\test\installer\installer.inf, DefaultUninstall" ;16422 = program files [AddTest] Name = ACME distorter SubDir = %Provider% Infotip = "This is a tooltip weeha!" CmdLine = 16422, "%Provider%\Distorter", Acmedist.exe WorkingDir = 16422, "%Provider%\Distorter" [AddTestEx] Name = %Soft_Name% SubDir = %Provider% Infotip = "This is a tooltip weeha!QQQQQQ" CmdLine = 16422, "%Provider%\%Soft_Name%", Acmedist.exe WorkingDir = 16422, "%Provider%\%Soft_Name%" [Strings] SMWCV="Software\Microsoft\Windows\CurrentVersion" Provider="ACME" Soft_Name="ACME distorter 5.0" AppLink="ACME distorter 5.0" App_Name="ACME distorter 5.0" App_StartMenuFolder="ACME\Distorter 5.0" App_ProgramFolder="ACME\Distorter 5.0" ShortCutFileName="ACME\Distorter 5.0.lnk" PathAndFileName="ACMEdist.exe" Arguments= "" In the same context, I would like to get back to the original problem - is there a way to understand why the spaces are replaced with underscores? I've spent a few days testing this workaround and completely forgot the fact that the original problem is much more simple in its nature. Perhaps I am exploring the wrong path?

This is a problem I am trying to deal with right now. The shortcut works, but I would like the underscores to be spaces. I guessed that it may have something to do with the number of double-quotes, as discussed in this thread, so I made a small INF file with multiple lines using various numbers of double quotation marks, hoping that one of them would look right. Here is the relevant part of the INF: setup.ini, group1,, """"Str ing3""",""""""%10%\Test\file.exe"""""",,,,""%10%\Test"",""file.exe""" setup.ini, group1,, """""Str ing4"""",""""""%10%\Test\file.exe"""""",,,,""%10%\Test"",""file.exe""" setup.ini, group1,, """"""Str ing5""""",""""""%10%\Test\file.exe"""""",,,,""%10%\Test"",""file.exe""" setup.ini, group1,, """""""Str ing6"""""",""""""%10%\Test\file.exe"""""",,,,""%10%\Test"",""file.exe""" Unfortunately, in each case spaces turn into underscores - so I think it is of reason to assume that the culprit is not in the number of double-quotes. Can someone tell me whether there is a solution to this problem? Or maybe it is time to switch from SetupAPI to something else?

well, i did continue my research, and i found it on a lot of places: NTFS3=NTFS5 NTFS3.1=NTFS5.1 so we're talking about the same thing here. the end of the world has been postponed again :-)

yeah, i believe that when people say NTFS5 they actually mean NTFS3, and the same about 5.1 and 3.1 but see this: [by the way, its ntfs.com, not .org] http://ntfs.com/ntfs_vs_fat.htm according to that info, NTFS3 and NTFS5 are indeed different things. i know about the issue you described. and i think i have the same problem with my program. from time to time i get reports from people saying that they cannot open the files created by the application... so i think the file is automatically changed by windows, and then when opened on a different machine - its 'unreadable' does anybody know what's really going on here?

i was recently fixing some problems with an application i develop, and at the moment im stuck with the version of NTFS of the partition on which the application resides. if you do a fsutil fsinfo ntfsinfo c: you will see which version of NTFS you have. i tested it on XP SP2, the version is 3.1 on ntfs.org they say that beginning with win2k, the OS supports NTFS 5. this version has a feature (sparse files) that probably interferes with my application. the problem is that i havent seen a system with NTFS 5, or NTFS 5.1 [which is the latest, as far as i understood], so i cant test my program in that situation. how can i convert from NTFS 3.1 to NTFS 5.1 ? and which OS really comes with NTFS 5?