Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!hpfcso!hpcndpc!jjw
From: jjw@hpcndpc.CND.HP.COM (Jimmy Wright)
Newsgroups: comp.windows.ms.programmer
Subject: Re: connecting Win30 (386 enh) programs to devices
Message-ID: <36330006@hpcndpc.CND.HP.COM>
Date: 22 Apr 91 17:11:48 GMT
References: <1991Apr19.195538.23441@ux1.cso.uiuc.edu>
Organization: HP Colorado Networks Division
Lines: 57

>> I want to use Windows 3.0 (386 enhanced mode) to talk to a device
>> (an ADC convertor) that requires interrupts. I got this to work
>> just fine by writing a DOS character device driver .sys file, and
>> sending commands to it with ordinary DOS writes and getting data
>> with ordinary DOS reads. But this appears to only transfer ONE byte at 
>> a time. Its inefficient.

>> So I tried using the DOS IOCTL calls - which can transfer several bytes per
>> call. I used the MSC 5.1 intdos call. Works fine in real mode -
>> bombs in standard and 386 mode.

	Are you making the DOS calls from a Windows Application?
	If you are then your problem is your passing addresses that address
	extended memory( i.e. Protected Mode ) to DOS which can only address
	memory below 1MB (i.e. Real Mode).

	For Standard Mode a piece of software called DOSX.EXE (its a
	Dos Extender) is suppose to copy the buffers to real mode addresses
	and pass the Real Mode address to DOS.  Then on the way back from
	DOS it will copy the Real Mode buffer back to the original Protected
	mode buffer and deallocate the Real Mode buffer.  The problem is
	that DOSX.EXE doesn't properly handle the IOCTL commands AX=4402,
	or AX=4403 correctly.  This has been confirmed by Microsoft.  The
	only work-around is to pass Protected Mode addresses that address
	memory below 1MB.  This can be done from a Windows Application by
	calling GlobalDosAlloc() to allocate memory below 1MB.

	DOSX.EXE is suppose to do this buffer copying for all DOS
	commands that are passed buffers from the user's space.  So there
	could be other commands that DOSX.EXE screws up on.  The DOSX.EXE
	also handles ROM BIOS calls that point to the users's address
	space.

	You should also be aware if the buffer you pass down through the
	IOCTL call also contains pointers to your applications address
	space then you will have problems.  The DOSX.EXE cannot translate
	pointers embedded in your buffer, since your buffer could have
	any format that you desire.  You will have to explicitly handle
	embedded pointers yourself via the GlobalDosAlloc() call mentioned
	above.

	In Enhanced mode a virtual device driver called DOSMGR (its built
	into the WIN386.EXE kernel file) does the buffer translation.
	I personally haven't seen any problems in its use.  I believe I
	tested the IOCTL commands and they worked correctly.  Again you
	would have to worry about pointers (if any) you have embedded in
	the buffer your passing to DOS.  You can try the GlobalDosAlloc()
	call for Enhanced mode but like I said the DOSMGR seems to do
	a much better job of buffer translation than the DOSX.EXE module
	does for Standard mode.

>> How does one do this? Tools I have: MSC5.1, the Windows 2.11 SDK, 
>> and assembler. I also run Qemm386.

>> Doug McDonald (mcdonald@aries.scs.uiuc.edu)

	JJ