JohnKaufmann

No. I'd call you a teacher. Thanks again for the quick reply. John Light Blue Ribbon Campaign for Freedom of Skin

As I was assembling a PE, I thought about this comment and wondered if you have a solution for subdirectory names like "Application Data" and "Local Settings" -- for which (as noted earlier in the thread) there are corresponding registry values, but which apparently have no corresponding WinNT.SIF (or other PE) setting. Likewise, do you remove settings like "Personalized" and "PersonalizedName" from the desktop.ini files? -- or just remove desktop.ini files altogether? Is there a way to control this from the PE? John

Yeah. Rabbit holes are deep. . Isn't there another choice besides red pills and blue pills? Thanks for that final present, John Light Blue Ribbon Campaign for Freedom of Skin

submix8c, thanks for responding to Seraph as well as to my questions. Terrific answer! - you and jaclaz are so good at what you do, I love the combination of intelligence and irony in your comments. Though I have not found the "final solution" that I had hoped for, this thread has been an education in ways that I did not anticipate. I still have to follow up on the final links from jaclaz, which I'm sure will be as worthwhile as the others -- but want to thank you both, as well as tomasz86, for great thoughts about system deployment and management. And thanks to Seraph, also, for the reminder about Microsoft's design objective (however poorly-realized). This has cost so much more time than I had bargained for, and has been more than worth the time spent. Thanks to all, John

Good point: There is no compelling reason to accept the idea of a "Downloads" folder inside a profile "Documents" folder, and a downloads folder at root eliminates the path length limit problem that prompted me to look for alternative directory names. But: 1) Why are you so emphatic about "NEVER ... download to a 'Profile'"? [As you say, MS thinks it is a good idea.] Is it something more than a path length limit problem? 2) It would still be nice to find a good, complete reference for WinNT.SIF, at least for the directory and path settings. I agree about separating the user home partition from the system partition. In fact, that was another one of the reasons to search for answers about ProfilesDir (and its subdirectories, which also have registry values). But: 1) What do you mean about: ? Do you just mean to avoid the MS "My Pictures", "My Music", "My ..." silliness? Or do you mean to separate those media files from other downloads? If so, automatically during download (and, if so, how?) or just by moving files after download? 2) What do you mean by: ? Do you mean the browser options? If not, what? If so, do you mean something more than the "download directory" option?Thanks, John

jaclaz, thanks for a thoughtful and mostly responsive reply. It took a while to digest all the links, and their links, but the time was well spent -- mostly for gosh.msfn.org and for the introduction to Link Shell Extension <http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html>, which was a secondary link from one of your links (and will be very useful for other purposes) -- but all of your links were, in one way or another, interesting. However, I began this thread by noting that the msfn.org home page has a tutorial on Windows XP deployment which concludes by referring the reader to MS Deployment Tools ref.chm for more info -- but a look at ref.chm shows that it does not even include all of the settings that are cited in the MSFN tutorial. So I asked if there were some collected super-reference, essentially a documented deployment API. Even with the helpful responses, what I have learned is that ref.chm is the closest thing to a deployment API, and it is incomplete -- so you and many others spend years not only developing deployment processes that improve on what MS provided, but also discovering deployment information that MS should have provided. While I am grateful that you and others do that [and I would, too, if I were regularly engaged in Windows support], it's not a substitute for complete, adequate deployment documentation. My concern is to make a clean installation with alternatives to the directory names MS has chosen. I was prompted to do this after (yet again) downloading a driver archive file which -- after expanding to to an installation directory many levels deep -- broke the installation process because a complete filepath\filename is so long (C:\Documents and Settings\All Users\Documents\Downloads\ ...\...\...\...\...) that Windows chokes on it (because the length exceeds the character limit for a file handle). I understand that the path length limit is a Windows problem, but there are times when I need to support Windows. My usual response is to copy the whole subdirectory to root and restart the installation, but I hate wasting time and energy on work-arounds like that. Since I have always found that, when the path limit breaks, it has never exceeded the limit by more than a dozen characters or so, one simple approach would be to reduce the MS default path length by a couple dozen characters with simple directory name changes [that would also, in my view, be more appropriate anyway]. That's how a search led me to msfn.org. It is also why my question focused on settings for directory names -- and why your links, though helpful in other ways, are mostly unresponsive to that initial concern. [Frankly, I was surprised to find that this kind of simple solution to a common nuisance seems so rare and undocumented.] As I asked, if ProgramFilesDir and CommonProgramFilesDir, with corresponding (though differently named) registry values, are not included in ref.chm, what other directory and path settings exist that are not documented in ref.chm? There are many similar directory settings in the registry (like AppData, AllUsersPath, DefaultUsersPath, HomeDrive, HomePath, MediaPath, ProgramFilesPath, ...) that presumably have deployment antecedents, but the for most part I have not found those antecedents. That's the kind of reference I was seeking. Though I have learned a lot of good stuff, I have to conclude that the reference I just described does not exist. Thanks again for your help, John

Ah, yes - delete cookies, login again, refresh page - all is good. So those silly ads do go away! Knowing what should happen is key, but your suggestion was most welcome. Thanks, John

That was so informative that - after following links to many levels deep - I almost forgot to come back and say thank you! For my current purposes, mostly I learned about more undocumented settings -- like floppylessbootpath, dospath, etc. -- but the introduction to the the structure of how the system is organized on disk was useful. By the way, do you happen to know what character encoding is used on sudhian.com? Firefox does not pick it up automatically because it is declared in the page source as ISO-8859-1, which apparently it is not, and of course that makes reading difficult. [The post is over five years old, but I understand that's the nature of XP questions.] I am increasingly inclined to give up looking for a good reference, because one theme of these explorations is that there is no such super-reference as I had assumed would exist. Maybe one only learns about these things by hexdumps on DLLs and experimenting with those discoveries. Life is too short for that. Thanks again, John

A small question with respect to those silly double-underlined "keyword" advertisements: When signed in after "Supreme Sponsor" subscription payment (which lists among its benefits ), should one still see them? If not, what is required to make them go away?

I guess you will have to "dirty your hands" with SID's, those are created "on-the-fly" at logon. See (as an example): http://www.raygibson.net/kb/profile_migration/ That was a great read - thanks! - but i don't see how it addresses the connection of installation settings to registry values, or registry values to environment variables. Did I miss something? That was also interesting. So the environment gets USERNAME from "DefaultUserName" and USERDOMAIN from "DefaultUserDomain"? - and those in turn are passed to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon from the SID? For example, "DefaulttUserName" comes from "Logon User Name" of the SID? And "DefaultUserDomain" comes from the default value of HKU\{SID}\Software\Microsoft\Windows\ShellNoRoam? If so, How do we learn such arcane details (particularly the inter-registry transfers, although the derivation of the corresponding environment variables would also be helpful)? Documentation? Thanks, but the variables per se are pretty familiar. It's the connections from the registry, and from the installation settings to the registry, that are my concern. i appreciate you getting me this far. If you have any thoughts on the follow-up questions, I would appreciate them, too. Regards, John

Thanks, but I think that's pretty close to what I said, except that the original post was a bit more complete. For example, while HKCU\Environment provides only TEMP and TMP, quite a few variables are provided from HKCU\Volatile Environment (APPDATA, HOMEDRIVE, HOMEPATH, LOGONSERVER, SESSIONNAME), and SystemRoot is apparently provided from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion -- and then there are the environment variables that are used but not defined in the registry, as well as environment variables that do not even appear in the registry. My questions were (and remain): 1) How do the installation values connect to the registry values? How are those registry values (like SystemRoot) derived from the installation values? 2) Where is SystemDrive defined in the registry? How is it derived from the installation? 3) For all of the registry values that are not found in HKCU\Environment HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Environment or even in HKCU\Volatile Environment HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion - and for those environment variables that are not defined in the registry, and those that do not even appear in the registry, how do they get to the environment? How and where are they stored? Any idea where to look for those answers? - where to find documentation on such cases? Regards, John

[rp Thanks for your reply, but of course that's exactly what I said. My question was: How do we know about such variables, which are not mentioned in ref.chm? The question was whether there is some super-reference of which ref.chm is a subset. Do you know of one? If so, i would like to check it for other variables which I know are not documented in ref.chm, but for which I don't have names. For that matter, i would also like to check such a reference for detailed usage notes missing from ref.chm, which does not provide information about which settings must have a drive spec, and which are accepted without a drive spec,such as: ProgramFilesDir = "\Apps" Thanks, but I'm also familiar with environment variables, as well as their Windows defaults - though in a related post I ask about how to track the relationship from the installation settings to the registry to the environment variables. To take, for example, the installation settings with which I began this thread (which are undocumented in ref.chm), 1) Installation setting "ProgramFilesDir" becomes "ProgramFiles" in the registry, which is passed to "ProgramFiles" in the environment. (Within the registry, "ProgramFiles" is also passed to "ProgramFilesDir" and "ProgramPath", neither of which is passed to the environment.) 2) Installation setting ""CommonProgramFilesDir" becomes "CommonProgramFiles" in the registry, which is then passed to "CommonFilesDir" in the registry, which is passed to "CommonProgramFiles" in the environment. Setting aside the fact that each train of names seems ridiculously convoluted [would it hurt to use a consistent name throughout? - to say nothing of having a consistent naming scheme? But I digress...], each of these trains begins with an apparently undocumented installation setting. My question was about where to find such documentation. I' m beginning to fear that, as tomasz86 says, - at least outside of MS developers. Reminds me why we like open-source ...Thanks for the replies. I hope this follow-up may get us a bit closer to answers, John

Trying to make the connections in in the subject line, I note that some installation values have relatively clear connections to the registry, others are obscure at best. An obvious example in the middle of those extremes is the registry (and environment) value SystemRoot, which seems to be derived from the installation values SystemDrive (from $OEM$ $1) and TargetPath (from WinNT.SIF). Is that inference correct? If not, how is SystemRoot derived? Bonus question for that example: Where is SystemDrive defined in the registry? It is used in the registry as value data (i.e., %SystemDrive% as part of a larger string), but I can't find it as a value defined under any key - yet the value is used often in the registry and is passed to the environment. Anyone know how this works? Related question: I have been able to identify the source of many environment variables in the registry under these keys; HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion (SystemRoot) HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Environment (Comspec, OS, Path, PATHEXT, windir) HKCU\Environment (TEMP, TMP) HKCU\Volatile Environment (APPDATA, HOMEDRIVE, HOMEPATH, LOGONSERVER, SESSIONNAME) But that still leaves environment variables that I don't find defined in the registry (like SystemDrive) and strings like USERDOMAIN and USERPROFILE that aren't even used in the registry. Where and how are these stored?

The tutorial page on WINNT.SIF was a helpful introduction, but incomplete, and at the end notes: But the tutorial page includes values like ProgramFilesDir and CommonProgramFilesDir that are not included in ref.chm (which is the same for SP3 and for SP2). So how do we know about variables like those? Is there some super-reference containing all of these values (preferably correlated with their respective registry keys and values)? One practical reason for asking: Are there other such variables related to registry values like AppData, AllUsersProfile, DefaultUserProfile, which govern where files are stored?