Armin wrote:
>I need to access I/O ports as well as memory locations of some special
hardware under NT/2000. I know, this usually has to >be done by a ring-0
driver. However, I don't want to go through the DDK hell ;-)
>I know that there are some "generic" drivers around that can be used at
least for I/O port access. But in addition I need to >access memory
locations - some "old" DOS programmers might remember expressions like
mem[A000:0000].....
>Does anyone know something to do this?? Freeware would be mostly
appreciated.
>Thank's for any help!!!!
>Armin
In any event you will have to develop a service module that talks to your
card. From the user application point of view, your application cannot
directly talk to I/O ports.
From the Win2k DDK:
http://www.microsoft.com/DDK/DDKdocs/Win2k/
Chapter 1 Summary of Kernel-Mode Support Routines
This chapter summarizes the kernel-mode support routines that can be called
by Microsoft® Windows NT®/Windows® 2000 and WDM kernel-mode drivers. Drivers
can also use routines provided by a compiler, such as C string manipulation
routines.
Support routines are categorized as follows:
* Initialization and unload in Section 1.1
* IRPs in Section 1.2
* Synchronization in Section 1.3
* Memory in Section 1.4
* DMA in Section 1.5
* PIO in Section 1.6
* Driver-managed queues in Section 1.7
* Driver-dedicated system threads and system worker threads in Section
1.8
* Strings in Section 1.9
* Data conversions in Section 1.10
* Access to and access rights on driver-managed objects in Section
1.11
* Handling errors in Section 1.12
Some routines are listed in more than one section or subsection of this
chapter.
1.3.3 I/O Ports
In the MS-DOS environment, a peripheral board typically has a range of I/O
ports to which it can respond. These ports are often configured by jumpers
on the board or through software setup. Special-purpose application programs
control and communicate with the board by performing 80386/80486 assembly IN
and OUT instructions to the ports supported by the board.
In Windows NT/Windows 2000, application programs have insufficient processor
privilege to access I/O ports. Therefore, the VDM intercepts IN and OUT
instructions from MS-DOS application programs and attempts to find an I/O
handler registered by a VDD for the specified port. Each VDD installs I/O
handlers (also known as I/O hooks) for one or more ranges of port addresses.
For example, a VDD could install I/O handlers for the port range 0x220-0x227
and 0x2F0-0x2F7. The VDM keeps track of all I/O port handlers installed by
VDDs in that VDM. When the VDM intercepts an IN or OUT instruction from an
MS-DOS application, it looks at all the installed I/O handlers to see if the
current port being accessed falls within one of the installed port ranges.
A VDD must install I/O port handlers for the ports used by its application.
The handlers are called each time there is an IN or OUT instruction on one
of the designated ports. A VDD OUT handler typically gathers several OUT
calls into a single complete command and then translates that command into a
Win32 DeviceIoControl call to the kernel-mode device driver for the board.
Likewise, a single driver call might require a VDD IN handler to be called
several times to completely transfer the information back to the
application.
A VDD installs its I/O port handlers within the VDD initialization routine,
explained in Registering the Driver . Initialize a
VDD_IO_HANDLERS structure with pointers to the VDD's I/O port handlers,
specifying one or more ranges of I/O ports the VDD responds to, and call the
VDDInstallIOHook function. The VDD_IO_HANDLERS structure contains slots for
IN and OUT handlers for byte, word, and string operations. The VDD must
supply at least byte-in and byte-out handlers. If you supply a NULL function
pointer for the word and string operations, the VDM automatically emulates
them by calling the byte operation functions the VDD provides, although it
is often more efficient to implement word and string operations yourself.
A particular VDD can only have one set of I/O handler functions for all the
I/O ports it uses. That is, a VDD cannot install one set of functions for
one I/O port range and another set of functions for another port range. Of
course, other VDDs can install their own functions for other ranges,
although two VDDs in the same VDM cannot use overlapping port ranges.
A VDD's main entry point function is also called when the VDD is about to be
terminated. At that time, the VDD can deinstall its I/O hooks by calling
VDDDeinstallIOHook.
Note A VDD should never directly hook the I/O ports for DMA or Video. Video
is handled by the VDM. See DMA for a discussion of how to
facilitate DMA transfers in the VDM environment.
The following functions are used with I/O hooks:
Function Description
VDDInstallIOHook Hooks the I/O ports the VDD is responsible for.
VDDDeinstallIOHook Unhoooks the I/O ports previously hooked by a VDD.
http://www.microsoft.com/DDK/DDKdocs/Win2k/vmport_3yuf.htm
6.4.2 Claiming Legacy Resources
A video miniport driver must claim and report all legacy resources in its
VIDEO_HW_INITIALIZATION_DATA structure during driver
initialization. Legacy resources are those resources not listed in the
device's PCI configuration space but that are decoded by the device. Windows
NT/Windows 2000 will disable power management and docking when it encounters
legacy resources that are not reported in the manner outlined in this
section.
Miniport drivers must do the following to report such legacy resources:
* If the legacy resource list for the device is known at compile time,
fill in the following two fields of the VIDEO_HW_INITIALIZATION_DATA
structure that is created and initialized in the
DriverEntry routine:
Structure Member Definition
HwLegacyResourceList Points to an array of VIDEO_ACCESS_RANGE
structures. Each structure describes a device I/O port
or memory range for the video adapter that is not listed in PCI
configuration space.
HwLegacyResourceCount Is the number of elements in the array to
which HwLegacyResourceList points.
* If the legacy resource list for the device is not known at
compile time, implement a HwVidLegacyResources function
and initialize the HwGetLegacyResources member of
VIDEO_HW_INITIALIZATION_DATA to point to this function. For example, a
miniport driver that supports two devices with different sets of legacy
resources would implement HwVidLegacyResources to report the legacy
resources at run time. The video port driver will ignore the
HwLegacyResourceList and HwLegacyResourceCount members of
VIDEO_HW_INITIALIZATION_DATA when a miniport driver implements
HwVidLegacyResources.
* Fill in the RangePassive field for each VIDEO_ACCESS_RANGE structure
defined in the miniport driver accordingly. Setting RangePassive to
VIDEO_RANGE_PASSIVE_DECODE indicates that the region is decoded by the
hardware but that the display and video miniport drivers will never touch
it. Setting RangePassive to VIDEO_RANGE_10_BIT_DECODE indicates that the
device decodes ten bits of the port address for the region.
Again, a driver should only include resources that the hardware decodes but
that are not claimed by PCI. Code in a driver that needs to claim minimal
legacy resources might look something like the following:
// RangeStart RangeLength
// | | RangeInIoSpace
// | | | RangeVisible
// +-----+-----+ | | | RangeShareable
// low high | | | | RangePassive
// v v v v v v v
VIDEO_ACCESS_RANGE AccessRanges[] = {
// [0] (0x3b0-0x3bb)
{0x000003b0, 0x00000000, 0x0000000c, 1, 1, 1, 0},
// [1] (0x3c0-0x3df)
{0x000003C0, 0x00000000, 0x00000010, 1, 1, 1, 0},
// [2] (0xa0000-0xaffff)
{0x000A0000, 0x00000000, 0x00010000, 1, 0, 0, 0},
};
// Within the DriverEntry routine:
VIDEO_HW_INITIALIZATION_DATA hwInitData;
hwInitData.HwLegacyResourceList = AccessRanges;
hwInitData.HwLegacyResourceCount = 3;
The miniport driver can "reclaim" legacy resources again in subsequent
call(s) to VideoPortVerifyAccessRanges ; however, the
video port driver will just ignore requests for any such previously claimed
resources. Power management and docking will be disabled in the system if
the miniport driver attempts to claim a legacy access range in
VideoPortVerifyAccessRanges that was not previously claimed in the
HwLegacyResourceList during DriverEntry or returned in
the LegacyResourceList parameter of HwVidLegacyResources
.
If you don't want to wade through all the DDS or SDK stuff, you would be
better served to get a kernel driver developer to help you out.
Try
http://www.jungo.com/
http://www.bsquare.com/default.asp
http://www.chsw.com/ddk/
All the best
David*Vukovic
Harris county Juvenile Probation Department
Houston, Texas
[eof]