Re^7: [JOB] The Perl Foundation seeks Windows Developer

Needless to say, (or perhaps it does need to be said?), I do understand both the problem you addressed and the MoveFileEx & MOVEFILE_DELAY_UNTIL_REBOOT solution that I assume you have used to address it.

As an aside to the primary subject of this thread, I believe that for most situations, (Ie. excluding the one you cite of a longing running Perl process that is using the DLL that is to be replaced), there is a somewhat easier solution that removes the need for the above API. I need to test it, but I will post/email you the details once I have and you can see if you think that it merits inclusion as a part of your fix.

In simple terms, if the module to be replaced is in use only by the current perl process (Ie. the one attempting to perform the replacement), then calling FreeLibrary(), or possibly FreeLibraryAndExitThread(), then overwrite the DLL, and the call LoadLibrary() to make the new version available to the current process--if required.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^7: [JOB] The Perl Foundation seeks Windows Developer Select or Download Code

Replies are listed 'Best First'.
Re^8: [JOB] The Perl Foundation seeks Windows Developer by demerphq (Chancellor) on Apr 03, 2006 at 14:28 UTC
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. --- $world=~s/war/peace/g	[reply]

Replies are listed 'Best First'.

Re^8: [JOB] The Perl Foundation seeks Windows Developer
by demerphq (Chancellor) on Apr 03, 2006 at 14:28 UTC

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.

---
$world=~s/war/peace/g

[reply]