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