Re: Hello all
----- Original Message -----
From: "Ching, Jimen" <Jimen.Ching@SpirentCom.COM>
To: <debian-win32@lists.debian.org>
Sent: Friday, November 16, 2001 7:00 AM
Subject: RE: Hello all
> >The one major problem I see with this whole setup is the one you
listed as
> >problem number 1, which is that Win32 won't allow for any
interactions with
> >a file that is already opened, and this makes for some interesting
> challenges
>
> I guess this is why all of the install tools (InstallShield, etc)
always
> recommend exiting all programs before running setup. setup.exe could
do
> the same. It would be consistend with other Windows app. behavior.
Well, it cannot if it is being run from within (say) dselect. Oh, you
mean dpkg there? Well dpkg has the same issue, and the same constraints.
> >in the area of updating/upgrading already running processes,
especially
> >the cygwin1.dll file. Additionally, there is the whole "chicken/egg"
> problem.
> >(How do you get/install dpkg to run dpkg to install dpkg.....)
>
> I may be ignorant of cygwin1.dll's purpose, but isn't it a kernel? It
> provides system calls like fork and open, does it not? If so,
upgrading
> cygwin1.dll is like upgrading the Linux kernel. It requires a reboot.
> Maybe a trick is needed to upgrade this dll. I.e. what if each time
this
> dll needs to be loaded, a copy of it is loaded instead. This way, you
> can still modify the original copy after the new copy is running.
> Hopefully,
> when all cygwin apps exit, the cygwin1.dll is unloaded and deletes
itself.
>
> I have not done this type of wizardry myself, so it is just a
suggestion.
The unloading .dll cannot delete itself. The following tricks are
available:
1) file copy on reboot. Available on 9x and NT via different mechanisms,
the file gets copied on the reboot.
issues: what if multiple files _must_ be updated in parallel? How do we
ensure that this happens instead of only one being upgraded?
2) Warn the user, then close all programs using file foo (say ash.exe,
or cygwin1.dll), then copy the new one into place, and resume setup.
Don't bother restarting all the programs, that is up to the user. If
setup.exe (aka rpm aka dpkg) depends on the file in question, either
fall back to 1) or start up a separate program that does not depend on
the file in question, that performs the operation, and then starts
setup.exe again with appropriate parameters to get it to run
automatically to where it was.
Rob
Reply to: