Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 beta 3/9/83; site microsoft.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!cornell!uw-beaver!microsoft!bryanwi From: bryanwi@microsoft.UUCP (Bryan Willman) Newsgroups: net.micro,net.micro.pc Subject: DOS Printer driver question Message-ID: <8759@microsoft.UUCP> Date: Wed, 3-Jul-85 17:29:36 EDT Article-I.D.: microsof.8759 Posted: Wed Jul 3 17:29:36 1985 Date-Received: Sat, 6-Jul-85 09:31:55 EDT Organization: Microsoft Corporation Lines: 37 Xref: watmath net.micro:10933 net.micro.pc:4459 Microsoft is working on the next release of DOS - which will be a full multitasking system. This naturally requires some changes to the print spooler package, as well as to the internal management of the printer device driver and the ROM INT17 code. In order to do this work in a way that won't break existing third party printer systems, we need some information on how custom printer drivers have actually written for Dos. We're aware of three different ways that such a driver might be implemented: 1. As a full blown dos installable device driver, that does not hook int17, but communicates with applications through open, write, close, etc. 2. As an installable device driver that hooks int17. (This amounts to a terminate and stay resident that actually gets loaded at init time.) 3. As a terminate and stay resident program that hooks int17. The question: How are real world printer drivers actually done? We believe that those printers which are not software compatible with the supported IBM printers have packages which use technique #3 to support them. Is anyone aware of any package that uses either of the other two techniques, or a technique not listed? If so, please let us know ASAP. Thanks Bryan Willman Microsoft /decvax \!microsoft!bryanwi \uw-beaver/