Re: Ini File vs Registry

See below...
On Sat, 20 Sep 2008 21:14:21 -0700, "David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:k4bbd4dn0vujgoje7qpiset4d2seuqbqk6@xxxxxxxxxx
By the way, where do you keep the configuration file on the USB device?
Certainly it
should not be in the executable directory, because then it is global to
all users. So how
DO you arrange for per-user customizations? For example, assume the key
is available to
several users who might each want their own settings, rather than being in
the posession
of a single individual. How do you manage the settings?

You could easily store config file in the executable directory, just embed
the user's login name into the filename, and presto, you have per user
configuration in the same directory.
****
Not in Vista or XP. Generally the executable directory is protected. So this solution
has a serious failure if the program is installed on a hard drive in any site that has the
slightest concept of "security"
****


But where would you store the data, and how would you store it? And why
is virtualization
of the Registry by a system a bad solution? Soounds like it solves the
problems I just
described, by having per-user settings.

You're kidding, right? Yeah, it's not a bad solution to invest thousands of
dollars in hacking the OS to introduce the concept of registry
virtualization just to humor a bad decision to save app settings into a
per-machine structure (the registry) that have no business being there in
the first place.
****
Why do you think the values are *not* per-machine? In fact, that is usually the case. I
don't use the same settings on my laptop as I do on my desktop (different screen geometry
and different usage patterns, for example, dictate different font sizes, different screen
layouts, etc.). In fact, I've found that almost always the settings are per-machine,
*especially* in our customer products (a failure mode: the serial port was configurable by
the user, but on one machine it was COM1 and another it was COM3, and I *had* done a
portable configuration file! This was clearly the WRONG decision in such a case)
****


You could more constructively argue that the
Registry needs virtualized hives that can be on other devices, which is a
much more
compelling argument than saying it should not be used at all.


Virtualized hive == single file. That's the easy way.


It sounds like you are saying that because you don't like the Registry, no
one should use
the Registry, because it doesn't solve one particular problem which is
generally
unintersting to solve for nearly all products nearly all the time.

It's only uninteresting because you continue to embrace the concepts that
give "thick client" a bad name. No XCopy deployment. Hard to migrate app
settings. Maybe your clients of mass spectrometers and what not don't care
about such things, but increasingly desktop developers are fighting it out
with web apps and their no-install worries propositions. I don't know about
you, but I think web development sucks. I don't want to be a web developer,
I want to stay on the desktop. So it is to our advantage as desktop
developers to mitigate the advantages of web apps over desktop apps, which
means: XCOPY deployment and easy app setting migration, as well as a bunch
of other things designed to lower the cost of ownership and management.
Perpetuating this monolith called the registry is at odds with that and not
in our best interest as thick client developers.
****
My customer base wants install programs, and in fact really doesn't want XCOPY deployment.
They feel very strongly about deliberately not supporting that. We've had very few
requests to migrate app settings, and the few times we actually anticipated this and did
migratable app settings, it turns out that they caused us more tech support calls than we
wanted to deal with (yes, really).

Web apps are interesting, but they are not where I work. And where would I store the
settings for a Web app anyway? At that level, a configuration file is no different than
the Registry...if I store it in user\appdata or the Registry, the effects are the same,
but it takes more work to create user configuration files in user\appdata.

Migratable app settings generated problems with getting the file in the right place, not
overwriting a file that was already there, *merging* settings between two files, deciding
which settings were per-user and which were per-machine (example: the COM port selection
in one app was per-machine but in another context it was per-user-per-machine, where each
user coming in over terminal services got a different COM port but if they used it on a
different server it required a different COM port...and yes, we had more phone calls and
redesigns on that one issue than was worthwhile! Copy the settings file from the server
to your machine and the program failed; copy your local settings to the server, the
program failed, and naming the settings as [user.machine] ended up generating truly
MASSIVE .INI files with lots of problems about if you changed the settings on machine 1
did the setting change for machine 2, or SHOULD it, and it turns out that each site had
different requirements as to which settings changed this way...we ended up ripping the
code out and putting it in the Registry, with Export and Import functions).

You can't use XCOPY deployment on licensed software unless it also carries the license key
with it, and that's something that virtually all of my customer base is not willing to
accept. They want a very specific install scenario that deals with licensing; I don't
write this code, but their (third-party) install packages work this way. So I don't see
reasons to solve problems that my client base does not want me to spend time solving.
joe
****

-- David

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Disadvantages to peristing replication settings as text?
    ... I'd actually have the mobile app include a "settings" ... in the registry. ... derived the encryption algorithm. ...
    (microsoft.public.sqlserver.ce)
  • Re: Vista makes me crazy, please help.
    ... It's hardly complex to have the filename or the section name contain the user ID if that's necessary or to place the INI under the user's app data folders. ... The overhead of the registry index structure cuts into that but even if it still saves space it is a small advantage that is utterly swamped by the advantages of the individual files. ... There is some buffering on INI files as well and unless you are doing a LOT of reading and writing settings the speed just is not an issue. ...
    (microsoft.public.vb.general.discussion)
  • RE: Reg/INI Discussion from much earlier
    ... If it takes a noticable time to save the configuration data, you've either written the app wrong, or defined configuration data wrong. ... > in the event of an improper shutdown, the registry is NOT saved. ... > uncontrolable factor and the user wants to save his/her settings. ...
    (microsoft.public.vb.general.discussion)
  • Re: Ini File vs Registry
    ... How do you manage the settings? ... dollars in hacking the OS to introduce the concept of registry ... Hard to migrate app ... but increasingly desktop developers are fighting it out ...
    (microsoft.public.vc.mfc)
  • Re: Deployment + Vista
    ... In my apps, they have a Server ... it's a good thing I do not use that for settings. ... In any event, when the app starts up for the first time, it checks for the ... then construct a string on the fly. ...
    (microsoft.public.dotnet.framework.adonet)