If perl used native file handles instead of MS CRT file handles, ...

It doesn't so the speculation is moot. And in any case, that idea directly contradicts your own assertion that C Std Lib pulls it off.

And think through the knock-on effects of that idea. What would Perl on *nix use? It only has CRT filehandles.

Finally, my assertion was made in the context of a discussion about non-core IPC modules, not re-writing the entire Perl core.

Windows Alertable IO/APCs are an improved implementation of unix signals

I absolutely agree that POSIX signals are a fundamentally flawed concept & that Asynchronous IO is a far better approach...

But seriously, suggesting the latter is a "better implementation" of the former is like suggesting that hydraulically operated anti-lock brakes with carbon-fibre pads and ceramic disks are a "better implementation" of jamming a stick in the wheel spokes.

Although the goals are similar, it's more 'a completely different approach to solving the problem' than a "better implementation".

Your absolutely wrong. If your claiming thats not true,

All that just goes to prove the futility of trying to emulate one operating systems behavior within another.

More grist to my mill that emulators are a waste of programmer effort in a world that has hardware assisted VMs; and further refutation of this:

No. My opinion is that they are much more efficient than a VM.

Upon which we will simply have to agree to differ.

Emulators are always bug-ridden; always out-of-date; and always slow. I can see no point at all in using them.

On my previous machine -- a lowly, single core P4 system -- I had Ubuntu running in a VirtualBox VM and could run Linux consoles (almost) transparently on my XP desktop. I then went a step further and ran XP inside a VM inside the XP hosted Ubuntu VM.

I wouldn't recommend the latter, but I can see no reason to run buggy, out-of-date emulations when you can run the real thing in a VM.