Orchid XP v8 schrieb:

> Heh. On Monday, I've got to see if a Windows 2.0 program works OK under 
> Windows XP. The fun part? To run it, you must replace SERIAL.SYS with a 
> custom modified version. (!!)

Uh - Windows TWO-point-zero?? Sure it isn't 3.1 at least? Who on earth 
used 2.0?

> It still amuses me that this program can't print on any network printer 
> who's name is more than 8 characters long...

Comes as not much of a surprise. It's rather a miracle that it can 
access networked printers at all...

> Oh, sure, it could put the installer file in
> 
>   %profile%\Local Settings\Temp
> 
> But it doesn't. It puts it in
> 
>   %profile%\Application Settings\Adobe\Acrobat\Updater
> 
> The Java installer does something similarly retarded for some reason. 
> Maybe it's an IE quirk of some kind?

I'd presume it's a safety measure to not end up with a crippled 
installation: Files in %profile%\Local Settings\Temp can be recycled by 
Windows' disk cleanup assistant. If the updater is designed using a 
multi-step approach, and there's a serious possibility that the steps 
may be run at very distinct points in time, you'll want those files to 
still exist when the second step commences.

If the updater cleans up after work, there shouldn' be a problem. If it 
fails to do, it somehow defies the exact purpose of the disk cleanup 
assistant, and would therefore need to be called poor design.

> You can't put, for example, the Word "normal" template in the registry. 
> But then, I guess it depends on what you consider to be "settings" and 
> what is "documents"...

Indeed, a clear line cannot always be drawn; for instance, are POV-Ray 
.ini files settings for POV-Ray, or are they part of the scene?

> FWIW, I think the registry actually works quite well for what it's 
> supposed to be for. You can lock it down with security, it's got 
> seperate user and system sections, and so on. The only real flaw is that 
> it's more or less impossible to do manual things like copy one user's 
> preferences to another user account, but only for one specific 
> application. (Because you will never, ever determine which keys to copy...)

Most software is pretty sane about this, storing /user/-specific 
settings in HKCU/Software/CompanyName/ProgramName, so the biggest 
obstacle is figuring the users' IDs.

Plus the fact that some software may not be using the registry to store 
settings, but files in one of the many %profile% subfolders instead.

Post a reply to this message

Darren New schrieb:
> clipka wrote:
>> I don't think Linux package managers will automatically un-install 
>> those if you uninstall that image processing package 
> 
> Actually, Windows will do this, too. The problem is that not every 
> installer will mark what dependencies it uses, so you'll often get the 
> question "Hey, the DLL called <incomprehensible>.DLL looks unused, 
> should I uninstall it?"

BTW, does Linux provide such a feature as well? If so, where does the 
"use count" live there?

Post a reply to this message

nemesis schrieb:
> clipka wrote:
>> in addition. I don't think Linux package managers will automatically 
>> un-install those if you uninstall that image processing package (it 
>> would be ill-advised, as I might have installed other, 
>> non-package-managed software that also relies on that library).
> 
> Non-package-managed software installed by hand is of no concern to the 
> package manager.  It will uninstall swiftly.
> 
> I'm used to compile up-to-date libs required by some hand-compiled 
> up-to-date software and install it to my ~/lib.  It's only annoying to 
> do the usual "LD_LIBRARY_PATH=~/lib foo" everytime, but, hey!, that's 
> why bash history is for. :)

I have no idea what you're talking about here, nor do I know whether you 
understood my point.

What I mean is this: Suppose I install a package-managed piece of 
software (let's name it "FooPNG" for now) that needs the libpng package. 
Of couse the package manager will recognize, and ask me whether I want 
to install the package as well. (Sure I do, yes please, go ahead.)

Now I compile this strange piece of software called POV-Ray, which 
obviously isn't package managed. But it needs the libpng nonetheless. No 
problem here, as the libpng is already there, so it compiles (and 
installs) fine.

Now I decide to uninstall FooPNG.

Will the package manager uninstall libpng as well, figuring that only 
FooPNG should rely on it? Will it leave libpng alone, figuring it 
/might/ be used by /some/ other app? Or will it actually have any way of 
/knowing/ that POV-Ray relies on it?

(I really don't care whether the package manager will uninstall 
/swiftly/ or /slowly/, I care /what/ it uninstalls :-))

Post a reply to this message

>> It still amuses me that this program can't print on any network 
>> printer who's name is more than 8 characters long...
> 
> Comes as not much of a surprise. It's rather a miracle that it can 
> access networked printers at all...

I'm guessing Windows does a sufficiently good job of pretending they're 
actually local. ;-)

We have another program that goes with this one. It's written in QBASIC. 
It requires a laser printer that understands PCL to be mapped to LPT2:. 
(I'm not sure what I could add to this description that would make it 
sound any worse...)

>> Oh, sure, it could put the installer file in
>>
>>   %profile%\Local Settings\Temp
>>
>> But it doesn't. It puts it in
>>
>>   %profile%\Application Settings\Adobe\Acrobat\Updater
>>
>> The Java installer does something similarly retarded for some reason. 
>> Maybe it's an IE quirk of some kind?
> 
> I'd presume it's a safety measure to not end up with a crippled 
> installation: Files in %profile%\Local Settings\Temp can be recycled by 
> Windows' disk cleanup assistant. If the updater is designed using a 
> multi-step approach, and there's a serious possibility that the steps 
> may be run at very distinct points in time, you'll want those files to 
> still exist when the second step commences.
> 
> If the updater cleans up after work, there shouldn' be a problem. If it 
> fails to do, it somehow defies the exact purpose of the disk cleanup 
> assistant, and would therefore need to be called poor design.

It downloads the installer, runs it, and then JUST LEAVES IT THERE. So, 
yeah, poor design.

But then again, as Warp pointed out, Java likes to cache every applet 
you've ever run, and provides no easy way (that I can discover) to 
remove this cache...

> Most software is pretty sane about this, storing /user/-specific 
> settings in HKCU/Software/CompanyName/ProgramName, so the biggest 
> obstacle is figuring the users' IDs.
> 
> Plus the fact that some software may not be using the registry to store 
> settings, but files in one of the many %profile% subfolders instead.

The really fun thing is that you can't edit a user's registry chunk 
without loading it first...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:

> Now I have a bat file that deletes all the crap I can find I run before 
> backups.

I had that.

Then I discovered that it can't delete the IE web cache. (Due to some 
kind of weirdness with it being system and hidden or something like 
that.) So I switched to a Tcl script. Even built a little Tk GUI for it, 
so you can see how much longer it's going to take. (Deleting 0.8GB of 
web cache takes a while...)

And then I switched it to Haskell, so I could more precisely control the 
file deletion algorithm. And I added logging. And I ran it as a service, 
scripted to run on the profile server every 300 seconds...

And then HQ IT decided that roaming profiles were too efficient, and 
disabled them. Now every...single...time...I set up a new PC, I have a 
stream of people asking me to come over and configure their email 
settings. And people whining that they have to adjust their Word 
settings manually for every PC they use. *sigh*

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sat, 19 Sep 2009 22:15:24 +0200, Darren New <dne### [at] sanrrcom> wrote:
> But the crap like caching java applets forever is hellishly annoying, I  
> find. That grows forever.

Are you talking about the deployment cache? If so, you can change that in  
the Java control panel. Alternatively, CCleaner can clear it for you.



-- 
FE

Post a reply to this message

Orchid XP v8 schrieb:
> The really fun thing is that you can't edit a user's registry chunk 
> without loading it first...

You could generate a registry patch (I think .reg is the extension) that 
would be written to the HKCU tree, and somehow make sure that thing 
executed next time the user logs in.

(The only thing which is a real nuisance there is that this doesn't 
allow you to /delete/ registry keys.)

Post a reply to this message

On Sun, 20 Sep 2009 18:11:27 +0200, clipka <ano### [at] anonymousorg> wrote:
> You could generate a registry patch (I think .reg is the extension) that  
> would be written to the HKCU tree, and somehow make sure that thing  
> executed next time the user logs in.
>
> (The only thing which is a real nuisance there is that this doesn't  
> allow you to /delete/ registry keys.)

Of course it does. What makes you think otherwise?



-- 
FE

Post a reply to this message

Fredrik Eriksson schrieb:
> On Sun, 20 Sep 2009 18:11:27 +0200, clipka <ano### [at] anonymousorg> wrote:
>> You could generate a registry patch (I think .reg is the extension) 
>> that would be written to the HKCU tree, and somehow make sure that 
>> thing executed next time the user logs in.
>>
>> (The only thing which is a real nuisance there is that this doesn't 
>> allow you to /delete/ registry keys.)
> 
> Of course it does. What makes you think otherwise?

Experience.

Name any syntax in a .reg file that will make a registry key /disappear/ 
when that .reg file is executed.

(And I'm not talking about setting it to zero or an empty string or some 
such, I mean really /eliminating/ it.)

Post a reply to this message

clipka wrote:
> Indeed, a clear line cannot always be drawn; for instance, are POV-Ray 
> .ini files settings for POV-Ray, or are they part of the scene?

Generally, if the user can change them, they shouldn't be in the 
program-files directory. :-)

> Most software is pretty sane about this, 

Mainly because that's the only place users have permissions to write. :)

Altho I have had software that was licensed per-user that stored its 
licensing settings in the per-machine area. It was broken in many other ways 
too, and written by the CEO's son, so I wasn't surprised.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message