POV-Ray : Newsgroups : povray.off-topic : Somewhat disappointing : Re: Somewhat disappointing Server Time
4 Sep 2024 19:20:22 EDT (-0400)
  Re: Somewhat disappointing  
From: Florian Pesth
Date: 27 Jan 2010 18:02:40
Message: <4b60c610$1@news.povray.org>
Am Wed, 27 Jan 2010 14:11:40 -0800 schrieb Darren New:

> Florian Pesth wrote:
>> If it is done correctly, it knows which programs depend on the "DLL"
> 
> No, it knows which *packages* depend on the DLL.
> 
> There's no good way under Linux (without walking thru /proc and trying
> to parse it, and hoping it doesn't change while you do so) of telling
> what DLLs
>   a given program is using that isn't in a package.

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?

(BTW, how do you ensure "atomic" process table lookups on any 
multitasking OS? It is not, that you can prevent the starting of new 
processes just after your check, can you?)

 There's also no good
>   way
> of telling what programs are running right now.

Just out of curiosity: Is there any way to tell of a process in windows, 
which executable file it stems from? What happens, if you unmount the 
volume the executable file is on or if the process you are looking at is 
actually a child process from the original one? 

>  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 without some form of 
either package management or a different centralized software 
distribution system (for example like the App store for the iPhone)? I 
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.

> 
> (For example, you have your media player running, and you update the
> media player executable and all the codecs. But now you go back to the
> running media player and play a different file, which loads the new
> codec DLL that is now incompatible with the running executable.)

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.

Of course if you don't use the package management you might break the 
system, but thats not different than tinkering with windows on a low 
level.

> 
> UNIX has always been a "95% is good enough" OS. Linux is doing slightly
> better, but still isn't 100% there.

Sure, it is still some way to go (I'm doing some administration on some 
linux machine on my job, but my primary job is using them for physics 
simulations - so its pretty annoying if the stuff doesn't work. And yeah, 
if it works for "practical purposes" its fine for me, even if it is 
technically broken.)

> 
>> (Also, if I run an executable it seems "locked",
> 
> You can't write to a program that's executing, in UNIX. Never could.
> 
> What you *can* do is delete the executable while it's running (well,
> technically, "unlink" it), and create a new file with the same name.
> 
> In Windows, to delete a file, you have to have write permission, and
> since you don't get write permission to an executing file in Windows
> (just like in UNIX), you can't delete the file.
> 
> In UNIX, you don't need any permissions on a file to unlink it from the
> directory its name is in.

Thanks, didn't know that!


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.