Path: utzoo!telly!attcan!uunet!van-bc!jspc From: jonathan@jspc.wimsey.bc.ca (Jonathan Story) Newsgroups: comp.windows.ms Subject: Re: Disable Windows handling of com port in 386 mode? Summary: in system.ini comment out "comm.drv" line Message-ID: Date: 3 Sep 90 09:05:23 GMT References: <4246@tuminfo1.lan.informatik.tu-muenchen.dbp.de> Lines: 33 In article <4246@tuminfo1.lan.informatik.tu-muenchen.dbp.de> rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) writes: > I have a problem with '386 mode of windows 3.0. For its virtualization > of the PC's resources, Windows handles the hardware interrupts of the > serial ports itself. > Because Windows 3.0 does not support the 16550 chip, I wrote a DOS > device driver which uses its advanced capabilities and creates a new > character device for DOS to access the 16550 port. > [....] > But under 386 mode, the driver does not receive any hardware interrrupt > How can I force Windows 3.0 in 386 mode not to handle serial port > interrupts [....] I also have a 16550A chip. In win.ini, I commented out the "com1" and "com2" lines (although this might not be necessary). Then, in the file system.ini I commented the line "comm.drv=comm.drv". As a result, uucp transfers work at very close to the same speed as under plain DOS, although I have had problems with sustained high-speed zmodem reception. I haven't tried changing the values of COMBoost or the other COM parameters in system.ini because I don't know what relationship they have with the (missing) comm.drv. Experimenters and other adventurous fools are encouraged to post their findings to the net. (As an aside from a former Desqview user: there are only two things about Windows which really bother me. One is that I can't quickly switch from one DOS session to another, but have to return to windows, select the next DOS icon, etc. The other peeve is that if I have to terminate a DOS session, Windows doesn't have the decency, unlike Desqview, to close any files that are still open. Maybe in 3.1....)