I disagree

You are entitled to your opinion, but nothing in the rest of your post suggests that opinion has any merit.

C Std Lib pulls it off.

Really? Can you use select on an win32 pipe? Or stdin?

use IO::Select;;
IO::Select->new( STDOUT ) or die $^E;;
@s = $s->can_read() or print "$^E";;
An operation was attempted on something that is not a socket
[download]

Interix and Cygwin pull it off.

That's like saying that a campervan pulls off being a house.

Cygwin was always a dog; and never got beyond POSIX 1 as far as I can tell.

Interix was deliberately ham-strung from the moment MS purchased it. They didnt want it to become a viable alternative development environment for windows. They offered and supported it only as a stop-gap to transitioning *nix software suits to the Windows Server environment. It will not ship with Windows 8.

If you want to develop in a *nix environment; install one of the billion free distributions. If you need to run a mixed environment, use an VM. It simply makes no sense to use a POSIX-1 emulator.

Signals on Windows are called Alertable IO. "

That is so wrong it defies refutation beyond this link.

MS Alertable IO has exactly zero to do with "POSIX signals"!

"Safe" signals on Win32 Perl are Windows Messages on the message queue,

Windows doesn't do POSIX signals.

"Safe signals": a) are purely a Perl concept; b) apply to Perl on *nix just as much as they do on Windows; c) the "safe" bit simply applies to when signals are responded to by the Perl interpreter, not how they are implemented.

The message queue is used to by Perl to implement its emulation of signals on Windows.

non-safe signals (CRT Ctrl C and exit) usually will crash the perl interp since they actually run from another thread.

That is about as far from the truth as it is possible to get.

Perl uses the SetConsoleCtrlHandler() function to allow it to handle the various console events.

Take a close look at Perl_sys_intern_init() & win32_ctrlhandler() in Win32.c for the details of how Perl emulates POSIX signal handling for a limited number of signals.

The signals emulated include INT, QUIT, TERM, and BREAK which are all trappable. All others non-trappable and cause the process to be terminated, cleanly via TerminateProcess().

1. Perl doesn't "crash" when it receives ^C.

   If you've installed a SIGINT handler. then it gets control:

   C:\test>p1
   [0] Perl> $SIG{INT} = sub{ print "Got ^C" };;
   [0] Perl> Got ^C
   Got ^C
   ;;
   [0] Perl>
   [download]

   If you haven't, the processes is cleanly terminated.

if you what you mean by "common interface" means "compile and go api compatibility", then no.

What I mean, is exactly what I said: IMO, Windows and *nix/POSIX IPC are just too different to successfully wrap them over in a common interface.

*nix IPC revolves around: a) fork & exec; b) signals; c) selectable, non-blocking IO; d) pipes; e) Unix domain sockets.

Windows has its own IPC mechanisms: a) Clipboard; b) COM; c) Data Copy; d) DDE; e) File Mapping; f) Mailslots; g) Pipes (Anon;Named;stream;message); h) RPC; i) Windows Sockets.

Even where the names on the different platforms are superficially similar; the implementation details are sufficiently different to make writing a common interface necessarily a lowest-common-denominator-via-crude-incomplete-emulation exercise that benefits no one.