[Intro] Translated by Eversiege#5457 / Iliya P.
When you install any application, you might've noticed a stage called "Adding keys to the registry" or "Product registration" during installation.
Or, for example, when reading a step-by-step guide about resolving some kind of a problem, ...
...you might've been asked to do the following: open the "Registry Editor", go to some registry key, open this, do that...
But have you over wondered about how does Windows registry work? How it's built and how do you correctly use it?
And is the registry good or is it still a mistake anyway?
That's what we're going to find out in this video
Get yourself some food since this seems to be a long topic; open your windows to air and let's get started.
It's not April Fools outside, so there won't be any jokes like secret effects or Longhorn...
...and in order to begin learning about the registry, we need to understand what is it at all and how did it get created in the first place.
Windows Registry - is a centralized storage system settings, apps and it's components, which is arranged as a hierarchical database of hives, ...
...values and keys, and is used by Windows operating system for storing of that said information.
The system and all installed apps constantly (or when it's needed to) request the registry to retrieve...
...and creation or editing of it's already existing keys.
First versions of OS Windows, beginning with Windows 3.1, use the registry as a single centralized place...
...of system settings storage and files format association storage for apps.
Registry was introduced in April 1992 with the release of Windows 3.1 and this innovation is designed to replace used to this point system of storing the parameters in INI-files.
Although some settings, such like desktop settings, parameters of some applications, etc, still remained in these INI-files...
For example, SYSTEM.INI, WIN.INI, CONTROL.INI, etc.
INI-files were easy to use, but didn't provide powerful enough features for storing and processing of large amount of parameters.
We will return to this later, but now we need to discuss something.
Registry of Windows 3.1 had only one hive: HKEY_CLASSES_ROOT.
It had only one binary file that was called REG.DAT and stored in the Windows catalog.
Thanks to this file, system determined with what application should the file be associated with.
So, when we open .TXT-file, then the opening process is then redirected to Notepad and by doing so, we can, with the help of the notepad, see what is written in a text file.
Same with pictures, documents and music files.
Every format will have an association and every association has a command, which system should run.
But, say, if you open a Microsoft Word file without installing that said Word, ...
...the system will tell us that it doesn't understand what to do with that file and how should it proceed.
and pls hlep)))))) [ that is not to me btw] (to him)
If we got the registry, so maybe the editor should appear with the system as well. (?)
And yes - a program REGEDIT.EXE appeared for viewing and actually editing the registry.
First ever registry already had an ability of importing data from *.REG-files.
And during the installation a file runs called SETUP.REG, that contains that said "first registry" in full.
And the limits here are even comical: you only have 64 kilobytes - no more, no less
If a situation ever happens that Windows 3.1's registry gets to that limit, Windows will just not record any new data, but I think you know what happens.
The modern Windows registry is 512 hives deep and 255 symbols for a key name, but a limit for one registry hive is still unknown.
This is not said even on Microsoft's documentation.
The next evolution of the registry as we know it occurred in the then-new Windows - with the release of Windows NT 3.1 in July 1993.
Registry gets all of the system configuration and new hives get created for it.
Windows NT also tries to get rid of now-obsolete files of MS-DOS era: AUTOEXEC.BAT and CONFIG.SYS, but also fully refuses from the system of storing settings in INI-files.
At least, in system components.
And finally, the registry became "modular"...
...every main hive of the registry, like HKCR and HKLM is now stored in separate files and everything is reassembled in one on startup.
All Windows 9x systems do exactly the same, but all of the registry is stored in two files: System.dat and User.dat.
And Windows ME added Classes.dat to these files.
Windows XP added a feature of automatic registry recovery, which allows the system to recover last version of the registry, if there was an error after an update.
And Windows Vista has introduced registry's new security model, which allows you to set different permissions and levels of access to keys and values.
The idea of Windows XP's registry recovery is now developing more and it's backup files are now located here: C:\Windows\System32\config\RegBack
Now I think it's a good time to actually tell you the structure of the Windows' registry: what registry folders does it have and what do they do.
When we open the registry editor in modern Windows, we see 5 main hives (or root directories, who likes what), and in every main hive there's sections, ...
...in which there are subsections, and inside these sections we have even more subsections, and so on to infinity... or before you see the first key.
Hives are the topmost level of the registry hierarchy. You better ask Microsoft about why are they called "hives" . It's them who gave that concept.
Let's break down each major and commonly found root directories of the system's registry in order and see, why does it need them for.
HKEY_CLASSES_ROOT (HKCR) stores info about file types and associations of the applications.
It stores all of the file associations, and, if removed, the system won't feel too good and will be impossible to use.
HKEY_CURRENT_USER (HKCU)
Has info about user's settings, which is logged in right now.
Including personal information about his profile, desktop settings, user's apps, etc.
Removal of this registry hive will result in a complete corruption of your (!!!) user profile.
HKEY_LOCAL_MACHINE (HKLM) contains all of the settings, related to hardware and software installed for every users on the computer.
And yes, this hive has the most amount of subsections, which are currently used by the system and are protected from removal (which is to be expected)
HKEY_USERS (HKU) is basically the same as HKEY_CURRENT_USER, but contains information about every user that has a user profile on the PC.
HKEY_CURRENT_CONFIG (HKCC) has information about right now current computer configuration, including info about drivers and connected devices.
Windows 9x systems have HKEY_DYN_DATA (HKDD) - this stored dynamically changing data about the computer
(for example how processor is used, paging file size, etc.)
Windows NT-based systems don't have that hive.
Subsections store keys, which can define the behaviour for any application; ...
...values of some data (for example digits, text or binary data), which then can be understood by the system or a component, etc.
Windows' registry can hold more than 50 000 keys of different types and any of the keys can have any value and dozens of parameters.
There's multiple types of keys.
REG_SZ: this key type used for storing data in strings, for example names of files or applications.
e.g. any full-fledged text.
REG_EXPAND_SZ: this type of key is a text, that has any variable that can be replaced when called by an application.
REG_BINARY: this type of key is used to store binary hex data (who would've guessed)
REG_DWORD: this type of key is used to store a 32-bit number that can be used for setting parameters and OS settings.
REG_QWORD: same as REG_DWORD, but now we work with 64-bit numbers.
REG_MULTI_SZ: this type of key is used to store lists that can contain multiple amount of values and strings.
Only the most common and frequent types of Windows registry keys are shown in this video.
Now we can (finally) answer the question: why did we get rid of INI-files?
Because INI-files has a lot of disadvantages, solutions to which were impossible to find.
Firstly, INI-files don't allow precise access control.
Since INI-files are just text files, you couldn't setup any access levels and permissions on the file level.
Basically, you couldn't just say "in this INI-file you can only change these keys, but don't touch those keys" to the program.
Secondly, INI-files could not be used by two apps at the same time.
Simultaneous change of any INI-file with two programs running at the same time could just easily damage it.
Or, one of two apps could get a read error while trying to open a file.
Thirdly, INI-files could only contain two levels of structure: [sections] and strings "like_this=inside_of_it"
Section nesting is impossible.
If you wanted to use binary, you have to somehow encode them into a string.
Fourthly, INI-files have a size limit - less than 32KB.
Fifthly, default directory for INI-files was the WINDOWS folder - nothing more, nothing less.
This long list of problems doesn't stop there. The registry system was invented as a single fix of all of these problems.
This was Microsoft's attempt to solve all problems of INI-files, but the registry also has it's cons, but we will talk about them later.
Now I want to show you some practice about working with Windows registry.
Have you ever wondered, how any application (like VS Code or DosBox-X) add context menu buttons to open a file through them after installation?
It's simple.
Go to HKEY_CLASSES_ROOT\*\shell\ in the registry.
In this section, you will see lots of subsections, which you can guess when examining them, that they contain the formation of their context menu items from third-party applications.
Add a subsection with any name you choose.
Here add a string and call it "Icon".
This parameter will store the file path to any icon file that will be should near your menu button.
In this same subsection, in the "(default)" key, type a name of your future menu button.
Later in this same subsection add a new subsection and call it "command".
Here (as you guessed) enter a command that will be run by the system in the "(default)" key.
After all these steps, when right clicked of any file, the list will should you your freshly added context menu button.
This works not only with files, but also with the Desktop's context menu: all steps are the same, although the file path is different.
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\DesktopBackground\Shell
Modern versions of Windows has an ability of turning off the lock screen if it bothers you in any way or if it suddenly annoys you.
You will need to go to this path for that: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Personalization
And yes, you can see here that Personalization subsection can just be missing. If that happens, you can just create one.
You will need to create a DWORD-key with the name of "NoLockScreen" and assign it a value of 1.
Restart your system and voila - you will never see even a glimpse of the lock screen.
If Win+L is pressed or you manually choose "Lock" or "End session" you will immediately get greeted with an account login screen.
In Windows XP's screen settings, in the background selection section there is an option of picture positioning: centered, walled and stretched.
The usual basic functionality.
But did you know that you can move your desktop background anywhere you want to?
Unfortunately no, we can't spin the background around it's axis, but you're welcome to move it with X and Y coordinates.
For that, go to HKEY_CURRENT_USER\Control Panel\Desktop, then create two string keys there called “WallpaperOriginX” and “WallpaperOriginY”.
The start of the coordinates is, of course, (0, 0), otherwise considered as the upper left cornet of the screen.
Write any number for X and Y respectively, re log to your account and voila.
This doesn't work on modern Windows versions, and these parameters have become not working placeholders.
Yes, the practical part can seem to you a little boring.
But at least this should prove you the fact that every single application talks with the registry on every single action.
If you have set a flag on anything in settings - this has already been passed to the registry with some kind of value, which the program will then understand.
But how the program itself will understand that is dependent on how this is written in the code of that app.
After our little practice in the registry, we will need to answer this next, as I think, interesting question: ...
...what are the consequences of using the registry incorrectly and brainlessly editing it's keys?
Let's see by investigating these pictures and this next demonstration
[well this is... this is what happens, if you play with the registry...]
[don't play with fire guys]
[a... oh, mom's came... well, f**k...]
[t.me/daneo03]
I think you got it :)
In all seriousness, any incorrect usage of the registry would lead to bad consequences.
Best case scenario, something from the components will no longer work (UWP, for example), ...
...and you can just restore this with SFC /scannow;
Worst - system will just beautifully show BSOD and will never boot again.
It's like a joke: Manna porridge comes out easy, but vinaigrette comes out beautiful.
And so that your computer doesn't become a decorative duster with the grandma's towel on the monitor, you will need to reinstall Шиндовс, ...
...and as everybody knows, won't reinstall itself!
So, my dear and beloved friends, the registry can be a bad joke.
The Windows registry itself tried to solve the problem of INI-files, but it also has it's problems...
... and once there was a lot of scandals, related to registry and software manufactures.
In older Windows versions, like Windows 98 or ME, in some cases, like driver installations, registry could be changed incorrectly, ...
...which led to system's fails or errors on application start ups.
In 2017 people found out that some applications, created by Lenovo, installed after themselves something called Superfish Visual Discovery, ...
...which turns out to be a spying software. This software module was installed in the Windows registry and could collect users' personal data.
And couple of years ago a security hole has been fixed in the registry in which some programs were installing and writing hidden keys.
This could lead to leaks of personal data, as well as the appearance of unwanted advertising and any spam.
All of these scandals were kind of serious and even have led to fines, criminal prosecution, and loss of trust from users.
But it's important to know that these examples are more like exceptions than rules.
Most of software manufactures and users use Windows' registry legally and safe.
What other OS will you ever see a "registry-like" database?
In addition to Windows, the database as a registry can be seen in ReactOS and in operating systems of the OS/2 family.
In other systems, especially UNIX-like, for storing system settings, software and other important stuff, ...
...use configuration files, and for every software there is it's own directory for storing settings.
What can I say at the end?
Windows registry, as it's been said earlier, has tried to solve the problem with the INI-files and it's cons.
This problem is solved, but with the advent of the registry other problems surfaces that even hit the scandals and headlines in the news portals.
Of course it has it's own cons.
In general, you can get along well with the registry if...
a) you have straight arms;
b) too much of recovery points;
and c) you give yourself an exact idea of what you want to do there and where you're going.
But what do you think about registry?
Is it a good and useful feature, or is it still a big mistake?
Have there been any incidents with the registry? Let's discuss it together in the comments!
And while you're writing a comment, I suggest you like this video and subscribe to the channel not to miss any new videos - it's more interesting together.
Thank you to all the people who support the channel with a cent and thank you - for watching.
See you again, dear friends!