You've hit the nail on the head.

The biggest problem (for the none *nix developer), that I've seen in my forays into Perl sources, is that (understandably given it's origins), most of the Perl sources are written directly to the architecture and semantics of *nix system calls and methods. Where the underlying OS does not directly support those architectures and semantics, it is up to each developer on each non-*nix OS to add conditional code in-situ, at the site of each use, to emulate the *nix behaviours.

It is the combined effect of the conditional codes for all the non-*nix OSs, (along with variations of minor tweaks and fixes for the myriad not-quite-*nix-compatible *nix-like platforms), that is responsible for a large part of the complexity and fragility of the sources.

It is made even worse by the need to apply the same conditional fix/work-around in-situ at each place in the sources where it is used. This just exacerbates the potential for the multiple implementations of the same fix to get out of synch. It's the cardinal sin of c&p code reuse. Your example of file open & sharing modes above relects the problem exactly.

It gets worse where a pair (or more), of related but otherwise atomic posix system calls, which get used directly in-line in the Perl sources, require a combination of 2 or 3 Win32 (or other platform) system APIs to achieve the same function. And it gets even worse when there is a need to convey some information (like OS handles) between the open and close sequences of a bracketing pair of calls. If the posix pair do not require the passing of a handle, then there is no provision in the architecture for this.

The architectural solution to this problem, for all platforms, not just Win32, would be to isolate OS dependant calls from the perl sources. Essentially, this would require building a Perl virtual OS layer and removing all system calls from the core sources in favour of calls to the virtual OS layer. The Perl sources would call the virtual OS functions and the platform dependant equivalents are conditionally compiled in to perform that function. In many places this has already been done--PerlIO is a good example.

The problem is that in a lot of cases, the virtualisation is done at too low a level. They require a one to one correspondance between the virtualisation and the underlying POSIX apis. When the OS is unable to easily provide that one to one correspondance, the need to cut&paste platform dependant fixes all over the source tree returns.

Of course, it is entirely the wrong time, too late, to attempt to address this properly in P5. Unfortunately, unless a cross-platform white knight has become involved in Parrot recently, that was headed in exactly the same direction.

However, I think there is a solution (for win32), that could be retro-fitted to the P5 sources without creating wholesale mayhem. It would require considerable effort; at least 3 or 4 commited, knowledgable, Win32 developers--though not necessarily all full time; and the involvement and support of 1 or 2 of the deeply knowledgable p5p source gurus. Essentially, there are already a bunch of Win32 OS specific virtual functions conditionally build into and exported from perl5x.dll. All the stuff that resides in win32\Win32.c.

The project would involve removing as much of the Win32 conditional code from the core of the sources and replacing it with calls to new virtualised functions added into Win32.c (or probably better Win32v.c or similar). This would benefit all p5 programmers. Core *nix programmers would have considerably less Win32 conditional code to work around. Win32 p5p developers (like yourself & Steve) could concentrate your efforts in one place more easily. And cross-platform developers and module writers would gain access to the Win32 equivalents of *nix functions exported from the Win32\* sources rather than needing to invent their own workarounds or cut&paste existing code.

Like you, I absolutely applaud and encourage any moves/projects that will enable Perl on Win32 to

1. Be less of a problem for non-Win32 authors to write modules that will easily port to Win32.
2. Be less of a source of bug-reports and grief to the p5p efforts in general.
3. Give me greater access to the facilities and semantics of my chosen platform.

My fear is that, as currently envisaged and described, the Vanilla/Strawberry projects, and this particular effort are not likely to achieve any of these.

I feel that the situation is analogous to General Motors designing and proposing a solution to the current fuel crisis and expecting Toyota (and Honda and Ford and BMW) to implement their solution without consultation or input.

The current proposal seems to revolve around allowing more modules written originally for non-Win32 platforms to be seen as functional on Win32, as measured by some statistic (currently the AS autobuild process). However, I think that as currently conceived, the project will achieved very little in the long term. Perhaps the problems that prevents the AS autobuild process from passing more modules is that it is automated. And as the endemic solution to compatibility problems is to hand-code in-situ, conditional work arounds to each problem as it arises, the automated approach cannot do that.

Whilst a short, concentrated effort now may result in a bunch of immediate fixes to individual incompatibilities, without an architected solution that allows those fixes to be virtualised and embedded into the core, the efforts would only allow a short term hiatus in the problems because new authors and new modules would be forced back into writing individual fixes to known problems with known solutions as soon as the manual 'bug hunt and fix' effort subsided.