plain-text registry hives
Moderator: Moderator Team
The problem of registries is that 99% of win32 apps are shipped with bad installers/deinstallers. The same as what happens with DLHell, happens in the registry. Just install any random application, uninstall it immediately afterwards, and search the registry for its name or its vendor's name. Lots of classes are left behind, and often the main settings as well (HKLM/Software/Vendor/Product). Not to mention that trial versions leave icky traces behind to make sure that you won't be able to start a new trial. You could say that the registry is simply being ill-treated. But well, that's what you get for implementing an NT-clone. You can improve on the OS, but the guest apps running inside are still the same, lazily programmed, not-properly-cleaning-up, instable, stupid, win32 apps. There simply haven't been enough proper guidelines from Microsoft on how you should best put together a windows application, handle the registry, minimize DLHell, etc, and this nice kludge is the result. Changing or eliminating the registry won't fix it, and plaintext is one of the worst ideas of "improvement" so far. You know what might help? Keeping a changelog of which process modified what, similar to installation trackers which allow for a "true uninstall". And even that brings overhead. You can only hope this overhead on a clean registry will be faster than a dirty registry where you can't keep track of things.
Once I had a program from Norton. Every time you installed a program it poped up and recorded all changes the program made, so they could be removed compleately. When one implements support for such things inside of the OS, it wouldn't even take much Resources.
Are you sure ? Are they used like in my idea ?Windows already uses three registries for redundancy purposes.
And what about keys the program made itself (i.e. not from the installer)? What about all the keys created in the HKLU tree? Those aren't (supposed to be, in proper NT apps) created by the installer, and often the installers leave behind their settings to make it 'easier' for you later if you reinstall it.Dr. Fred wrote:Once I had a program from Norton. Every time you installed a program it poped up and recorded all changes the program made, so they could be removed compleately. When one implements support for such things inside of the OS, it wouldn't even take much Resources.
"People do have a real life." -- w3seek
Guess that means I'm not a person
Guess that means I'm not a person
i used to use one called cleansweeper i think, i forgotten, used to be good.SirTalon wrote:And what about keys the program made itself (i.e. not from the installer)? What about all the keys created in the HKLU tree? Those aren't (supposed to be, in proper NT apps) created by the installer, and often the installers leave behind their settings to make it 'easier' for you later if you reinstall it.Dr. Fred wrote:Once I had a program from Norton. Every time you installed a program it poped up and recorded all changes the program made, so they could be removed compleately. When one implements support for such things inside of the OS, it wouldn't even take much Resources.
But anywho, i don't understand what the big fuss is about a couple of bytes of text left behind with programs.
sure its annoying, but is it really a big a deal as people seem to claim?
i've tend to avoid posting in this forum now as its starting to turn in a flaming forum, well, when someone questions things or suggests new ideas it seems too, which is a shame
the way i see it, the problem with programs not leaving anything behind, at least in the way shareware/trialware etc is concerned is that no one would ever buy anything, just install, uninstall, install again 30 days later, from a user thats great but as someone trying to earn living...not so great
my only problem with the registry is that there is no confirmination when things are added to the run sections, it would be nice if reactos was able to prevent programs adding themselves with a popup
Except that those 'couple of bytes of text' add up over time, making every time a program access the registry a bit slower. This really adds up over time. Just take a look at a installation of XP was installed a few years ago. Then compare it to a computer that was installed a few days ago.Stead wrote:i used to use one called cleansweeper i think, i forgotten, used to be good.SirTalon wrote:[Ommited to save loads of space.]
But anywho, i don't understand what the big fuss is about a couple of bytes of text left behind with programs.
sure its annoying, but is it really a big a deal as people seem to claim?
i've tend to avoid posting in this forum now as its starting to turn in a flaming forum, well, when someone questions things or suggests new ideas it seems too, which is a shame
the way i see it, the problem with programs not leaving anything behind, at least in the way shareware/trialware etc is concerned is that no one would ever buy anything, just install, uninstall, install again 30 days later, from a user thats great but as someone trying to earn living...not so great
my only problem with the registry is that there is no confirmination when things are added to the run sections, it would be nice if reactos was able to prevent programs adding themselves with a popup
Most of the time people don't release a time expiring trial of a program (since they are so easy to defeat), and use a program that just has a limited functionality as a demo.
Oh and if you want a confirmation if a program is adding something to the startup, just install the newest version of SpyBot Search & Destroy (it includes TeaTimer, which will prompt you when a program attempts to, it also allows you to remember you decision for certain things)
"People do have a real life." -- w3seek
Guess that means I'm not a person
Guess that means I'm not a person
Two things:
There is already something called Linux Registry (or the Elektra Initiative as it is called now) and it tries to get us saved from /etc/* hell.
http://elektra.sourceforge.net/
I think it is a good idea (and in the right direction). I would like to able to play with it on my Debian, but I could not install it.
Anyway, the idea is great --IMHO.
Then there is Reiser4 --for those of you who think it would be too large or to slow to have a text-based Registry. Well, with Reiser4 the issue is almost irrelevant. Reiser4 is geared for small files from the beginning.
Reiser4 would laso be great if someone wrote a Registry plugin for this purpose.
Damn... all roads seem to lead to Reiser4
There is already something called Linux Registry (or the Elektra Initiative as it is called now) and it tries to get us saved from /etc/* hell.
http://elektra.sourceforge.net/
I think it is a good idea (and in the right direction). I would like to able to play with it on my Debian, but I could not install it.
Anyway, the idea is great --IMHO.
Then there is Reiser4 --for those of you who think it would be too large or to slow to have a text-based Registry. Well, with Reiser4 the issue is almost irrelevant. Reiser4 is geared for small files from the beginning.
Reiser4 would laso be great if someone wrote a Registry plugin for this purpose.
Damn... all roads seem to lead to Reiser4
-
- Posts: 237
- Joined: Fri Nov 26, 2004 10:44 pm
- Location: Fallowfield
Is the Registry a small file?a2z wrote:Well, with Reiser4 the issue is almost irrelevant. Reiser4 is geared for small files from the beginning.
Well anyway, I don't really know anything about Reiser4, so I can't say how good it would be for a plain text registry. But if other file systems can't cope well, then that might be a problem. Maybe it's not a good idea to use a plain-text registy if it will negatively affect ReactOS' performance on other file systems.
[quote="counting_pine"][quote="a2z"]Well, with Reiser4 the issue is almost irrelevant. Reiser4 is geared for small files from the beginning.[/quote]
Is the Registry a small file?
[/quote]
Well... yes and no.
No: Registry --in conventional sense-- is a great big blob of file holding stuff in its own weird internal format. But, this is not what am referring to.
Yes: When Reactos is coupled with Reiser4, you you can think of Registry as both a file and as a directory hierarchy. [Just like a Zip file contains various files and folders in it.]
The difference here, in the case of Reiser4, is that you can access --natively-- each Registry record as a small file.
This is how you can have your cake and eat it too.
IOW, I am referring to 'a file can be a folder' metaphor in Reiser4.
I hope this is clearer.
Is the Registry a small file?
[/quote]
Well... yes and no.
No: Registry --in conventional sense-- is a great big blob of file holding stuff in its own weird internal format. But, this is not what am referring to.
Yes: When Reactos is coupled with Reiser4, you you can think of Registry as both a file and as a directory hierarchy. [Just like a Zip file contains various files and folders in it.]
The difference here, in the case of Reiser4, is that you can access --natively-- each Registry record as a small file.
This is how you can have your cake and eat it too.
IOW, I am referring to 'a file can be a folder' metaphor in Reiser4.
I hope this is clearer.
-
- Posts: 237
- Joined: Fri Nov 26, 2004 10:44 pm
- Location: Fallowfield
OK, so, you're not suggesting that the registry be stored as a plain text file on a Reiser4 file system, but that the registry be stored as a file that you can mount as Reiser4 and access all the (folders/files) (keys/values) inside?
Sounds like an idea. As I said before I don't know much about Reiser, but if you had a registry that used Reiser, I guess it would probably be more robust, and you could take advantage of permissions and whatever other features Reiser4 has.
I'm not sure how good this idea is from a Windows-compatibility point of view. The file system might have to be modified a bit to accomodate, e.g. the way that every key has a default value. And some features may have to be removed, like maybe hard/symbolic links, and there may have to be a limit on file sizes.
I don't know, I think I'm out of my depth a bit now.
I can see some advantages in storing the Registry as a proper file system, though.
Sounds like an idea. As I said before I don't know much about Reiser, but if you had a registry that used Reiser, I guess it would probably be more robust, and you could take advantage of permissions and whatever other features Reiser4 has.
I'm not sure how good this idea is from a Windows-compatibility point of view. The file system might have to be modified a bit to accomodate, e.g. the way that every key has a default value. And some features may have to be removed, like maybe hard/symbolic links, and there may have to be a limit on file sizes.
I don't know, I think I'm out of my depth a bit now.
I can see some advantages in storing the Registry as a proper file system, though.
To make a Reiser-Registry fast you'd have to run it off memory.
To make a Reiser-Registry stable and robust you'd have to stripe it across sets of memory and add parity bits, and have it back itself up constantly. Perhaps even its journal would have to lay on the drive in a swapfile.
To make a Reiser-Registry stable and robust you'd have to stripe it across sets of memory and add parity bits, and have it back itself up constantly. Perhaps even its journal would have to lay on the drive in a swapfile.
*************************************
Go Huskers!
Go Huskers!
from what i can tell, the argument for a text based registry, is, so you can edit it easily
i can't see any advantages from what the developers have said, surely if you are concered about recovering a computer if the registry gets corrupted, i can think of a few things
have an option on the boot menu to restore the registry to previous boot, i think thats what the load last known good configuration does on windows, but have 2 backups of the registry?
or just have a program that would read the registry files from a recovery disk of some sort, to me plain text files would seem like it would take an awful lot of time to load into memory, and from what i can tell someone was suggesting have everything in its own text files, with directories structure similar to the start menu, if thats what is being suggested i am strongly against that, the windows start menu is a bad idea performance wise in my opinion, yes its easy to edit, but the first time it loads its slow, well not that noticable i suppose. but then its hardly lots of data
the idea of having a special folder in windows for the registry seems like a nice idea i guess, but wouldn't that work in the same way that regedit does now?, an address bar would be nice, i once wrote a program that just viewed registry keys and you would get to them by typing them in the an address bar like text box, you could navigate it using the cursor keys, up/down selects from the nice autocomplete box, use left and right to go up or down a level, always liked that, think i'm getting off topic here tho
regarding my previous post about is it really an issue with those few extra bytes, anywho, didn't someone mention time stamping the keys, then have a utility or have it run automatically that if something hasn't been accessed for over a month remove it, but not delete just move it tempoarily, if nothing stops working then remove it perminatly say a week later, but would that create performance issues, although isn't the registry loaded in memory, so any performance would be unnoticable on todays computers, besides it wouldn't have to timestamp everything, maybe just have a number in a property of the current day of the week and month, or just change a 0 to a one, at the begging of everymonth assign everything a 0, as keys are accessed change that to a 1 to show its been read, then at the end of the next month delete all registry entires that the property of 0 then change all the existing 0's to 1's, can't see that affecting performance in everyday
just an idea?
p.s. i know programs are out that monitor the startup keys in the registry, but i'm generally against that one useful utility in the background as they do seem to add up quite quickly, would be nice if a service or something could be implented that had hardly any overhead
i can't see any advantages from what the developers have said, surely if you are concered about recovering a computer if the registry gets corrupted, i can think of a few things
have an option on the boot menu to restore the registry to previous boot, i think thats what the load last known good configuration does on windows, but have 2 backups of the registry?
or just have a program that would read the registry files from a recovery disk of some sort, to me plain text files would seem like it would take an awful lot of time to load into memory, and from what i can tell someone was suggesting have everything in its own text files, with directories structure similar to the start menu, if thats what is being suggested i am strongly against that, the windows start menu is a bad idea performance wise in my opinion, yes its easy to edit, but the first time it loads its slow, well not that noticable i suppose. but then its hardly lots of data
the idea of having a special folder in windows for the registry seems like a nice idea i guess, but wouldn't that work in the same way that regedit does now?, an address bar would be nice, i once wrote a program that just viewed registry keys and you would get to them by typing them in the an address bar like text box, you could navigate it using the cursor keys, up/down selects from the nice autocomplete box, use left and right to go up or down a level, always liked that, think i'm getting off topic here tho
regarding my previous post about is it really an issue with those few extra bytes, anywho, didn't someone mention time stamping the keys, then have a utility or have it run automatically that if something hasn't been accessed for over a month remove it, but not delete just move it tempoarily, if nothing stops working then remove it perminatly say a week later, but would that create performance issues, although isn't the registry loaded in memory, so any performance would be unnoticable on todays computers, besides it wouldn't have to timestamp everything, maybe just have a number in a property of the current day of the week and month, or just change a 0 to a one, at the begging of everymonth assign everything a 0, as keys are accessed change that to a 1 to show its been read, then at the end of the next month delete all registry entires that the property of 0 then change all the existing 0's to 1's, can't see that affecting performance in everyday
just an idea?
p.s. i know programs are out that monitor the startup keys in the registry, but i'm generally against that one useful utility in the background as they do seem to add up quite quickly, would be nice if a service or something could be implented that had hardly any overhead
I don't want a plain text registry because it is easily editable, I want it because it would be _MUCH_ faster than a binary registry (you would have to write a DB from scratch for a binary registry, when a DB that is far faster than anything you could write already exists, which is called a file system).Stead wrote:from what i can tell, the argument for a text based registry, is, so you can edit it easily
If a binary registry gets corrupted, a MASSIVE amount will be gone. A text based registry won't (unless your using a crappy filesystem like NTFS or FAT).Stead wrote:i can't see any advantages from what the developers have said, surely if you are concered about recovering a computer if the registry gets corrupted, i can think of a few things
That would be the same as doing a reinstall of windows, all programs would lose their registry settings. You would almost be better off just formatting the drive.Stead wrote:or just have a program that would read the registry files from a recovery disk of some sort
With a plain text registry you don't have to load it all into memory, and a file system like Reiser 4 will get the files off of the disk VERY fast. Hardly ever are more than a few kilobytes read from the registry at a time.Stead wrote:to me plain text files would seem like it would take an awful lot of time to load into memory, and from what i can tell someone was suggesting have everything in its own text files, with directories structure similar to the start menu, if thats what is being suggested i am strongly against that, the windows start menu is a bad idea performance wise in my opinion, yes its easy to edit, but the first time it loads its slow, well not that noticable i suppose. but then its hardly lots of data
So if I don't use a program once every month all of its settings get deleted? That would suck.Stead wrote:regarding my previous post about is it really an issue with those few extra bytes, anywho, didn't someone mention time stamping the keys, then have a utility or have it run automatically that if something hasn't been accessed for over a month remove it, but not delete just move it tempoarily, if nothing stops working then remove it perminatly say a week later, but would that create performance issues, although isn't the registry loaded in memory, so any performance would be unnoticable on todays computers, besides it wouldn't have to timestamp everything, maybe just have a number in a property of the current day of the week and month, or just change a 0 to a one, at the begging of everymonth assign everything a 0, as keys are accessed change that to a 1 to show its been read, then at the end of the next month delete all registry entires that the property of 0 then change all the existing 0's to 1's, can't see that affecting performance in everyday
If you had a service, you would have to run a second program to connect to it to ask you permission (look at ZoneAlarm, theres the TrueVector service, and the client), that would be more overhead that 1 program.Stead wrote:p.s. i know programs are out that monitor the startup keys in the registry, but i'm generally against that one useful utility in the background as they do seem to add up quite quickly, would be nice if a service or something could be implented that had hardly any overhead
"People do have a real life." -- w3seek
Guess that means I'm not a person
Guess that means I'm not a person
Trust me, its _MUCH_ slower than a binary registry. If you're familiar with programming in general or string parsing you should know why.SirTalon wrote:I want it because it would be _MUCH_ faster than a binary registry
we already wrote that stuff and it's working fine, and considering ReactOS is still pre-alpha our registry is running pretty fast and stable already. You can't compare the registry to a file system, file systems are optimized to store larger amounts of data, the registry is intended to store little information structured to access it as fast as possible. Besides, the registry requires a underlying file system as it's stored as standard files.SirTalon wrote:you would have to write a DB from scratch for a binary registry, when a DB that is far faster than anything you could write already exists, which is called a file system
A text registry will get corrupted much easier, e.g. by people violating the syntax using their text editor.SirTalon wrote:If a binary registry gets corrupted, a MASSIVE amount will be gone.
considering NTFS a crappy file system leads to the conclusion that you're either a *nix troll or you just don't have any technical background of NTFS. I however agree with you on FAT.SirTalon wrote:A text based registry won't (unless your using a crappy filesystem like NTFS or FAT
You'd have to load it completely into memory to parse it. There's pretty much no other way to build an index without parsing the file. It'd require to page in all of the huge text file and parse hundreds of megabytes of a string. Since the registry builds on top of a file system, it depends on the file system on how fast it can get paged into memory. However, a binary registry doesn't have to be parsed and completely paged into memory. It's sufficient to page in the parts of the root key, as soon as deeper levels of the registry need to be accessed, it just accesses the memory using the pointers (calculated by the base address + the offset in the file) and if that part of the registry isn't present, it just gets paged in. Searching for key names and values is rather easy by just iterating the key directories and comparing the names. Now, tell me an algorithm how to load in parts of a text file, building a tree from it without parsing the file entirely and accessing any parts of it as fast as possible. If you manage to do that, you're god!SirTalon wrote:With a plain text registry you don't have to load it all into memory, and a file system like Reiser 4 will get the files off of the disk VERY fast.
see above, hardly judgable without knowledge of string parsing, paging, file systems, ...SirTalon wrote:Hardly ever are more than a few kilobytes read from the registry at a time.
You propably haven't gotten the concept of system service, security, etc...SirTalon wrote:If you had a service, you would have to run a second program to connect to it to ask you permission (look at ZoneAlarm, theres the TrueVector service, and the client), that would be more overhead that 1 program.
I don't know what's so "cool" about Reiser4....you're free to implement a driver for reactos! If you're so much convinced of text based registry, feel free to implement it. I guarantee you there's a chance of exactly 0.0% of getting that code into the official source repository, but you wouldn't even attempt to submit that code because ros would slow down so bad that it'd take hours to just boot it up.
Who is online
Users browsing this forum: Ahrefs [Bot] and 47 guests