[comp.windows.ms.programmer] Port I/O and interrupts in Windows

davidds@microsoft.UUCP (David D'SOUZA) (12/20/90)

In article <16648@brahms.udel.edu> garrett@brahms.udel.edu (Joel Garrett) writes:
>Hello fellow cwmp readers!  I am working on a project that has controlled a
>set of stepper motors through a controller/interface card that has been
>operated via IN and OUT statements in either MS C or QuickBasic in real mode
>under MS-DOS.  We want to develop a newer version of this application that
>would make use of Windows 3.0 for its user interface.

A reasonably educated guess says that you probably won't have any
problems doing the INs and OUTs from a Windows program.  In real mode
and standard mode there are no problems.  In 386 enhanced mode, you
have to be careful because (potentially) the instructions could take a
"long" time.  386 Enhanced mode is a virtual machine so some ports are
virtualized (ie. basically the instructions now take longer to execute
because ports are trapped). Since you were doing this in basic, you
probably aren't concerned about moving lots of data  quickly so you
shouldn't have problems.  I believe Windows 386 may also need to make a
ring transition before doing the actual OUT or IN, which slows the
instruction a little further... (If this timing is a concern, you'll
need a DDK which will allow you to write a Win386 virtual device driver
(VxD) to fix this.)  Also, if you want to control this stepper motor
from different virtual machines ie dos boxes, you will need a VxD.

As for hooking interrupts from a Windows DLL (interrupt hooks should be
in DLLs), you need to be careful in the protected mode environments
(Standard and Enhanced mode).  If you use the int21 service (ah=35h) to
hook an interrupt from a Windows DLL, you will be hooking on the
protected mode interrupt chain ie. the processor will be in protected
mode when you get called back and addresses are selector:offset.  If
you want to hook the real mode chain, you will need to use one of the
DPMI services ie. the processor will have transitioned into real mode
and any addresses are segment:offset.  Communicating with a DOS TSR you
may want to hook the real mode chain otherwise any addresses you pass
back to the TSR will be meaningless or you will have to map them using DPMI
services...

--Dave