Hi,
I want to make an addon for Windows XP 64 bit, but I don't know the ID of SysWow64 folder (needed to copy some files to).
If I use 11, the file is copy to system32 folder.
Edit: Where I can find informations about folders ID's used in inf files?
SysWow64 folder ID
There is no dirid for SysWOW64. You can see the list. Microsoft's own hotfix installers just hard-code the name (%10%/SysWOW64).
I think there are only three cases where a traditional true addon makes sense.
1) If you are replacing system files (but that's usually done in an update pack, not an addon)
2) If other parts of your setup depends on your addon (e.g., if you are making a C runtimes addon)
3) If there is something that can't easily be done outside of Windows setup (e.g., if you need to install something to WinSxS).
Unless your addon fits one of those three criteria, it is almost always better to repackage your addon into a switchless installer instead. If done correctly, it's cleaner (edit svcpack.inf, add one file to svcpack), tidier (I really hate it when an addon leaves an INF behind, which is what happens if you use sysoc), and in most cases, will eat up less CD space (and in the rare case where it does eat up more space, it usually won't be by a significant amount). The only true addon that I use for my integrations is my C runtimes addon, and everything else, from fonts to PowerToys to LegitCheckControl, etc., etc. is packaged as switchless installers.
Now, I'm not trying to take this off-topic, because this actually ties in with your question.
The other advantage of the switchless installer is that it allows you to take advantage of the Wow64 redirector in x64 Windows.
The Wow64 redirector works like this: if you run a 32-bit app, it will redirect any registry changes you make to Wow6432Node, and it will redirect any file system operations from System32 to SysWOW64 and from "Program Files" to "Program Files (x86)". So, if you use a 32-bit installer to install a 32-bit application, you don't have to worry about any of the 32-vs-64 stuff. You just do stuff normally, exactly as you would on a 32-bit system, and Windows will take care of all the nitty gritty for you. You can't do this with a true addon, because Windows setup is 64-bit and any INFs launched from Windows setup will not get any of the redirector's help. Trying to install 32-bit stuff using an INF launched from a 64-bit installer is just extra trouble that you don't need.
So how this works is this (and you can look at my DirectX installers for an example of how I do this): the 7z sfx module is 32-bit, so all 7z installers are 32-bit. This also means that when 7z calls up rundll32 to execute the INF, it's calling up the 32-bit version of rundll32 (the filesystem redirector makes sure that the 7z installer gets SysWOW64/rundll32.exe instead of System32/rundll32.exe), and since the installing process (technically, rundll32.exe) is 32-bit, the redirector will be in play.
But what if you want to make a switchless installer that installs something that's 64-bit? The 7z author didn't release a 64-bit version of the 7z installer, and the 32-bit of the 7z installer will never be able to call the 64-bit rundll32 because any attempt to run the System32 version will be redirected to the SysWOW64 version. In that case, you can use your own 64-bit setup launcher in lieu of rundll32, which is what I did for the 64-bit DirectX runtimes. Since the setup process is now the 64-bit LaunchINF64.exe instead of the 32-bit rundll32.exe, the INF will run without the redirector getting in the way, and your 64-bit stuff will be installed correctly.
The beauty of all this is that by relying on the redirector, you will never have to worry about how to handle the various 32-bit virtualizations (and as Microsoft even says, hard-coding SysWOW64 is discouraged, as that name is subject to change in future Windows versions), and you can use the exact same switchless installer on both 32-bit and 64-bit systems.
I think there are only three cases where a traditional true addon makes sense.
1) If you are replacing system files (but that's usually done in an update pack, not an addon)
2) If other parts of your setup depends on your addon (e.g., if you are making a C runtimes addon)
3) If there is something that can't easily be done outside of Windows setup (e.g., if you need to install something to WinSxS).
Unless your addon fits one of those three criteria, it is almost always better to repackage your addon into a switchless installer instead. If done correctly, it's cleaner (edit svcpack.inf, add one file to svcpack), tidier (I really hate it when an addon leaves an INF behind, which is what happens if you use sysoc), and in most cases, will eat up less CD space (and in the rare case where it does eat up more space, it usually won't be by a significant amount). The only true addon that I use for my integrations is my C runtimes addon, and everything else, from fonts to PowerToys to LegitCheckControl, etc., etc. is packaged as switchless installers.
Now, I'm not trying to take this off-topic, because this actually ties in with your question.
The other advantage of the switchless installer is that it allows you to take advantage of the Wow64 redirector in x64 Windows.The Wow64 redirector works like this: if you run a 32-bit app, it will redirect any registry changes you make to Wow6432Node, and it will redirect any file system operations from System32 to SysWOW64 and from "Program Files" to "Program Files (x86)". So, if you use a 32-bit installer to install a 32-bit application, you don't have to worry about any of the 32-vs-64 stuff. You just do stuff normally, exactly as you would on a 32-bit system, and Windows will take care of all the nitty gritty for you. You can't do this with a true addon, because Windows setup is 64-bit and any INFs launched from Windows setup will not get any of the redirector's help. Trying to install 32-bit stuff using an INF launched from a 64-bit installer is just extra trouble that you don't need.
So how this works is this (and you can look at my DirectX installers for an example of how I do this): the 7z sfx module is 32-bit, so all 7z installers are 32-bit. This also means that when 7z calls up rundll32 to execute the INF, it's calling up the 32-bit version of rundll32 (the filesystem redirector makes sure that the 7z installer gets SysWOW64/rundll32.exe instead of System32/rundll32.exe), and since the installing process (technically, rundll32.exe) is 32-bit, the redirector will be in play.
But what if you want to make a switchless installer that installs something that's 64-bit? The 7z author didn't release a 64-bit version of the 7z installer, and the 32-bit of the 7z installer will never be able to call the 64-bit rundll32 because any attempt to run the System32 version will be redirected to the SysWOW64 version. In that case, you can use your own 64-bit setup launcher in lieu of rundll32, which is what I did for the 64-bit DirectX runtimes. Since the setup process is now the 64-bit LaunchINF64.exe instead of the 32-bit rundll32.exe, the INF will run without the redirector getting in the way, and your 64-bit stuff will be installed correctly.
The beauty of all this is that by relying on the redirector, you will never have to worry about how to handle the various 32-bit virtualizations (and as Microsoft even says, hard-coding SysWOW64 is discouraged, as that name is subject to change in future Windows versions), and you can use the exact same switchless installer on both 32-bit and 64-bit systems.
code65535 has a point.
But, the code is there for SysWOW64 (16425), the description is just not written very clearly. I use it successfully in my Update Pack.
For more IDs, there's also gosh's list. Since he wasn't using a 64-bit OS, however, his descriptions for 16425, 16426 and 16428 are incorrect. They're undefined in a 32-bit OS. Here are the correct mappings:
But, the code is there for SysWOW64 (16425), the description is just not written very clearly. I use it successfully in my Update Pack.
For more IDs, there's also gosh's list. Since he wasn't using a 64-bit OS, however, his descriptions for 16425, 16426 and 16428 are incorrect. They're undefined in a 32-bit OS. Here are the correct mappings:
- 16425 - %SystemRoot%\SysWOW64
16426 - %ProgramFiles(x86)%
16428 - %ProgramFiles(x86)%\Common
Ah, I stand corrected.5eraph wrote:But, the code is there for SysWOW64 (16425)
But I still prefer having the redirector handle the WOW64 stuff for me. 
And the embarrassing thing is that I had looked the dirid stuff up last year, but I had totally forgotten about it! And worse, the page that I linked to contained info on how to get the full list, and I still forgot about it.
Anyway, Microsoft's official documentation for the dirids is that for the special folders, the ID used by the INF is just the ID used by the the various shell API functions, OR'ed with 4000h. So with that, here's the list (complete w/ Microsoft's typos) of every defined ID as of Windows 2008, though there are some, like 16385, that aren't usable.
Code: Select all
DESKTOP 16384 // <desktop>
INTERNET 16385 // Internet Explorer (icon on desktop)
PROGRAMS 16386 // Start Menu\Programs
CONTROLS 16387 // My Computer\Control Panel
PRINTERS 16388 // My Computer\Printers
MYDOCUMENTS 16389 // My Documents
FAVORITES 16390 // <user name>\Favorites
STARTUP 16391 // Start Menu\Programs\Startup
RECENT 16392 // <user name>\Recent
SENDTO 16393 // <user name>\SendTo
BITBUCKET 16394 // <desktop>\Recycle Bin
STARTMENU 16395 // <user name>\Start Menu
[unused] 16396
MYMUSIC 16397 // "My Music" folder
MYVIDEO 16398 // "My Videos" folder
[unused] 16399
DESKTOPDIRECTORY 16400 // <user name>\Desktop
DRIVES 16401 // My Computer
NETWORK 16402 // Network Neighborhood (My Network Places)
NETHOOD 16403 // <user name>\nethood
FONTS 16404 // windows\fonts
TEMPLATES 16405
COMMON_STARTMENU 16406 // All Users\Start Menu
COMMON_PROGRAMS 16407 // All Users\Start Menu\Programs
COMMON_STARTUP 16408 // All Users\Startup
COMMON_DESKTOPDIRECTORY 16409 // All Users\Desktop
APPDATA 16410 // <user name>\Application Data
PRINTHOOD 16411 // <user name>\PrintHood
LOCAL_APPDATA 16412 // <user name>\Local Settings\Applicaiton Data (non roaming)
ALTSTARTUP 16413 // non localized startup
COMMON_ALTSTARTUP 16414 // non localized common startup
COMMON_FAVORITES 16415
INTERNET_CACHE 16416
COOKIES 16417
HISTORY 16418
COMMON_APPDATA 16419 // All Users\Application Data
WINDOWS 16420 // GetWindowsDirectory()
SYSTEM 16421 // GetSystemDirectory()
PROGRAM_FILES 16422 // C:\Program Files
MYPICTURES 16423 // C:\Program Files\My Pictures
PROFILE 16424 // USERPROFILE
SYSTEMX86 16425 // x86 system directory on RISC
PROGRAM_FILESX86 16426 // x86 C:\Program Files on RISC
PROGRAM_FILES_COMMON 16427 // C:\Program Files\Common
PROGRAM_FILES_COMMONX86 16428 // x86 Program Files\Common on RISC
COMMON_TEMPLATES 16429 // All Users\Templates
COMMON_DOCUMENTS 16430 // All Users\Documents
COMMON_ADMINTOOLS 16431 // All Users\Start Menu\Programs\Administrative Tools
ADMINTOOLS 16432 // <user name>\Start Menu\Programs\Administrative Tools
CONNECTIONS 16433 // Network and Dial-up Connections
[unused] 16434
[unused] 16435
[unused] 16436
COMMON_MUSIC 16437 // All Users\My Music
COMMON_PICTURES 16438 // All Users\My Pictures
COMMON_VIDEO 16439 // All Users\My Video
RESOURCES 16440 // Resource Direcotry
RESOURCES_LOCALIZED 16441 // Localized Resource Direcotry
COMMON_OEM_LINKS 16442 // Links to All Users OEM specific apps
CDBURN_AREA 16443 // USERPROFILE\Local Settings\Application Data\Microsoft\CD Burning
[unused] 16444
COMPUTERSNEARME 16445 // Computers Near Me (computered from Workgroup membership)Um, in the case of OGA, like WGA, it shouldn't matter where it gets installed since the COM registration should point stuff in the right direction no matter where it is. The problem is that a 64-bit app cannot use a 32-bit DLL, and vice-versa. If you have the 32-bit OGA, you cannot use it from the 64-bit IE, period. Same goes for WGA. (WGA should be installable by switchless, and OGA too).conan wrote:Thanks for the list guys. I will use it to modify two addons (MS Update Catalog and MS OGA). Those two files were copied to system32 (ID=11) and the sites asked for installing them.
As for the MS Update Agent (I assume you meant agent and not catalog?), shouldn't that have been a part of an update pack?
The Microsoft Update Catalog uses a different ActiveX control than the Update Agent. I don't include it only because I haven't heard of anybody using it.
Ah, I had forgotten about that. I've used that only a couple of times to find drivers.5eraph wrote:The Microsoft Update Catalog uses a different ActiveX control than the Update Agent. I don't include it only because I haven't heard of anybody using it.
conan, you should be careful about installing 32-bit ActiveX controls on a 64-bit system (first, you are using the default 32-bit IE, and not the 64-bit IE, right?) because you can't rely on self-registration if you are running it from a 64-bit setup. Self registration requires that the setup app load the DLL that is being registered so that it can call the DLL's registration functions, and that wouldn't work if you are trying to register a 32-bit DLL from a 64-bit setup process. In other words, use switchless.
(I just started playing around with a 64-bit OS this week, and I'm discovering just how convoluted everything is. For one, I don't get why the heck Microsoft didn't just leave the 32-bit stuff in system32 and made a system64 for the 64-bit stuff; since 64-bit apps have to be recompiled and sometimes reworked for 64-bit anyway, it's not like they are losing out on compatibility.)
You are right. I tried 16425 instead of 11 and it not works. The files were copied to system32 directory and probably doesn't registered. The sites for MS Office Updates and MS Update Catalog prompts to install activex controls (those files are 32 bit dll). Next time I will use sfx archives. Thanks.code65536 wrote: conan, you should be careful about installing 32-bit ActiveX controls on a 64-bit system (first, you are using the default 32-bit IE, and not the 64-bit IE, right?) because you can't rely on self-registration if you are running it from a 64-bit setup. Self registration requires that the setup app load the DLL that is being registered so that it can call the DLL's registration functions, and that wouldn't work if you are trying to register a 32-bit DLL from a 64-bit setup process. In other words, use switchless.