|
|
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
|
|