RE: Win32 port

From: Joshua N Pritikin [mailto:[email protected]]
> As seen from here, the problem is that any work involving 
> Win32 seems to demand monitary compensation.  Personally,
> I'm not going to hack Win32 in spare time.  So I think it's
> just a matter of deciding how much it's collectively worth
> to do the port.

Not fair! I'd do Win32 porting (subject to the arrival of a few tuit
shipments). But I don't understand the Unix code. At all. Learning the Unix
constructs, just to be able to emulate them in Win32, is not my idea of fun.
To make it worse, Win32 has a different set (as far as I can see) of
features for event-driven programming than Unix does. Watch a process handle
for completion? Watch the GUI message queue? Watch for a change in the
contents of a directory? So forcing Win32 into the Unix-modelled Event
mindset (remember - I admit to understanding little of the setup here!)
where you can wait on filehandles or timers and that's it seems a retrograde
step.

Maybe I should go back and start trying to understand the Event model again,
but when I last tried, I found the documentation difficult to follow, and
the code totally incomprehensible (due to my lack of understanding of Unix,
I hasten to add!)

The problem with most of these cross-platform issues is generally that there
are very few people who know more than one environment, and so who can
design a useful "synthesised" API, as opposed to a lowest common
denominator. So the end result is often based strongly on one environment,
with others being forced to emulate. Perl is strongly Unix-based, so the
Win32 (and other) ports are naturally pressed to emulate Unix constructs,
for better or worse (witness fork()). But the "impedance mismatch" is high.
Fork is not a good model on Win32 - threads are much better (where I gather
threads are worse than fork for many problems on Unix). Event is a big loser
here, as Win32 is event-driven from the ground up (heck, event handling came
before preemptive multitasking!!) and so the model is very rich, where the
Unix event model is very limited.

To me, Event would be a real "killer" module on Win32, but it would have to
be done properly. If Perl+Event could make Win32 overlapped IO, thread
programming, GUI event loops, event-based Internet programming, etc etc,
easy, then you could get a BIG Win32 following - people who are used to, and
like, the event model, as opposed to Unix people who are just "seeing the
light" as a result of Event.

End of rant. Sorry, I'd LOVE to see Event "done well" for Win32. But I don't
know who has the knowledge to champion it. I'll look again, and TRY to
learn, but I really don't have the time I'd need.

But don't dismiss Win32. Event is needed more (in some sense) there than on
Unix. But the Win32 Perl population is small, and the number who really know
both Win32 and Unix, and who have the time to work on it is even smaller.
And (IMHO) Win32 users *need* to find out about Perl, and about open source,
and about co-operative development like this.

OK, I lied. The rant ends here.

Paul.