Content Type
Profiles
Forums
Events
Posts posted by gr8dude
-
-
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,0x0000000AAnother 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?
0 - I cannot delete the shortcut
-
The only double quotes required in my tests seemed to be those shown. The only differences were that in VISTA and Windows 7, if newlink-name includes spaces those spaces are replaced with underscores.
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?
0 -
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 :-)
0 -
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?
0 -
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?
0
SetupAPI on 64-bit platforms vs registry redirection
in Application Installs
Posted
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
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
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
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:
Any ideas will be greatly appreciated.