OSDev.org

as u can see i am taking the windows approach by creating VolTroX 4.

i have come accross many ideas but some cant not be implemented due to the fact that its real mode lol.
but for system resource and information, is a registry, or journal on events, updates and if they were completed, programs, graphics worth implementing? or would these programs events and information be kept in a place with the program that uses them?.

btw, im not fully resourcing my ideas of how things work on windows lol, just the idea of a registry came to mind and i wanted to see if it is a good idea to creat and use one of my own. if this seems as an unclear question, please tell me and i will shorten it

thank u for your time, and the os is coming well, i hope so is yours

Do you understand the purpose of the Windows registry? It can store general information, but it mainly used to inform the system of various hacks needed to run a program (a program which is *wrong*, due to the fact that it needs them). Ideally, you don't want a registry centered design - Windows only does it to please the software companies that don't want to fix their own code. It's also slow, and often a security hazard.

I'm not particularly sure, but I'm sure someone who is beter equipped to advise you on this particular choice will come along: A good way to implement a small, reliable DB in a kernel (as in integrated/inbuilt) should be to use SQLite.

http://www.sqlite.org/

If that link doesn't work, google SQLite.

EDIT: Pedigree uses it, so you know it's good.

Ghost, I'm not quite sure what the intent of your post is, but I'll attempt to cover every case I've interpreted.

For starters, I'm going to be using Unix terminology. I don't know how familar you are with Unix-like operating systems, but they attempt to have a very simple method of storing/accessing information: Everything is a file.

In Windows, the registry deals with two issues, configuration and operational information. It deals with neither completely. It is common in complex programs that work with Windows (as opposed to simple user space programs that work on top of it) to require several methods of polling for information (the simplest is probably the registry). Programming with and learning the inconsistent interfaces is not fun. Unix-like OSes, on the other hand, place data on their filesystems. Configuration files are located in the /etc/ directory, and operational files are in /proc/. For example, if you are on Linux or BSD, type "cat /proc/cpuinfo" to see information about your processor.

Log files, in Unix, are stored in /var/log/.

The big advantage in making everything a file is that all you need to know (from an API perspective) is open, read, write, seek, close. Very simple, and consistent interfaces. The only sad note is that traditional Unix OSes have strayed from this model. Plan 9 was an attempt to counter the trend, but it didn't catch on (for various reasons).

Take a few minutes to read the wikipedia page on unix filesystems. It explains where some information is stored in Unix-like OSes. Learning Linux or *BSD is a really good idea, their internals are much better documented than Windows (therefore much easier to learn). If nothing else, it is just a good idea to see how other operating systems do things.

The registry is one big reason why windows fails so hard. It's easily corruptible, its SLOW, and its rather annoying to access. I agree with stephenj, the unix way of doing it is much nicer (storing in /etc) not only because its fast, but because its easier.

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

Pedigree uses SQLite as a form of 'registry' - and its sexy:

• Transactions - all writes are trasactions, and can be rolled back/verified
• Very, very flexible, with good performance
• Simple to use and interface with
• Table and database encryption
• Supported features can be enabled as you add support for them in your OS (like pthreads)
• Callback functions - for example, if a program changes the video mode and stores it in a in-memory table, the OS can be notified of this (or any program)
• Fairly portable, written in standard C with some POSIX/Win32

The registry is full of blech. Of all the ugly hacks in Windows, the registry is by far the worst. It's slow, breakable, and easy for a n00b (or even an IT pro who's worked at a PC repair shop for countless years) to screw up. One accidental double-click and you can import an entire registry from a windows 95 computer into that of a brand new hypergaming windows 7 BEAST!!! *woof woof awwwooooooooooooooooooooooooo oww ow awwwooooo!!*

Troy Martin wrote:The registry is full of blech. Of all the ugly hacks in Windows, the registry is by far the worst. It's slow, breakable, and easy for a n00b (or even an IT pro who's worked at a PC repair shop for countless years) to screw up. One accidental double-click and you can import an entire registry from a windows 95 computer into that of a brand new hypergaming windows 7 BEAST!!! *woof woof awwwooooooooooooooooooooooooo oww ow awwwooooo!!*

It seems to me that everyone is overlooking the GOOD things the registry offers. The number one example there being a common API to do something every OS and most applications need: a way to store configuration data without having to roll your own. The registry is a great idea, IMO. It could very well be that just the implementation is flawed.

Hmm, I thought the point of this thread isn't to bash Windows' implementation of the registry concept. It's to talk about the concept of the registry itself, which as quok has already mentioned is actually not a bad idea.

To answer the question...

just the idea of a registry came to mind and i wanted to see if it is a good idea to creat and use one of my own

The key to a good registry is to make sure the data in the registry follows a very precise set of guidelines. Windows falls in this regard: there's no standardisation.

I also disagree with the concept of a "single" registry - I think there should be multiple different data stores, each with its own speciality. For instance, one store for video mode settings, another for user data, and another for xyz application. This way you don't have a monster file but you still get the benefits of the registry concept.

Okay, if we're talking the general concept of a single file that hierarchially stores information, it's great. It prevents the need for the OS to search for thousands of configuration files throughout multiple possible terabytes of hard drive space, among other things.

I'll post more thoughts tomorrow, it's getting late and I have a niiice large 2 science math class tomorrow, blech.

Several points itching to be made, here.

1) "Everything is a file", except when it isn't. You cannot seek in a tty. You cannot append to /dev/sda. They've gone through three systems of creating files in /dev in short time because they had to realize things weren't that simple. They have a special command (ioctl(), with its very ugly, very syscall-like interface) for handling the files that aren't.

It's a good paradigm, but it was taken too far.

2) "Everything is a database key" tends to grow that kind of generic, do-everything but do-nothing-great interface that programmers around the world hate with a passion. I don't think that the system interface for maintaining configurations has to be the same that's managing file type registrations, COM objects and the list of installed applications. Trying to handle them through an identical interface gives very much the same problem as under 1).

It's a good paradigm, but it was taken too far.

That leads us to...

3) "Everything is..." is an excellent hint that someone is selling you BS. "Everything is..." heralds the attempt of someone to oversimplicate things, because not everything is the same. IMNSHO.

That being said, there is...

4) You shouldn't confuse the concept of a registry (which can be handy, on the backend of e.g. a package manager, the file type manager or the configuration manager), with the crufty way that Microsoft implemented it.


To get back to the original question, "is it worth it?". It can be handy to have a system database, as many things you'll want to store are database-ish in nature. Just be careful that you provide proper domain-specific APIs, so that reading / saving a configuration feels like just that, and not like some kind of database operation (or worse yet, requires you to hobble together SQL statements).

A serious drawback of the registry solution is that it becomes non-trivial to correct configurations outside the running system. You can't boot from a generic Live CD to fix a problem that breaks your OS' boot process, as you can with Unix. Getting an overview, searching for something by regular expression, saving / restoring content, all this is easier with files than it is with a database.

Every paradigm is best taken with moderation. Apply paradigms where they fit and make things easier for the client, not where they make things easier for you, the programmer.

The Windows Registry: A data repository accessed using a common API.

To answer your question, ask yourself do you need a data repository that all applications can access without worrying about how it is stored, maintained and secured (I bet the answer is yes).

The Windows Registry was an attempt to replace data repositories including:

- Environment Variables
- INI files
- User setting files
- Bootup Script settings
- Installation/Configuration databases

Regardless of what you call it, your OS will probably implement some sort of data store that all applications would want access to.

Do not however make the mistake of wanting to save log files in the same registry as where your "settings" are located.

Hi,

My idea, when I thought I had enough time for an OS(!) was to implement individual applications settings stores through a common interface, much like the MS "application data" path and the .NET Config namespace, but taken a bit further. The idea in my design document ran sort of like this:

* All applications must be installed via the provided installation API.
* Applications install to a subfolder of a common path (like "Program Files" - probably /programs/appn...). The system installation API does not allow executables to be installed anywhere else.
* There is a /config folder, with a subfolder for all apps - same structure as the /programs folder. The system config API places all app data in the appropriate subfolder.
* Provision for some shared settings...
* A /data folder of the same structure for storing user documents and so on...

The idea was that to exactly backup your application data, all you needed to do was put the contents of /config/appn to a removable drive and copy over to your second computer, so you only need to configure everything once. I even had a system for allowing single-time initial configuration for apps on a network.

I hope you can find some inspiration somewhere in this mishmash of ideas

Cheers,
Adam

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...

AJ wrote:The idea in my design document ran sort of like this

That's a good idea imho, sort of what I'd invent if I weren't taking things a bit differently. I'd want to have links at filesystem level though so that I have all the app data and config both available for easy copying in a single tree, and close to the program files if I want to backup a single app including its binaries.


JAL

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.

Nonsense. Take a look on a desktop lately? How has windows failed? M$ owns some 70% of the market, hardly a failure. The registry IS NOT slow. 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.

piranha wrote: I agree with stephenj, the unix way of doing it is much nicer (storing in /etc) not only because its fast, but because its easier.

To be more precise, this is one of the main reasons for *nix failure. Every application has it's own configuration file with a separate format and domain knowledge is required to change settings. M$ introduced the registry to replace the INI files which were stored all over the place and collaborate them into a common location. In times past nearly every application would code mechanisms to save and load settings resulting in small files all over the drive. The registry is simply an attempt to put them all in one file and offer a common access method.

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

WTH are you talking about? Do you even know what the registry is? The registry stores configuration settings and some minor info in a database as opposed to flat files. That is all. It does nothing special. There is nothing about the registry that has backed M$ or windows into a corner. ~IF~ there were an issue (which there is not) it would be nothing short of simple to replace the guts of the registry to use files instead of a database. None of the client apps would even have to change.