@@askleonotenboomoh, you mean the system stats like CPU load, GPU load and the like? Yeah, I was shocked to learn the place to query those is in the registry 😅
@@askleonotenboom that the user is inactive does not mean the system is inactive. Have made software that captures software installations. I am well aware of all file and registry changes that Windows makes when it is running even when it is “idle”. And many of the things are usefull for most users, i am not a fan of “slimmed down Windows versions” that are published by individuals as better. Mainly because most users that download and use these unofficial versions do not understand what is disabled and blame Microsoft for broken things that the author of the modded version is to blame for.
The main issue is that Microsoft have no conventions about How to store data in the registry. And applications, include Microsoft ones, have no documentation about what every registry key do.
@@IIARROWS What you mean when you say «other people's applications»? Applications of other accounts on my computer? Or applications, written by other people? I obviously may need to know settings of all application, installed on my account, and other's application, if I'm an admin of this computer.
@@vbifusful Why yes. Because the application can sanitize your settings, warn you if you have contrasting settings, or set the best for your hardware, etcetera... Always follow the guidelines for your application.
There are a few reasons for this and it's not usually bad. One is if it's installed stuff other software may use it might mark it so the other software doesn't duplicate installing that item think about how all those programs installed various directx dll's for each and every one or the 40th time a program wanted to install ver xx.yy.zz of the dotnet runtime, etc. Another is minor machine (vs user) specific settings that might matter if you re-installed or installed a new version. Also to keep you from installing free ten day trials over and over again (though they now just make you sign up and then check online). And lastly windows almost always ignores registry entries that don't apply to anything so all you waste there is a couple bytes in on obscure file on storage like billions to trillions the size of the data. If you're truly worried about it you can use a reputable un-installer. Be extremely careful about 'registry cleaners' as they almost never do anything actually useful and are more likely to hose the system than speed it up. Windows has gotten pretty good at ignoring dead entries.
But if that data in your registry doesn't do anything, there is also not a problem. It even do not slow down your system, it takes a few kb of storage on a GB drive, that's all. Do NOT use any cleaner program, that makes everything worse.
It looked like that due to similarity in design of regedit with file explorer. They even share icon. But windows does it in more places where stuff can be navigatable easly kindda like folders. But its just a facade
@@chrisjlocke It kind of is a file system. It is a hierarchical data structure built out of keys(paths) and values(files). The keys live in a hive(partition) that can be loaded(mounted) or unloaded(unmounted) at runtime. In other words, it is a data structure with the exact same structure as a windows file system. The reason it exist was that NTFS wasn't released yet. It is a file system that was made because the primary file system of Windows at the time was insufficient and Microsoft needed a fix faster then it could change file systems. If NTFS had came along a bit sooner, Windows would have just used files similar to how Linux uses /etc.
@@Amir_404 Interesting historical knowledge, can I read somewhere about that? Though I don't fully believe MS would have sticked to "INI files"; the Registry is a search-efficient B-tree structure with granular security permissions on key-level; all merits of NTFS aside, I'm not sure it could compete with that. There is a reason why we still have database technologies/engines with their own binary file formats - and not a heap of raw text files.
I remember modifying the WIN.INI, SYSTEM.INI, and other .INI files that the applications create. The registry IS a much more advanced system that can directly read or write specific keys instead of parsing an INI text file which allows a greater chance of compromising settings and properties, if a program parses into a settings line at the wrong point. The same goes for AUTOEXEC.BAT and CONFIG.SYS (Remember when Windows 3.1 was a thing and when you add a CD-ROM drive and it adds the 'MSCDEX' line AFTER "win" so your CD-ROM driver didn't load until after you exited Windows?).
I'm a network administration student, and though I am fairly knowledgeable in active directory and the registry, working through that on the regular, is NOT FUN.
The registry was a noble attempt to make a database for system settings. Unfortunately it was done in a half-bottomed way. The system APIs for the registry are half-baked. No concept of versioning or backing out changes. It's easy for any app to mess up the registry. It's like a small directory structure, but not a fast or good structure. Half a system design problem and half a mess caused by apps not doing things in quite the best way. Long ago I was trying to install a device driver with an installer program. Ran into several intractable problems with installing and removing and updating device drivers. Real obvious activities, like enumerating drivers by name, or backing out a driver, seemed to have plenty of dead ends, where you could add registry keys but have trouble deleting or renaming or moving registry keys. An awfully weak aspect of a complex operating system.
To fix that, Windows is more and more virtualizing the registry so that apps can run amok in their virtual registry and not affect the actual registry.
The portable feature is never used. I work in IT and none of our business apps “transfer” their settings from one pc to another. Maybe you are referring to roaming profiles or backups but I’ve never seen an enterprise app put settings in the user hive and everywhere I worked the management want machines wiped and a standard image deployed so those settings are lost
I have seen it but it was in the early days, its just that so very few programs actually make use of it that its mostly not worth the effort since your would have to have all your applications supporting it, if not, your going to have a mess. The idea was good but MS should have tried to enforce it more, over time it seems less and less other applications make the effort. Today different programs store data in different ways defeating the portability idea. Still, in corporate settings, the ability to enforce registry settings and prevent changes are actively used. With ini files, that would be way more complex and many programs would probably invent their own "registry" solution once settings get to many, making it even harder to centralize.
I have implemented it a few times. it is almost required if your do any sort of the Terminal server farms or Citrix implementations. It does have it issues it definitely slows down logon times since you have to update the registry and user profiles as well.
@@midnightwatchman1 I’m talking about environments without terminal services or Citrix and where the app settings are not stored in the user hive by design. I’ve never seen settings transferred from one software hive to another as an integrated feature of the registry in a domain environment without 3rd party intervention, backup, cloning or clustering
Why then Microsoft cannot create a "Purge & Rebuild" option for the Registey file? So many problems are embedded into the registry file because it is a dump landfill file where uninstall programs leave their trash.
Probably because core components & updates that were installed since the last clean install all leave their traces. It's just too risky and usually not worth it to manually force a state the registry was never in naturally or apply a backup onto a set of altered system files. Also, what you crave can mostly be accomplished by a combination of sfc, dism, system restore and some third party registry surveillance tool (only checking for changes).
What do you think happens if uninstalled programs leave their trash behind? They are just unused, it's not like they do something, like slow down your PC. And unless the software is really badly engineered, it shouldn't take more than a few kB of space. In that case, never trust that company again.
@@IIARROWS the way the windows registry works means every entry is processed any time a number of major registry features get used i.e on boot up. and it cant tell the difference between “this is important” and “this is junk from a program who’s dev decided they didn’t need to add the extra lines of code to the uninstaller to remove all these entries they put in”. One program’s left overs isn’t the issue its after years of operating you start to hit the limit of legacy windows code still used in the registry. The other is microsoft’s QA on updates is awful these days. I got hit by a update on win10 that broke a registry entry for a windows telemetry service’s ability to phone home the telemetry services response was to regularly cause all drivers to restart causing a lot of issues. Microsoft deployed a patch that they said should “fix it” they did replace the entry and gave the service a new address to send data too but they forgot one critical thing they never got around to actually registering the domain they were trying to send data too leaving the entire thing still broken months later. I ended up upgrading to win11 hoping that would fix it assuming with some of the additions to win11 they would of revamped their telemetry system. and i ended up being right.
And, in a somewhat related thought, why do Windows apps have to store program files in different places ? Program Files, Program Files (x86), ProgramData, AppData, etc ? I'm not sure that I would call the DOS days as the "good old days", but if you wanted to move your program files, you just moved them. Today, if you even think about it, something will break. The worst part is that some, such as certain email programs, will store part of your data in one location, and other parts elsewhere. I don't always want to backup my entire drive, but if I don't, I might miss something important like my contacts which might be in Appdata.
It's because Windows 10+ uses a hybrid file system built on top of Windows 7. The earlier, openly accessible parts of the file system are maintained for backward compatibility with legacy applications. The Windows 10 file system uses hidden folders and checksummed keys to prevent tampering with folders installed by apps purchased from the Microsoft Store and to prohibit installation of third party software on Windows10S machines. The system folder names and locations follow ad hoc Microsoft conventions that accumulated gradually over the years.
It’s not necessary if an app is designed properly. But Windows is a developer’s culture, and lifelong Windows engineers get entrenched in doing things a certain way.
Program files and Program Files x86 both store binaries and are supposed to be write-protected. ProgramData stores system-wide data that programs use, including things like the list of parts of a large program (say, Office) that you installed, downloaded fonts, etc. AppData is per-user storage. It's like asking why Linux has /bin, /etc, and dot-files in your home directory.
@@QuicksilverSG Since they have the whole abomination of secretly writing files in Program Files to somewhere else, that does't explain why we have Program Files x86. Anyway, why should Microsoft be enforcing this? Why should this part of the file system behave differently, and why shouldn't I be able to write there if I want to? For your typical app developer, having the directory writable for admin only should be more than enough incentive to do something sensible.
@@xpusostomos Back in the Windows 95 days there was just one Program Files folder, as all applications were 32-bit (aka "x86"). When Microsoft later upgraded Windows to support 64-bit apps, they renamed the old Program Files folder to "Program Files (x86)" and reserved the new Program Files folder for installation of 64-bit apps. Microsoft was expecting third-party app developers to migrate their apps to 64-bit and planned to eventually phase out the (x86) version of Program Files. Much to their surprise, it didn't turn out that way. Since 64-bit Windows was backward-compatible with 32-bit apps, the easiest path for developers was to continue producing a single x86 app to run on both 32-bit and 64-bit versions of Windows.
In other systems, each program gets its own directory. There it saves the settings in an .ini file. If the program does not work, the entire directory can be deleted and the program reinstalled. that then solves all problems.
@@fnunez The INI file should be stored per user, possibly with per user data. The program binaries and libraries should be stored separately. If your INI gets trashed, you delete it and let the app create a new one with default settings, or you restore the file from backup.
The problem with registry is that application data is not isolated but instead it's saved in a global place. And what's worse, is that it's not guaranteed that the data is not removed after uninstalling an application which can affect system and its stability. I remember there were a lot of problems related with the default application and file extensions when I uninstalled notepad++ 32-bit and installed the 64-bit version, this was because there were a lot of leftovers in the registry after uninstalling notepad++ 32-bit. Such bugs are really not fun to deal with. Unfortunately MS can''t remove registry because of backward compatibility, too many applications will break😑.
The problem is not the registry but how poorly it is organized. Every database sucks when it's poorly organized. E.g. Microsoft should have made a way better distinction between "here's that's the personal storage space for your app, do there whatever you want and if your app is deleted, we just remove all of that, no uninstaller needed" and system information that apps may also want to read and may be even allowed to modify but the later should have never been possible without prompting the user for permission first. There seems to be this distinction top level, until you realize that a lot of critical system information is stored in the same places were uses apps also store their stuff and to that user apps have full access, including write access, so they can easily mess up your system e.g. by messing up Windows-Explorer that Microsoft treats like a normal app, when in fact it's a critical core system component.
But what if I want to uninstall an application, delete all of its operating files because it failed for some reasons, and keep user settings? When you uninstall often you get the option to keep those, and it's useful. If the uninstaller doesn't give you the option and doesn't delete the settings, it's the uninstaller fault, not Microsoft or the registry.
@@IIARROWS If reinstalling did fix something, it's probably because the uninstaller removed the settings and it was the bad settings that caused the issues, so just removing all settings would have had the same effect without reinstalling anything. Applications are basically read-only (if they are code signed, they must never change and on other systems they are often even hosted on read-only volumes), so uninstalling and re-installing them should not lead to a different content on disk in the end but you should get byte for byte the same executable and libraries as before.
@@IIARROWS clicking to keep user settings should never leave registry entries. the most common is a settings file/folder in the folder it was previously installed or in either local or roaming in the c/users/“username”/appdata hidden folder. The registry is not for general settings and preferences of ordinary apps the biggest legitimate use by consumer software is for storing licensing/activation records to avoid needing to reactivate every time you run a program with such a system.
Microsoft have some kind of filozofy about how to put things in Registry, shame that they not share with rest of us. Documentation for Registry is so poor that it became a guessing game, how things should be. The mess with Wow6432Node don't help.
I have had my Registries get corrupted. So much so that they ended up with entries, keys and values with random numbers and characters where the system becomes so unstable I had to do a clean re-install of the system and all programs I was using. The problem with it is when it does get corrupted the whole system is affected. When an INI get corrupted only one program get affected and then we know what corrupted it. Especially if it happens more than once. And we only have to fix that program not the entire system. No, it is not a sophisticated DB it is a crappy simple DB that is prone to errors and corruption that can not clean itself of data that is no longer needed thus gets extremely bloated. Did I mention that it has multiple duplicate Entries that bloat that data even more.
This is the same way I feel about the registry and I wish Microsoft would have never started using it. I work in IT with Windows but my computer at home has Linux on it. Most config files in Linux are in the same hidden folder in your profile and the files are named after the applications they belong to. It's so much better and vastly more intuitive.
@@garystreck5991 I disagree. Over the years, those files have moved around and different distros do have their own take which can cause any number of problems. And not all programs store their settings in the etc folder and on some distros there are multiple etc folders also. I had that problem where the same file existed in 3 places with different settings, used by different programs so you you had to know which one you needed to change depending on which program you wanted to affect :/ Not saying registry is better but linux is not necessarily better either. And I have been using Unix/Linux since back when SCO still was the good guys and the only way to run unix on a normal PC and when linux was still considered to hobbyist for corporate use.
@@davidmartensson273 I'm thinking it must depend a lot on which distro you use then. I will admit that not every single config file is in the .config folder, but a huge majority of them are for me. And if a distro has multiple etc folders that's just sloppy and unmanageable. I use Arch.
Ia am sorry, but in now 31 years of using the registryon literally thousands of systems, with VERY complex software on many highend machines the registry never ever got corrupted in such a way you say. It seems like you either got malware, tampered with lowlevel software or defective hardware like RAM. Also the registry is saved in different places as well, and a standard user cent even write to the system related entries. Whatever went wrong on your machine is definitely not the case of the registry routines.
If a subsystem just works, people wouldn't complain about it. They just would not know about it. A 'registry" word is widely recognized among non-professional users, so there's something wrong with it.
Because people Google "Slow Computer" and it returns junkware "Registry Cleaners". They download and run them, things get worse, now they're convinced that it's definitely the registry.
@@TheNamelessOne12357There's nothing wrong with the registry. I would bet that the reason so many people blame the registry for their issues is because of PUPs like CCleaner and their shitty registry "cleaners"
A plus of the registry is that most configuration settings in Windows are located in a central location. Where as some other operating systems have files that usually should be located in a common location but most of the time there are is no real standard that developers follow. Not beating anything up. But there are positives and negatives to every operating system. Noting is perfect. In the end developers for any application and any OS or device must strive to produce quality software and stop "pointing" ;) fingers.
The beauty of registry is in remote support, when I can use the power shell to scan the whole office to see known configuration error in a very short time if the target option/ application setting is written in registry, and I don't need to risk contaminating the other setting data as long I Don't touch the folder structure The problem it sometime the stuff is all over the place and even Microsoft don't document it properly for external use One example is the Uninstaller registry, they never properly document the relation between the 32-bit and 64-bit of this registry, program scanner through the registry I reverse what they are doing To Do a workable solution The scanning this part create report way faster than other native gui command
You can do that with the text files that other OSes use without much effort. Tripwire in particular can also check the binaries as well while you're at it.
If used responsibly by a knowledgeable technician, they can actually be useful. But whatever you do, NEVER let them clean ANYTHING automatically! Go through everything it happens to find and suggest, and go through them with a fine tooth tech comb and knowledge and experience with the registry. Some things they might find might be remnants from old software that's been uninstalled. Those can almost always safely be removed. Other things they might find can be erroneous path names. Those aren't all that common, but it does happen and those can be manually edited if you know the correct path/filename. But when in doubt, or you just aren't familiar with the registry, just simply don't muck around with it.
What bothers me a lot is that I want to just compile something using Linux components, and it requires downloading a lot of stuff instead of stand-alone build. There are a lot of other problems with Linux and Unix systems, which are still unsolved.
Lots of users and companies have time and skills invested in Windows. People have software in Windows they use. Linux has a learning curve, people don’t necessarily want that. In my view, neither system really cuts it.
As a Linux user, I haven't seen registery for x numbers of years now. Yeah, it does make certain things easier or easier to fix. But sometimes it gets bloated too much often
I hate the process of finding the right file, figuring out some convoluted syntax and the finding the right change when something goes wrong on my Linux box. Several times I've ended up reinstalling rather than trying to find the fix.
@@kylewilson4097 Yeah, configuration is by no means any better in a typical Linux environment. And if you look in a typical .config folder, it is equally messy as the Windows registry, full of no longer installed programs, outdated versions, etc.
@@jbird4478 but you can deal with .config like any other files.... mv, cp, rm etc. and when you do it, all of a program's config is dealt with, not just some.
@@kylewilson4097 I've seen in a certain distro (I don't remember which) where all the configuration files are in a .YML standard. I don't know whether they just made a wrapper around the programs or whether they've rewritten all the programs.
Leo, I just wanted to say, your videos are amazing and have helped me out with a lot of issues and questions I've had in my upgrade journey from an 11-year old Windows 7 PC to the new Windows 11 system I'm using now. Your style of speaking and your way of explaining things is so intelligent, and understanding, and patient. Have you ever considered doing narration for audio books, like tech manuals or even novels? You have the perfect voice for it! Anyways, thanks again, and I'm really glad I found your channel!
It would be nice to have an "undo" feature on the regedit menu. There are third party tools that probably offer that feature, and other registry features (such as backing up the registry, etc). But an undo option, I would think, would not be difficult for Microsoft to include.
@PaxAlotin-j6r Windows does do the same. That's what VSS and Restore Points are about. Once you set it up to back up, you can right-click the file and say "restore earlier version." If it's a system file, you pick the restore point and say "restore this" and it restores those files.
@@darrennew8211 I don't know what that is, like 99.99% of other users, but the problem is, whatever backup solution you have is not going to play nice with it. I can't open up my favourite backup solution and say, restore %HOME\AppData\Mozilla and have everything work.... If I even can, or know how to, or even have a backup of the registry, it's going to be at a different time and be out of sync with my backup.
That's what export is for. If you are playing around in the registry, you should always export a copy of what you are playing with first. Registry editor should not request admin privileges to use. User settings should be accessible without it. Request escalation if you are moving onto system settings, not user settings.
@@mikechappell4156 EVERYTHING plays in the registry which is why you don't know when you should be exporting. . Which is why it's a problem that it doesn't play nice with backup programs
@@xpusostomos I was referring to directly editing with regedit. If you are in regedit you know what keys you plan on deleting or modifying. Most settings are stored in the registry and iirc there are some dynamic keys as well, which prevents you from copying hives that are in use. I'm aware that windows locks the files. The file should be user readable when it isn't being written though. I'm not even sure you can export the entire registry. I've done large portions in the past and it was painfully slow though. Regedit should have an option to backup any hive or hives and restore any hive or hives. Obviously admin access for restore system hives, user access should be sufficient to manipulate user level hives though. I think regedit is also accessible from the repair console, so you can edit hives that aren't currently mounted, and in the repair console you can copy the DAT files as well. I don't think I've used it since windows 7, so I'm not sure how much it has changed, but it wasn't designed for the average user and is not what you'd call user friendly.
There is a flaw with the SOFTWARE hive when dealing with multi-user environments. Eventually enough “breadcrumbs” are left behind via guid data that the registry begins to “bloat.” When this bloat occurs, logins can be very time consuming for every user. Zapping those entries too late does not fix the issue as registry hives do not automatically compact.
But they could move to a sandboxed registry per application model for backwards compatibility. So the system with updates would gradually use the registry for less and less settings, and at one point none of the system components would use that. But if an application needed that, a sandboxed empty registry would be available separately for each and every application.
You make is sound like ini files are not portable or able to be secured. I see it as the opposite. ini files, or any text based config file is way more portable. It's just a text file that can be copied to any machine or synced over a network. And as far as security, that's where users and groups come into play. Where the registry is one big database. You can export parts of it to a .reg file, which in itself is just a text file. But you have to dig through the registry or already know what you parts you want, and what you are looking for might be in separate areas of the registry. Plus, the registry is made of a few large files. if the file gets corrupted, you can lose everything. Individual config files would prevent this. If one gets corrupted, it probably isn't going to break the system. And if that did happen, you can always delete the messed up file and a default skel file will normally be created or used. Since the config files are easy to back up, it's also easy to revert back to a working file, without any special software.
...it's funny how you like to ignore the downsides of ini files, and why companies like Apple and Microsoft decided to use a different approach. *_"Plus, the registry is made of a few large files. if the file gets corrupted, you can lose everything. "_* No, you don't, that's what a backup or redundancy is for.... that is required for EVERY operating system, no matter how good it. If your SSD totally fails beyond repair, then that information is gone, regardless the OS you used. The extend of the drama is that point not related to the quality of the OS, but your skills as a user. If you're that lazy guy who doesn't care about proper redundancy or backups then it's just YOU who is responsible when you lose everything.
There are so many drawbacks in using the registry and the purpose it serves is fairly simple. I worked over 20 years as a SW engineer in quite a few companies and I have to tell that in most cases of using registry it led to problems. All sort of problems. Don’t forget that registry is also very slow compared to a straightforward configuration file. BTW in the newest platforms I moved to using TOML format instead of JSON. Readability is amazing
You can use ACLs to limit the read/write access to INI files on a granular level and if you can share the registry hive on the domain, you could also share INI files. It probably is easier to manage with group policy. They could have designed a *nix like system where the main configs were used and checked to see if local/personal configs were available, but they didn't initially. It seems like what they are doing with AppData though.
I didn't realize there's people who want it to go away. It was just yesterday I was thinking how many more inconveniences I've experienced in Linux due to everything being a file, and not having something like the Windows Registry.
One of the worst abuses of the Registry I've encountered was a game (System Protocol One) which stored its _saved games_ in the registry. Which, of course, you'd never remember when you had to reinstall Windows, so you'd never think to export the relevant Registry keys, and thus end up losing your saves every time you reinstalled Windows.
I worked on an old windows program that used the registry to store various user settings. Then had to do major overhauls when windows started applying security to the registry. Had to move a lot of settings to the User hive rather than the root hive. I guess the fault of our developers not understanding the purpose of the various hives but when MS had no security to prevent us misusing it, I don't blame my forbearers too much. But the real mess was realizing that windows kept separate registry values for 32 bit and 64 bit programs,
The original intention of the registry wasnt even for settings. It was a registry for Component Object Model (COM) class IDs. These are GUIDS for classes along with details on what dll the code was in and how to create an instance of it. Then any application could re-use these software components. Its a fundamental technology in Windows and Office and its still a good idea. But once they realized they had this central system database to store information it occurred to them they could use it store other things too.
The registry is freely accessible by application installers (not to mention knowledgeable users). There are parts of the registry that Microsoft conceals or keeps read-only, and other parts that are automatically restored at start up. It's not "just a database", it's an active part of the Windows OS infrastructure that works independently and in conjunction with the Windows file system.
@@Turco949 The registry is not stored in specifically named files in the Windows system folders. It is a collection of relational databases (called "hives" in Microsoft jargon) that are distributed among a variety of Windows system files. The lists of keys and values displayed by RegEdit are generated dynamically to report the current internal state of Windows, each time you run the app.
The real reason why registry exists is because all file paths for applications on Windows start with disk letter, and it can change at runtime. On the other hand registry always stores your data entry in a pretty defined path. Like files in /etc and ~/.config on unix-like systems :)
This nonsense started well before that was an issue. It wasn't until I started to use USB drives and the like that I started to have disks popping up with changing letters. Floppy drives were basically always A; and/or B: and the primary HDD started with C and continued to the end of the disk before moving onto the next disk. In practice, there was no inconsistency as there would usually be only one drive and probably only one partition per drive. The only reason I have problems with drive letters changing now is because I'm swapping a pair of disks for backup that I want to use the same drive letter.
Writing scripts to collect, update, or remove information from the registry was always pita. Running a mixed environment, I always hated dealing with windows reg
Corporate users aside it is really horrible experience when you are copying a program or a game to a new machine and it just refuses to work because of some missing key in the registry You are lucky when program is shipped with some init script that auto-populates the registry for you. Also trying to find something in the registry is almost impossible task Why couldn't they just have flat list of folders where each folder represents a program?
I don't think simply copying programs between systems is a good idea, because besides of the registry issue, the programs can depend on some dynamic libraries that could be missing from the different system. That being said programs shouldn't crash because of some missing registry value either. Default configuration should in my opinion always be hardcoded in case it's missing for whatever reason.
@@fisyr almost every program in windows is either shipped with its own copy of dlls or uses common things like c++ runtime that are really easy to install on new machine
There is barely docs available for devs to make registry settings safe. UWP and Windows App SDK tried to solve this by saving the app's virtual registry into its own file but developers won't move to this new SDK
@@kipchickensout Anything you like, from simple soft links to revision control systems to basic rsyncing a backup to a separate directory/system. And since they're mostly just text files, you can use any other utility you like to quickly parse and potentially modify them. The problem with the Windows registry more than anything is that it tries to do too much and doesn't have any particularly good way of purging obsolete entries or fixing it when it gets corrupted. I've thought for decades at this point that if they want to have a registry fine, but at least have it generated from other files that can be edited by hand if need be. I've just had too many times where the registry got corrupted and took the entire system down. I have never had that happen, not even once, with Linux of FreeBSD. I haven't paid as much attention to Linux, but FreeBSD has sysctl that does a lot of the same stuff that the Windows registry does, but it's regenerated on boot from actual files. As to your question, there are a lot of utilities for managing those dotfiles dotfiles.github.io/utilities/
There has to be a way, I know it's needed for legacy apps but they could come up with a way for it to create a reg file in the app folder or if it tries to create keys and all the other api calls can just be emulated or ignored. This is exactly what Proton is doing now for windows games on linux and they run really well and don't pop up any errors when they need the registry. I know unreal tournament stores it's resolution settings in the registry, Proton just moves that to the game folder.
The registry was around in Windows 3, too. Having it as a flat database is a bit of a handicap. As a desktop support person, trying to remember is the key I want Is in the HHKEY_LOCAL_MACHINE/current_config/software/Microsoft/Windows or WindowsNT or in a different hive. Group Policy Object (GPO) helps a bit with this as you can create a policy to always have a key at a certain value, or even delete it outright. Changing to a relational database or, having symbolic links to values that are common to several keys would be better, I think. Linux and UNIX use the concept of a registry with the /etc directory, through it doesn't provide the Interconnectivity of the registry. The registry is a good thing with Windows, but the way information is torwd is outdated and grows to be unwieldy very quickly.
When virtual machines came along followed by sandboxing, the registry became obsolete. If you are using an OEM smartphone and you accidentally dl-ed something malicious, uninstalling + rebooting gets rid of 99% of the viruses. I sure don't miss the days of manually deleting harmful registry entries! 😵
*_"When virtual machines came along followed by sandboxing, the registry became obsolete."_* Nonsense. When you want to run software that requires a lot of processing power (3D/video rendering, games, crypto mining,etc), it would be foolish to run it in a virtual machine. Different applications... different requirements, but it seems to me that you only use a computer to browse the internet.
The Registry came when Microsoft bought Digital's VMS as that company was going bankrupt. In VMS it was called the "verb table", and it was a way to start programs from the command line and pass parameters. It was pretty scary changing the verbs, you culd crash the machine with one tiny typo. Sound familiar?
I have to say that I am ignorant of the "verb table" even though I was a VAX/VMS administrator (self-taught) on a MicroVAX II. I was working as a research engineer at the Oak Ridge National Laboratory at that time but I had a good deal of computer experience as an ordinary user on IBM mainframes and the largest DECSystem 10 in the world, as well as MS-DOS PCs. The procedures for connecting the hardware, loading the operating system from tape cartridges, and installing the Fortran and C compilers were so well documented that I had a system put together and running withing 24 hours. I was able to add or remove users, grant permissions, and make backups within the next 24 hours. The group I was working for used that MicroVAX for 3 years before transitioning to an HP 9000 730 PA-RISC workstation, running engineering software we developed ourselves. I never had occasion to learn about anything called the "verb table."
One of the problems with registry is that you can't read content in a human readable form like you can read in the files that you can find in the editable text configuration in GNU Linux.
Cant read content in readable form? Tells me you have never worked with the registry. Its values can be strings, boolen ect. Just like a config file. It is config files just structured in a database. I work with both windows and gnu linux. Does windows have more history to maintain and be backwards compatible yes. Is that realy the biggest issue with windows, no. Windows lacks ONE huge feature that all distros have. Packet managment. They have some here and there in the later years. But far from what the gnu linux distros have. This forces companies to maintain this them self. And everyone is for them self. Using SCCM, Intune ect
@@eirikgg Tell me exact meaning of {042D8A51-5878-4000-9C10-C04AFF122A1F}" In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{042D8A51-5878-4000-9C10-C04AFF122A1F}" "Triggers"=hex:00
@@The_Penguin_City and /etc/shadow root:$6$xyz123$abcdefghijklmnopqrstuvwxyz123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ:18000:0:99999:7::: We can agree we both can read them and edit the values.
@@The_Penguin_City The exact meaning of "{042D8A51-5878-4000-9C10-C04AFF122A1F}" is a 128-bit number. The point isn't what the value of that number actually is, but that number represents something unique subset of the system.
Unifying all of the operating system data and application data in a single place was a colossally stupid idea. I don't use the registry in my applications.
@@heyyou274 1. Because it conflates all program data into one place. This makes it more difficult to find and separate out. And there is little corresponding benefit to it. 2. Because if the registry gets destroyed, the system is dead. And windows used to destroy its own registry a lot. Admittedly it has got better at this. 3. Removing an application got way more difficult with the registry. Many or even most applications don't clean their registry entries when removed, and in fact some call this a "feature", because it supposedly maintains settings. This can cause interesting things like applications that have persistent problems because the registry entries don't go away, and have to be manually removed. As a developer, I am a big advocate of "one tree, one application" methodology. That is, an application is contained in one tree under one directory entry, without change on installation. This means it is installed by simply copying the tree to disc, and can be removed by simply removing that tree. It does not use a complex installer process (such as flatpack or other). It does not spread itself all over the operating system. And all of its configuration files are contained in that tree. Eclipse is one such application, as are all of my applications. Do I use the registry? In cases I am forced to. For example the path is in the registry, and I have to alter it. There are other examples. But I prefer to keep as much data outside the registry as possible.
it's not necessarily bad. i think, the thing that's bad is how Microsoft went about it. not enforcing rules like which application owns which entry, and when stuff gets removed. they were naive in thinking it would be a temporary solution
All I know is I switched to Linux a few years ago & haven't had very many issues with anything at all since. Might be worth mentioning that I'm a pretty heavy gamer, too.
"Those issues would still exist for any other replacement technology". I see this on Linux. There are at least three places you could store your application configuration, and many end up going with the least recommended one and dumping it directly in a hidden folder in your home anyway.
Bravo Leo, very good explanations and competent views on the complexities with the registry. The registry is frustrating, but also reveals just how complex a modern PC is. You have a new subscriber :-)
Another “feature” (if you can call it that) of the Registry is the fact that it prevent(ed) your hard disk from filling up too quickly. Most files have an allocation of 4KB and if you have many files with a 4KB allocation, your disk space goes away quickly. This was more a problem back when hard disks were very small (compared to today) and a database-type solution that has many different values in only three or four files saves a significant amount of disk space.
Registry needs to be made easier to search and also have a transactional record, including what applications did what and what time. We also need to know what application(s) owns different registry entries or at least initially created them (yes I know some are shared). It needs options to rollback and roll forward as well.
You're right in saying we cannot just ditch the Registry outright...however we could at least have some consistency with it. And *actual* documentation. And while it would require a complete rewrite of specific parts of the Windows code base...I'd be hesitant to say that it'd be impossible. Also, for portability the Registry is entirely outdated even IF it's still used for that express purpose... Whether people like it or not (And just to be clear I do NOT like it), cloud storage is the standard for portability going forward. So it's hardly like the Registry couldn't be outright ditched, or be made better...it's more whether or not Microsoft FEELS like doing it.
It's actually harder to do that with the registry than with configuration files. A short shell script can both check the file into the revision control system and make the edit with little fuss or muss. Or, you can do it without the script at all in like 3 lines of commands. And really, it's only one line if you're concerned about having that backup.
If you turn code analysis on for any C or C++ program that uses the registry and has never been statically analyzed before, you're practically guaranteed to find at least a dozen actual or latent bugs
2:17 the registry is not in any way critical for settings across machines. The exact same information could be exchanged as .ini files or whatever else.
The problem with the registry is Microsoft 3E'd themselves with it Look across to Linux and the DCONF which is basically the same idea as "registry" but: A) It's not the only place where settings are stored, so you can have your own roaming config files elsewhere without corrupting the main config B) It's human-legible, it's a plaintext file you can read and parse and use the manual to understand C) Some genius wrote the DCONF Editor flatpak which allows you to browse the dconf via the tags and parents with searching There are better ways of doing things, the "everything is a file" and "one config file for one program" seems to make more sense
@@user-rk9kb2sd9b Linus fell for a scam recently, he couldn't install Pop_OS which I've been using for months, I wouldn't trust him on anything Linux related.
@@orangejuice7964 The only real reason to retain the registry is that it was a convenient way to make it harder to port programs to other OSes. It doesn't make it that much harder, but every little bit helps.
Yes, Linux is an alternative. I use Linux Mint, BTW. I have several screwdrivers in my tool box. I don't worry about which screwdriver is most popular. I worry only that it does what is needed at the moment.
@@xpusostomos Those are much more common now than they used to be. It's getting to be a lot less common for programs to not have a no-install version that is essentially just a self-contained directory that contains everything that it needs to run.
A lot of that seems like a lack of a proper file permission system like linux does. The access control part is completely redundant if you replicate linux's permissions.
With my applications I aim to put all the application-specific settings in the application directory itself. That way, the application can be moved, copied, backup up, restored, *as* *one* *item*. You don't end up with the application copied to somewhere else and then falling over because you haven't also copied seperate configureation data from a separate location, which you can't even "copy", but have to export and then import. Additionally, I aim to put all the user-specific configuration settings in the user's settings directory. Again, so the user can transfer all their user stuff *in* *one* *go*, not copy their user data and then upon running the application somewhere else have it fall over because their user-specific setup has vanished because it's physically somewhere else. And this is because I started programming on a proper networked computer system in the early '80s - an *EIGHT* *BIT* system - almost two decades before any of this crept up on Microsoft's conciousness.
Which is the right thing to do. The settings should be in some combination of the install directory and user home directory as appropriate. If you've got a system wide package system like on Linux and most of the other *NIX OSes, then you can put the settings elsewhere.
Much better can be done than the current/old Windows Registry, including a backward compatibility. There is also a so big mess in this database that one could ask how dare one can see it as a database?
Not exactly a Windows fan, but if there's something that works fine on it is the registry. People tend to forget that in a multi-user operating system having a common configuration file like an INI for all users (human or not) is a big no-no in so many levels you can't even imagine all the problens would arise.
Only because they spend decades fixing the many issues that come of it. One of MS' addictions is being overly careful about backwards compatibility even when it causes problems later on because you can still load files from decades earlier, ones that most people have had many years during which to update to a more recent standard.
I hated how it was never documented or the way to use it was documented - or if it was, this wasn't publicised. The move to Windows 3.1 to NT/95 was clouded by this lack of documentation … unlike the WIN.INI and SYSTEM.INI files, where I knew every line of it. Instead, everything just became mysterious and each time we were told to do something in the registry, it was just a single unique key. Compare that to the Resource Editor (ResEdit) on the Mac, and all the 4-char resources were official. Each had a purpose and you could look it up.
Programms should have there own registry which is just an overlay to the complete registry. Program writes to there overlay and reads to everything combined
Many years ago I switched from a sound Blaster card to another manufacturer ( I can't remember who) after installing the drivers I found that my games ( notably Half Life 2, yes that long ago) had no sound. I went through the registry searching for every instant of sound blaster or creative, there were loads all over the place and I deleted records and keys as appropriate. After that my sound worked in games.
If I remember correctly, Creative made "total uninstallers" available on their website for just such situations. Lame that it wouldn't come with the software for the hardware, but it still was available.
The idea behind the registry is actually good, just wish they keept it "cleaner" and "leaner". Tons of pretty much orphaned data is there already at a fresh install. Not to mention its all baked together... if each program / service had its own "hive" or space in it - It would be way easier to make proper uninstallers etc and find orphaned stuff that is just bloating out the database and slows it down
It was always a terrible solution to the problem of storing configuratoin information. Sysctl from FreeBSD is a much better system and there are other systems that other OSes use as well. At a quick look you can identify a bunch of setttings and you can either adjust them once using a built in tool or you can have it changed more or less permanently by editing one of the files it reads. Some portions cannot be changed at different run levels and sometimes you need to adjust the permission to do any operation on it at all. In the years I've been using the OS, I have never had any problems with that system. I have, however, had the registry cause significant problems at various times on Windows that required a reinstall. That hasn't happened in a while, so perhaps they've finally got that fixed.
3:53 if the problem is applications sticking data in there “unsupervised”, isn’t that still MSWindows’/Microsoft’s fault for not controlling that better? Instead of letting any old application write anything to the registry all willy-nilly, restrict it to read-only access and require all new additions be handed to the OS via APIs so that the data can be standardized, checked for conflicts, and _registered_ in a meaningful way so that the OS knows every key/value in there and has checked it for conflicts and conformance. And malformed data can be just rejected outright. Surely that would be a better way to handle a central store that theoretically every application relies on?
The registry is useful to provide a system abstraction for more efficiently writing various values, especially on SSD since storing them in files on an SSD inevitably results in excessive SSD write cycles. And having a corrupted partially written file is way more likely than corrupted registry.
No, it's not. That's why you write to a new file and then copy it into place when completed or buffer the write. Also, apart from a failing drive, I can't remember the ever happening. I have, however, had the registry go bad a few times and take my entire install out with it. And if any of that's a concern, you really ought to have a USP protecting the computer from power problems.
@@SmallSpoonBrigade As I said, writing to files results in excessive wear on SSD. I've had multiple applications completely lose all their configuration settings due to corrupted files, but registry has always been rock solid.
i never understood why we needed a registry. its a resource hog. everytime the OS or an app does something it has to access the registry. applications cant be moved easily as all the path are hardcoded into the registry. i hated the bloody thing from the day of its inception and my hate for it has not faded away and is still going strong. i miss the days when an app crashed and it was possible to troubleshoot whats going on or have your own directory structure. it makes no sense to me that i have to google for example where a game stores a save file. windows is such a mess.
I believe that you don't actually understand The Registry. It's a mythical thing to most people, it seems. Like a Unicorn that most people have never actually experienced.
The registry was first introduced in Windows 3.0. Swear. I was playing around with Windows 3.0 for various retro reasons circa 2005 and stunned when I installed some app - Microsoft Access 1.0 I think - that included a registry viewer! Could not edit anything, mind but I could view registry keys. Alas I lost all that good stuff with a dropped HDD but I had discovered Linux by then and the 'fun' began again. Windows from 3.1 was just so, soooo boring! OK, I like Windows 95 in terms of UI even though it was at war with itself.
When they rolled out the registry, they didn't roll out an API to interact with it, so every vendor had their own version. When everything depends on one system, and everything touches it, it's a recipe for disaster, whether the registry itself is robust (it isn't) or not. But entrenched bad design decisions are the very foundation of windows, putting the "backwards" into "backward compatible" (which it isn't, either).
The registry is only API and nothing else and never was. Nobody actually knows where the data is really stored, or writes procedures against manipulating bytes on the hard disk.
Oh... in the title and the first seconds of the video I thought you meant dump the entirety of the registry in case of a bugcheck xd I've never heard anyone ask whether we should just get rid of it
The problem is that the registry is an extremely leaky abstraction. It’d be like if every MySQL client needs to know how construct their requests to produce correct binlogs. Users and developers shouldn’t need to interact with or know much about how the registry works under the hood to facilitate the advanced OS features. Unfortunately, the registry is the direct API for both consumers, exposing everyone to the same complicated concerns. Except for that context, yeah, people are just “holding it wrong.”
Instead of the registry they should use a strongly-typed hierarchical configuration database, capable of fast searches and fast inserts, and divided up into separate trees for computer settings and per-user settings. Oh, wait...
The answer to the question is, "What alternative to the registry do you suggest?" All the configuration information for the APIs and various protocols used for software, API, and hardware interactions has to be stored somewhere. Should we just let each software developer create their own custom formatted text, xml, or json file? The registry provides a standardized schema and an interface for it that's searchable. Yes, the registry could be documented more thoroughly. Right now for many it's a riddle wrapped in a mystery inside an enigma, to borrow Churchill's characterization of the Soviet Union's government, another arcane system that was similarly difficult to wrap one's mind around.
I would disagree with the security aspect. ALthough it can be secured for admins, all users have access to read . ANd not to mention how many times when permissions are messed up by Windows themselves
Registry should only have been a thing for OS specific settings. Applications should not have been allowed to write their config there and instead use text files like before. That would be the best of both worlds
I always thought it was to control. Concept sold to programming companies. To convince them to make programs to make sure people can't copy and use their software or give copies away. It's early 2000s tech ideas.
Turns out that giving apps the ability to throw whatever they like into a central system heap of data is not a great idea. While “too entrenched” is a good argument for why you can flip a switch to transition, there are quite a number of ways one could transition from the registry. Not going to outline one of them but lets just say that 1) transitionary period 2) virtual interface for legacy software and 3) a more isolated application model along with a 4) “compatability mode” will allow for a transition over 2-3 windows versions. But perhaps Microsoft just values maximum backwards compatability more.
A decade or two ago it being "too entrenched" might have been a compelling argument, these days, they could easily capture and redirect the attempts to write to or read from the directory either to actual files or smaller virtual-registries if they wanted to. They could also have a system like on other OSes where the registry is built from other files and just regenerates whenever the OS boots up. Parts that don't change can potentially be cached without much harm. It would be a much better system than what we've got now.
I’d much rather all programs and all files associated with them were self contained in their own folders, this idea of having data spread out all over the place results in most programs not being fully removed, scattered data, and an OS that gets worse as it ages.
With modern disks being so large, fat packages are often times a reasonable solution to a lot of different problems. I wouldn't go so far as to say that all programs should be like that as I think that goes a bit too far.
@@SmallSpoonBrigade not saying they can’t share some things like libraries etc, more anything that relates only to that program should be sandboxed in its own folder, so no need to write to things like the registry.
TLDR: The registry in theory is great, but the mere existence of the registry opens it up to idiots using it wrong. So the question still stands: why not replace the registry? If idiots / forgetting to have your app remove some values can cause things to break, it doesn't matter how secure and robust the system is, obviously
That's less of a problem now than it used to be, but it's still a problem and it's mostly because those apps are trying to write to are read from things that they shouldn't ever have been accessing.
if you are ultraparanoid about legacy registry settings surviving after an uninstall, you can use ushampoo to monitor installs and do a perfect uninstall. kinda a pain, but less work than reinstalling windows if you want a clean hive.
There are tools, for example zeroinstall and just using the no-install version of software. Many, if not most, software programs these days offer that. At least as far as free and opensource software goes.
I love how registry contains like 99.9% of values that never change, it's more like a genome than a config database
What I find interesting is that there are also registry entries changing every second. On an inactive machine. ¯\_(ツ)_/¯
@@askleonotenboom i wonder if one is a copy of it updating its unix time/date.
@@askleonotenboomoh, you mean the system stats like CPU load, GPU load and the like? Yeah, I was shocked to learn the place to query those is in the registry 😅
@@askleonotenboom that the user is inactive does not mean the system is inactive. Have made software that captures software installations. I am well aware of all file and registry changes that Windows makes when it is running even when it is “idle”. And many of the things are usefull for most users, i am not a fan of “slimmed down Windows versions” that are published by individuals as better. Mainly because most users that download and use these unofficial versions do not understand what is disabled and blame Microsoft for broken things that the author of the modded version is to blame for.
The main issue is that Microsoft have no conventions about How to store data in the registry. And applications, include Microsoft ones, have no documentation about what every registry key do.
You don't need that. Your software does what it needs.
You don't need to know settings used by other people's applications, including Microsoft.
@@IIARROWS What you mean when you say «other people's applications»? Applications of other accounts on my computer? Or applications, written by other people? I obviously may need to know settings of all application, installed on my account, and other's application, if I'm an admin of this computer.
@@vbifusful Applications written by other people/companies.
You set your apps settings following those apps manual.
@@IIARROWS Why not?
@@vbifusful Why yes.
Because the application can sanitize your settings, warn you if you have contrasting settings, or set the best for your hardware, etcetera...
Always follow the guidelines for your application.
Unfortunately, when you uninstall a program, it doesn't always remove all its data from the registry
With the Revo Uninstaller you can remove everything related to most programmes.
There are a few reasons for this and it's not usually bad. One is if it's installed stuff other software may use it might mark it so the other software doesn't duplicate installing that item think about how all those programs installed various directx dll's for each and every one or the 40th time a program wanted to install ver xx.yy.zz of the dotnet runtime, etc.
Another is minor machine (vs user) specific settings that might matter if you re-installed or installed a new version.
Also to keep you from installing free ten day trials over and over again (though they now just make you sign up and then check online). And lastly windows almost always ignores registry entries that don't apply to anything so all you waste there is a couple bytes in on obscure file on storage like billions to trillions the size of the data.
If you're truly worried about it you can use a reputable un-installer. Be extremely careful about 'registry cleaners' as they almost never do anything actually useful and are more likely to hose the system than speed it up. Windows has gotten pretty good at ignoring dead entries.
But if that data in your registry doesn't do anything, there is also not a problem. It even do not slow down your system, it takes a few kb of storage on a GB drive, that's all. Do NOT use any cleaner program, that makes everything worse.
@@Wimvroman Basically the windows registry is like a cat. It'll take care of itself and if you try to clean it your likely to get bloodied.
*Adobe*: I dont care.
The Registry always looked like a shadow file system.
Its nothing to do with files though - its a database of key/value pairs.
Than , any xml-file is a file system for you, cause you can adress the element with a path.
It looked like that due to similarity in design of regedit with file explorer. They even share icon. But windows does it in more places where stuff can be navigatable easly kindda like folders. But its just a facade
@@chrisjlocke It kind of is a file system. It is a hierarchical data structure built out of keys(paths) and values(files). The keys live in a hive(partition) that can be loaded(mounted) or unloaded(unmounted) at runtime. In other words, it is a data structure with the exact same structure as a windows file system.
The reason it exist was that NTFS wasn't released yet. It is a file system that was made because the primary file system of Windows at the time was insufficient and Microsoft needed a fix faster then it could change file systems.
If NTFS had came along a bit sooner, Windows would have just used files similar to how Linux uses /etc.
@@Amir_404 Interesting historical knowledge, can I read somewhere about that? Though I don't fully believe MS would have sticked to "INI files"; the Registry is a search-efficient B-tree structure with granular security permissions on key-level; all merits of NTFS aside, I'm not sure it could compete with that. There is a reason why we still have database technologies/engines with their own binary file formats - and not a heap of raw text files.
Fun fact: the registry was designed to replace .ini files. Also, active directory group policies are the registry
* are in the registry.
I was gonna say this!!!!!!!😊
I remember modifying the WIN.INI, SYSTEM.INI, and other .INI files that the applications create. The registry IS a much more advanced system that can directly read or write specific keys instead of parsing an INI text file which allows a greater chance of compromising settings and properties, if a program parses into a settings line at the wrong point. The same goes for AUTOEXEC.BAT and CONFIG.SYS (Remember when Windows 3.1 was a thing and when you add a CD-ROM drive and it adds the 'MSCDEX' line AFTER "win" so your CD-ROM driver didn't load until after you exited Windows?).
Group policy files are not, but what the group policy client does when APPLYING group policies, THAT is saved to the registry
I'm a network administration student, and though I am fairly knowledgeable in active directory and the registry, working through that on the regular, is NOT FUN.
The registry was a noble attempt to make a database for system settings. Unfortunately it was done in a half-bottomed way. The system APIs for the registry are half-baked. No concept of versioning or backing out changes. It's easy for any app to mess up the registry. It's like a small directory structure, but not a fast or good structure. Half a system design problem and half a mess caused by apps not doing things in quite the best way. Long ago I was trying to install a device driver with an installer program. Ran into several intractable problems with installing and removing and updating device drivers. Real obvious activities, like enumerating drivers by name, or backing out a driver, seemed to have plenty of dead ends, where you could add registry keys but have trouble deleting or renaming or moving registry keys. An awfully weak aspect of a complex operating system.
At least with NT, you're bond by your credentials, so it's harder to mess up certain branches.
Windows exists 20 years and still no have comfortable registry😮
To fix that, Windows is more and more virtualizing the registry so that apps can run amok in their virtual registry and not affect the actual registry.
You're still living in the Windows 1995 era.... the current Windows registry is far more robust.
I feel like most windows apis are half baked in that they’re too granular unspecific and permissive while lacking conventions
The portable feature is never used. I work in IT and none of our business apps “transfer” their settings from one pc to another. Maybe you are referring to roaming profiles or backups but I’ve never seen an enterprise app put settings in the user hive and everywhere I worked the management want machines wiped and a standard image deployed so those settings are lost
I have seen it but it was in the early days, its just that so very few programs actually make use of it that its mostly not worth the effort since your would have to have all your applications supporting it, if not, your going to have a mess.
The idea was good but MS should have tried to enforce it more, over time it seems less and less other applications make the effort.
Today different programs store data in different ways defeating the portability idea.
Still, in corporate settings, the ability to enforce registry settings and prevent changes are actively used.
With ini files, that would be way more complex and many programs would probably invent their own "registry" solution once settings get to many, making it even harder to centralize.
@@davidmartensson273 you’re just repeating the point I was making
@@adamstrange3155he isn't.
I have implemented it a few times. it is almost required if your do any sort of the Terminal server farms or Citrix implementations. It does have it issues it definitely slows down logon times since you have to update the registry and user profiles as well.
@@midnightwatchman1 I’m talking about environments without terminal services or Citrix and where the app settings are not stored in the user hive by design. I’ve never seen settings transferred from one software hive to another as an integrated feature of the registry in a domain environment without 3rd party intervention, backup, cloning or clustering
Why then Microsoft cannot create a "Purge & Rebuild" option for the Registey file?
So many problems are embedded into the registry file because it is a dump landfill file where uninstall programs leave their trash.
Probably because core components & updates that were installed since the last clean install all leave their traces. It's just too risky and usually not worth it to manually force a state the registry was never in naturally or apply a backup onto a set of altered system files.
Also, what you crave can mostly be accomplished by a combination of sfc, dism, system restore and some third party registry surveillance tool (only checking for changes).
What do you think happens if uninstalled programs leave their trash behind? They are just unused, it's not like they do something, like slow down your PC.
And unless the software is really badly engineered, it shouldn't take more than a few kB of space. In that case, never trust that company again.
@@IIARROWS the way the windows registry works means every entry is processed any time a number of major registry features get used i.e on boot up. and it cant tell the difference between “this is important” and “this is junk from a program who’s dev decided they didn’t need to add the extra lines of code to the uninstaller to remove all these entries they put in”.
One program’s left overs isn’t the issue its after years of operating you start to hit the limit of legacy windows code still used in the registry.
The other is microsoft’s QA on updates is awful these days.
I got hit by a update on win10 that broke a registry entry for a windows telemetry service’s ability to phone home the telemetry services response was to regularly cause all drivers to restart causing a lot of issues.
Microsoft deployed a patch that they said should “fix it” they did replace the entry and gave the service a new address to send data too but they forgot one critical thing they never got around to actually registering the domain they were trying to send data too leaving the entire thing still broken months later.
I ended up upgrading to win11 hoping that would fix it assuming with some of the additions to win11 they would of revamped their telemetry system. and i ended up being right.
How would Windows know which registry keys and values to purge and which to keep?
@@IIARROWS Exactly!
And, in a somewhat related thought, why do Windows apps have to store program files in different places ? Program Files, Program Files (x86), ProgramData, AppData, etc ? I'm not sure that I would call the DOS days as the "good old days", but if you wanted to move your program files, you just moved them. Today, if you even think about it, something will break. The worst part is that some, such as certain email programs, will store part of your data in one location, and other parts elsewhere. I don't always want to backup my entire drive, but if I don't, I might miss something important like my contacts which might be in Appdata.
It's because Windows 10+ uses a hybrid file system built on top of Windows 7. The earlier, openly accessible parts of the file system are maintained for backward compatibility with legacy applications. The Windows 10 file system uses hidden folders and checksummed keys to prevent tampering with folders installed by apps purchased from the Microsoft Store and to prohibit installation of third party software on Windows10S machines. The system folder names and locations follow ad hoc Microsoft conventions that accumulated gradually over the years.
It’s not necessary if an app is designed properly. But Windows is a developer’s culture, and lifelong Windows engineers get entrenched in doing things a certain way.
Program files and Program Files x86 both store binaries and are supposed to be write-protected. ProgramData stores system-wide data that programs use, including things like the list of parts of a large program (say, Office) that you installed, downloaded fonts, etc. AppData is per-user storage.
It's like asking why Linux has /bin, /etc, and dot-files in your home directory.
@@QuicksilverSG Since they have the whole abomination of secretly writing files in Program Files to somewhere else, that does't explain why we have Program Files x86. Anyway, why should Microsoft be enforcing this? Why should this part of the file system behave differently, and why shouldn't I be able to write there if I want to? For your typical app developer, having the directory writable for admin only should be more than enough incentive to do something sensible.
@@xpusostomos Back in the Windows 95 days there was just one Program Files folder, as all applications were 32-bit (aka "x86"). When Microsoft later upgraded Windows to support 64-bit apps, they renamed the old Program Files folder to "Program Files (x86)" and reserved the new Program Files folder for installation of 64-bit apps. Microsoft was expecting third-party app developers to migrate their apps to 64-bit and planned to eventually phase out the (x86) version of Program Files. Much to their surprise, it didn't turn out that way. Since 64-bit Windows was backward-compatible with 32-bit apps, the easiest path for developers was to continue producing a single x86 app to run on both 32-bit and 64-bit versions of Windows.
In other systems, each program gets its own directory. There it saves the settings in an .ini file.
If the program does not work, the entire directory can be deleted and the program reinstalled. that then solves all problems.
What do you do if you have more than one user on the computer who can run the app, or if your company's IT people want to enforce some setting?
@@fnunez What do the IT people do if they want to enforce something that's not a string or a number and lives in %HOME%\AppData ?
@@xpusostomos They use applocker to block apps that don't store their config in the registry.
@@fnunez The INI file should be stored per user, possibly with per user data. The program binaries and libraries should be stored separately. If your INI gets trashed, you delete it and let the app create a new one with default settings, or you restore the file from backup.
@@mikechappell4156 Now you know why Program Files and the HKEY_CURRENT_USER registry hive exist, and why the registry is organized like a tree.
The problem with registry is that application data is not isolated but instead it's saved in a global place. And what's worse, is that it's not guaranteed that the data is not removed after uninstalling an application which can affect system and its stability. I remember there were a lot of problems related with the default application and file extensions when I uninstalled notepad++ 32-bit and installed the 64-bit version, this was because there were a lot of leftovers in the registry after uninstalling notepad++ 32-bit. Such bugs are really not fun to deal with. Unfortunately MS can''t remove registry because of backward compatibility, too many applications will break😑.
That's why I've decided to switch to the MacOS, fuck Microshat
you scared me with that wasp pfp
@@UnixPerdunix Your point is moot. Applications can also liters config files in Preferences folder.
@@samic Welp, for me at least it's much easier to clean up folder than freaking registry database
@@UnixPerdunix It's a tree structure and you can treat it like folder and files. (And ACL too)
This is literally a skill issue.
The problem is not the registry but how poorly it is organized. Every database sucks when it's poorly organized. E.g. Microsoft should have made a way better distinction between "here's that's the personal storage space for your app, do there whatever you want and if your app is deleted, we just remove all of that, no uninstaller needed" and system information that apps may also want to read and may be even allowed to modify but the later should have never been possible without prompting the user for permission first. There seems to be this distinction top level, until you realize that a lot of critical system information is stored in the same places were uses apps also store their stuff and to that user apps have full access, including write access, so they can easily mess up your system e.g. by messing up Windows-Explorer that Microsoft treats like a normal app, when in fact it's a critical core system component.
But what if I want to uninstall an application, delete all of its operating files because it failed for some reasons, and keep user settings?
When you uninstall often you get the option to keep those, and it's useful.
If the uninstaller doesn't give you the option and doesn't delete the settings, it's the uninstaller fault, not Microsoft or the registry.
@@IIARROWS If reinstalling did fix something, it's probably because the uninstaller removed the settings and it was the bad settings that caused the issues, so just removing all settings would have had the same effect without reinstalling anything. Applications are basically read-only (if they are code signed, they must never change and on other systems they are often even hosted on read-only volumes), so uninstalling and re-installing them should not lead to a different content on disk in the end but you should get byte for byte the same executable and libraries as before.
@@IIARROWS clicking to keep user settings should never leave registry entries. the most common is a settings file/folder in the folder it was previously installed or in either local or roaming in the c/users/“username”/appdata hidden folder.
The registry is not for general settings and preferences of ordinary apps the biggest legitimate use by consumer software is for storing licensing/activation records to avoid needing to reactivate every time you run a program with such a system.
Microsoft have some kind of filozofy about how to put things in Registry, shame that they not share with rest of us. Documentation for Registry is so poor that it became a guessing game, how things should be. The mess with Wow6432Node don't help.
I have had my Registries get corrupted. So much so that they ended up with entries, keys and values with random numbers and characters where the system becomes so unstable I had to do a clean re-install of the system and all programs I was using.
The problem with it is when it does get corrupted the whole system is affected. When an INI get corrupted only one program get affected and then we know what corrupted it. Especially if it happens more than once. And we only have to fix that program not the entire system. No, it is not a sophisticated DB it is a crappy simple DB that is prone to errors and corruption that can not clean itself of data that is no longer needed thus gets extremely bloated. Did I mention that it has multiple duplicate Entries that bloat that data even more.
The registry is split into, I wanna say four files.
This is the same way I feel about the registry and I wish Microsoft would have never started using it. I work in IT with Windows but my computer at home has Linux on it. Most config files in Linux are in the same hidden folder in your profile and the files are named after the applications they belong to. It's so much better and vastly more intuitive.
@@garystreck5991 I disagree.
Over the years, those files have moved around and different distros do have their own take which can cause any number of problems.
And not all programs store their settings in the etc folder and on some distros there are multiple etc folders also.
I had that problem where the same file existed in 3 places with different settings, used by different programs so you you had to know which one you needed to change depending on which program you wanted to affect :/
Not saying registry is better but linux is not necessarily better either.
And I have been using Unix/Linux since back when SCO still was the good guys and the only way to run unix on a normal PC and when linux was still considered to hobbyist for corporate use.
@@davidmartensson273 I'm thinking it must depend a lot on which distro you use then. I will admit that not every single config file is in the .config folder, but a huge majority of them are for me. And if a distro has multiple etc folders that's just sloppy and unmanageable. I use Arch.
Ia am sorry, but in now 31 years of using the registryon literally thousands of systems, with VERY complex software on many highend machines the registry never ever got corrupted in such a way you say. It seems like you either got malware, tampered with lowlevel software or defective hardware like RAM.
Also the registry is saved in different places as well, and a standard user cent even write to the system related entries.
Whatever went wrong on your machine is definitely not the case of the registry routines.
0:12 - I find it interesting how people who don't know how to use computers are so confidently saying that it's registry.
If a subsystem just works, people wouldn't complain about it. They just would not know about it.
A 'registry" word is widely recognized among non-professional users, so there's something wrong with it.
@@TheNamelessOne12357 i've used Windows since 3.1, and even used MS-DOS before that, until today, i have never encountered a Registry problem.
Because people Google "Slow Computer" and it returns junkware "Registry Cleaners". They download and run them, things get worse, now they're convinced that it's definitely the registry.
@sepg5084 i have but i've also encountered disk corruption and other failures that corrupt data. The registry is just a database.
@@TheNamelessOne12357There's nothing wrong with the registry. I would bet that the reason so many people blame the registry for their issues is because of PUPs like CCleaner and their shitty registry "cleaners"
A plus of the registry is that most configuration settings in Windows are located in a central location. Where as some other operating systems have files that usually should be located in a common location but most of the time there are is no real standard that developers follow. Not beating anything up. But there are positives and negatives to every operating system. Noting is perfect. In the end developers for any application and any OS or device must strive to produce quality software and stop "pointing" ;) fingers.
The beauty of registry is in remote support, when I can use the power shell to scan the whole office to see known configuration error in a very short time if the target option/ application setting is written in registry, and I don't need to risk contaminating the other setting data as long I Don't touch the folder structure
The problem it sometime the stuff is all over the place and even Microsoft don't document it properly for external use
One example is the Uninstaller registry, they never properly document the relation between the 32-bit and 64-bit of this registry, program scanner through the registry I reverse what they are doing To Do a workable solution
The scanning this part create report way faster than other native gui command
You can do that with the text files that other OSes use without much effort. Tripwire in particular can also check the binaries as well while you're at it.
You should not use registry cleaners. Even Microsoft does not recommend using registry cleaners
Cleaners are like snake oil, registry would be like Swiss cheese.
Most of those 'cleaners' do more bad than good. Mostly they are just malware installers. Old programs that should be forbidden , never use them!
Well, you can’t stop me
If used responsibly by a knowledgeable technician, they can actually be useful. But whatever you do, NEVER let them clean ANYTHING automatically!
Go through everything it happens to find and suggest, and go through them with a fine tooth tech comb and knowledge and experience with the registry.
Some things they might find might be remnants from old software that's been uninstalled. Those can almost always safely be removed.
Other things they might find can be erroneous path names. Those aren't all that common, but it does happen and those can be manually edited if you know the correct path/filename.
But when in doubt, or you just aren't familiar with the registry, just simply don't muck around with it.
Some work very well. MS obviously doesn't want normies using them though.
The real question is: why don't we just ditch Windiws?
What bothers me a lot is that I want to just compile something using Linux components, and it requires downloading a lot of stuff instead of stand-alone build. There are a lot of other problems with Linux and Unix systems, which are still unsolved.
@trevoro.9731 if you want standalone builds, use flatpak
Lots of users and companies have time and skills invested in Windows. People have software in Windows they use. Linux has a learning curve, people don’t necessarily want that. In my view, neither system really cuts it.
Windows could be really good if only Microsoft took a more conservative approach to introducing new "features"
@@trevoro.9731 Then just use appimages, snaps or flatpaks
If you compile anything from source on any OS it requires fulfilling dependencies.
As a Linux user, I haven't seen registery for x numbers of years now.
Yeah, it does make certain things easier or easier to fix.
But sometimes it gets bloated too much often
I hate the process of finding the right file, figuring out some convoluted syntax and the finding the right change when something goes wrong on my Linux box. Several times I've ended up reinstalling rather than trying to find the fix.
@@kylewilson4097 Yeah, configuration is by no means any better in a typical Linux environment. And if you look in a typical .config folder, it is equally messy as the Windows registry, full of no longer installed programs, outdated versions, etc.
@@jbird4478 but you can deal with .config like any other files.... mv, cp, rm etc. and when you do it, all of a program's config is dealt with, not just some.
Systemd is Linux Registry.
@@kylewilson4097 I've seen in a certain distro (I don't remember which) where all the configuration files are in a .YML standard. I don't know whether they just made a wrapper around the programs or whether they've rewritten all the programs.
Leo, I just wanted to say, your videos are amazing and have helped me out with a lot of issues and questions I've had in my upgrade journey from an 11-year old Windows 7 PC to the new Windows 11 system I'm using now. Your style of speaking and your way of explaining things is so intelligent, and understanding, and patient. Have you ever considered doing narration for audio books, like tech manuals or even novels? You have the perfect voice for it! Anyways, thanks again, and I'm really glad I found your channel!
It would be nice to have an "undo" feature on the regedit menu.
There are third party tools that probably offer that feature, and other registry features (such as backing up the registry, etc). But an undo option, I would think, would not be difficult for Microsoft to include.
@PaxAlotin-j6r Windows does do the same. That's what VSS and Restore Points are about. Once you set it up to back up, you can right-click the file and say "restore earlier version." If it's a system file, you pick the restore point and say "restore this" and it restores those files.
@@darrennew8211 I don't know what that is, like 99.99% of other users, but the problem is, whatever backup solution you have is not going to play nice with it. I can't open up my favourite backup solution and say, restore %HOME\AppData\Mozilla and have everything work.... If I even can, or know how to, or even have a backup of the registry, it's going to be at a different time and be out of sync with my backup.
That's what export is for. If you are playing around in the registry, you should always export a copy of what you are playing with first. Registry editor should not request admin privileges to use. User settings should be accessible without it. Request escalation if you are moving onto system settings, not user settings.
@@mikechappell4156 EVERYTHING plays in the registry which is why you don't know when you should be exporting. . Which is why it's a problem that it doesn't play nice with backup programs
@@xpusostomos I was referring to directly editing with regedit. If you are in regedit you know what keys you plan on deleting or modifying.
Most settings are stored in the registry and iirc there are some dynamic keys as well, which prevents you from copying hives that are in use.
I'm aware that windows locks the files.
The file should be user readable when it isn't being written though.
I'm not even sure you can export the entire registry. I've done large portions in the past and it was painfully slow though.
Regedit should have an option to backup any hive or hives and restore any hive or hives. Obviously admin access for restore system hives, user access should be sufficient to manipulate user level hives though.
I think regedit is also accessible from the repair console, so you can edit hives that aren't currently mounted, and in the repair console you can copy the DAT files as well.
I don't think I've used it since windows 7, so I'm not sure how much it has changed, but it wasn't designed for the average user and is not what you'd call user friendly.
There is a flaw with the SOFTWARE hive when dealing with multi-user environments. Eventually enough “breadcrumbs” are left behind via guid data that the registry begins to “bloat.” When this bloat occurs, logins can be very time consuming for every user. Zapping those entries too late does not fix the issue as registry hives do not automatically compact.
But they could move to a sandboxed registry per application model for backwards compatibility. So the system with updates would gradually use the registry for less and less settings, and at one point none of the system components would use that. But if an application needed that, a sandboxed empty registry would be available separately for each and every application.
It kinda already does that, at least between 32-bit and 64-bit applications on 64-bit Windows.
You make is sound like ini files are not portable or able to be secured. I see it as the opposite. ini files, or any text based config file is way more portable. It's just a text file that can be copied to any machine or synced over a network. And as far as security, that's where users and groups come into play. Where the registry is one big database. You can export parts of it to a .reg file, which in itself is just a text file. But you have to dig through the registry or already know what you parts you want, and what you are looking for might be in separate areas of the registry.
Plus, the registry is made of a few large files. if the file gets corrupted, you can lose everything. Individual config files would prevent this. If one gets corrupted, it probably isn't going to break the system. And if that did happen, you can always delete the messed up file and a default skel file will normally be created or used. Since the config files are easy to back up, it's also easy to revert back to a working file, without any special software.
...it's funny how you like to ignore the downsides of ini files, and why companies like Apple and Microsoft decided to use a different approach.
*_"Plus, the registry is made of a few large files. if the file gets corrupted, you can lose everything. "_*
No, you don't, that's what a backup or redundancy is for.... that is required for EVERY operating system, no matter how good it.
If your SSD totally fails beyond repair, then that information is gone, regardless the OS you used. The extend of the drama is that point not related to the quality of the OS, but your skills as a user. If you're that lazy guy who doesn't care about proper redundancy or backups then it's just YOU who is responsible when you lose everything.
There are so many drawbacks in using the registry and the purpose it serves is fairly simple. I worked over 20 years as a SW engineer in quite a few companies and I have to tell that in most cases of using registry it led to problems. All sort of problems. Don’t forget that registry is also very slow compared to a straightforward configuration file.
BTW in the newest platforms I moved to using TOML format instead of JSON. Readability is amazing
You can use ACLs to limit the read/write access to INI files on a granular level and if you can share the registry hive on the domain, you could also share INI files. It probably is easier to manage with group policy. They could have designed a *nix like system where the main configs were used and checked to see if local/personal configs were available, but they didn't initially. It seems like what they are doing with AppData though.
You're living in the 80's. Watch "Linus Torvalds on why desktop Linux sucks"
I didn't realize there's people who want it to go away. It was just yesterday I was thinking how many more inconveniences I've experienced in Linux due to everything being a file, and not having something like the Windows Registry.
One of the worst abuses of the Registry I've encountered was a game (System Protocol One) which stored its _saved games_ in the registry. Which, of course, you'd never remember when you had to reinstall Windows, so you'd never think to export the relevant Registry keys, and thus end up losing your saves every time you reinstalled Windows.
I worked on an old windows program that used the registry to store various user settings. Then had to do major overhauls when windows started applying security to the registry. Had to move a lot of settings to the User hive rather than the root hive. I guess the fault of our developers not understanding the purpose of the various hives but when MS had no security to prevent us misusing it, I don't blame my forbearers too much.
But the real mess was realizing that windows kept separate registry values for 32 bit and 64 bit programs,
It took about a decade before it was uncommon for programs to not need administrator rights to run, after WinNT and its children to come out.
The original intention of the registry wasnt even for settings. It was a registry for Component Object Model (COM) class IDs. These are GUIDS for classes along with details on what dll the code was in and how to create an instance of it. Then any application could re-use these software components. Its a fundamental technology in Windows and Office and its still a good idea. But once they realized they had this central system database to store information it occurred to them they could use it store other things too.
The registry is freely accessible by application installers (not to mention knowledgeable users). There are parts of the registry that Microsoft conceals or keeps read-only, and other parts that are automatically restored at start up. It's not "just a database", it's an active part of the Windows OS infrastructure that works independently and in conjunction with the Windows file system.
How exactly does Windows Registry work independently?
it also duplicates sections of itself into separate hives from the main hive so you have several versions of it in memory at any one time...
@@Turco949 The registry is not stored in specifically named files in the Windows system folders. It is a collection of relational databases (called "hives" in Microsoft jargon) that are distributed among a variety of Windows system files. The lists of keys and values displayed by RegEdit are generated dynamically to report the current internal state of Windows, each time you run the app.
The fact that it's independent of the file system's logical hierarchy is the actual problem and the reason it's an abomination.
you obviously didn't watch the video
The real reason why registry exists is because all file paths for applications on Windows start with disk letter, and it can change at runtime. On the other hand registry always stores your data entry in a pretty defined path. Like files in /etc and ~/.config on unix-like systems :)
_THE_ Registry.
Windows actually has %AppData%/Local and %AppData%/Roaming for user config which is pretty analogous to ~/.config
This nonsense started well before that was an issue. It wasn't until I started to use USB drives and the like that I started to have disks popping up with changing letters. Floppy drives were basically always A; and/or B: and the primary HDD started with C and continued to the end of the disk before moving onto the next disk. In practice, there was no inconsistency as there would usually be only one drive and probably only one partition per drive.
The only reason I have problems with drive letters changing now is because I'm swapping a pair of disks for backup that I want to use the same drive letter.
Writing scripts to collect, update, or remove information from the registry was always pita. Running a mixed environment, I always hated dealing with windows reg
Corporate users aside it is really horrible experience when you are copying a program or a game to a new machine and it just refuses to work because of some missing key in the registry
You are lucky when program is shipped with some init script that auto-populates the registry for you.
Also trying to find something in the registry is almost impossible task
Why couldn't they just have flat list of folders where each folder represents a program?
I don't think simply copying programs between systems is a good idea, because besides of the registry issue, the programs can depend on some dynamic libraries that could be missing from the different system. That being said programs shouldn't crash because of some missing registry value either. Default configuration should in my opinion always be hardcoded in case it's missing for whatever reason.
@@fisyr almost every program in windows is either shipped with its own copy of dlls or uses common things like c++ runtime that are really easy to install on new machine
@@fisyr Why not? It works on other OSes without any problems. Any 3rd party software should be checked for by the program if it's that sensitive.
There is barely docs available for devs to make registry settings safe. UWP and Windows App SDK tried to solve this by saving the app's virtual registry into its own file but developers won't move to this new SDK
Dotfiles or nothing, i will die on this hill 🤣
`/etc` forever!
Which method do you use to manage em?
@@kipchickensout sync thing, I have been looking into chezmoi
so true
@@kipchickensout Anything you like, from simple soft links to revision control systems to basic rsyncing a backup to a separate directory/system. And since they're mostly just text files, you can use any other utility you like to quickly parse and potentially modify them.
The problem with the Windows registry more than anything is that it tries to do too much and doesn't have any particularly good way of purging obsolete entries or fixing it when it gets corrupted. I've thought for decades at this point that if they want to have a registry fine, but at least have it generated from other files that can be edited by hand if need be. I've just had too many times where the registry got corrupted and took the entire system down. I have never had that happen, not even once, with Linux of FreeBSD. I haven't paid as much attention to Linux, but FreeBSD has sysctl that does a lot of the same stuff that the Windows registry does, but it's regenerated on boot from actual files.
As to your question, there are a lot of utilities for managing those dotfiles dotfiles.github.io/utilities/
There has to be a way, I know it's needed for legacy apps but they could come up with a way for it to create a reg file in the app folder or if it tries to create keys and all the other api calls can just be emulated or ignored. This is exactly what Proton is doing now for windows games on linux and they run really well and don't pop up any errors when they need the registry. I know unreal tournament stores it's resolution settings in the registry, Proton just moves that to the game folder.
The registry was around in Windows 3, too. Having it as a flat database is a bit of a handicap. As a desktop support person, trying to remember is the key I want Is in the HHKEY_LOCAL_MACHINE/current_config/software/Microsoft/Windows or WindowsNT or in a different hive.
Group Policy Object (GPO) helps a bit with this as you can create a policy to always have a key at a certain value, or even delete it outright.
Changing to a relational database or, having symbolic links to values that are common to several keys would be better, I think.
Linux and UNIX use the concept of a registry with the /etc directory, through it doesn't provide the Interconnectivity of the registry.
The registry is a good thing with Windows, but the way information is torwd is outdated and grows to be unwieldy very quickly.
When virtual machines came along followed by sandboxing, the registry became obsolete.
If you are using an OEM smartphone and you accidentally dl-ed something malicious, uninstalling + rebooting gets rid of 99% of the viruses. I sure don't miss the days of manually deleting harmful registry entries! 😵
*_"When virtual machines came along followed by sandboxing, the registry became obsolete."_*
Nonsense. When you want to run software that requires a lot of processing power (3D/video rendering, games, crypto mining,etc), it would be foolish to run it in a virtual machine.
Different applications... different requirements, but it seems to me that you only use a computer to browse the internet.
@@user-rk9kb2sd9b True, but you only use licensed official copies of those softwares from the vendor, DON'T YOU? 😂😂😂😂🤣🤣🤣🤣
The Registry came when Microsoft bought Digital's VMS as that company was going bankrupt. In VMS it was called the "verb table", and it was a way to start programs from the command line and pass parameters. It was pretty scary changing the verbs, you culd crash the machine with one tiny typo. Sound familiar?
Do you have any substantive documentation that demonstrates what you've said here is true, by chance?
Microsoft didn't buy VMS from DEC. The lead designer of VMS left DEC for MS. DEC was later sold to Compaq. Even later than that and Compaq sold to HP.
I have to say that I am ignorant of the "verb table" even though I was a VAX/VMS administrator (self-taught) on a MicroVAX II. I was working as a research engineer at the Oak Ridge National Laboratory at that time but I had a good deal of computer experience as an ordinary user on IBM mainframes and the largest DECSystem 10 in the world, as well as MS-DOS PCs. The procedures for connecting the hardware, loading the operating system from tape cartridges, and installing the Fortran and C compilers were so well documented that I had a system put together and running withing 24 hours. I was able to add or remove users, grant permissions, and make backups within the next 24 hours. The group I was working for used that MicroVAX for 3 years before transitioning to an HP 9000 730 PA-RISC workstation, running engineering software we developed ourselves. I never had occasion to learn about anything called the "verb table."
One of the problems with registry is that you can't read content in a human readable form like you can read in the files that you can find in the editable text configuration in GNU Linux.
Cant read content in readable form? Tells me you have never worked with the registry. Its values can be strings, boolen ect. Just like a config file. It is config files just structured in a database. I work with both windows and gnu linux. Does windows have more history to maintain and be backwards compatible yes. Is that realy the biggest issue with windows, no. Windows lacks ONE huge feature that all distros have. Packet managment. They have some here and there in the later years. But far from what the gnu linux distros have. This forces companies to maintain this them self. And everyone is for them self. Using SCCM, Intune ect
@@eirikgg Tell me exact meaning of
{042D8A51-5878-4000-9C10-C04AFF122A1F}"
In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{042D8A51-5878-4000-9C10-C04AFF122A1F}"
"Triggers"=hex:00
@@The_Penguin_City and /etc/shadow
root:$6$xyz123$abcdefghijklmnopqrstuvwxyz123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ:18000:0:99999:7:::
We can agree we both can read them and edit the values.
@@The_Penguin_City The exact meaning of "{042D8A51-5878-4000-9C10-C04AFF122A1F}" is a 128-bit number. The point isn't what the value of that number actually is, but that number represents something unique subset of the system.
@@jovetj Yes, but what does it represents?
Unifying all of the operating system data and application data in a single place was a colossally stupid idea. I don't use the registry in my applications.
Why is this such a bad idea? It sounds good at first glance
@@heyyou274 1. Because it conflates all program data into one place. This makes it more difficult to find and separate out. And there is little corresponding benefit to it.
2. Because if the registry gets destroyed, the system is dead. And windows used to destroy its own registry a lot. Admittedly it has got better at this.
3. Removing an application got way more difficult with the registry. Many or even most applications don't clean their registry entries when removed, and in fact some call this a "feature", because it supposedly maintains settings. This can cause interesting things like applications that have persistent problems because the registry entries don't go away, and have to be manually removed.
As a developer, I am a big advocate of "one tree, one application" methodology. That is, an application is contained in one tree under one directory entry, without change on installation. This means it is installed by simply copying the tree to disc, and can be removed by simply removing that tree. It does not use a complex installer process (such as flatpack or other). It does not spread itself all over the operating system. And all of its configuration files are contained in that tree. Eclipse is one such application, as are all of my applications.
Do I use the registry? In cases I am forced to. For example the path is in the registry, and I have to alter it. There are other examples. But I prefer to keep as much data outside the registry as possible.
@@heyyou274 It is a good idea.
it's not necessarily bad. i think, the thing that's bad is how Microsoft went about it. not enforcing rules like which application owns which entry, and when stuff gets removed. they were naive in thinking it would be a temporary solution
good ting the registry doesn't do that then
All I know is I switched to Linux a few years ago & haven't had very many issues with anything at all since. Might be worth mentioning that I'm a pretty heavy gamer, too.
"Those issues would still exist for any other replacement technology". I see this on Linux. There are at least three places you could store your application configuration, and many end up going with the least recommended one and dumping it directly in a hidden folder in your home anyway.
Bravo Leo, very good explanations and competent views on the complexities with the registry. The registry is frustrating, but also reveals just how complex a modern PC is. You have a new subscriber :-)
Another “feature” (if you can call it that) of the Registry is the fact that it prevent(ed) your hard disk from filling up too quickly. Most files have an allocation of 4KB and if you have many files with a 4KB allocation, your disk space goes away quickly. This was more a problem back when hard disks were very small (compared to today) and a database-type solution that has many different values in only three or four files saves a significant amount of disk space.
That was never a real problem for most people. There just aren't enough files for configuration for that to be a problem.
Registry needs to be made easier to search and also have a transactional record, including what applications did what and what time. We also need to know what application(s) owns different registry entries or at least initially created them (yes I know some are shared). It needs options to rollback and roll forward as well.
You're right in saying we cannot just ditch the Registry outright...however we could at least have some consistency with it. And *actual* documentation. And while it would require a complete rewrite of specific parts of the Windows code base...I'd be hesitant to say that it'd be impossible.
Also, for portability the Registry is entirely outdated even IF it's still used for that express purpose... Whether people like it or not (And just to be clear I do NOT like it), cloud storage is the standard for portability going forward.
So it's hardly like the Registry couldn't be outright ditched, or be made better...it's more whether or not Microsoft FEELS like doing it.
We can, they just have chosen not to virtualize it for the programs that legitimately need it as part of a phase out period.
As a sysadmin, I like the registry. Really makes applying specific settings across computers easy.
It's actually harder to do that with the registry than with configuration files. A short shell script can both check the file into the revision control system and make the edit with little fuss or muss. Or, you can do it without the script at all in like 3 lines of commands. And really, it's only one line if you're concerned about having that backup.
Has macOS something like this as well?
If you turn code analysis on for any C or C++ program that uses the registry and has never been statically analyzed before, you're practically guaranteed to find at least a dozen actual or latent bugs
Why? There are API-Functions, no program writes directly to the registry.
2:17 the registry is not in any way critical for settings across machines. The exact same information could be exchanged as .ini files or whatever else.
Dude, you're living in the '80's.
@@user-rk9kb2sd9b dude, you’re making an irrelevant claim not responding to my comment.
Problems in OSI Payer 8.
Thank you very much for the explanation.
What is the LINUX/UNIX analog to the Windows Registry?
Lots of .ini files.
Whenever you see someone asking the question, you know that someone has no idea what it is.
The question is why aren't we using it enough?
The problem with the registry is Microsoft 3E'd themselves with it
Look across to Linux and the DCONF which is basically the same idea as "registry" but:
A) It's not the only place where settings are stored, so you can have your own roaming config files elsewhere without corrupting the main config
B) It's human-legible, it's a plaintext file you can read and parse and use the manual to understand
C) Some genius wrote the DCONF Editor flatpak which allows you to browse the dconf via the tags and parents with searching
There are better ways of doing things, the "everything is a file" and "one config file for one program" seems to make more sense
Come back when you can find a Linux Desktop distro that can compete with Windows, watch "Linus Torvalds on why desktop Linux sucks".
3E means Embrace, Extend, Extinguish; i don't see how your comment is supposed to make sense.
dconf is kind of a mess though tbh...
could be worse, though, I guess
@@user-rk9kb2sd9b Linus fell for a scam recently, he couldn't install Pop_OS which I've been using for months, I wouldn't trust him on anything Linux related.
@@orangejuice7964 The only real reason to retain the registry is that it was a convenient way to make it harder to port programs to other OSes. It doesn't make it that much harder, but every little bit helps.
What are the alternatives? Different operating system? But how popular are they compared to Windows?
Yes, Linux is an alternative. I use Linux Mint, BTW.
I have several screwdrivers in my tool box. I don't worry about which screwdriver is most popular. I worry only that it does what is needed at the moment.
The alternative is not to use the registry. Apps that advertise they don't use it have a selling point in my opinion.
@@xpusostomos Those are much more common now than they used to be. It's getting to be a lot less common for programs to not have a no-install version that is essentially just a self-contained directory that contains everything that it needs to run.
A lot of that seems like a lack of a proper file permission system like linux does. The access control part is completely redundant if you replicate linux's permissions.
Modern Windows permissions are a lot better than they used to be when the registry was first created.
With my applications I aim to put all the application-specific settings in the application directory itself. That way, the application can be moved, copied, backup up, restored, *as* *one* *item*. You don't end up with the application copied to somewhere else and then falling over because you haven't also copied seperate configureation data from a separate location, which you can't even "copy", but have to export and then import.
Additionally, I aim to put all the user-specific configuration settings in the user's settings directory. Again, so the user can transfer all their user stuff *in* *one* *go*, not copy their user data and then upon running the application somewhere else have it fall over because their user-specific setup has vanished because it's physically somewhere else.
And this is because I started programming on a proper networked computer system in the early '80s - an *EIGHT* *BIT* system - almost two decades before any of this crept up on Microsoft's conciousness.
Which is the right thing to do. The settings should be in some combination of the install directory and user home directory as appropriate. If you've got a system wide package system like on Linux and most of the other *NIX OSes, then you can put the settings elsewhere.
Much better can be done than the current/old Windows Registry, including a backward compatibility. There is also a so big mess in this database that one could ask how dare one can see it as a database?
Not exactly a Windows fan, but if there's something that works fine on it is the registry. People tend to forget that in a multi-user operating system having a common configuration file like an INI for all users (human or not) is a big no-no in so many levels you can't even imagine all the problens would arise.
Only because they spend decades fixing the many issues that come of it. One of MS' addictions is being overly careful about backwards compatibility even when it causes problems later on because you can still load files from decades earlier, ones that most people have had many years during which to update to a more recent standard.
I hated how it was never documented or the way to use it was documented - or if it was, this wasn't publicised. The move to Windows 3.1 to NT/95 was clouded by this lack of documentation … unlike the WIN.INI and SYSTEM.INI files, where I knew every line of it. Instead, everything just became mysterious and each time we were told to do something in the registry, it was just a single unique key.
Compare that to the Resource Editor (ResEdit) on the Mac, and all the 4-char resources were official. Each had a purpose and you could look it up.
It _is_ documented. Not all of it is well documented, but some of Windows's internal data Registry structures don't matter to user programs.
Programms should have there own registry which is just an overlay to the complete registry. Program writes to there overlay and reads to everything combined
Many years ago I switched from a sound Blaster card to another manufacturer ( I can't remember who) after installing the drivers I found that my games ( notably Half Life 2, yes that long ago) had no sound.
I went through the registry searching for every instant of sound blaster or creative, there were loads all over the place and I deleted records and keys as appropriate.
After that my sound worked in games.
If I remember correctly, Creative made "total uninstallers" available on their website for just such situations. Lame that it wouldn't come with the software for the hardware, but it still was available.
The idea behind the registry is actually good, just wish they keept it "cleaner" and "leaner". Tons of pretty much orphaned data is there already at a fresh install. Not to mention its all baked together... if each program / service had its own "hive" or space in it - It would be way easier to make proper uninstallers etc and find orphaned stuff that is just bloating out the database and slows it down
It was always a terrible solution to the problem of storing configuratoin information. Sysctl from FreeBSD is a much better system and there are other systems that other OSes use as well. At a quick look you can identify a bunch of setttings and you can either adjust them once using a built in tool or you can have it changed more or less permanently by editing one of the files it reads. Some portions cannot be changed at different run levels and sometimes you need to adjust the permission to do any operation on it at all.
In the years I've been using the OS, I have never had any problems with that system. I have, however, had the registry cause significant problems at various times on Windows that required a reinstall. That hasn't happened in a while, so perhaps they've finally got that fixed.
3:53 if the problem is applications sticking data in there “unsupervised”, isn’t that still MSWindows’/Microsoft’s fault for not controlling that better? Instead of letting any old application write anything to the registry all willy-nilly, restrict it to read-only access and require all new additions be handed to the OS via APIs so that the data can be standardized, checked for conflicts, and _registered_ in a meaningful way so that the OS knows every key/value in there and has checked it for conflicts and conformance. And malformed data can be just rejected outright.
Surely that would be a better way to handle a central store that theoretically every application relies on?
The registry is useful to provide a system abstraction for more efficiently writing various values, especially on SSD since storing them in files on an SSD inevitably results in excessive SSD write cycles. And having a corrupted partially written file is way more likely than corrupted registry.
No, it's not. That's why you write to a new file and then copy it into place when completed or buffer the write. Also, apart from a failing drive, I can't remember the ever happening. I have, however, had the registry go bad a few times and take my entire install out with it. And if any of that's a concern, you really ought to have a USP protecting the computer from power problems.
@@SmallSpoonBrigade As I said, writing to files results in excessive wear on SSD. I've had multiple applications completely lose all their configuration settings due to corrupted files, but registry has always been rock solid.
The Year of the Linux Desktop was 1995 for me. So glad I never had to deal with registries.
I meet GNU Linux in1998 and start to use it in 2000, full Time user since 2002😊
i never understood why we needed a registry. its a resource hog. everytime the OS or an app does something it has to access the registry. applications cant be moved easily as all the path are hardcoded into the registry. i hated the bloody thing from the day of its inception and my hate for it has not faded away and is still going strong.
i miss the days when an app crashed and it was possible to troubleshoot whats going on or have your own directory structure. it makes no sense to me that i have to google for example where a game stores a save file.
windows is such a mess.
Ah... yes... As a Heroes of Might and Magic 3 player, I can confirm that I like the feeling of knowing where the file of the saved match gets created.
I believe that you don't actually understand The Registry. It's a mythical thing to most people, it seems. Like a Unicorn that most people have never actually experienced.
The registry was first introduced in Windows 3.11, but then fully implemented in Windows 95
The registry was first introduced in Windows 3.0.
Swear.
I was playing around with Windows 3.0 for various retro reasons circa 2005 and stunned when I installed some app - Microsoft Access 1.0 I think - that included a registry viewer! Could not edit anything, mind but I could view registry keys.
Alas I lost all that good stuff with a dropped HDD but I had discovered Linux by then and the 'fun' began again. Windows from 3.1 was just so, soooo boring! OK, I like Windows 95 in terms of UI even though it was at war with itself.
_What_ would work better?
Files in the Filesystem? In what universe?
When they rolled out the registry, they didn't roll out an API to interact with it, so every vendor had their own version. When everything depends on one system, and everything touches it, it's a recipe for disaster, whether the registry itself is robust (it isn't) or not. But entrenched bad design decisions are the very foundation of windows, putting the "backwards" into "backward compatible" (which it isn't, either).
The registry is only API and nothing else and never was. Nobody actually knows where the data is really stored, or writes procedures against manipulating bytes on the hard disk.
The registry is such a bloated mess that you can hide all your crimes and private keys there and even NSA won't even find it.
For me is increadible the "size" of the registry even when nothing is installed except the OpSys.
Oh... in the title and the first seconds of the video I thought you meant dump the entirety of the registry in case of a bugcheck xd
I've never heard anyone ask whether we should just get rid of it
The problem is that the registry is an extremely leaky abstraction.
It’d be like if every MySQL client needs to know how construct their requests to produce correct binlogs.
Users and developers shouldn’t need to interact with or know much about how the registry works under the hood to facilitate the advanced OS features.
Unfortunately, the registry is the direct API for both consumers, exposing everyone to the same complicated concerns.
Except for that context, yeah, people are just “holding it wrong.”
Most group policies, are just editing or creating registry keys.
Instead of the registry they should use a strongly-typed hierarchical configuration database, capable of fast searches and fast inserts, and divided up into separate trees for computer settings and per-user settings.
Oh, wait...
Applications can store .ini files in roaming profile and corporate users can sign in different machines and have their .ini files portable.
The answer to the question is, "What alternative to the registry do you suggest?" All the configuration information for the APIs and various protocols used for software, API, and hardware interactions has to be stored somewhere. Should we just let each software developer create their own custom formatted text, xml, or json file? The registry provides a standardized schema and an interface for it that's searchable. Yes, the registry could be documented more thoroughly. Right now for many it's a riddle wrapped in a mystery inside an enigma, to borrow Churchill's characterization of the Soviet Union's government, another arcane system that was similarly difficult to wrap one's mind around.
Problem is that any application can mess with any other applications registry.
It was interesting.
Thank you, Leo!
Great video Leo!!
I would disagree with the security aspect. ALthough it can be secured for admins, all users have access to read . ANd not to mention how many times when permissions are messed up by Windows themselves
Registry should only have been a thing for OS specific settings. Applications should not have been allowed to write their config there and instead use text files like before. That would be the best of both worlds
I always thought it was to control. Concept sold to programming companies. To convince them to make programs to make sure people can't copy and use their software or give copies away. It's early 2000s tech ideas.
Turns out that giving apps the ability to throw whatever they like into a central system heap of data is not a great idea.
While “too entrenched” is a good argument for why you can flip a switch to transition, there are quite a number of ways one could transition from the registry. Not going to outline one of them but lets just say that 1) transitionary period 2) virtual interface for legacy software and 3) a more isolated application model along with a 4) “compatability mode” will allow for a transition over 2-3 windows versions.
But perhaps Microsoft just values maximum backwards compatability more.
A decade or two ago it being "too entrenched" might have been a compelling argument, these days, they could easily capture and redirect the attempts to write to or read from the directory either to actual files or smaller virtual-registries if they wanted to. They could also have a system like on other OSes where the registry is built from other files and just regenerates whenever the OS boots up. Parts that don't change can potentially be cached without much harm.
It would be a much better system than what we've got now.
I’d much rather all programs and all files associated with them were self contained in their own folders, this idea of having data spread out all over the place results in most programs not being fully removed, scattered data, and an OS that gets worse as it ages.
With modern disks being so large, fat packages are often times a reasonable solution to a lot of different problems. I wouldn't go so far as to say that all programs should be like that as I think that goes a bit too far.
@@SmallSpoonBrigade not saying they can’t share some things like libraries etc, more anything that relates only to that program should be sandboxed in its own folder, so no need to write to things like the registry.
the registry is still used by so many programs. removing the registry would break backwards compatibility. hell, Microsoft _still_ uses the registry.
Using only configuration files seems to work quite well in Linux.
TLDR: The registry in theory is great, but the mere existence of the registry opens it up to idiots using it wrong. So the question still stands: why not replace the registry? If idiots / forgetting to have your app remove some values can cause things to break, it doesn't matter how secure and robust the system is, obviously
As a kid I loved the registry. I would change a whole bunch of things and see what it did. Made me feel 1337.
Along with registry they also need to dump the kernel, frameworks, libraries, foundation classes, etc.
don't forget NTFS, that's garbage.
What do you think should replace all of those?
The issue is apps needing admin rights when not a single one needs it to function.
That's less of a problem now than it used to be, but it's still a problem and it's mostly because those apps are trying to write to are read from things that they shouldn't ever have been accessing.
Windows has all these interesting roaming features, but home users get none of it.
Very well presented, as usual, revealing and informative.
Saved you a click: "Registry doesn't kill Software, Software kills Software."
if you are ultraparanoid about legacy registry settings surviving after an uninstall, you can use ushampoo to monitor installs and do a perfect uninstall. kinda a pain, but less work than reinstalling windows if you want a clean hive.
There are tools, for example zeroinstall and just using the no-install version of software. Many, if not most, software programs these days offer that. At least as far as free and opensource software goes.
If windows switched to something more like /etc for the registry, then items could be modified and remove without risk to the rest of the system.
The registry is that there is just one global registry instead of having registry files imho.