JimWilson
Just checked contents of my FarSave1.reg:
~10.5 k lines — Colors\Highlight
~4.0 k lines — KeyMacros
~2.5 k lines — Plugins
~1.5 k lines — PluginsCache
~3.5 k lines — SavedDialogHistory
24 - ( 10.5 + 4.0 + 2.5 + 1.5 + 3.5 ) = 2
What's “unused crap” there?
Store settings in INI instead of registry
It needs to be done only once and store it in memory. 200k memory overhead is nothing and if you strip all history information (which you won't probably need on a portable version) in could be even less than 50k. What could be faster than memory?Lofote wrote: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 ...
When I come to help some user who messed his system I'd prefer to launch Far with my config file and my shortcuts avoiding messing with user's registry and his personal tastes. I do not care where it will be stored - just give me a possibility to launch it from command line. I also do not want to import/export my registry to his machine, because it contains passwords.Lofote wrote: - 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.
Well, the path to application data is always %APPDATA% and I agree with you that saving config somewhere in secret folder system-wide and using it is a bad practice, because in case of problems even reinstall may not help. But the registry is no better in this case.Lofote wrote: - 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.
XML is better automated and FILTERED anyway. Try to exclude your private details and passwords from your .REG In case of XML - use XSLT or any script language you would like. If you have a list of private keys in another XML future maintenance is a breeze.Lofote wrote: - 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.
MS platform enforcement has its positive benefits, but most prefer own personalized settings.Lofote wrote: - Can be automated really easy in networks in many ways, each of them easy - group policies, login scripts.
Two weeks ago I had my system crashed. I was able to retrieve all my documents from HDD, but, unfortunately, forgot to backup Far registry. Now I am tuning Far anew.Lofote wrote: - 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.
Have you tried to edit Far registry file with Far? Sometimes there is a little problem - the file is in Unicode.Lofote wrote: - 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 should be an intermediate format. Using it you will be able to provide several means for manipulating Far settings exporting it in suitable format and importing it back. This, of course, will not be as straightforward as .ini or registry, and therefore will be a little complicated.Lofote wrote: 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.
If somebody give me an injector intercepting Far calls registry calls to HKCU/Software/Far and exporting them as callback API, then it will not be hard to make DLL serialization of Far settings in either .INI or .XML files.pepak wrote:I take it this suggestion/topic is dead, isn't it? I still think my "plugin" approach would solve it nicely for both sides of the issue
The list of functions that should be intercepted:
RegDeleteKeyA
RegCreateKeyExA
RegSetValueExA
RegDeleteValueA
RegQueryValueA
RegOpenKeyA
RegEnumKeyExA
RegOpenKeyExA
RegQueryValueExA
RegCloseKey
RegEnumValueA
It is my understanding that this is very nearly impossible to do from the outside, unless you have administrator privileges and use hacking techniques. I would expect that it would be much easier if done by the developers rather than us outsiders.techie wrote:If somebody give me an injector intercepting Far calls registry callspepak wrote:I take it this suggestion/topic is dead, isn't it? I still think my "plugin" approach would solve it nicely for both sides of the issue :-(
A bit late but ...
Well, actually if someone is still interested there are some good places to look for api hooking samples. I'm not allowed to post urls because a restriction on the forum for new users.
Let me know if anyone is still looking for this.
Regards,
Mike
Let me know if anyone is still looking for this.
Regards,
Mike