REGLN - Manage Windows Rregistry Links V20R0 ====================================================================== Antoni Sawicki ; Dublin, July 10 2005; Index ----- - Legal stuff - Usage instructions - What else can I do with links? - Where are some other registry links in the system? - Source code & building - Release history - Compatibility - Contacts/Support - References - Thanks - Credits Legal Stuff ----------- The following Copyrights apply: Copyright (c) 1998-2005 by Antoni Sawicki Copyright (c) 1998-2005 by Tomasz Nowak Copyright (c) 1998 by Mark Russinovich License: This software is distributed under the terms and conditions of GPL - GNU General Public License. The software is provided AS IS and ABSOLUTELY NO WARRANTY IS GIVEN. The author takes no responsibility for any damages or consequences of usage of this software. For more information, please read the attached GPL.TXT file. WARNING: PLEASE READ THE LICENSING AGREEMENT BEFORE USING THE SOFTWARE. USING IT AUTOMATICALLY ASSUMES THAT YOU HAVE AGREED TO THE TERMS AND CONDITIONS OF THE LICENSE. PLEASE REMEMBER: ABSOLUTELY NO WARRANTY IS GIVEN AND THE SOFTWARE IS PROVIDED AS-IS. THE AUTHOR *TAKES NO RESPONSIBILITY* FOR THE SOFTWARE, DAMAGES OR ANY CONSEQUENCES CAUSED BY ITS USAGE. Usage instructions ------------------ Syntax: Usage: regln [-v] regln -d Where: link_key is new registry key (link) target_key is existing registry key -v = volatile, exist in memory only -d = delete link REGLN operates in two modes: Create and Delete. = To Create a Registry Link you need to have a Registry Key to link to and decide whenever the link has to be Volatile or Permanent. Volatile means it will be stored in the RAM memory and not saved in any HIVE file. This is good for testing because a simple reboot will remove the link. If you don't specify "-v" option the link will be created permanently and stored in a registry HIVE file and will last untill it will be manually removed. The key names used by NTAPI are just NT Namespace Paths. For example: \Registry\Machine\Software\Microsoft However for compatibility and ease of use, a conversion function to translate to Win32 "root key" names was implemented in the public release. From now on, you can simply use: HKEY_LOCAL_MACHINE\Software\Microsoft or: HKLM\Software\Microsoft Unfortunately the "virtual root keys" like HKEY_CURRENT_USER and other are only Win32 addition and are not visible from the Native API and it is not possible use them in REGLN. Therefore the only valid "root keys" are: Win32 Abbr Namespace ----------------------------------------------------- HKEY_LOCAL_MACHINE HKLM \Registry\Machine HKEY_USERS HKUS \Registry\User Note: For compatibility with scripts and other utilities the root key name "HKU" was added as synonym of HKUS or HKEY_USERS. The keys: HKEY_CURRENT_USER, HKEY_DYN_DATA, HKEY_CLASSES_ROOT or any other CANNOT be used by REGLN. No, it is not possible at all. Also you cannot create links (or any other keys) directly under the "root keys", for example from one user profile (in HKUS) to another. Also you cannot link HKLM\FREEWARE to HKLM\SOFTWARE etc. If you want to do that, you have to load up a hive file and link it all top-level entries. Perhaps it would be possible to do that using Namespace Links, however it's out of scope of this utility. = To Delete a Registry Link you just have to specify the link-key name with "-d" option. It does not matter if the link is volatile or not. = Examples: regln -v HKLM\Software\TestInc HKLM\Software\Microsoft Will create a temporary link TestInc pointing to Microsoft. If you open Regedit or any other registry editor and go to HKLM->Software and then TestInc you will see exacly same content as in Microsoft key. If you add/delete/change something in a Microsoft tree, it will be obviously "changed" in TestInc as well. (Remember to refresh display by pressing F5 if you're using the system regedit.exe) regln -d HKLM\Software\TestInc Will remove the link... Now a more interesting example: Imagine yourself (no, I'm not recommending this to inexperienced users) renaming "HKLM\Software\Microsoft\Windows\CurrentVersion" to "HKLM\Software\Microsoft\Windows\Version1" and creating the link: regln \Registry\Machine\Software\Microsoft\Windows\CurrentVersion \Registry\Machine\Software\Microsoft\Windows\Version1 This will create a permanent link from CurrentVersion pointing to existing key Version1. Now copy the whole tree recursively from Version1 to Version2 so that you'll have: HKLM\Software\Microsoft\Windows: - CurrentVersion --LINK-->> Version1 - Version1 - Version2 Now, alter some variables in Version2 and try to re-link the key CurrentVersion to Version2 by typing: regln -d \Registry\Machine\Software\Microsoft\Windows\CurrentVersion regln \Registry\Machine\Software\Microsoft\Windows\CurrentVersion \Registry\Machine\Software\Microsoft\Windows\Version2 As you see now, you can have many "sets of settings" for various applications, or even whole Windows and can swap them around at any time. This is useful for testing and debugging purposes... ! Remember: you have to extend Registry Quota to have enough space to do things like that... Also most applications will have open handles to the registry keys and will write to the old place so you usualy will have to reboot to use this. However if the application uses registry dynamically (opens and closes keys), it will work just fine. It seems clear that the "CurrentVersion" key was really designed just for that, except the functionality was never fully released (...it is now) What else can I do with links? ------------------------------ First of all, you can link any registry key to one of the "HardwareProfiles" extending their functionality and allowing any registry key to be Hardware-Profile dependent. You can then have various system or application settings dependent on boot selected Windows Hardware Profile. Another idea, is to swap some settings that are system-based (HKEY_LOCAL_MACHINE) with settings that are based on the user, (HKEY_CURRENT_USER) or in other words allow users to change settings that normally would be in HKLM. It's also possible to reverse this -> to link some user-based keys to HKLM to force all users to have all the same, common setting for example a desktop color scheme or the background. Normally you do that group polices. However linking is far more effective, especially on stand-alone terminal server, etc. Another possibility is to group some sets of settings spreaded across whole registry in a single HIVE file for easier backup, sharing/distributing or editing purposes. There are a few other variations and possibilities associated with upgrades and installation of new software, backups, etc. If you find any other thing you can do with REGLN, please let me know. Thanks. * NEW: Recently Thomas Kobler asked me about the possibility of having two different users using (sharing) a one, common profile. For example (but other combinations are possible) a master user with full access to the profile and a slave user, that has only read access to the master user profile. After a short investigation, we've found out that this is quite possible. The only thing is that you can't link the whole profile and you have to use the existing profile hive file (ntuser.dat). You have to wipe it out - clear all top-level keys and re-link it to a top-level keys of another profile, for example: HKU\S-1-2-3-SLAVE\Console -> HKU\S-1-2-3-MASTER\Console HKU\S-1-2-3-SLAVE\Environment -> HKU\S-1-2-3-MASTER\Environment ... etc... (Thomas has written a little batch script that does this automatically). After this little operation everything works fine and you can have two or more users running on one single profile. You can obviously link only some keys and allow users to have few settings user-depenent while other are common or shared. You have to remember however that the master profile have to be loaded before slave. You can consider loading some separate hive file permanently to the registry or linking the top-level keys to HKEY_LOCAL_MACHINE. You can also create links in HKU\.default and let all new users have the "linked" profile by default... There are infinite combinations. * NEW: More recenly Karim Loukili informed me of use of regln to solve a problem with daylight saving time and TZInfo over reboot a EWF enabled device on Windows XP Embedded (WES2009). Where are other registry links in the system? --------------------------------------------- In Windows NT, they are really used by Control-Sets and Hardware Profiles only (to link to the "Current" one). Also NTBACKUP and few other utilities are able to open registry links to perform backups. As far as I know, no other software currently uses the Registry Links. Source code & building ---------------------- C Source code is provided in the zip file along with .h include file (regln.h). No documentation is provided apart from my comments in the files. If you need more informations or have any questions feel free to email me or my colleagues or follow the references secion. The original public release was built using Lcc-Win32 compiler by Jacob Navia, from 2.0 however I've switched to MSVC to keep more compatibility between various platforms. Release history --------------- - Fall 1999 - internal release 0.9 - Summer 2000 - internal release 1.1 - Summer 2001 - public release 1.2 - November 2002 - public release 1.4 - February 2002 - public release 1.6 - March 2003 - internal release 1.7 - April 2003 - public release 1.8 - July 2005 - public release 2.0 Compatibility ------------- REGLN has been successfully tested on the following platforms: Hardware: - axp DEC/Compaq/HP Alpha AXP - mips Mips R4000 - x86 Intel IA-32 / i386 - x64 Intel EM64T, AMD64, x64, x86-64 - ia64 Intel IA-64 [Itanium] - ppc IBM PowerPC Software: - Windows NT 3.51 (Including Citrix WinFrame) - Windows NT 4.0 (Including Terminal Server Edition) - Windows 2000 - Windows XP - Windows NET 2003 Server REGLN doesn't work on Windows NT 3.1 (all platforms) Contacts/Support ---------------- No support is given but you can contact us directly by email if you have any questions, problems or remarks. The email address is regln@ntinternals.net You can also contact the author directly: Antoni Sawicki References ---------- - http://undocumented.ntinternals.net/ (most other NTAPI functions are documented here) - Windows NT DDK, Platform SDK, MSDN Library. - http://www.sysinternals.net/ - some usefull info and examples - http://www.cs.virginia.edu/~lcc-win32/ - LCC-Win32 - http://forum.winimage.com/index.php?c=8 - Gilles' tips on Win64 Thanks ------ - Mark Russinovich - for some NTAPI stuff - Gilles Vollant - for Alpha AXP MSVC6 - Jason Stevens - for MIPS Qemu & MSVC - R Stricklin - for PPC Port - Alex Finch - for giving us the opportunity Credits ------- Antoni Sawicki Tomasz Nowak ======================================================================