On Mon, 24 Oct 2005, Brian Dessent wrote: > Automatically running rebaseall from setup.exe has issues too. For one > thing, it would run into problems if the user had programs or services > running. The rebaseall script bails if it cannot write to a DLL, so > unless the user was very careful to close all running programs, it would > fail in almost all cases. Rebaseall would have to be modified to rebase > in-use DLLs, but this would require the user to reboot. And, somehow > this would have to be communicated to setup.exe so it could notify the > user. Plus, consider if setup.exe installed a DLL that was in use > (writing it to name.dll.new, and scheduling that for replacement at next > boot) and then rebaseall was run. The rebaseall script would have to > know to rebase name.dll.new and not name.dll. It just gets more and > more complicated. The only workable solution would be to incorporate > the entire rebaseall functionality internally into setup.exe, which is > not an insignificant undertaking, and one which no one is eager to > undertake.
Doesn't setup have similar problem with updating 'packages' for running apps? I think it prompts for a reboot to complete. So I'm guessing the same approach can be used when it needs a rebase. > On top of that, there is a problem with running out of address space. I > don't think this happens (yet!) with the official packages but someone > has reported that it can happen if you suppliment an installation with > some of the Cygwin ports like KDE. So this solution of rebasing every > single DLL is clearly not scaleable into the future, unless the Cygwin > DLL's memory layout is rearranged, or unless DLLs are rebased into > another memory space. Ok - here you are claiming there are fundamental problems with cygwin which rebase might not be able to fix. Satish -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
