Re: Ini File vs Registry
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:ijcfd41lmd7dp4nvucnjgftc90q2edgtt4@4ax.com...
Well, all the manuals I deliver tell the user what the Registry keys are..
That's like pointing to 2 point type at the bottom of a contract and saying,
"see I told you I did that." No one cares about that. They do care when
their registries fill up with crap though.
How do you "delete" an app by deleting only its folder? The folder is
protected, in any
sanely administered sytem, so the executable cannot be modified (only
admin rights allow
modification of the folder) nor any other files, so the data *has* to be
stored somewhere
else. So you have to deal with the appdata or documents folders as well,
anyway. Why is
the Registry different?
There really is a reason for "uninstall" programs. Believing that we are
living in a
1960s world as we approach 2010 is unrealistic. So the concept of a
single, monolithic
.exe file as being the sole source of the executable code doesn't hold up
under modern
practice. The notion of shared DLLs can be critical to th design and
deployment of many
apps. Should I give up this idea, too?
Shared DLL's for one application is fine. That's what AppLocal deployment
is, that's what Registration-Free COM is, and yes, both are tremendous
breakthroughs to support putting everything in one folder.
Except for the issue of the effort to get it right.
Most apps read their settings on startup (in the GUI thread), write them
when the user changes them via the Settings dialog (in the GUI thread),
and/or when the app exits (in the GUI thread). We don't have to reinvent a
fault tolerant, or even thread-safe database here.
-- David