Florian Pesth wrote:
> Right, if you install programs not in the package management, the package 
> management doesn't work on this programs. But this is to be expected, 
> isn't it?

Yep. But notice how this differs from Windows. If it can replace a DLL, it 
means nobody is using it right now, whether that program is in the package 
management system of Windows or not.

> (BTW, how do you ensure "atomic" process table lookups on any 
> multitasking OS? 

Well, you could do something like (for instance) trying to open the 
executable for writing. If it fails, someone is running it. If it succeeds, 
then nobody at this point can "exec" it, because they'll get back that the 
file is busy from the exec call.

At least, that's how it works on serious operating systems, like mainframes. 
Everything you would commonly want to do is atomic in one way or another.

> Just out of curiosity: Is there any way to tell of a process in windows, 
> which executable file it stems from? 

Sure. The task manager does it no problem, so I can't imagine it's hard.

> What happens, if you unmount the 
> volume the executable file is on 

Dunno, offhand. I suspect either it doesn't let you unmount it or the 
process gets killed before the unmount completes.

> or if the process you are looking at is 
> actually a child process from the original one? 

Which would the "original" one be?

>>  There's also no good
>> way of figuring out if a currently-running program is compatible with
>> the new DLL you just downloaded, even if that running program hasn't
>> loaded that DLL.
> 
> Again, how do you expect to solve this problem 

This one is definitely more difficult, yes. In Windows, this is part of what 
the COM system does, or you use NTFS atomic transactions. So either you say 
"replace all these files including the executable" and the executable fails 
so none get replaced, or you put the new COM software out there and 
atomically update the registry to point to the new COM server.

> can always compile a DLL with a same name which is incompatible to what 
> some program expects. That can only be solved by package management.

Sure. I'm just saying that package management systems fall down at some 
point, more or less complexly. You *can* ensure this doesn't happen under 
some systems. UNIX isn't one of them, because the semantics aren't there in 
the atomic parts of the system.

There's a reason it's called the "registry".

> If the package management works, this is what happens:
> You update the *package* of the media player. When you do this the 
> package manager notices, that you have an older version of that package 
> installed and checks if you have an instance of the program running (It 
> doesn't really matter, if this check is done in a nonstandard way, 
> because the package manager knows *exactly*, what version is installed 
> and how to check it.). It pops now a window asking you to restart the 
> player.

How does it know how to check if some random user is using an arbitrary 
program at the moment? Or if that program is running in a way that can't be 
interrupted with a "window"? What if I started some long-running data 
munching job in the background and logged out. Who do you ask if you can 
replace its DLLs? Or if it's not in a package but the DLLs it's using are?

> if it works for "practical purposes" its fine for me, even if it is 
> technically broken.)

Yeah, I grew up on mainframes where the folks writing the OS actually paid 
attention to all the corner cases, so it bugs me when there's no guaranteed 
way to see if something is already running, etc.

It's only since /proc came along that you could even tell if a service was 
already running and not restart it if it was.

> Thanks, didn't know that!

Yeah, Windows doesn't have a problem deleting an open file in general. It 
just has a problem deleting an open file that you specifically said "don't 
let others delete this while it's open." It just happens that the OS opens 
executable code files that way, so it can page out of the files directly 
without copying them to swap space.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message