🚀 go-pugleaf

   Thanks for your reply. You misunderstood my question about the address
format. What I wanted to know was during an I/O transfer if the device driver
provides an IOCtl interface to the application (instead of requiring the application t[C
cation to do a DosRead or DosWrite) would the data address was passed in by the
application 
to the driver (I know that it goes through the kernel and gets formatted to a 
request packet form) be in a 16:16 or 0:32 bit form. Since the kernel does
not do the locking and the virtual to physical address conversion in the 
case of a IOCtl call, I am concerned if for 16-bit applications the data
address (virtual address) that gets passed to the driver would be in a 16:16
form. I want to be able to do data transfer above 64K at a time.
   When you say that you have been compiling your OS/2 2.0 drivers using 
MSC 6.0 and CSET/2 have you been generating 32-bit driver code. (I thought
MSC 6.0 is a 16-bit compiler) If I generate a 32-bit assembler code (for the
entry points) using MASM 6.0 will the code be able to recognize the 16:16 bit
format of the request packet address.
 Also, would anyone happen o know how expensive the DevHlp call VML'VMLock' is ?
When you set the flag to return immediately if enough physical memory is not
available does the page manager (or whatever is in charge of allocating physical
memor) try its levels best to allot pages for you or does it immediately return
after a search for free memory?  Does setting the falg to block till memory 
becomes available cause some active swapping to be initiated?
  I am a little confused by this 16-bit 32-bit hybrid OS/2 model. I would really
appreciate it if you could explain to me the real implications of the OS/2
device driver architecture being 16-bit from a device driver writer's point
of view.