From: Marjolein Katsma on
Don (phoney.email(a)yahoo.com) wrote in
news:i0kct1hf9gapha8lcc8mftf2caievue8qd(a)4ax.com:

> The trouble is most of them don't even try. They just use the original
> log when the program was installed which is just not enough.

Once more: standard installation software CANNOT do this. "Trying"
doesn't come into it - it's *logically* impossible: the installation
program cannot know *how* an application stores its data.

The only alternative is to develop an (un)installer that contains much
of the same logic as the actual application. No software developer will
do that, since it would make the product far too expensive for very
little added value. And they'd lose customers.


> Windows bloat referrers not only to the Windows' directory but to the
> installation as a whole.

Sure. But that's totally irrelevant when we are talking about *user
data*. The same application running on two or three different OSs will
store the same amount of user data on each.


> Bingo! And "bad programming" is where MS shines! ;o)

MS also shines at good programming. MS is *BIG* and what one department
does well, another department does extremely badly. I refuse to
generalize about MS except by saying they're BIG. And MS doesn't develop
installer utilities - so that statement is irrelevant, too. (They do
provide a framework - but that's something else again: that's just to
make writing installers easier (read: with higher-level logic).)


> I know, and that's exactly the problem. The installer that comes with
> various MS tools is appalling and that's just to package the
> application in the first place, never mind the uninstall later!

Installer and uninstaller are the same program, only in a different mode
of operation. The quality of the installer depends on the quality of the
generating tool, and the quality of the parameters provided to build the
installer. What remains is that some things are *impossible* to know for
an installer. Installers cannot know how an application operates or how
or where it stores user data.


>>The *application* knows where they are - the *installer* does not! An
>>installer has absolutely no idea how a program functions or what it
>>may store where.
>
> And that's exactly the problem!

See alternative above. You wouldn't be complaining about uninstalling
because you wouldn't be able to afford the program in the first place.
;)

> I don't agree that would be a huge and expensive program. It's just a
> question of standardization.

LOL!

>>it does *not* know how an application works or how an application
>>stores its settings.
>
> Which can be standardized very easily.

ROFL!

Explain to me, please, how a dictionary, a GIS application, and a
printer driver can be standardized so they all store their (user) data
in the same format in the same way? Just for example?


> I don't think so. Installers (as they are now) are not that
> complicated to write. It's exactly that simplicity which is the
> problem.

They get very complicated very quickly. It's a specialized sort of
software with endless decision trees of ifs and buts and elses that an
application - once installed - doesn't need to worry about.

But as I said - installers aren't "written" any more - they're generated
with the help of tools that know how to take care of all these ifs and
buts and elses.

--
Marjolein Katsma
*Help with HomeSite/Studio: http://hshelp.com/
*Travel blog: http://blog.iamback.com/
*Spam reporting addresses: http://banspam.javawoman.com/report3.html
From: Don on
On 24 Jan 2006 21:00:19 GMT, Marjolein Katsma <nobody(a)example.net>
wrote:

>> The trouble is most of them don't even try. They just use the original
>> log when the program was installed which is just not enough.
>
>Once more: standard installation software CANNOT do this. "Trying"
>doesn't come into it - it's *logically* impossible: the installation
>program cannot know *how* an application stores its data.

Which is why standardization is needed to abstract the location of
user *settings* (not *data*!) so installers know where it is.

>> Bingo! And "bad programming" is where MS shines! ;o)
>
>MS also shines at good programming. MS is *BIG* and what one department
>does well, another department does extremely badly. I refuse to
>generalize about MS

That's where we definitely differ. MS does things extremely badly and
is forced kicking and screaming to make any improvements.

As I said, their mentality is to develop what is the easiest for their
programmers to do, second is to suffocate any inkling of competition,
and 3rd... well, there is no third. Users don't enter into this
equation at all.

Why? Because MS is a monopoly. Just like IBM before them. And IBM
behaved in exactly the same way. In any monopoly situation there are
no users or customers, there are only hostages.

>Explain to me, please, how a dictionary, a GIS application, and a
>printer driver can be standardized so they all store their (user) data
>in the same format in the same way? Just for example?

I think you're missing what I'm saying. We are talking about user
*settings* not generic user *data*. As in NikonScan *settings* not any
images you may have scanned.

In more generic terms, *everything* can be standardized. The question
is only when you reach the case of diminishing returns. And due to the
simplicity of Windows installers there is a long way to go before such
a point is reached.

In the most primitive/elementary form all that's needed is a single
*standardized* registry entry to point to a directory where user
settings are stored. Indeed, the same approach can even be used to
also note where user data is stored should one be so inclined.

Don.
From: Marjolein Katsma on
Don (phoney.email(a)yahoo.com) wrote in
news:fdcft1t8cbi67hqhkoqrvlm3eutsu3cotj(a)4ax.com:

>>Explain to me, please, how a dictionary, a GIS application, and a
>>printer driver can be standardized so they all store their (user) data
>>in the same format in the same way? Just for example?
>
> I think you're missing what I'm saying. We are talking about user
> *settings* not generic user *data*. As in NikonScan *settings* not any
> images you may have scanned.

Settings *are* user data. But let me rephrase:

So explain to me how you would standardize how and where the settings
for a dictionary, a GIS application, and a printer driver can be
standardized so they all store their settings data in the same format in
the same way?

> In more generic terms, *everything* can be standardized.

I think you're still missing my point. Both bikes and motor cars have
steering mechanisms, as do boats. How would you standardize them? More
to the point, why would you? Get it?

> And due to the simplicity of Windows installers (...)

Only very simple applications can have simple installers. For most non-
trvial application installation is non-trivial either, and far from
simple.

> In the most primitive/elementary form all that's needed is a single
> *standardized* registry entry to point to a directory where user
> settings are stored. Indeed, the same approach can even be used to
> also note where user data is stored should one be so inclined.

Let's just stick to settings - as the locations for other user data can
be endless, and (hopefully!) not fixed (and hence not possible to be
registered); the most applications do is keep track of the last path(s)
used.

Settings must be stored somewhere - but why should it be a directory?
Settings can be stored in the Registry as well. There are reasons for
choosing one or the other - some applications even store settings in
several places (often for good reasons). Then there's the matter of
different users, each of which have their own settings, as well as
default settings the application might want to keep track of so the user
can restore to a known starting point. How would you standardize this?

--
Marjolein Katsma
*Help with HomeSite/Studio: http://hshelp.com/
*Travel blog: http://blog.iamback.com/
*Spam reporting addresses: http://banspam.javawoman.com/report3.html
From: Don on
On 25 Jan 2006 20:58:59 GMT, Marjolein Katsma <nobody(a)example.net>
wrote:

>>>Explain to me, please, how a dictionary, a GIS application, and a
>>>printer driver can be standardized so they all store their (user) data
>>>in the same format in the same way? Just for example?
>>
>> I think you're missing what I'm saying. We are talking about user
>> *settings* not generic user *data*. As in NikonScan *settings* not any
>> images you may have scanned.
>
>Settings *are* user data. But let me rephrase:
>
>So explain to me how you would standardize how and where the settings
>for a dictionary, a GIS application, and a printer driver can be
>standardized so they all store their settings data in the same format in
>the same way?

There are literally dozens of ways to reconcile heterogeneous data.
Let's take the latest fad: XML for starters! I'm not a big fan because
it has it's own many problems. But all that is a distraction... The
important point is this:

Forget MS, forget everything and ask yourself: What does a user want
from an (un)installer?

The answer is, an automatic install so the user doesn't have to copy
any files manually or twiddle any OS settings (e.g. add registry
entries by hand).

Then, when the time comes to uninstall, automatic removal of all files
*including* any files the program has generated because it needs them
to operate! That does not include user *data*, of course, but it does
include user *settings*, temp files, OS settings, etc.

Conceptually and physically those settings are a part of the program
and you don't want them lingering on after uninstalling. What good are
those settings or temp files (the preview) etc. after you uninstall
the program? You want them gone!

In short, an uninstaller should *fully* restore to "status quo ante",
(not a *partial* restore with bits left all over the place). Only when
everything program-related is removed can that be called a clean
uninstall. Everything else is a mess.

>> In more generic terms, *everything* can be standardized.
>
>I think you're still missing my point. Both bikes and motor cars have
>steering mechanisms, as do boats. How would you standardize them? More
>to the point, why would you? Get it?

Yes, but you didn't get it, because you missed the very next sentence
which is key:

On Wed, 25 Jan 2006 18:17:09 +0100, Don <phoney.email(a)yahoo.com>
wrote:

>The question is only when you reach the case of diminishing returns.

So, of course, you can standardize all those steering mechanisms but
that would be "solving" a non-existent problem and would be counter
productive because it would only create inconveniences without getting
much back. Which is another way of saying "diminishing returns".

By contrast, removing all program related files (whether they existed
at the time of initial installation or not) is meaningful and a real
problem especially if you don't know where they all are? And, to get
specific again, NikonScan sprinkles them all over the place. Not
necessary Nikon's fault, it's just the way Windows works. Which gets
us back to poor MS programming!

>> In the most primitive/elementary form all that's needed is a single
>> *standardized* registry entry to point to a directory where user
>> settings are stored. Indeed, the same approach can even be used to
>> also note where user data is stored should one be so inclined.
>
>Let's just stick to settings - as the locations for other user data can
>be endless, and (hopefully!) not fixed (and hence not possible to be
>registered); the most applications do is keep track of the last path(s)
>used.

Which is why I said at the beginning that (at the very least) an
uninstaller should be able to delete any settings in the program's
default location and the last user-selected location.

>Settings must be stored somewhere - but why should it be a directory?
>Settings can be stored in the Registry as well. There are reasons for
>choosing one or the other - some applications even store settings in
>several places (often for good reasons). Then there's the matter of
>different users, each of which have their own settings, as well as
>default settings the application might want to keep track of so the user
>can restore to a known starting point. How would you standardize this?

The program and the OS need discipline. That's what standardization is
all about! Standardization means: Instead of a free for all, both the
program and the OS agree to observe certain established rules so they
can work together. For example, abstracting a directory (via
indirection) for user settings instead of hard-coding it. Etc.

Windows has traditionally had very little discipline. That's why there
are so many problems even when MS tries to retrofit discipline. And
also why MS programmers are anything but good. The fact that there are
so many *uncontrolled* places to store all those settings is a prime
example of all of that. It's also a prime example of sloppy OS design.
And so on...

Don.
From: Marjolein Katsma on
Don (phoney.email(a)yahoo.com) wrote in
news:senht1homrov9slq8m1v6f7cn8717imejb(a)4ax.com:

>>So explain to me how you would standardize how and where the settings
>>for a dictionary, a GIS application, and a printer driver can be
>>standardized so they all store their settings data in the same format
>>in the same way?
>
> There are literally dozens of ways to reconcile heterogeneous data.
> Let's take the latest fad: XML for starters!

XML is no better or worse than .ini files or Registry entries (well, maybe
a little better in some respects, and owrse in others ;)) - what matters
is *semantics* of the data. XML doesn't solve anything in that respect.
The problem with standardizing is in the kinds and types of data
necessary: semantics. This is a BIG problem.

And once you have (theoretically only, since it's not even feasible)
standardized the types of data needed for all existing apps, a new one
comes along that needs different data yet again. What do we need: a world-
wide repository of user settings semantics? Accessible over the Internet?
What if a computer user doesn't have Internet access?

> What does a user want from an (un)installer?

1. Easy installation with enough choices to let an installation adapt to
*my* system rather than adapt my system to an installer (that means both a
"standard" instaland a "custom" install, at least.
2. Uninstallation of everything that was *installed*
3. Tell me about any user data left in directories create by the installer
or subdirectories of that

Given that, it's
1) The application's responsibility to store any settings that are not
directly editable by the user in the Registry *below* a branch that was
created by the installer - so an uninstaller is able to remove those
2) The application's responsibility to store any settings that *are*
directly editable by the user in the file system *in* or *below* the
application's installation directory, or in a standard "Application data"
subdirectory - so the installer can warn the user not all data have been
removed (OR use a single .ini file in the %windows% directory created at
install time so the uninstaller can find it - but this is deprecated, not
least because it doen't handle different settings for different users)
3) The *users* resposibility to take care of any user data stored in a
location *they* decided in the first place - no uninstaller can know about
those and no installer should touch them anyway

BUT that ignores the multi-user situation - which makes the simplified 1-
2-3 lists above a whole lot more complicated.

> The answer is, an automatic install so the user doesn't have to copy
> any files manually or twiddle any OS settings (e.g. add registry
> entries by hand).
>
> Then, when the time comes to uninstall, automatic removal of all
> files *including* any files the program has generated because it needs
> them to operate! That does not include user *data*, of course, but it
> does include user *settings*, temp files, OS settings, etc.

A user may *want* that - but I've already explained that it's just not
possible. Maybe I should say, only naive users want that - users who
understand a little how applications and the OS they're running on work
will not wish for the impossible - and will not be prepared to pay the
price of a dedicated uninstaller which duplicates half the program's
logic.

> Conceptually and physically those settings are a part of the program
> and you don't want them lingering on after uninstalling. What good are
> those settings or temp files (the preview) etc. after you uninstall
> the program? You want them gone!

They're NOT part of the program. Very often, I *don't* want them
uninstalled, so a newer version of the software can use them (directly, or
by importing them). Temporary files are the user's responsibility anyway -
who decides *how long* they should be kept? Only the user.

> In short, an uninstaller should *fully* restore to "status quo ante",
> (not a *partial* restore with bits left all over the place).

It should bloody NOT! An uninstaller that does that to me will mean I will
never, ever even consider another version of that software, unless I'm
reassured it's bettered its life. An uninstaller should NOT touch *my*
data (or at most ask me friendly whether to remove what it knows how to
find). Anything else is just not well-behaved.

Sure, remove the *program* and anything it needs to start up. But do NOT
touch ANY data.

> By contrast, removing all program related files (whether they existed
> at the time of initial installation or not) is meaningful

No, it's impolite, to say the least. Hands off MY data! And not feasible
anyway. Your "just standardize" completely misses the reality of an
infinite set of semantics to describe all those data. See above.


> And, to get specific again, NikonScan sprinkles them all over the
> place.

Such as where?

> Not necessary Nikon's fault, it's just the way Windows works. Which
> gets us back to poor MS programming!

No, it's not "just the way windows works". Where data are stored depends
on two things: the application (its own data) and the user's choice (user
data). An application that deosn't allow a user to choose where to store
their data is badly programmed. Nothing to do with how Windows works,
Windows makes these choices possible for responsible programmers.

> Which is why I said at the beginning that (at the very least) an
> uninstaller should be able to delete any settings in the program's
> default location and the last user-selected location.

Of course, we only need to "just standardize" how the last user-selected
location of all the possible somethings for all possible users are
recorded. For all possible applications used anywhere on the world.

> Standardization means: Instead of a free for all, both the
> program and the OS agree to observe certain established rules so they
> can work together.

And don't forget those semantics. ;-) They come before establishing rules.
See above.

> Windows has traditionally had very little discipline.

In the sense that Windows is an application, yes; it's a tad sloppy - but
that is mostly because of backwards-compatibility with original bad
choices.
In the sense that Windows does not *enforce* any specific locations for
anything, true as well.

Both of these apply equally to *nix though. Mac OS is only partly an
exception in that OS X is built on top of *nix and you can do all *nix
things in it, as well. (Conveniently ignoring other OSs for a moment.)

> That's why there are so many problems even when MS tries to retrofit
> discipline.

Do they try that? Try to retrofit dicsipline?
Only in the sense that some deprecated (and insecure) approaches are no
longer possible (such as direct access to hardware). Otherwise backwards
compatibility rules, which has its disadvantages but huge advantages as
well.

The real responsibility is with application programmers; an OS only
provides a framework to make responsible applications happen.

> And also why MS programmers are anything but good.

Some MS programmers are *very* good. I've said it before: MS is BIG. Then
again, some MS programmers are indeed bad.

> The fact that there are so many *uncontrolled* places to store all
> those settings is a prime example of all of that.

It's a result of flexibility. ;)

> It's also a prime example of sloppy OS design.

No - where settings and user data are stored is not a result of whatever
kind of OS design, merely of programmer and user choice.

I intensily dislike any application that *doesn't* give me a choice where
to store my data (including my settings). Most programs that don't won't
ever make it past trial install and are quickly removed. Especially a
program that insists on storing user data (as opposed to settings here)
below the installation directory: I keep a strict separation between
programs and my data, they go on different physical drives.

It's MY system, after all. *I* decide what goes where. A program that
doesn't respect that doesn't deserve my respect.

....

Enough of that, I've explained enough now. If you still don't get it, I
give up.

So, tell me: what are all those places where Nikon Scan stores data during
operation (i.e., after installation)? Places that weren't set or accepted
by you in the first place?


--
Marjolein Katsma
*Help with HomeSite/Studio: http://hshelp.com/
*Travel blog: http://blog.iamback.com/
*Spam reporting addresses: http://banspam.javawoman.com/report3.html