MoveFileEx & MOVEFILE_DELAY_UNTIL_REBOOT solution that I assume you have used to address it.
Yep, thats the one. And some weird logic with renaming and stuff but MoveFileEx is the tricky part.
In simple terms, if the module to be replaced is in use only by the current perl process
Yeah, i thought about this too. Actually we thought of a number of tricks, but eventually there was something like a consensus that using MoveFileEx would be best as its covers all the scenarios thus means its a fairly simple mechanism. Using FreeLibrary() would only really resolve DLL related problems within a limited context, and we have reason to believe that other contexts are common enough that they should be dealt with. I mean, one advantage to the current setup is that a program could reinstall something like the MSVCRT dll if it needed to.
There is also another use case to consider, the default open mode for native Win32 perl is to open with r/w sharing, but not delete sharing. This means that a module that ends up leaving a filehandle open (say because it has a DATA section) will be opened in a form that cant be deleted nor renamed. Using MoveFileEx even such a file as this could be dealt with, albeit with a potential reboot.
Anyway, unfortunately I scheduled the ex-ExtUtils-Install releases for deletion in preparation of releasing a new production version of ExtUtils-Installs, but there is a good chance you can still get it from CPAN. The latest contains a thinko relating to MANIFEST.SKIP so it might be best to wait for the "release" version which wont happen until weds or so. Anyway, id love to hear any feedback you might have, or if you feel up to it, any patches you might want to contribute.
In reply to Re^8: [JOB] The Perl Foundation seeks Windows Developer
by demerphq
in thread [JOB] The Perl Foundation seeks Windows Developer
by adamk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |