Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
piranha wrote:The registry is one big reason why windows fails so hard. It's easily corruptible, its SLOW, and its rather annoying to access.
tantrikwizard wrote:It's a database, that is all, and the entire purpose of a database is to store and save data efficiently and effectively. Also, the registry IS NOT easily corruptible, in the thousands of computers I've maintained over the years I've only seen one or two actually corrupted.
Both of you are right, but you are talking about different things. The registry is hard to corrupt (from a database perspective), but is vulnerable to malicious programs (think autorun programs, internet exploder addons and whatnot). There is nothing preventing one application from interfering with another application's settings. More precisely, there is nothing isolating one application's settings (or data) from those of another application. Unfortunately *nix with its gazillion configuration files is (theoretically) just as vulnerable as well. Without some sort of strong authentication this problem cannot be solved. The Isolated Storage feature of the .NET framework attempts to solve this, but not everyone uses .NET.
piranha wrote:
The registry was a bad idea. It's also why windows hasn't progressed significantly in the time since it was introduced (all they've really done is make it more fancy). But they can't redo/rewrite the system so that the registry is gone, because so many programs depend on it. Microsoft is totally screwed when it comes to their operating system. It's been engineered into a corner.
-JL
The registry - a subsystem of windows - has nothing to do with its UI or the failure of Vista.
NickJohnson wrote:Do you understand the purpose of the Windows registry?
Window bashing alert! You do realize that you're talking utter nonsense here, right? I would've thought better of you...
I was just assuming that the OP was talking in terms of the Windows registry, which is generally the only thing people think of when you say "registry" (I would call it a database if it were anything else). The other versions of his OS seemed to be sort of MS-DOS clones, which also made me assume he was trying to make a Windows-style registry. The Windows registry has (arguably, I suppose) a pretty bad design. I wanted to point out that a large factor in the registry's continued existence is backward compatibility, instead of usefulness or elegance.
A database for system organization is generally an okay idea, although I would probably take it less far than the Windows registry does. Config files are much better for 90% of situations, just because of their transparency, and the filesystem is just a type of database. Maybe you could combine the UNIX idea of a unified filesystem and the Windows idea of a separate configuration database and get a virtual filesystem that contains program configuration data and is mapped to a database - essentially a registry that can be accessed from the filesystem transparently.
I think, once I've gotten to the point where I need it, I would implement a settings database similar to the Windows Registry, except for one difference: A program is only allowed to access it's own settings. Unfortunately, I'd have to come up with some kind of method to verify that a program is, in fact, what it says it is to help prevent malicious code from corrupting things.
In my opinion both approaches (registry and set of files) have their advantages and, of course, their disadvantages.
In the case of a UNIX-like configuration directory, containing a bunch of files, the advantage is of course that configurations are accessed exactly like any other file, which means that they benefit from the system's privilege management, can be stored on just about any type of storage device/filesystem combination, and that the OS itself doesn't have to bother "knowing" what most of the files are about. The main disadvantage, ironically enough, is that every file has its own format (ranging from CSV-ish to scripts to binary data), and that each program ends up having to either use a library for a given format or implement its own.
The registry approach bypasses that problem by offering a common structure for configuration. However, it requires specific code to manage this database, ranging from basic access (transactions, structure, etc..) to privilege management. It is also much more limited in what it can contain (or at least in what it *should* contain - storing 100+ byte strings in there just doesn't seem like a good idea, but then again, I'm biased), which results in having some parts of the configuration stored as e.g. files.
The brown matter is bound to hit the revolving, airflow-generating implement.
The registry - a subsystem of windows - has nothing to do with its UI or the failure of Vista.
Im not saying it was the only reason, im just saying (it could be argued) that it was one factor that made vista less....good.
I know it as nothing to do with the GUI, but really. Look at the differences between versions: The main difference between most windows versions is just the interface (specifically, how nice it looks).
These are the main new features as listed by microsoft. It took them how many years to do that?
Mods: Suggest splitting the thread and putting the off topic ones (such as this one, and I apologize) in Auto-Delete or GR as this is really just another Windows Vs. Unix thing.
I'll admit, however, that the idea of a central informations database has some merit. I wouldn't personally do things this way, but I can see why others would. I just mostly don't like the method that microsoft chose to do it in, and the style that it is.
One thing that could work is a combinations: /conf/<programname>/files. Every file is some sort of standard (like xml or something). The only problem would be enforcing this rule.
true, slow and laggish, know that if i were to take every bit of information and parameters on certain programs and how they work a certain way, would be good info wise, but the organization would be a hassle, finding and removing the target entry would not be hard, but dtermining if it should be removed if the host program doesnt ask the userlayermanager to tell the kernel to remove it, wil be the problem, and make the registery log bulky and space wasting. tho i wil need a data base to keep info on things i could easily change through update programs i distribute, like how th interface works or what version of file is being used, or if the update was sucsessful and that running the program would not be reccomended. information as of that category i will take up with the links u (everyone in general) have provided me.
thank u all for your time and support. and if i come up with a conflict with choice, or software problem, i wil take it up with google, and if not the search engine, ill be sure to come here
I like the idea of applications being self contained in their own directories, say a global read-only directory for the executables, and a user-specific read/write directory. Implemented correctly, a program can be uninstalled by removing those two folders, and you can also see much memory a program is taking by comparing the size of those two directories. Uninstallation should simply mean removing these directories.
Having a database without any sort of standard where can easily lead to bloating. You could uninstall a program and values have stayed dormant in the registry for years. After years of installing and uninstalling programs, this database could grow to gigabytes, and when you try to clean it up you're not sure what's safe to delete. You might be able to provide an uninstaller to clean it up, but what if you moved the application to a different location, or wanted to copy it to a different computer, or you install or patch and application over the top, and the uninstaller then misses files because it wasn't designed to take it into consideration or fails completely.
Using Windows Vista as an example, you are provided with Program Files (where the executable is stored, read-only if you're not an administrator), Users\...\AppData\ (user specific stuff - settings, plugins, etc), Users\...\Documents (user specific documents, but not just for the program). I think that's a good example of how a program's files should be laid out.
I know Vista also has the registry, so it has both worlds. I've rarely written a program which interacts with the registry.
[ot]
You can't say Windows doesn't break backwards compatibility. There are plenty of older programs that try to install icons into C:\Windows\Desktop, try to write to their folder in Program Files (so you have to run them with administration privileges), the removal of WoW32 (16-bit Windows compatibility) in 64-bit Windows, and plenty of APIs (Windows Presentation Foundation (XP SP2 and above), Direct3D 10 (Vista and above), Direct2D (Vista and above)) that are only available on the newer OS's.
[/ot]
MessiahAndrw wrote:say a global read-only directory for the executables
Patch would fail.
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.
ru2aqare wrote:There is nothing preventing one application from interfering with another application's settings.
This is not entirely accurate. M$ registry keys (post NT4 IIRC) have permissions that can restrict access and modifications. Its up to the application to lock down and tightened security but its entirely possible as part of the API.
tantrikwizard wrote:This is not entirely accurate. M$ registry keys (post NT4 IIRC) have permissions that can restrict access and modifications. Its up to the application to lock down and tightened security but its entirely possible as part of the API.
Correct me if I'm wrong, but to the extend of my knowledge the NT permission system deals with user accounts, not with applications. Two applications ran by the same user could still corrupt each other's settings.
@MessiahAndrw
i was thinking about an unistaller of the sort. i just need to keep everything updateable and replaceable, without having to replace the kernel when i have to, is my goal, if i have to update the graphics device interface controller, i want it to be a program of its own, not inside the kernel. so when i want to change something, replacing the os, wont be needed.
sorry if some of that was OT, but i wanted to explain a little bit of my goals for future reference.
MessiahAndrw wrote:say a global read-only directory for the executables
Patch would fail.
But, only administrators should be able to patch/update a program since it affects all users, unless you also had a local Program Files. So in a way, a file system could be:
/Users/All/Applications
- global applications - readable/executable by all users
/Users/All/Documents
- global documents - readable/writable by all users
/Users/[user]/Applications
- user-specific applications, also user-specific binary data/settings for global applications
- readable/writable/executable by specific user
- if the directory is set to not be executable then users on a shared system can not specify their own programs
/User/[user]/Documents
- user-specific documents, readable/writable but not executable by specific user
tantrikwizard wrote:This is not entirely accurate. M$ registry keys (post NT4 IIRC) have permissions that can restrict access and modifications. Its up to the application to lock down and tightened security but its entirely possible as part of the API.
Correct me if I'm wrong, but to the extend of my knowledge the NT permission system deals with user accounts, not with applications. Two applications ran by the same user could still corrupt each other's settings.
Correct, permissions are based on users, but that doest not exclude an app from securing its own settings. An app is suggested to run under it's own restricted account when running as a server, read the MSDN for more info.
i have administration rights for users in mind. i will encode what files will do, the only way some files will be able to do things is by accessing functions via through compnents in my os, only files that need access to replace, or modify any system files wil not have access to functions that r capable, if they do not have the code, and file signature, (the code will be password like, to tell the system, this is a trustable file to run. only people who r on my cite, and make moduals for my os. only they wil get the password and the way to have their files acsess kernel functions. or i will just have a file that has a list of all the trusted files, seeems alot easier. wont have to mess with passwords
