|
Why on earth are you all using XML DOM? It is so slow and resource consuming. Don't you know about the SAX2? (Example: when parsing the 100kb XML file with DOM, the engine allocates approx. 1mB of memory). SAX not only reads XML, it can write with XMLWriter.
|
|
|
|
|
For one thing, you probably shouldn't have a configuration settings file thats 100kb. The DOM should work fine for small config files.
Secondly, yes I do know about SAX but I haven't used it much. The DOM is quick and easy for the novice to pick up and use.
YoSilver wrote:
SAX not only reads XML, it can write with XMLWriter.
You know what, that's a great idea for an article so why don't YOU write it!
Jason Henderson
start page
articles
"If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
One of the many reasons Microsoft implemented the registry was to eliminate all of the INI files that applications created in system- and program-specific areas. As one comment mentioned, anyone who has ever tried to write software that will function properly in a multi-user environment can attest to how well the registry works.
The registry contains two general areas that you should save program settings into: HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. The local machine area, as the name implies, is for storing program information that all users of the system will need. The current user area is for storing user-specific data. In a multi-user and multi-system environment, the user's registry generally follows the user from one machine to another. This used to be called a "roaming profile" in the Windows 95 days.
To mimic this using XML, you would need to save one file in a system-specific area, and another in a user-specific area. Both of these do exist, in the form of the C:\Documents and Settings\All Users\Application Data\ and C:\Documents and Settings\username\Application Data\ directories, but there is a problem: replication.
Many Windows shops will replicate a user's registry settings when the user logs in and out of various workstations. Replicating files is less common. Why? Simple: Most users create an inordinate amount of files in their "My documents" folder. This is good, because it provides a backup server with a single place to look when making a backup from the system. However, if full replication is used, all of these files are transferred between the Domain Controller and the workstation at every log on and log off. This is a huge waste of bandwidth! On my LAN at home, I set the systems to replicate all user profile data except for the "My Documents" folder. On 100 Mbps, it takes 15 seconds to get on or off a workstation because of the amount of data being transferred.
So, to end my rant with my opinion on this subject as both a software developer and a systems administrator: Follow Microsoft's recommendation. Software developers should save program settings in the proper area of the registry. By creating subkeys, one can have heirarchical storage of the data with very little additional effort. Plus, it enables program settings to be carried from one system to the next using replication. In the business environment, these are all important things to keep in mind.
XML was originally intended as a data description and transfer mechanism, not as an actual storage format. The registry may not be human-readable without a tool like RegEdit, but it was intended to be efficient, and store many different types of data in a heirarchical fashion. Duplicating this with text (XML) files doesn't accomplish anything beneficial.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Paul A. Howes wrote:
Duplicating this with text (XML) files doesn't accomplish anything beneficial.
I disagree, mainly because RegEdit is not a good tool for the lay-person. The registry is too big, cumbersome and dangerous to have your clients playing with when they call in for tech support.
Also, it appears that MS is going to recommend XML .config files in .NET.
Admittedly, XML is not good for very large sets of preferences.
In the end, it's up to the developer.;)
Jason Henderson
start page
articles
"If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
Jason Henderson wrote:
I disagree, mainly because RegEdit is not a good tool for the lay-person. The registry is too big, cumbersome and dangerous to have your clients playing with when they call in for tech support.
Jason, I think you're forgetting one important thing: Users should not be messing with the registry in the first place! It is supposed to be a place where applications can store configuration and state information, and nothing more.
Even as a software engineer, I rarely find a need to work within the registry. I have never found a reason to tell one of my customers to use RegEdit to fix something related to one of my applications. If you have had that experience with your customers, then you should spend more time on your design!
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Paul A. Howes wrote:
Users should not be messing with the registry in the first place!
Exactly! But in the real world they do sometimes. The apps our company writes are quite large and the users aren't computer savvy. We do use the registry (too much IMO) and on occasion, we have had to look at the registry for many reasons.
Paul A. Howes wrote:
Even as a software engineer, I rarely find a need to work within the registry.
Really? I'm willing to bet you are in the minority.
Jason Henderson
start page
articles
"If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
Totally agree. It is a good practice to choose whatever is good for your project instead of follow M$ for everything they recommend.
|
|
|
|
|
> The registry is too big, cumbersome and dangerous to have your clients
> playing with when they call in for tech support.
Maybe the solution to this is to store your settings in the registry as usual, but add a button somewhere in your program labeled "Export Program Settings" (part of, say, a dialog box called by a Tech Support button in the About box, like the Office apps).
Have this button create a simple .REG file that your users can email back to you... Doesn't RegEdit even have some command-line parameter to export a subkey in a non-interactive mode (no UI)? That's what I'm thinking but for some reason I can't find the docs right now...if that's the case, that'd be just a matter of spawning RegEdit from your own program, so that'd be, what, two lines to write? and (you'd assume!) bug-free from the start. Reimporting the file if necessary would be just as easy.
Just to add to the conversation, I'd have to agree with going against XML for storing program settings; for one thing, a *big* assumption is that the proper DLLs are already installed on the client machine...if the program you're writing isn't already using XML for some reason, why drag along the entire redistribution package just for storing the program settings? But if you already have another reason for using XML in your program, fine, but as others have pointed out, you may run into multi-user/multi-location problems. Using the <profile>\AppData directory is an idea, but then what are you going to fall back to on OSes that didn't even have that directory? Heck, even My Documents didn't exist on 95.
While I don't disagree that sometimes you need to have program settings forwarded to tech support, I don't believe XML is really the answer. I don't want to discredit Jason or undermine his efforts, so I'll say this much--the article is providing a very decent intro to XML manipulation in C++. So, thanks!
- DanielD
|
|
|
|
|
To each his own. 
Jason Henderson
start page
articles
"If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
I have to agree. Another case of a technology being mis-applied.
Tim Smith
"Programmers are always surrounded by complexity; we can not avoid it... If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather that part of the solution."
Hoare - 1980 ACM Turing Award Lecture
|
|
|
|
|
Explain how technology can be misapplied?
Isn't it up to the developer how they want to use technology?
Jason Henderson
start page
articles
"If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
As I stated in the beginning of this thread, XML is a document mark-up language. It was not designed to be used as a data storage mechanism. This is what he is finding fault with: Applying a document markup language in a way that it was not intended.
These days in the industry, your customers (especially the government and military!) will be your best friend if you can put the letters "XML" into a proposal, requirements, or design document. This is true even if the project would not benefit from XML in any way.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Not a data storage mechanism? What do you think goes between the XML tags?
What was intended of crude oil when it was discovered? It is used in thousands of ways each just as legitamate as the other. XML is the same way. Who cares how people use it, are we going to have document police now?
Paul A. Howes wrote:
This is true even if the project would not benefit from XML in any way.
Let's let the developer decide OK?
Jason Henderson
start page
articles
"If you are going through hell, keep going." - Sir Winston Churchill
|
|
|
|
|
I believe XML is Unicode based, not ASCII.
|
|
|
|
|
The first, and biggest for me, reason to use XML over the registry: portability. You may not care about writing applications for more than just Windows, but there are a ton of us out there who do. So keeping application settings in the registry just means more work later when you port your application.
A second reason is the fact that it makes it much easier to make changes to settings while in development. Nothing is worse than having to open RegEdit and find your buried application folder just to make a quick change.
Thirdly, when I delete an application I like to delete everything, this includes application settings. It's funny how my registry ballons after installing numerous applications, yet it hardly shrinks after uninstalling those applications. Of course, if I go through the registry and finally find the folder the applications are using, lo and behold, their information is still there. Much easier to just open up the application directory and delete all files located there.
Fourth, considering the registry contains information required for Windows to run, having numerous applications writing/reading from it all day long just increases the chance of corrupting the files the registry resides in.
Fifth, for those of us running a duel boot system, it sucks having to install the same application into the same directory for both operating systems, just to get the application settings written into the registry for both OS's. Yes, you could search the registry for the application in question, export the settings, then import them into the other OS's registry, but that's hardly something a common user can, or even should do. Of course, had they used files (such as XML) no extra steps would be required.
Sixth, as a few others mentioned, if users are having problems and you want to take a look at their application settings it's easier, and safer, to have them email you a file rather than trying to wade through the registry.
- Houdini
|
|
|
|
|
Houdini wrote:
The first, and biggest for me, reason to use XML over the registry: portability.
The XML itself is portable, but the methods used to access it are not. You may argue that SAX, SAX2, and DOM are standard interfaces, but every platform seems to have a different implementation. If you want to write your own parser, that's fine, but there are better uses of a developer's time than recoding something that already exists. You may even want to drag a third-party library along, such as Xerces, but that becomes yet-another dependency to deal with when you distribute your application. However, I do not disagree with you: I have been looking into some cross platform development (Windows and FreeBSD w/ KDE) and encountered the same problem.
Houdini wrote:
A second reason is the fact that it makes it much easier to make changes to settings while in development.
I may be missing something here, but I have rarely run into cases where hacking the registry fixed my application. I try to follow a simple rule: Every registry setting has a corresponding GUI setting.
Houdini wrote:
Thirdly, when I delete an application I like to delete everything, this includes application settings.
If your deinstallation program doesn't remove settings that were created by either the installation program or the application itself, then the deinstaller was poorly written. I would consider that a defect. Don't take that statement personally; I am not directing it at you. I have had the same experience with many applications.
Houdini wrote:
Fourth, considering the registry contains information required for Windows to run, having numerous applications writing/reading from it all day long just increases the chance of corrupting the files the registry resides in.
It's funny -- I have never had a corrupted registry that I am aware of, and yet I hear people talk about this all the time. I would be curious to know how you define "corruption", and how it actually occured.
Houdini wrote:
Fifth, for those of us running a duel boot system...
Ugh! There we fully agree! I gave up on dual-booting a long time ago simply because I found it to be to aggravating. The only half-decent solution I ever found to dual booting was to authenticate against a domain controller that replicated my registry settings. Then at least they would follow me around. Of course 99% of the users out there do not have a server in their house!
Houdini wrote:
Sixth, as a few others mentioned, if users are having problems and you want to take a look at their application settings it's easier, and safer, to have them email you a file...
True, but as someone mentioned in another thread, it wouldn't be that hard to put a reg-dump button into the GUI. However, that would be more work for the developer than telling a user to e-mail a file, and would certainly pose a rather large problem if the application couldn't even be started to get to the reg-dump.
Okay, I have gone from being fully in the registry camp to being on the fence between XML and the registry... Each seems to have its advantages and disadvantages. Would anyone else like to fan the flames and attempt to bring me over to the dark (XML) side? 
--
Paul
"I drank... WHAT?"
|
|
|
|
|
First off, I'd like to commend you on your well thought out reply. You made some very good points and kept and open mind. I guess I'm just not used to that when dealing with message boards .
The XML itself is portable, but the methods used to access it are not. You may argue that SAX, SAX2, and DOM are standard interfaces, but every platform seems to have a different implementation. If you want to write your own parser, that's fine, but there are better uses of a developer's time than recoding something that already exists. You may even want to drag a third-party library along, such as Xerces, but that becomes yet-another dependency to deal with when you distribute your application. However, I do not disagree with you: I have been looking into some cross platform development (Windows and FreeBSD w/ KDE) and encountered the same problem.
True, it's not a perfect solution. However, if you were going to port it to a different operating system, you'd need to make more changes going from the registry to XML than you would plugging in a 3rd party parser.
Of course, it may be even easier to just create your own portable, and simple, text file format and reader/writer.
I may be missing something here, but I have rarely run into cases where hacking the registry fixed my application. I try to follow a simple rule: Every registry setting has a corresponding GUI setting.
That's a very good rule to follow, and something I admit I don't always follow myself =). Still there may be interal data you don't see a need to, or would rather not, expose to the user. Such as last known positions of windows, a MRU list (you may not want MFC to handle the MRU if you have portability in mind, and other libraries may not even support this internally (Borland, WTL, Win32, QT, etc)).
If your deinstallation program doesn't remove settings that were created by either the installation program or the application itself, then the deinstaller was poorly written. I would consider that a defect. Don't take that statement personally; I am not directing it at you. I have had the same experience with many applications.
Yes, in this case the deinstaller was poorly written and should be considered a defect. Still, there are many programs that have this bug, and there will always be some that will, unless Microsoft decides to automatically clean an applications registry folder upon uninstall.
It's funny -- I have never had a corrupted registry that I am aware of, and yet I hear people talk about this all the time. I would be curious to know how you define "corruption", and how it actually occured.
Ok, ok, I've never actually had my registry "corrupted" but I have experienced invalid entries which I could never track down that caused me to get numerous error messages upon starting Windows. And since Windows booted successfully the backup registry files got overwritten with the "invalid" ones. In the end I decided to re-install a new Windows over my old one, which of course meant I needed to re-install all my applications since they kept information in the registry.
Still, I would think that corrupted registries are fairly uncommon, but nonetheless it is another potential problem when applications access it constantly.
- Houdini
|
|
|
|
|
Why learn XML to create an INI file.
INI files and using the registry is much easier.
I have to know too many languages as it is.
|
|
|
|
|
The problem with the registry is that it's WAY too big and unsafe for application settings and stuff like that.
The registry might be a good thing for windows restricted operations, only the windows OS should read and write from it, too many clients ( us, programmers ) abuse the registry to hold data.
Using XML ( which, is mostly just a structured data text file ) it's easier for the programmer and the users to manage application settings without the risk of corrupting the whole system.
I think it's a good idea to use XML, the only problem now is that windows rely too much on it ( i.e. file assocs, shell open cmds, ... )
using XML files to hold settings is a bit like using .<somthing>rc on unix.
Max.
|
|
|
|
|
There's one big reason to use the registry.
Have you ever written software for multi-user environments? In this case using the registry (HKCU)would be the best (if not the only) solution, especially if the user profile is not stored locally but on the server.
---
Author of FileZilla FTP
http://sourceforge.net/projects/filezilla
|
|
|
|
|
Each user in a multi user system will get their own personal folder which is where the HKCU data is stored anyway. I don't see why this would be any different using XML files.
|
|
|
|
|
Sure I like the clean syntax of INI files for a small bunch of data. For big applications, I would rather choose the XML just to get XSL-HTML views.
Nevertheless, these files should be hidden from the user, so there is no harm for a developer to have multiple choices. Takes what fits best your taste.
The registry sounds to much Windows-specific, dirty and dangerous to me, especially with growing parameters. What about user-specific preferences? Would create a weird depp tree...
Eric
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
