dwa@sdcc12.UUCP (Don Anderson) (03/27/85)
I am running MS-DOS 2.11 on an AT&T 6300. I have a modified COM driver which I am using to drive async port #2 (ASYNC from Mike Higgins) to which I have the source assembly code, so I can tell what it does. In trying to use this driver to send data out to various devices, I discovered that control-Z's weren't making it if I used the write function for a text file from Turbo Pascal. To eliminate the possiblility that it was Turbo that was intercepting the character, I switched over to MS-DOS systems calls - specifically, I opened the file with a call 03DH and wrote to it with a call 040H. Everything goes through just fine except when I try to write a control-Z to the device. I get back a result of 0 characters written and nothing goes out the port. Insofar as I can tell, MS-DOS is intercepting this character, presumably because it considers it to be an end of file character. When one is driving a graphics printer, this is excessively "user-friendly". I can kludge my way around this by creating a special variant call indicating the intention to send a control-Z, through DOS call 044H (IOCTL) if I modify the device driver. Otherwise, I could bypass DOS entirely, but I hate to do that. The AT&T provided COM2: driver and the IOCTL service provided through MODE seem not to work at all, producing write fault errors on everything sent to COM2:, though GW BASIC can use this port if one opens a file to it using the "ds" option to do some undocumented thing to the dsr line. I have not checked whether or not GW can send a control-Z to COM2: successfully, as it is against my principles to use BASIC. Has anyone else had this problem? Is this a feature of MS-DOS? Is there any "standard" way to get around it? -don anderson