From: Surfer! on
In message <Xns9753F2F65CF5Eiamback(a)194.109.133.242>, Marjolein Katsma
<nobody(a)example.net> writes
>Surfer! (surfer(a)127.0.0.1) wrote in news:izAXpRjrn90DFwhL(a)nevis-
>view.co.uk:
>
>>>I just checked my installation directory of Nikon Scan 4 and found
>>>FDUtility.exe sitting there - so it was installed along with Nikon Scan,
>>>only no shortcuts were created for it (not on the desktop, not in the
>>>start menu).
>>
>> So it is! Thanks for that. Hopefully I will never need to use it...
>
>Glad to hear it's solved! :)

And guess what - I needed it this morning!
>

--
Surfer!
Email to: ramwater at uk2 dot net
From: Marjolein Katsma on
Surfer! (surfer(a)127.0.0.1) wrote in news:mFN20SlbDK1DFwa8(a)nevis-
view.co.uk:

> And guess what - I needed it this morning!

Aaw, gosh!

If it weren't so hard to type (or put negatives in sleeves) that way I'd
keep my fingers crossed for you! ;)

--
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 22 Jan 2006 15:37:57 GMT, Marjolein Katsma <nobody(a)example.net>
wrote:

>> I was very unnerved the first time I uninstalled NikonScan
>> only to be faced with the same preview image after a re-install!
>> Unlike bad registry entries these files don't do any real damage but
>> it's still very sloppy.
>
>As to directorie with .tmp and .set files - or anything actually created
>during *use* of a program - it's normal for an uninstaller to NOT remove
>those: it's user data and they don't throw away what you *might* be
>wanting to keep. I'd be very cross if an uninstaller did throw away such
>files without even asking!

I understand all that but I would prefer if they would at the very
least offer the option of having those directories deleted. The
trouble is when they just leave them around without asking or
sometimes even without telling!

I mean you may want to keep things if you're re-installing but when
you are removing a program you don't want the "droppings" to stay
behind all over the place. That's the main cause of the notorious
Windows' bloat.

Now, a user can change the default user directories and the program
may only be aware of the current setting, but that's a different case.
The program can still offer to delete at least the initial default and
the latest (current) user setting.

>And normally, a well-written uninstaller will
>let you know at the end of its process that it has left some data
>untouched.

The problem is when they only give you the standard "legal disclaimer"
without telling what is actually left behind!

>As to registry entries - any left behind are usually also those that are
>created during usage of the program and thus the (un)installer has no
>knowledge of them.

Well, the program knows where they are! It created them. Also, there's
nothing preventing the uninstaller from reading the relevant program
settings and logs (before deleting them) to figure out which registry
entries were added afterwards and where.

>This is all in the nature of installation programs: they keep some sort
>of log of what they install where, and remove *that* when uninstalling.
>What's not in the log simply cannot be uninstalled. (I sometimes move a
>program's location, and I'm always careful to not only fix any registry
>entries but *also* the installation log if it's in plain text (most
>are).

That's the problem! Most installers are lazy. Instead of going about
it in a more intelligent way by taking note of the current
state/settings most simply go back to the original log. The
uninstaller may not be able to tell if the directories were changed
more than once but it does know the current setting and the default.

But that's how MS works in general. They always do the least and
what's the easiest for the MS programmer, not what's the easiest for
the user. After all, it took MS some 4-5 DOS versions to start warning
people before overwriting files during copy. Before than they would
just silently wipe out any existing file without a word.

>So ... all I can say is, nice of Nikon to provide a utility to clean up
>what an uninstaller *cannot* remove. ;-)

Or, Nikon were just too incompetent to do it all at once! ;o)

Sadly, having talked to Nikon's so-called "support" extensively, I'd
say that explanation is more likely! :-(

Don.
From: Surfer! on
In message <Xns975480D0CC1Aiamback(a)194.109.133.242>, Marjolein Katsma
<nobody(a)example.net> writes
>Surfer! (surfer(a)127.0.0.1) wrote in news:mFN20SlbDK1DFwa8(a)nevis-
>view.co.uk:
>
>> And guess what - I needed it this morning!
>
>Aaw, gosh!
>
>If it weren't so hard to type (or put negatives in sleeves) that way I'd
>keep my fingers crossed for you! ;)

ROFL!


>

--
Surfer!
Email to: ramwater at uk2 dot net
From: Don on
On 23 Jan 2006 20:20:43 GMT, Marjolein Katsma <nobody(a)example.net>
wrote:

>> I understand all that but I would prefer if they would at the very
>> least offer the option of having those directories deleted. The
>> trouble is when they just leave them around without asking or
>> sometimes even without telling!
>
>Leaving them around without asking is OK, as far as I'm concerned, but
>without telling is not. But an installer can only do that with data it
>"finds out" about: most oftn that takes the form of a directory that is
>not empty after removing all files it *does* know it has to remove
>(because they're in the installation log).

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.

>> I mean you may want to keep things if you're re-installing but when
>> you are removing a program you don't want the "droppings" to stay
>> behind all over the place. That's the main cause of the notorious
>> Windows' bloat.
>
>Nothing to do with Windows bloat - we're talking about *user files*
>here: *data*.

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

But even we take the definition of Windows bloat literally all those
extra registry entries which are left around are certainly a part of
Windows.

>> Now, a user can change the default user directories and the program
>> may only be aware of the current setting, but that's a different case.
>
>If the application program doesn't know about that, that's just bad
>programming. ;-)

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

>But regardless what the *program* is aware of, what the *installer* is
>aware of is a totally different matter. It's a completely separate
>program, not actually written by the program's developers, but generated
>with a tool by providing a bunch of parameters. Still, an installer can
>only know what's known at installation time - not user data that get
>generated during use of the program of which workings an installer has
>no idea - it cannot and is not designed to do so.

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!

>But just because there are stupid installers that throw away such data
>*without* even asking, the very first thing I do after installing a
>program is check how I can tell it where to store my data. Via options,
>preferably, or via a Registry hack if needed. ;-)

I usually back up my Registry before and after an install, as well as
do a full directory listing from DOS. The key word here is "usually".
:-( Actually that should be "sometimes". OK, OK, I admit I actually do
this very rarely! ;o) But I should do it every time.

>>>As to registry entries - any left behind are usually also those that
>>>are created during usage of the program and thus the (un)installer has
>>>no knowledge of them.
>>
>> Well, the program knows where they are! It created them.
>
>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!

>> Also, there's nothing preventing the uninstaller from reading the
>> relevant program settings and logs (before deleting them) to figure
>> out which registry entries were added afterwards and where.
>
>Theoretically, it would be possible to write an installer utility that
>could be told how to read a multitude of program's settings in a
>multitude of formats in a mutitude of locations. In practice, that
>doesn't happen - if it's even feasible, such a program would be huge,
>and very, very expensive. Program developers might as well go back to
>developing their own installation software.

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

>Installer software is *standard* software. It knows about a file system,
>executables, registration of services in the registry, and such things.
>it does *not* know how an application works or how an application stores
>its settings.

Which can be standardized very easily.

>Be glad that we have standard software installation utilities these days
>- it makes our software much more affordable.

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.

Don.