Newbie switching from TCL

[Paul Duffin]

Jeffrey Hobbs wrote:
> 
> Paul Duffin wrote:
> >
> > Alex Martelli wrote:
> > >
> > > "Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
> > > news:WMCNkKAOfDp5EwGf at jessikat.fsnet.co.uk...
> > > > I use select only because it's in python for sockets. In win32 Tcl
> > > > I used the event model which relied on threading to do the notification.
> > > > I regard that as rather strange especially since as you so helpfully
> > > > point out there are dozens of ways to do it.
> > >
> > > Tcl's architects may have chosen that architecture for portability
> > > reasons.  There may be a few ways to do general eventing on
> > > System V, a couple more to do it on BSD, a few more to do it
> > > in VMS, yet others for Win32, MacOS, BeOS, etc, etc -- but if
> > > you want to use a single architecture and do a decent job of
> > > covering them all, you're probably left with auxiliary thread[s]
> > > as maybe the only choice that stands a chance.
> > >
> >
> > I think the reason why Tcl's architects chose that approach was that they
> > simply do not know all of the Windows specific ways of doing things. They
> > are also UNIX people at heart so "select/poll" *IS* the only way to do
> > event driven I/O.
> >
> > They started off with the mapping from select to WaitForMultipleObjects
> > and tried to make everything fit into that. By the sounds of it there
> > may be better ways to do this.
> >
> > BTW. Does overlapping I/O work with sockets ?
> 
> To set the record straight, the guys that did the initial Windows port
> were Windows-savvy (if still likely with a Unix bent).  However, the
> real PITA that they have to deal with is support for Windows 3.1 and
> 16 bit programs (shudder).  That's been totally ripped out since the
> last few versions, but 5 years ago that was important to some.  Although
> it has been ripped out, we haven't had the opportunity to rearchitect
> the Windows I/O from the ground up.   And yes, we have looked at
> (are looking at) overlapped I/O.
> 
> At the time, the way it was implemented in Tcl was about the most
> efficient working cross-platform way to do things.  Even now it isn't
> a bad way, just a stylistic choice.  Life would be much easier if one
> could ignore the entire Win9* line as well, because remember that it
> isn't just about choosing the best "documented" API, you have to choose
> one that works, and MS is notoriously bad for good-looking APIs that
> all need work-arounds.
> 

Thanks for the clarification Jeff, I keep forgetting that Tcl used to
work with Win 3.1 and how could I forget the differences between Win 9*
and the others.