SysWow64 folder ID

Windows XP Professional x64 Edition Update Pack discussion.
Post Reply
User avatar
conan
Posts: 50
Joined: Tue Apr 03, 2007 4:12 pm

SysWow64 folder ID

Post by conan » Sat Sep 06, 2008 5:24 pm

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?

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Sat Sep 06, 2008 6:20 pm

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.
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

User avatar
5eraph
Site Admin
Posts: 4619
Joined: Tue Jul 05, 2005 9:38 pm
Location: Riverview, MI USA

Post by 5eraph » Sat Sep 06, 2008 10:50 pm

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:
  • 16425 - %SystemRoot%\SysWOW64
    16426 - %ProgramFiles(x86)%
    16428 - %ProgramFiles(x86)%\Common

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Sun Sep 07, 2008 12:15 am

5eraph wrote:But, the code is there for SysWOW64 (16425)
Ah, I stand corrected. :) 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. :oops:

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)
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

User avatar
conan
Posts: 50
Joined: Tue Apr 03, 2007 4:12 pm

Post by conan » Sun Sep 07, 2008 2:52 am

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. :)

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Sun Sep 07, 2008 7:39 am

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. :)
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).

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?
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

User avatar
5eraph
Site Admin
Posts: 4619
Joined: Tue Jul 05, 2005 9:38 pm
Location: Riverview, MI USA

Post by 5eraph » Sun Sep 07, 2008 9:07 am

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.

User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

Post by code65536 » Sun Sep 07, 2008 11:17 am

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.
Ah, I had forgotten about that. I've used that only a couple of times to find drivers.

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.)
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

User avatar
conan
Posts: 50
Joined: Tue Apr 03, 2007 4:12 pm

Post by conan » Sun Sep 07, 2008 1:08 pm

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. ;)
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.

Post Reply