DLLs won't go

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

DLLs won't go

rafe-2
trying to clear out a bunch of old Seamonkeys, Firefoxes, and Mozillim
-- almost invariably there seems to be a DLL which proves undeletable
-- trying gives a noisy "in use" popup under the WPS, or "Sharing
Violation" under FC/2.  namely:

RWSSRV07.DLL
RWSCLI08.DLL
RWSSRV08.DLL
nssckbi.dll

I'm 99% sure I can get rid of them without worry while booted to a
maintenance partition, but can someone confirm?  also I'm curious why
this happens, since nothing else remains of the browser (it's often
months after I've deleted the whole rest of the directory), nor are
they the names the same as any DLLs which actually seem to be used by
the latest versions of Seamonkey and Firefox?  and none are marked
System or Read-Only.

-rafe
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: DLLs won't go

Steve Wendt
On 10/19/08 01:52 pm, rafe wrote:

> -- almost invariably there seems to be a DLL which proves undeletable
>
> RWSSRV07.DLL
> RWSCLI08.DLL
> RWSSRV08.DLL

The location of the Remote Workplace DLLs get registered when you use
them; if you want them in a more permanent place, you should uninstall
and reinstall it (such as in \os2\dll).

> nssckbi.dll

This is probably due to the location being hard-coded in one of your
profile's files (such as secmod.db).  There's not a good fix for that
right now (it's a cross-platform problem), other than removing those and
letting them rebuild.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: DLLs won't go

Dave Yeo-3
In reply to this post by rafe-2
On 10/19/08 01:52 pm, rafe wrote:
> I'm 99% sure I can get rid of them without worry while booted to a
> maintenance partition,

Simpler then using a maintenance partition is to download the lxlite
package from hobbes then extract unlock.exe from the package and put it
on the PATH.
Then when you have DLLs such as the above that won't delete you can use
eg unlock nssckbi.dll from the command line and the DLL will be loaded
into memory allowing you to delete it.
The old DLL will still be used until you reboot.
Dave
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: DLLs won't go

Paul Ratcliffe
On Sun, 19 Oct 2008 15:52:37 -0700, Dave Yeo <[hidden email]> wrote:

> The old DLL will still be used until you reboot.

The old DLL will still be used until it is not referenced any more, at
which point it will be unloaded.
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: DLLs won't go

Ilya Zakharevich
In reply to this post by Dave Yeo-3
[A complimentary Cc of this posting was sent to
Dave Yeo
<[hidden email]>], who wrote in article <[hidden email]>:
> On 10/19/08 01:52 pm, rafe wrote:
> > I'm 99% sure I can get rid of them without worry while booted to a
> > maintenance partition,
>
> Simpler then using a maintenance partition is to download the lxlite
> package from hobbes then extract unlock.exe from the package and put it
> on the PATH.

(If you have more than EMX runtimes?) EMX includes:

    K:\>emxupd
    Usage: emxupd <source_file> <target_path>
           emxupd -d <old_file>
    Options:
      -d   Delete the file

Hope this helps,
Ilya
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: DLLs won't go

Rich Walsh
In reply to this post by rafe-2
On Sun, 19 Oct 2008 20:52:05 UTC, rafe <[hidden email]> wrote:

> trying to clear out a bunch of old Seamonkeys, Firefoxes, and Mozillim
> -- almost invariably there seems to be a DLL which proves undeletable
> -- trying gives a noisy "in use" popup under the WPS, or "Sharing
> Violation" under FC/2.  namely:
>
> RWSSRV07.DLL
> RWSCLI08.DLL
> RWSSRV08.DLL
> nssckbi.dll
>
> I'm 99% sure I can get rid of them without worry while booted to a
> maintenance partition, but can someone confirm?  also I'm curious why
> this happens, since nothing else remains of the browser (it's often
> months after I've deleted the whole rest of the directory), nor are
> they the names the same as any DLLs which actually seem to be used by
> the latest versions of Seamonkey and Firefox?  and none are marked
> System or Read-Only.

I went to great lengths to prevent the RWS dlls from getting locked
like this and know of only two reasons this happens:

- you (or some app) just registered a WPS class.  For some reason,
  this causes the WPS to load every class it knows about, regardless
  of whether it's currently needed.  The solution for RWS is to open
  your browser, go thru the motions of downloading a file but cancel
  when the "what should I do with this file" dialog appears.  Now,
  close the browser - the dlls should be unlocked.

- you have one of the mozapps currently running.  This may seem odd,
  but no matter how many copies of the RWS dlls you have, only one
  pair is ever used - and they can be anywhere.  In this case, the
  pair in use is the one that's locked.  The fix is simple:  close
  all your mozapps.

  If you run multiple mozapps, your best bet is to move the rws08 dlls
  and rws08.cmd (or rwsutil08.cmd) to some neutral location - putting
  them in a directory already on your LIBPATH wouldn't be a bad idea.
  From their new directory, run rws08.cmd and have it register the
  RWS08 class.  This pair will now be the only ones that mozapps use.

I'm puzzled why rwssrv07.dll is locked - no mozapp has used it in
several years.  If you have a utility to deregister WPS classes
(or you have rws07.cmd) use it to deregister the class.  If that
fails, kill the WPS, then delete it.  The RWS07 or RWS08 classes
are *never* loaded automatically by the WPS (except as described
above).  Their dlls are only loaded when an app needs them and
_should_ be unloaded when the last app using them terminates.
(Note that simply opening a mozapp does not load the dlls - the
app has to ask for an icon or the name of a helper app first.)


--
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |         DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2
Reply | Threaded
Open this post in threaded view
|

Re: DLLs won't go

Trevor Hemsley-2
In reply to this post by Dave Yeo-3
On Sun, 19 Oct 2008 22:52:37 UTC in mozilla.dev.ports.os2, Dave Yeo
<[hidden email]> wrote:

> On 10/19/08 01:52 pm, rafe wrote:
> > I'm 99% sure I can get rid of them without worry while booted to a
> > maintenance partition,
>
> Simpler then using a maintenance partition is to download the lxlite
> package from hobbes then extract unlock.exe from the package and put it
> on the PATH.

Though if you use the UDF filesystem on DVD or CD-RWs then you also want to
rename one of the unlock.exe's that each provide so that they do not
repace/interfere with each other.

--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
_______________________________________________
dev-ports-os2 mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-ports-os2