Classic example is Cwd. CPAN uses Cwd internally. This means the Cwd.dll is locked when you try to build and install Pathtools from CPAN shell. The simple solution is to exit CPAN and go to the Pathtools directory and do the build by hand. But that only works if you are using ExtUtils::MakeMaker to do the build. If you use Module::Build then you have the same problem as CPAN would as MB also uses Cwd.dll

Likewise this problem shows up in situations where you are upgrading XS modules that are in use elsewhere in the system. For instance i have some processes that run 24 hours a day. With the updated ExtUtils::Install I can install new versions of XS modules that this process uses, and it Just Works. Without the new version EU::I Just Fails because the dlls are locked and cannot be deleted.

The strategy employed by the newer EU-I code is to try to rename the locked dll to a temporary name, install the new code, and schedule the renamed dlls for deletion at boot. If the rename fails it installs using a temporary name and arranges the replacement of the in use file at reboot.

So, there are a variety of ways that you could avoid needing this functionality, but that doesnt mean the functionality is unneeded.

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.

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

As I understand it, if a file is open, e.g. C:\perl\lib\CPAN.pm, that file can't be deleted by Windows. You can install a newer version as C:\perl\site\lib\CPAN.pm, but @INC lists C:\perl\lib before C:\perl\site\lib, so you'll wind up using the older version when you think you're using the newer one.

demerphq's patch (not yet on CPAN) uses Win32 API calls that effectively rename the open file, install the new file in place of the old one, and schedule the renamed old file for deletion upon next reboot. (Ever see how Windows install/uninstall programs tell you they can't complete until rebooting? Same thing.)

As I understand it, if a file is open, e.g. C:\perl\lib\CPAN.pm, that file can't be deleted by Windows.

Whilst true, this is a Good Thing(TM) not a bad one. And the simple answer is to close the file before you try and delete it. Of course, that doesn't solve the real problem, but it would for the problem as you describe it.

But the bigger problem is that your understanding of the actual problem that demerphq has addressed in incorrect.

Ever see how Windows install/uninstall programs tell you they can't complete until rebooting?

Of course.

Same thing.

Actually not!

For the real problem see demerphqs post at Re^6: [JOB] The Perl Foundation seeks Windows Developer.

And that succinctly demonstrates my biggest fear with respect to the proposal in the OP. It is being driven by the needs of people who do not know the platform and it's APIs, and are proposing solutions without a full understanding of the real problems, or the possibilities available for solving them.

Did you ever hear/read the lyrics to the old XTC song, Making plans for Nigel?

---

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.

Well, to be fair to xdg, I dont think his characterization is wrong. Its a touch on the simplisitic side, and glosses over some of the finer points, but hes not really wrong.

I think you have a point when you say

It is being driven by the needs of people who do not know the platform and it's APIs, and are proposing solutions without a full understanding of the real problems, or the possibilities available for solving them.

However I see this as an issue of education. Since the VP and SP projects are intended to broaden access to Win32/Perl development enviornments hopefully we can expect to see people start to ramp up their Win32 knowledge and long term we can put aside of sillier UNIX-centric workarounds that have popped up.

Anyway, it would be really nice to have someone like yourself contributing to this effort, so I really hope you decide to help out.

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