[fpc-pascal]Synapse for FPC

[Matt Emson]

> But under Dos you would do simple polling, since the eventloop of your
own.
> The rest is event driven. (Dos can also be eventdriven, e.g. Turbo Vision,
> but the eventloop is under your control)

Yes, but doing that in DOS was not trivial. Where as in UNIX it's just a
fork away.

> While with most other OSes/toolkits the OS/toolkit has the eventloop, and
> you only provide callbacks and msghooks.

Yes, but most other moder OS/Toolkits run on top of a mutitasking kernel. If
you're lucky it's preemptive. That wasn't always the case.

> > Now consider M$ Windows 3.1. It had no threaded capability and only very
> > crude methods for yielding to other processes. This is the reason that
M$
> > opted for non-blocking api, and the fact that it eased the event driven
> > model was a bonus rather than a goal.
>
> But TCP/IP and blocking/non-blocking existed before Windows (and probably
> will exist after). Maybe win3.1 that had some effect on the Windows api,
> but not on TCP/IP as a whole.

Never said M$ invented it. Just said that it came about on small OS (small
as opposed to large commercial OS of the 70's like UNIX) because the OS as
they were could not handle blocking TCP/IP.

> > If your app on Win3.1 didn't yield to other processes, you locked
Windows.
>
> This means that your app can't be 100% blocking. However that doesn't mean
> you need to have threads. You app must deblock once every second or so and
> process messages/yield.

Yes. This is how non-blocking api's work, in essence. Surely this is a
circular argument?

Matt