Store settings in INI instead of registry
Store settings in INI instead of registry
It would be very nice if the settings were stored in an ini,xml or whatever file instead of the registry because FAR could be used as a portable application. So we could use it on machines where there aren't rights to change the registry. PLZ change this.
Re: Store settings in INI instead of registry
I always thought that would be a good idea too. While the batch files SaveSettings and RestoreSettings are wonderful, an .ini file would certainly cure the "insufficient rights" problem.TCA wrote:It would be very nice if the settings were stored in an ini,xml or whatever file instead of the registry because FAR could be used as a portable application. So we could use it on machines where there aren't rights to change the registry.
I personally find INI files much better than the Windows Registry, because they make applications easy to move, simpler to configure, and do not require a cumbersome/uncomfortable editor to edit. In fact, I don't think we ought to defend why INI files are better; I think others have to defend why the Windows Registry is better and I'm still waiting for a good reason.
Oh my god. Stone age is back!
Registry is better in just about ANY objective view, because:
- Performance. Reading 100+ entries from an unsorted textfile plus parsing strings to numbers (for integer entries) costs a lot of CPU. Yes, even today when so many settings need to be loaded (and FAR does load a lot!). Writing is even much more worse: You will need to read the entire text file to know a) is the entry already there, b) is the caption at least already there or c) is appending enough. For EVERY setting that is. The registry is an indexed database. You don't need to be a good programmer to understand why this by far outruns any textbased format.
- Clear definition of what is user-level, what is system-level. Especially great in domains. And: Saving INI files or anything in the program file dir is a no-do anyway - users should never be able to write to program files. Unix/Linux doesn't do it, for a good reason, it was a bad idea in DOS/Windows to even start with that.
- Easy to explain to a novice user (yes!), because its the same on every system. The path is EXACTLY the same, no need to do explain a) where the program might be (because that is selectable), b) where the documents and settings folder is (that is dependand on system drive selection, operating system, update path (Win2000 saves it somewhere else when being installed fresh than when updating from NT), and system language.
- Can be automated REALLY easy. Just post a REG file with the settings you want the user to merge. Yes, MERGE. Something that is not easily possible at all with INI files.
- Can be automated really easy in networks in many ways, each of them easy - group policies, login scripts.
- And: Yes, it can be backed up, restored and whatever you want, you just need to learn how. You needed to learn it for the INI file, so I don't see an advantage on an INI file here. And FAR even provides two batch files which do exactly that!! Make a batch file which automatically restores settings from a .reg (which is INI file format by the way, so you could do your editing there ), run FAR and update the REG afterwards and you could easily do a mobile FAR thing there doing that all on an USB stick.
- And: You have a good enough editor. I mean come on, you don't think its "easy" and not "cumbersome" to edit an INI file, where finding out whether a specific setting is in the correct caption.
XML file? Even worse. You can also use atom bombs to kill a bird.
- Even slower.
- Even more complex to learn for the user, because you can easily invalidate its integrity.
- XML is perfect for data swapping. With what application would you want to swap FAR settings!?
XML is a great thing, don't get me wrong, but it isn't the killa-thing for everything. Using it to save application settings is a total abuse.
@Wiseman: Now to you ... Why would we have to defend the Registry, if a) its the (wise) choice by the FAR team? If you would want it differently than them then OF COURSE its your turn to prove that INI is better. Good luck. b) its the recommended and standard way on Windows since Windows NT 3.1 (1993) and Windows 95 (1995). Come on, even you should have had enough time to get used to REGEDIT, its not that hard, and when you don't stick so on that legacy stuff you might even come to the conclusion that it is by far advanced. No, really ...
FAR runs absolutely perfect on systems where you have no admin rights. *Because* they use the registry, more specifically in the right way (using HKEY_CURRENT_USER, which is *made* for user settings, you should be able to figure that out just by reading the word "HKEY_CURRENT_USER" ).
Registry is better in just about ANY objective view, because:
- Performance. Reading 100+ entries from an unsorted textfile plus parsing strings to numbers (for integer entries) costs a lot of CPU. Yes, even today when so many settings need to be loaded (and FAR does load a lot!). Writing is even much more worse: You will need to read the entire text file to know a) is the entry already there, b) is the caption at least already there or c) is appending enough. For EVERY setting that is. The registry is an indexed database. You don't need to be a good programmer to understand why this by far outruns any textbased format.
- Clear definition of what is user-level, what is system-level. Especially great in domains. And: Saving INI files or anything in the program file dir is a no-do anyway - users should never be able to write to program files. Unix/Linux doesn't do it, for a good reason, it was a bad idea in DOS/Windows to even start with that.
- Easy to explain to a novice user (yes!), because its the same on every system. The path is EXACTLY the same, no need to do explain a) where the program might be (because that is selectable), b) where the documents and settings folder is (that is dependand on system drive selection, operating system, update path (Win2000 saves it somewhere else when being installed fresh than when updating from NT), and system language.
- Can be automated REALLY easy. Just post a REG file with the settings you want the user to merge. Yes, MERGE. Something that is not easily possible at all with INI files.
- Can be automated really easy in networks in many ways, each of them easy - group policies, login scripts.
- And: Yes, it can be backed up, restored and whatever you want, you just need to learn how. You needed to learn it for the INI file, so I don't see an advantage on an INI file here. And FAR even provides two batch files which do exactly that!! Make a batch file which automatically restores settings from a .reg (which is INI file format by the way, so you could do your editing there ), run FAR and update the REG afterwards and you could easily do a mobile FAR thing there doing that all on an USB stick.
- And: You have a good enough editor. I mean come on, you don't think its "easy" and not "cumbersome" to edit an INI file, where finding out whether a specific setting is in the correct caption.
XML file? Even worse. You can also use atom bombs to kill a bird.
- Even slower.
- Even more complex to learn for the user, because you can easily invalidate its integrity.
- XML is perfect for data swapping. With what application would you want to swap FAR settings!?
XML is a great thing, don't get me wrong, but it isn't the killa-thing for everything. Using it to save application settings is a total abuse.
@Wiseman: Now to you ... Why would we have to defend the Registry, if a) its the (wise) choice by the FAR team? If you would want it differently than them then OF COURSE its your turn to prove that INI is better. Good luck. b) its the recommended and standard way on Windows since Windows NT 3.1 (1993) and Windows 95 (1995). Come on, even you should have had enough time to get used to REGEDIT, its not that hard, and when you don't stick so on that legacy stuff you might even come to the conclusion that it is by far advanced. No, really ...
Why would a user not have rights on its own HKEY_CURRENT_USER key? That is simply not true!So we could use it on machines where there aren't rights to change the registry.
FAR runs absolutely perfect on systems where you have no admin rights. *Because* they use the registry, more specifically in the right way (using HKEY_CURRENT_USER, which is *made* for user settings, you should be able to figure that out just by reading the word "HKEY_CURRENT_USER" ).
Re: Store settings in INI instead of registry
I've tried with this registry wrapper (Registry Rapper 1.8.0.0)... and it works just fine!TCA wrote:It would be very nice if the settings were stored in an ini,xml or whatever file instead of the registry because FAR could be used as a portable application. So we could use it on machines where there aren't rights to change the registry. PLZ change this.
http://portasoft.org/e107/download.php?view.4
Registry Rapper is a template for allowing the use of programs that save their settings to the reigstry as portable applications. First it will check the registry for settings of the program and then save them if present. Then it will write the settings for the program to the registry, run the program and then rewrite the registry settings to a file for later use. it will then delete the settings from the registry; removing any trace of the program. Finally rewritting the original current local settings back to the registry.
This program is a registry encapsulation program, which takes care of all the registry settings a program might need to run and make sure nothing is left behind on the host system. Allowing programs that were not created as portable (i.e saving their settings to .ini files within the program folder) to be used as portable.
NOTE: For some reason, the Mcafee Antivrus program belives there is a virus within the registry Rapper program zip file. This is NOT correct. This is a false positive possibly due to the nature of the example program. I will look into it and find a reason. However, this file has NO virus within it, and is safe
Yes, it IS a problem.I would like to see FAR as portable application. Performance is not a problem in because loading and storing INI or even XML is done only at startup/exit and save options.
I certainly don't want to wait for FAR just because it loads of some stupid text file.
You seem to totally underestimate what it means to load ~200 settings at startup. Maybe you should try it out before you state something like that.
And you can make it easily portable, if you simply use a batch file that imports your settings into HKCU, loads FAR then and exports it afterwards.
Now this would be a totally exceptable way to solve the problems for all parties.It could be made optional - I mean XML settings could be specified from command line if necessary. I remember I had some codepiece for converting between XML and registry formats.
Media Player Classic by the way did this (with INI instead of XML however) and it works good there. It's great and flexible for every situation.
Halo man, so tell me how do you import reg files into the registry, if you don't have the rigthts to modify the registry? At least an option would be great, so everybody could decide himself, if he wants ini or registry. And don't tell me that is is sooooooo slow, because there are lots of programs that stores their preferences this way, and they aren't slow. (Media Player Classic is a good example)
Lofote: believe me, there are places, where you can't add new entries to HKEY_CURRENT_USER, AND if you ever looked at SaveSettings.bat you should've seen that not HKCU is the only place where FAR stores things.
Lofote: believe me, there are places, where you can't add new entries to HKEY_CURRENT_USER, AND if you ever looked at SaveSettings.bat you should've seen that not HKCU is the only place where FAR stores things.
As I already said, yes, that would be a totally acceptable thing.At least an option would be great, so everybody could decide himself, if he wants ini or registry.
Media Player Classic is a bad example, simply because it has a lot less to save there. Just compare the number of entries with FAR: For example very time you enter something in a dialog, 99 entries within HKEY_CURRENT_USER\Software\Far\SavedDialogHistory\SearchText are changed. You *would* experience this delay every single time a dialog is used, believe me.And don't tell me that is is sooooooo slow, because there are lots of programs that stores their preferences this way, and they aren't slow. (Media Player Classic is a good example)
You can't compare the brakes of a bicycle with that of a Ferrari, ya know .
Yes, HKCU\Software Policies for example. And no, FAR does not save anything there.believe me, there are places, where you can't add new entries to HKEY_CURRENT_USER
HKCU\Software\Far is writable for everybody. Even for guest users (their settings are just resetted after logoff).
Next to nothing is saved in HKLM\Software\Far. (The license key is stored there, which is ok, since you license Far per computer not per user.) So you can "REM" out the line in LoadSettings.bat without loss.you should've seen that not HKCU is the only place where FAR stores things.