I didn’t realise that Win32 is a “magic” module — that explains a great deal.

Unfortunately, that's only half of the story.

Win32 ports of Perl implemented some functions in core, but in the namespace Win32, so they were available without having to load the Win32 module, and without loading the module. Other functions were implemented only in the Win32 module and were available only after that module had been loaded.

That's not very clean, but at least it was documented by marking all in-core functions with [CORE] in the documentation of the Win32 module.

Now (and that's new to me, too, just reading the documentation Win32CORE and Win32), the functions marked with [CORE] are no longer in-core, they are replaced with stubs that implicitly load the Win32 module.

I don't think the stubs are much cleaner than having the functions in core. But at least it allows to update the Win32 code independant from perl. I would have prefered extending the heuristics for "(perhaps you forgot to load "%s"?)" to detect when a [CORE] function was called without having loaded the Win32 module. This way, perl -E "say Win32::OSVersion()" would result in the error message "Undefined subroutine &Win32::OSVersion called (perhaps you forgot to load "Win32"?)  at -e line 1." instead of just "Undefined subroutine &Win32::OSVersion called at -e line 1.". But that would have caused badly written old scripts to complain or crash, and as we all know, that's a no-go for new perl versions. Well, except for given/when and the smartmatch operator.

The difference between Win32 [CORE] and Win32 non-[CORE] functions never made sense for me. Win32::BuildNumber() is specific for ActiveState Perl and is by definition not portable, not even to other Win32 ports. All other functions could be in an external XS module, as they are mostly thin wrappers for Win32 API calls.

Alexander