Paul Moore <[EMAIL PROTECTED]> writes:
>
>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.
Fair.
>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.
There is something to be said for the UNIX approach that "everything is
a file handle" view of the world, but for "event" purposes even on
UNIX not all file handles are equal :-(.
>
>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!!)
But sadly they designed in all the backward compatible Win16 stuff
as though it belonged there. Why do we need to use different API to see
if Socket, the Console, a Pipe has more data for us?
>and so the model is very rich,
== inconsistent ;-)
>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.
The big challenge is to allow mixing of NT-ish "Handle" based events
with Win16-ish GUI-messages.
NT's Handle scheme is essentialy just UNIX's "everything is a file descriptor"
abstracted one more level so that "A file descriptor is just one kind of
Handle". That unifies files, pipes, processes (and almost but not quite
Sockets and the Console). But sadly as far as I am aware there is not
a clean API what applies to "any Win32" that unifies GUI messages with
the Handle family.
>
>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.
Because of this very issue Event is supposed to be "modular" in that
you can add new watcher types at the C level where the "native" C API
is available. But then these watchers all look the same to the perl code.
_*BUT*_ the innermost "wait for next event" needs to be very OS specific.
On modern UNIX is fundamentally poll() which waits for selected events.
On Win32 it wants to be MsgWaitForMultipleObjects() - but also work
on Win9X and WinCE !
>
>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.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
