Foxmail problem

[Jeff Needle]

On the Pricelessware website there is a note about Foxmail that it is a
no-install program. I like that.

But someone in the support forum for Foxmail indicated that it makes
changes to the system registry. If Foxmail is no-install, why are there
changes being made to the registry?

 

[Azzman]

On the Pricelessware website there is a note about Foxmail that it is
a no-install program. I like that.

But someone in the support forum for Foxmail indicated that it makes
changes to the system registry. If Foxmail is no-install, why are
there changes being made to the registry?

Probably to save it's settings. I prefer that a no-install writes it's
settings to an ini-file. But for example the no-install programs from Pablo
van der Meer:
http://www.pablosoftwaresolutions.com/
also write their settings to the registry.

 

[Jeff Needle]

Probably to save it's settings. I prefer that a no-install writes it's
settings to an ini-file. But for example the no-install programs from
Pablo
van der Meer:
http://www.pablosoftwaresolutions.com/
also write their settings to the registry.

I prefer that the settings are saved in its own folder, too. Too bad,
it's a pretty good program.

 

[old jon]

I prefer that the settings are saved in its own folder, too. Too bad,
it's a pretty good program.

With the large size of modern H\drives, there`s no reason why programs
should have to write to the registry.
They could all be accomodated within their own folder.
They can easily call any common .DLLs they need from the system.

 

[Susan Bugher]

I prefer that the settings are saved in its own folder, too. Too bad,
it's a pretty good program.

Just an FYI about the ACF program info pages - the apps that are labeled
(n.r.) don't make entries in the registry. The (n.i.) (n.r.) notes are a
bit hit and miss - as many authors don't note that info on their web
pages (I usually glean the (n.r.) info from posts to ACF). IOW - absence
of a (n.r.) notation does NOT necessarily mean the app does write to the
registry.

I hope the above explanation is clear. . .

Susan
--
Posted to alt.comp.freeware
Search alt.comp.freeware (or read it online):
http://www.google.com/advanced_group_search?q=+group:alt.comp.freeware
Pricelessware & ACF: http://www.pricelesswarehome.org
Pricelessware: http://www.pricelessware.org (not maintained)

 

[Luis Cobian]

With the large size of modern H\drives, there`s no reason why programs
should have to write to the registry.

Oh believe me, there are. Lots of reasons.

 

[Spacey Spade]

Hi Susan! I don't know how you make time for this, but I'm sure glad
you are with us.

And now on with the regularly scheduled program:

For those pesky, naughty programs that save their settings to the
registry...
Once you have all the settings the way you want them, you can export
the settings from the registry and save it in the folder you have your
program (hopefully not on the same drive you have the operating system
on). That way when you format the OS drive, or copy the program to
another puter, you don't lose all your settings.

Spacey

 

[Luis Cobian]

That way when you format the OS drive, or copy the program to

another puter, you don't lose all your settings.

This is a good idea that every program should implement. You can also of
course export the registry key and import it next time you install your
program/os.

You see, the problem here is that the registry offers toooo maaany
advantages in comparation to plain ini files that it's just not funny (per
user security permisions and settings being the main advantage, but don't
forget about multiple instances and multithreading access to the same
settings at the same time, to just mention a few). The only disadvantage is
the one you mention, but it can be easily solved by exporting the key or if
the program have an exporting function. But anyway, thanx god for the
registry.

 

[old jon]

Oh believe me, there are. Lots of reasons.

And they are ?. Please Luis.

 

[Luis Cobian]

And they are ?. Please Luis.

Oh, I have replied with some of the reasons in another post, but here we go:

1) Security. Imagine your program is shared by 5 users that use your
computer. Your wife have some settings, but you like some others. The kinds
use some other settings. The program needs a way to separate the settings
for every user. Sure , this can be implemented using ini files but: if you
use only a ini file, then you have no security at all. If an user deletes
the file, all the settings of all users are gone. If you store important
settings or passwords, then some user could maliciously delete or change
those settings. Using the registry makes this automagically easy: use the
key

HKEY_CURRENT_USER\Software

No other user than you (or of course, root) can access this key. They cannot
even read it.

2) Multithreading issues. Supose you have yor settings in an ini file. Your
program span several threads or, say, several instances of itselve. Supose
thet all the instances modify some settings and they need to write them to
the ini file. Sure, you can use mutexes or WaitForSingleObject to
synchronize, but, why? The registry is a database. Thread safe. End of the
story. You can have 100 instances reading/writing to the registry at the
same time. No problem, the registry handles this. And way more.

3) Flexibility. An ini file can store, well, strings. The registry can store
Ansi strings, unicode strings, binary objects, you name it.

4) Speed: The registry is always in memory. Accessing a registry key is
musch faster than accessing the dis, loading the ini file and parsing it.

Yes, everything can be done using ini files too, but it is a lot more work.
I use myself ini files sometimes, but only if I have plans to port some
program to some other OS, otherwise, I often use the registry.

 

[old jon]

Thanks Luis.
I accept the multi-user point of view.
There were no such problems back in the good old Amiga days.

 

[Thomas Lauer]

[snipped a few good reasons to use the Windows registry]

I agree with what you wrote... but most of your reasons have more to do
with making life simple for programmers than making the app easier to
use.

Let's face it: for every hour a programmer spends on an app there are
thousands, if not millions of user hours (assuming a reasonably
successful app). This aspect is all too often overlooked.

And the killer advantage of separate INI files (for me in user mode, not
in programming mode) is that it can be make apps portable. This
consideration overrides all other points (again, my opinion).

 

[Luis Cobian]

I agree with what you wrote... but most of your reasons have more to do
with making life simple for programmers than making the app easier to
use.

Yes, of course. The **average** user should not even care about where the
program is saving the settings.

And the killer advantage of separate INI files (for me in user mode, not
in programming mode) is that it can be make apps portable. This
consideration overrides all other points (again, my opinion).

I agree, but like I said, every program should have an "Export
settings/Import settings" function to have the best of both worlds. A
wonderful example of this is the brilliant mail program "The bat!" which
have such an option.

Anyway, both methods have their good and bad sides, like always. The thing
that matters is how it is implemented.


Regards

 

[Thomas Lauer]

I agree, but like I said, every program should have an "Export
settings/Import settings" function to have the best of both worlds.

.... plus a third option to *completely* delete all entries it imported
into the registry!

 

[Renan]

grep Thomas Lauer:

I agree with what you wrote... but most of your reasons have more to do
with making life simple for programmers than making the app easier to
use.

Making the programmer's life simpler results in better programs, IMHO.
AIUI (I'm no programmer, engineer, computer scientist or whatever,
though I have done some programming), it is faster to access a
'database' like the registry, for large data amounts (or anybody wants
to make a megabyte-sized DB in text files?).

 

[David]

grep Thomas Lauer:

Making the programmer's life simpler results in better programs, IMHO.
AIUI (I'm no programmer, engineer, computer scientist or whatever,
though I have done some programming), it is faster to access a
'database' like the registry, for large data amounts (or anybody wants
to make a megabyte-sized DB in text files?).

You are correct if the data is actually stored in memory but you are
ignoring the memory requirements needed to store such a humungous
amount of data especially when most of it is not needed until a
program is actually invoked. I have programs that write data into the
registry yet I would only use those programs occasionally.

Starting a program and reading an ini file as it is invoked utilises
less memory and once the program is closed the memory from the ini
data can/should be released. The only data that need to be in memory,
in my opinion, would be the file-type/called-program information. Even
that is/was stored mainly in an ini file by Windows, at least up until
W98.

The risk of corruption of the single registry file is greater than the
risk of corrupting multiple ini files. Lose your registry and you can
be faced with reinstalling multiple programs. Lose an ini file and you
only have one program that needs to be reinstalled.

I do not agree that using the registry makes life easier for the
programmer and it certainly makes life harder for the end users who
have to pay for the upgrades required to store that data in memory. Of
course often the registry data is written to the swap file so you are
not saving any time by not using an ini file.

 

[Thomas Lauer]

I do not agree that using the registry makes life easier for the
programmer and it certainly makes life harder for the end users who
have to pay for the upgrades required to store that data in memory. Of
course often the registry data is written to the swap file so you are
not saving any time by not using an ini file.

I think you're right. When the registry in its current form was first
mooted, in the early 90s, I was a big fan. But over the years I have
seen that the disadvantages outweigh the advantages.

Today I think the only valid reason to use the registry is for stuff
that has to do with system integration. All the rest should be done
locally.

And given the prevalence of cheap GB-sized USB sticks, we will see the
registry in its current form wither. (I hope.)

 

[Thomas Lauer]

grep Thomas Lauer:

Making the programmer's life simpler results in better programs, IMHO.

That's far too general a remark. API design (balancing ease of use for
programmers and raw power) is a difficult job and M$ learned it while on
the job. (Some people would doubt that M$ learned anything but I think
compared to the early days of Win16 APIs we have now a decently
structured API.)

 

[Luis Cobian]

(Some people would doubt that M$ learned anything but I think

compared to the early days of Win16 APIs we have now a decently
structured API.)

Well, at least they **have** a decent API. Don't let me started about other
OS )))))

 

[Gary R. Schmidt]

That's far too general a remark. API design (balancing ease of use for
programmers and raw power) is a difficult job and M$ learned it while on
the job. (Some people would doubt that M$ learned anything but I think
compared to the early days of Win16 APIs we have now a decently
structured API.)

No, M$ learned nothing. If you have ever programmed on VMS, you keep
running into things in NT that are strangely reminiscent. (And if you
have ever programmed on VMS, you will remember how long the
blue/orange/grey wall of manuals for it was!)

Cheers,
Gary B-)