From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,27d2d03d60db9bd1,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-11-02 19:15:48 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!news2.near.net!news.delphi.com!usenet
From: tmoran@bix.com
Newsgroups: comp.lang.ada
Subject: Re: Ada replacements for DOS I/O
Date: 3 Nov 1994 03:15:48 GMT
Organization: Delphi Internet Services Corporation
Message-ID: <399kl4$4fv@news.delphi.com>
NNTP-Posting-Host: bix.com
Date: 1994-11-03T03:15:48+00:00
List-Id: <comp.lang.ada>

>... built their I/O packages around a "two process" model.  The main
>program and all user defined tasks run in a single process, but you
>have a package that mediates all I/O events and hands them to a second
>process which does the waiting and event handling.
As I recall from writing a DOS RAM disk driver many years ago, DOS
device drivers are structured with two calls, one to start (or queue)
the operation, and one to get the result.  So the single tasking must
come from broken implementation somewhere, not broken device driver
interface design.
('All your problems will be solved by Windows xx, from the company
that brought you MSDOS!') O.O