REASONS not TO USE THE REGISTRY
and TIPS N TRIKS ON HOW TO SET
THINGS UP INSTEAD
(all from Delphi elists.org user group, re use of the registry and 'SECURITY')
****************************************************************************************
Thanks for the suggestion. Yes, I'm sure there are places under the
Windows directory to store individual user profiles -- just as there are in the
Windows Registry. I don't want to use them though: the point emphasized by
such contributors to the "tips/tricks/techniques" thread of a few days back as
Kerry Neighbour, Todd Lang and Jim Burns is that it's well to stay clear of both
the Registry and the Windows directories. One analogy I especially liked (it
happened my own spot had been stolen that morning) is that the application
should be self contained and should "use its own parking space" instead of
barging in somewhere it doesn't belong.
There are plenty of ways to skin this cat. One could have subdirectories or
uniquely named files or table entries or what you will contained within the
application's directory or on individual users' PCs. I was just hoping
someone might already have invented this particular variation on The Wheel.
****************************************************************************************
>'in a networked environment (where several users are working
>with the same intranet-based application, as this is what I am
>beginning to work on now) will there not be potential problems
>with network file-locking when INI files are used for security and
>configuration..?'
Sure - the easiest way is to put them in the Windows directory. Even with
shared profiles or networked installation on Windows, there is always a
separate Windows directory for every user. ie
function getwindir: string;
var
X: WORD;
buf: Pchar;
begin
Getmem(buf, 500);
X := GetWindowsDirectory(buf, 500);
getwindir := StrPas(buf);
Freemem(buf, 500);
end;
I don't particularly like this solution either - as people often remove
Windows and re-install it. So I always check for the existance of this
file, and if not their, I generate it with all the default values. This
will delete any registration codes you might be saving there though.
A better option (I think) is to generate a separate user directory under
the application dir, and store the INI file in there. Or to name the INI
file after the user ie SimViews_PETER.INI. The name you would get off
the Computer Name.
I certainly would not use one file (in the application dir) for everyone.
It is unlikely that you would get file locks as the INI file is usually
only in use for very short periods. But you need to keep separate option
for each user generally.
But honestly, as much as I HATE putting things in the Windows directories,
I find that this is generally the easiest thing to do (we have to be
practical, after all).
-- Kerry Neighbour, kneighbour@simcomcity.com on 2/10/2000
********************************************************************************
> Further to saving multiple user INI files: How do I determine the current
> network user name?
I do it this way:
VAR
Temp : PChar;
Count : cardinal;
begin
Count := 0;
GetUserName(nil,Count);
Temp := StrAlloc(Count);
GetUserName(Temp, Count);
UserName := StrPas(Temp);
StrDispose(Temp);
end;
****************************************************************************************
PS - We do not use the BDE. We are using ADO so we never
need a program install. Just a copy from test folder to the
production folder.
However, there can be issues with ADO, so you should probably distribute
the MDACTYP update file with your application. But, if ADO is working,
your application is highly mobile on that machine. Drop it here, drop it there,
everything works!
Todd Lang
****************************************************************************************
"We place our program (EXE) and settings file (INI) on a network drive. (We
don't use the registry, which tends to make a number of scenarios well-nigh
impossible to implement). The users have read capabilities to the folder. We
create a NAL script to place a short cut on every desk top that belongs to the
appropriate group. When the user logs in to the Network, the NAL runs and a
few seconds later, the program is available to the user. We can update the EXE
and/or INI file and all users are using the new software. Our support and
maintenance is almost nil by doing things this way.
PS - We do not use the BDE. We are using ADO so we never need a program
install. Just a copy from test folder to the production folder".
"*EVERYTHING* that you can store in the registry can just as easily
be stored in a configuration file in the same directory as your program. And
people appreciate a program that actually *completely* disappears when you
uninstall it. And uninstalling it can be as simple as deleting the directory it
comes in".
"Absolutely. I could not agree more. This is our firm company policy (set
by me) and it is strictly enforced. And for all the reasons you state. I am glad that
others think the same way".
****************************************************************************************
kneighbour@simcomcity.com
Dear Kerry
hope it's OK mailing you direct re an issue that has cropped
up a lot lately on Delphi@elists.org (re use of the registry...)
I tend to agree with you that where possible one should use
INI files... INI files are cool, they are simpler to use, more
maintenance free, they don't clutter up the user's registry
with stuff, they can be easily 'uninstalled' (ie removed/deleted)
etc etc (and some people seem to get carried away with what
seems almost to be a 'macho' approach with regard to using
the registry)...
BUT
my experience (so far) has been with applications that exist
in a simple (non-networked) environment, so my question is
'in a networked environment (where several users are working
with the same intranet-based application, as this is what I am
beginning to work on now) will there not be potential problems
with network file-locking when INI files are used for security and
configuration..?'
any feedback on this would be much appreciated
****************************************************************************************
Jim Burns wrote:
> Absolutely. I've argued time and again that we should remain consistent.
> After all, it makes little sense to develop our software to take advantage
> of OO design principles and then break them to store our garbage across the
> system, in my case, on a completely different hard drive, where they're
> completely out of scope. Do our OO principles hold or not?
I've always opposed registry and similar techniques. However, and I may
be repeating what I have written before, there still may be exceptions
and I don't think you always have to be so strict. Right now I can think
of two exceptions which I think are acceptable:
1) The Borland Shared subdirectory in the Program Files folder. I think
storing the BDE, common glyphs and other stuff that is common to more of
their development tools there is fine
2) On network multi-user system, the app may store settings into the
user's own disk space. This is how it works on UNIX systems and I think
it proved itself a good idea. Even in the windows world it can be still
so. I know an organization where all users login into the NT
workstations as guest and almost everything is read-only for them. OTOH
everyone has his/her own Novell user account and some disk space on the
fileserver of their own. Applications have almost no chance to store
settings (or anything else) into their own directories on the local NT
disks. Those applications which are able to store settings on the user
diskspace are most user friendly. Moreover, when you think about it, you
find out this approach is also quite secure.
The disadvantage is uninstallation which is no longer trivial. On the
contrary, these systems usually have a network administrator who should
be able to handle this task.
HTH
****************************************************************************************
> One analogy I especially liked (it
> happened my own
> spot had been stolen that morning) is that the application should be self
> contained and should "use its own parking space" instead of barging in
> somewhere it doesn't belong.
Absolutely. I've argued time and again that we should remain consistent.
After all, it makes little sense to develop our software to take advantage
of OO design principles and then break them to store our garbage across the
system, in my case, on a completely different hard drive, where they're
completely out of scope. Do our OO principles hold or not?
> There are plenty of ways to skin this cat. One could have
> subdirectories or
> uniquely named files or table entries or what you will contained
> within the
> application's directory or on individual users' PCs. I was just hoping
> someone might already have invented this particular variation on
> The Wheel.
Ok, so you're there and you're asking the right questions. As you see there
are many answers. In keeping with OOP, the nice thing is once you develop
the answer, if you DID hold true to OOD you'll find that answer pops quickly
into place in every project.
You are correct in that the registry does provide, what I like to call, the
"poor man's multi-user" capability. Consider also that this isn't always so
straightforwardly an advantage. For example, I run in 1600x1200 and when I
need to jump to a lower resolution to test something or whatever, I don't
risk my desktop setup on my normal login so I relogin as another user.
However, the poor man's multi-user capability usually means I have a number
of hurdles to jump through when I login as another user if I want to run
some applications that provide different configurations based on user (like
Delphi). Sure, Delphi provides a way to do a pseudo-install and only
rebuild the registry entries. But this is foolish. For one, I must
remember all the installation choices? Did I install the Interbase client?
Did I install the Database Desktop? No, this is silly, and is yet another
example of taking a shortcut that doesn't really prove helpful in the real
world. Try this with something as horrendous as Office and life really
starts to get stressful!
After all, why bother with this hassle when you can simply export the entire
borland registry key and under the other user, with one double-click, import
it completely and be done with it? D'oh! :)
Better the application keep the information it needs to itself to manage and
maintain, and leave the OS to it's own business. It's questionable whether
or not the OS can handle it's job anyway right! :)
****************************************************************************************
What I've been doing is setting up a user-list dat file, loading them into
a stringlist and setting them this way. I can do this with one dat file no
matter how many users. I've always hated the idea of the Registry for
anything application specific!
Several contributors to the "need tips/tricks/techniques for debugging"
thread have explained compelling reasons (popular components -- and Delphi
help files -- to the contrary) for not storing configuration information in
the Windows registry. I'm convinced. I offer one obvious reason why this
practice has become so prevalent: an application on a network, with multiple
users on multiple PCs, each of them setting their own configuration
preferences, will obviously need to store multiple sets of user settings.
It's tempting to use the Registry because it's there, guaranteed present on
every user's PC, rather than code for storage locations for multiple users'
INI files.
Which brings me to my question: does anyone have components/techniques for
managing such sets of configuration information? There are several around
for loading/saving component properties to INI files (or ;-> to the
Registry) -- IniOut and RxLib's FormStorage are two such -- but they don't
address the issue of keeping multiple configurations separate. It can be a
bit of an uphill battle, especially since the TIniFile assumes unless told
otherwise that INI files are to be found in the Windows directory -- another
place for well-behaved applications to stay clear of.
****************************************************************************************
Rich
Ofcourse if the registry became corrupted and you had a
network situation or otherwise for your program, many other
programs would be screwed also, perhaps even the kernel
so once the registry is corrupted, then not being able to run
our system would be the least of our customers' worries. Yes?
And the network file locking issue, i've experienced exactly that.
I saw massive systems built around the scheme those guys
are hailing as excellent and until the day i left it was fatally flawed
due to the locking of a network ini, 'fragment.ini' it was called and
users constantly rang about not being able to start the system.
Our support teams then had to say, 'Oh, just try again' of course by
then the system started ok as the simultaneous problem had gone
but of course support resources had by then been employed. The money
the company put into that prob was unbelievable - due to bad system
design i thought.
Seriously, if i'm wrong then seniority does not come into it, but
i'm right Rich.
Remember this one, it will serve you well. Network file locking - its a swine!!
The days of ini files are numbered on systems such as Seneca - honest.