WinDriver FAQs

A device driver is a software module that controls hardware. In today’s

operating systems, this software module usually resides in the kernel mode

(ring 0). However, WinDriver enables you to write this code in the user mode,

utilizing our lower-level kernel driver(s), and thus frees you from the need

for any driver development knowledge. For a better understanding of the basic

WinDriver architecture, refer to the WinDriver Architecture page on our site.

WinDriver also includes the

Kernel PlugIn

feature, which allows you to ‘drop’ sections of your user-mode code into the

kernel mode for better performance and greater flexibility (for

PCI/CardBus/PCMCIA/PCI Express/ISA).

Whether the code you develop resides in the user mode or the kernel mode, it is

still the code driving the hardware, and therefore it is a driver (but you can

call it anything you like …).

Using WinDriver, you gain the following benefits:

• Cost — Save 90% of the development time.

• Reliability — WinDriver has been market tested thoroughly in

  thousands of applications (see the

  Testimonials page for

  more on this). It has been debugged on almost every platform in the

  market. Therefore it not only speeds your development time, but cuts

  your debugging time as well.

• Time to market — WinDriver is ready for you today. Using

  WinDriver will drastically shorten your development cycle.

• Flexibility — WinDriver supports multiple operating systems, such

  as Windows 7, Vista, Server 2008, Server 2003, and XP, Windows CE

  (including Windows Mobile), and Linux (depending on the version you are

  using) — so even if you only need your driver on one platform

  today, using WinDriver gives you the flexibility of running under any

  platform tomorrow. (Please refer to

  Technical Document #4

  for a list of the supported operating systems for each type of hardware

  — PCI/ISA/USB).

• Stability — WinDriver keeps you away from the OS kernel. While

  our pre-written kernel module is doing all the transactions with your

  hardware, you write your code in the protected application mode. This

  way you get a kernel mode driver (written by our experienced

  developers), which was tested on practically any OS/platform/BIOS

  combination available and was found rock stable.

Not at all. With WinDriver, you are coding your device driver in the user mode.

WinDriver already provides you with the lower level kernel mode driver,

which implements the WinDriver API (see the

WinDriver Architecture page

on our site). You can, therefore, use your favorite development environment to

program and debug your driver, in the user mode, thereby drastically

decreasing your device driver development time.

Recommended development steps:

1. Start DriverWizard — WinDriver/wizard/wdwizard (or

   /Applications/wdwizard.app on Mac OS X — in WinDriver

   versions that support this OS). On Windows, you can also run the

   DriverWizard using the shortcut icon on your desktop, or from Windows’

   Start menu:

   Start –> Programs –>

   WinDriver –> DriverWizard.

1. Use the graphical DriverWizard to easily diagnose your hardware,

   without writing a single line of code. For PCI/ISA — read/write

   the hardware resources (memory/IO/registers) and listen to

   interrupts.

   For USB — transfer data on the pipes, reset the device, etc.

1. Select the “Generate Code” option from the toolbar, or press the

   Next button. Select your target compiler/development

   environment, and let the DriverWizard create a skeleton of a device

   driver application for your device. The generated code will include

   convenience structures and functions, which utilize WinDriver’s basic

   API to access the resources detected and defined (by you) for your

   hardware.

   You can use the DriverWizard to generate code in C, C#, or Visual Basic

   .NET (VB.NET) (USB only); earlier versions (until v11.2.0) also

   supported code generation in Delphi (Pascal) or Visual Basic (VB 6.0).

   The DriverWizard will also create makefiles and the relevant build

   environment for leading 32-bit and 64-bit

   compilers — such as MS Visual Studio, GCC, or

   Windows GCC (MinGW/Cygwin).

   You can also use one of the WinDriver samples as the basis for your

   development. Specific samples for enhanced-support hardware can be

   found under the relevant directory for that hardware, such as PLX,

   Altera, Cypress, etc. — see the for more

   information regarding WinDriver’s enhanced support for specific PCI and

   USB chip sets.

   General samples, in C, can be found in the

   WinDriver/samples directory.
    

   .NET samples are found in the WinDriver/csharp.net

   (C#) and WinDriver/vb.net (VB.NET) directories

   (beginning with v7.0.0 of WinDriver).

    

1. Use the manual and help files to modify the generated diagnostics code

   and add the specific functionality that you need (if any), in

   accordance with your hardware’s specification.

   The WinDriver user’s manuals and help files are found in the

   WinDriver/docs directory and can also be accessed

   via Windows’ Start menu (for Windows users). All documents are

   also available online from the page.

1. Compile and build your code (from the user mode!) using any

   32-bit or64-bit compiler.

DONE!

Yes. Jungo provides full-featured evaluation versions of the WinDriver tool-kit.

The trial versions can be downloaded from the

Downloads page on our site. The

limitations of each evaluation version (as compared with the registered version)

are outlined in the WinDriver User’s Manual and in

Technical Document #9.

Yes. All versions of WinDriver are backwards compatible, except for rare

occasions documented in the

WinDriver Release Notes.

In most cases, code compiled with an earlier WinDriver version will work,

without recompilation, after replacing the driver file with that from a newer

version; on Windows you may also need to replace the device’s INF file with one

from the newer version.

One exception is when upgrading from version 5.2.2 and below to version 6.0.0

and above: In version 6.0.0 we renamed the WinDriver kernel module from

windrvr to windrvr6, therefore upgrading to a

version that uses the new driver requires rebuilding the code with the header

files from the new version (see

Technical Document #116); the

old API will still be supported, for backwards compatibility, after rebuilding

the code.

It is recommended, however, to always use the newest API, to fully utilize the

improvements introduced in newer versions.

NOTE: The

Kernel PlugIn is not

backwards compatible. Therefore, when upgrading to a newer version of

WinDriver, you must also rebuild yourKernel PlugIn driver (if you have created such a driver) using the new version.

First, review the support resources available on the

WinDriver Support page. If

you cannot find an answer to your problem, use our

Secured Support Center

(or the

Non-Secured Support Center)

to report a problem or get any type of product support.

To ensure a quick and effective response, be sure to specify all relevant

information, as outlined in the support center and below.

You can also contact us

by telephone. If you

call outside our office hours, or if all support personnel are occupied, leave

your full contact details (name, company name, email and phone numbers) and we

will be sure to contact you shortly.

When reporting a problem, please include a clear description of all the steps

you performed, and specify which step failed and what was the exact nature of

the failure or erroneous behavior that you encountered (including complete

error messages).

Please check specifically that you have included the following

information:

1. In general, please indicate
   • Your operating system. For example: Windows Vista

     64-bit; Windows XP SP3; Windows Embedded Compact 7, Windows CE

     v7.0; RedHat Linux 7.2, Linux kernel version 2.6.32-5-686.

   • Your WinDriver version. For example: WinDriver version

     11.2.0.

   • The entire output of the

     Debug Monitor

     utility: Run the Debug Monitor, set the debug level to ‘Trace’,

     reproduce your problem and attach the output from the Debug

     Monitor window (including the version information at the top).

1. For licensing problems: In addition to the Debug Monitor log,

   please be sure to specify your full license registration string,

   which you received when purchasing the software, and your development

   computer’s registration code. You can view the license

   registration string and the PC registration code from the

   DriverWizard’s Licensing Information window

   (File –> Registration Options).

1. For PCI related problems: In addition to the Debug Monitor log,

   please also attach the entire output of the

   pci_dump utility

   (found in the WinDriver/util directory), and be be sure to

   specify your card’s vendor ID and device ID as well.

1. For installation related problems, in addition to the Debug

   Monitor output, be sure to specify the exact installation steps that

   you performed (which files were copied to which directories; usage of

   the wdreg installation utility; installation of INF files; etc.)

   and the result of each step, and attach a copy of the exact error

   message that you received (if any).

   On Plug-and-Play Windows platforms (Windows 7/Vista/Server 2008/Server

   2003/XP/2k/Me/98), please also attach a copy of the device INF file

   that was used in the installation (if any), and a copy of the

   %WINDIR%\setupapi.log file from

   the PC on which the problem occurred.

Please contact sales@jungo.com to request an extension

of the evaluation period. Please also refer to the

WinDriver User’s Manual

and to Technical Document #9

for a description of the evaluation limits of the different WinDriver kits.

Jungo provides tool kits for writing device drivers. We do not provide

ready-made drivers for commercial hardware.

To completely remove WinDriver from your computer, follow the instructions

found at the Uninstall Page on

our site. NOTE: The online uninstallation instructions are for the latest

WinDriver version. If you are using an older version, follow the uninstallation

instructions in the WinDriver User’s Manual for your specific version.

Simply order the product from our online store. Alternatively, download a

text order form, and email it to

sales@jungo.com, or Fax it

to “Jungo — Connectivity Software Department” (see the

contact details on our site).

Your registered license will include the registered WinDriver version, official

documentation and 2 months of free product upgrades and technical day support.

To get technical support or be eligible for version upgrades after the

expiration of the complimentary two months support and maintenance period, you

must subscribe to the WinDriver annual Upgrade & Support plan.

You can subscribe to this plan from the online store.

For more information regarding the support & maintenance plan, refer to the

Support Purchase page.

The prices of the support plans are derived from the prices of the original

licenses. As you will be able to see, it is much cheaper to subscribe to the

upgrade and support plan during the period of a current valid upgrade &

support subscription (including the 2 months complimentary upgrade &

support period). Once you subscribe to this plan, use Jungo’s

Secured Support Center

(or the

Non-Secured Support Center)

to contact our support team at any time. Please also refer to

the following FAQ to find out how to report a problem effectively:

http://www.jungo.com/st/support/faq.html#lfc.

After purchasing the license from Jungo, you own your driver. The license is

issued for the development stage. The executable/DLL that you create is yours

to distribute freely, in as many copies as you wish. No royalties are to

be paid to Jungo. The only exception to this is if you have created a driver

development kit with WinDriver. For this reason you cannot distribute the

WinDriver header files or your license registration string, thereby enabling

others to develop a driver with WinDriver. For more information, take a look at

the Distributing Your Driver — Legal Issues Appendix in the

WinDriver User’s Manual or

contact sales@jungo.com.

When using a registered version of WinDriver, you must register your specific

license registration string from the code.

The generated DriverWizard code for the registered tool-kit will already

include the relevant code for registering your license (provided you have

activated your license from the wizard before generating the code). However,

if you used the DriverWizard to generate the code during the evaluation

period, or if you are using one of the WinDriver samples, you will need to add

the registration code yourself.

Note that after the initial registration of the license from the DriverWizard,

your license string will automatically be activated with every session of the

wizard. This is the reason that you have found that your code seems to work

if you first run DriverWizard (since the license was already registered from

the wizard, even though it was not explicitly registered from the code).

Please refer to the description of WDU_Init() (USB) /

WDC_DriverOpen() (PCI/ISA) in the

WinDriver User’s Manuals to learn how to correctly register your license registration

string from the code.

If your codes uses the low-level WD_xxx APIs instead of the WDU or

WDC APIs, use the function WD_License() to register your license

string. WD_License() is described in the

WinDriver PCI Low-Level API Reference

(WinDriver/docs/wdpci_low_level_api_ref.pdf) in

v8.0.0 and above of WinDriver. In earlier versions the function is described

in the WinDriver User’s Manual, which is found under the

WinDriver/docs/ directory for the specific version. (If you

are using version 5.0.5b or earlier of WinDriver, you can refer to the

WinDriver/redist/register/register.txt file for relevant

registration instructions).

Beginning with version 5.2.0 of WinDriver, the generated DriverWizard evaluation

code already includes the required license registration code, but using a demo

license string. When moving to a registered version you simply need to replace

the demo license string that is used in the call to WDU_Init() /

WDC_DriverOpen() / WD_License() in the evaluation

code with your specific license registration string.

NOTE: Make sure that your code calls the license registration function before

any other WinDriver API call (apart from WD_Open or

WD_Version(), when using the low-level WD_xxx APIs).

When installing WinDriver, the only thing that will be locked to one machine is

the development environment — i.e., the DriverWizard (unless you are using a

floating WinDriver license, which enables you to use the DriverWizard on any

PC). Once you have written and built your code, you may install and run it on

any machine you want. The device driver you create using WinDriver is yours to

distribute in as many copies as you wish, royalties free, provided you do not

distribute your own driver development kit (see the following FAQ:

http://www.jungo.com/st/support/faq.html#MIP).

To find out how to distribute the driver you developed with WinDriver, please

review the driver distribution chapter in your WinDriver User’s Manual, and the

distribution technical documents for your WinDriver version in the

Licensing And Distribution section of the WinDriver

Technical Documents. Please note that before distributing your driver

you must register your license registration string from the code, as explained

in the manual and in the following FAQs:

http://www.jungo.com/st/support/faq.html#reg1

and

http://www.jungo.com/st/support/faq.html#lfc19.

The Debug Monitor (a.k.a. Monitor Debug Messages, in older WinDriver

versions) is an application program that logs detailed debugging information

from the WinDriver kernel driver(s). This application is available in two

versions: wddebug_gui — a fully graphical version; and

wddebug — a console-mode version, which also supports GUI

execution on Windows CE platforms (beginning with v10.0.1 of WinDriver).

Both versions of the Debug Monitor can be found at WinDriver/util; (on

Mac OS X, in WinDriver versions that support it, the GUI version can be found

in the OS’s /Applications folder).

For detailed information on this utility and how to use it, refer to the

WinDriver User’s Manual, and

to the following Technical Documents:

#12 (wddebug_gui for

Windows, Mac OS X, Linux, and Solaris),

#13 (wddebug for

Windows, Windows CE (including Windows Mobile), Mac OS X, Linux, and Solaris),

and #14 (wddebug for

VxWorks — last supported in WinDriver v5.2.2).

For information regarding redirecting debug information from the Debug Monitor

to a kernel debugger, refer to

Technical Document #44.

NOTE: The Debug Monitor can also be run on target platforms on which only on

the WinDriver driver(s), and not the entire WinDriver tool-kit, have been

installed. This can be useful, for example, for debugging problems on your

customers’ platforms, as explained in the following FAQ:

http://www.jungo.com/st/support/faq.html#lfc6009.

Yes. You can select to send the debug information from the

Debug Monitor to a kernel debugger, as

explained in

Technical Document #44.

On Windows, in order to save the debug information in case of a

hang/crash, you will need to install the kernel debugger on another PC and

establish a debug session between this PC and your development PC. For more

information on what to do in case of a crash on Windows, refer to

Technical Document #121.

On Linux you will find the debug log, after reboot, in

/var/log/messages.

WinDriver provides an API for accurate sleep times (in 1 microseconds

resolution) — WD_Sleep().

By default, WD_Sleep() performs a

busy sleep.

If you need to perform a non-busy sleep:

• If a resolution of ~17,000 microseconds is sufficient for you, then you

  can either set up the

  SLEEP_NON_BUSY flag in the

  dwOptions field of the

  WD_SLEEP structure, which is

  passed to WD_Sleep(), in order to

  perform a non-busy sleep; Or use the standard OS sleep functions (e.g.,

  Sleep(),

  WaitForSingleObject(), etc.).

  Using WD_Sleep() will maintain

  your code’s portability, as opposed to the standard OS sleep functions.

• If you need a higher resolution, you can write a

  Kernel PlugIn

  application, using the Virtual Timer Device (VTD) API in Win95. The

  problem is that the code that will execute on the timer is kernel mode

  code. You will have to write code to transfer the data from user mode

  to kernel mode, and then transfer the results back from kernel mode to

  user mode.

YES! The code of the device driver you write runs in normal Win32 user mode.

Therefore, you can compile and debug your code using MS Visual Studio /

Visual C++.

Please refer to Technical Document #19 for more information regarding debugging

your driver code with WinDriver.

If you need to define more than

WD_CARD_ITEMS items for your card

(currently 20 items, according to the definition of

WD_CARD_ITEMS in windrvr.h), do

not modify the value of WD_CARD_ITEMS in

the code, but instead, simply call

WD_CardRegister() several times from your

code, with different items each time. (It is not mandatory to lock all the

resources on a specific card with a single

WD_CardRegister() call.) Alternatively,

consider grouping several memory/IO address ranges into a single BAR

definition, so that the overall resources item count does not exceed the

default 20 items limit.

Please do not change anything in windrvr.h. The affect will

certainly not be what you expect and it could be potentially disastrous.

The sample programs were written with the evaluation version in mind (so that

they can be distributed and used without a license during the evaluation

period). You can modify their source code in order to register your license

registration string from the code — as explained in the following FAQ:

http://www.jungo.com/st/support/faq.html#reg1.

You can replace the calls to WD_Transfer() with direct memory access, by utilizing the

virtual user mode mapping of the base physical address for the relevant memory

range, which is returned by WD_CardRegister() in:

cardReg.Card.Item[i].I.Mem.dwUserDirectAddress

(where ‘i’ is the index number of the memory base address in the WD_ITEMS ‘Item‘ array).

This is documented in the

WinDriver User’s Manual

(see the description of WD_CardRegister()

in the “Function Reference” chapter and the “Improving Performance” chapter)

and in Technical Documents #74

and #17. Technical document

#17 also includes other

suggestions on how you might improve your driver’s performance with WinDriver.

WinDriver’s Debug Monitor utility can run on any machine (unlike the WinDriver

DriverWizard utility, which is locked down to the development machine).

Therefore, you can simply copy the wddebug_gui or wddebug program

file from the development machine (from WinDriver/util or from

/Applications on Mac OS X — in WinDriver versions that support

this OS), to a target machine on which the WinDriver driver(s) have been

installed, and run the Debug Monitor on the target. For detailed information

regarding the Debug Monitor utility, refer to the

WinDriver User’s Manual

and to the Debug Monitor FAQ.

The Kernel PlugIn is an integral part of the WinDriver PCI/ISA tool-kit.

No additional license or payment is required in order to use it.

If you are using Kernel PlugIn to develop a Windows SYS driver, you need to

install Microsoft’s Windows Driver Kit (WDK), or the earlier Driver Development

Kit (DDK) — depending on your target OS and WinDriver version — in

order to successfully build your Kernel PlugIn driver.

For information regarding acquiring the WDK, refer to:

http://www.microsoft.com/whdc/devtools/WDK/WDKpkg.mspx.

[Note that when using the WDK/DDK to build your

Kernel PlugIn driver, you will also need to set the

BASEDIR or

DDKROOT environment variable to the

location of your DDK library, as explained in the

WinDriver User's Manual.]

Development of VxD Kernel PlugIn drivers, which was supported for Windows 98/Me

in earlier versions of WinDriver (v6.0x-), does not require you to install

Microsoft’s WDK/DDK in order to successfully build the driver, unless you

choose to add your own DDK function calls to your Kernel PlugIn

application. (Note that using OS-specific DDK functions can damage the driver’s

portability).

Using WinDriver’s Kernel PlugIn feature, you can expect to handle more than

100,000 interrupts per second, without missing any of them.

For sample Kernel PlugIn interrupt handling code, use the DriverWizard to

generate code for your device (for PCI and PCMCIA devices, define the data for

clearing the interrupt in the wizard before generating the code), or take a

look at the WinDriver Kernel PlugIn sample code —

KP_PCI (WinDriver/samples/pci_diag/kp_pci — v7.0.0+) or

KPTEST (WinDriver/kerplug/kptest/kermode — v6.2.3-a).

In the user mode you can handle around 5,000-10,000 interrupts per second, but

since Windows is not a Real Time OS, you might miss some of the interrupts once

in a while (although WinDriver tells you when you have missed an interrupt and

how many interrupts were missed).

For an explanation regarding interrupt latency with WinDriver, refer to

Technical Document #48.

Yes.

WinDriver implements malloc() and

free() for kernel mode memory allocation

(see Technical Document #34).

Since the allocated memory is locked, you can also use this memory in your

Kernel PlugIn interrupt routines.

You can also share a memory buffer between the user mode and

Kernel PlugIn applications — as explained in

Technical Document #41.

Yes — You can erase the user mode interrupt handler routine.

You can also implement some of the interrupt handling in the

Kernel PlugIn and some of it in the user mode. The return value of

KP_IntAtDpc() (which is called when the

high-priority KP_IntIrql() routine

returns TRUE) determines the number of

times that the user mode interrupt handler routine will be executed (if at all).

Kernel PlugIn enables you to create an add-on *.sys/.kext/.o/.ko kernel

driver — depending on your OS — to extend the features of WinDriver

for your needs. The Kernel PlugIn driver your create is not

standalone — it can only work together with a user-mode driver that

activates it.

Note that when using WinDriver’s Kernel PlugInfeature, you must

also install the WinDriver kernel module — windrvr6.sys/.dll/.o/.ko or WinDriver.kext,

depending on the OS and the WinDriver version.

You can use WinDriver’s WD_DebugAdd() API

(available from v5.0.3 and above) to print debug messages from your Kernel

PlugIn or user mode code to the Debug Monitor

utility, and then view the messages in the Debug Monitor log.

WD_DebugAdd() can be called from within

any user-mode or Kernel PlugIn function, including

KP_IntAtIrql().

You can also select to send the debug information from WinDriver’s Debug

Monitor to a kernel debugger, as explained in

Technical Document #44.

In addition, you can add calls in your Kernel PlugIncode to OS

kernel functions that print directly to the kernel debugger — such as

KdPrint() on Windows

, or

printk() on Linux.

This might happen if you are enabling the interrupt from your

Kernel PlugIn interrupt routines, and simultaneously disabling it

from the user mode (using WD_IntDisable()

or InterruptEnable() /

WDC_IntEnable() — which call

WD_IntDisable()). Since the interrupt is

active (having been enabled from the Kernel PlugIn), the interrupt

cannot be disabled and the PC hangs waiting for

WD_IntDisable() to return.

A possible solution, is to call WD_IntDisable()/InterruptEnable()/WDC_IntEnable() as an

atomic operation, so that it will disable the interrupts successfully before

theKernel PlugIn interrupt routine enables the interrupt.

Please refer to http://www.jungo.com/st/support/faq.html#kplinux under the

Linux Issues section for the

answer to this question.

No. Only the callbacks used by WinDriver need to be declared as

__cdecl.

When writing device drivers, developers must write a separate device driver

for the Win 9x and the Win NTx kernels. Microsoft has developed a

cross-platform operating system support for input devices, in order to

provide a uniform way for code to access such devices across Windows 7, Vista,

Server 2008, Server 2003, XP, 2000, 98, and Me platforms. This new support is

known as Windows Driver Model or “WDM”. WDM is based on the

original Windows NT driver model, with modifications to support Plug-and-Play

and power management, and is used for most multimedia device types and many

other newer device types, such as USB and 1394 devices.

Beginning with version 5.2.0 of WinDriver, WinDriver’s kernel module —

(windrvr6.sys / windrvr.sys in v5.2.2-) —

which implements WinDriver’s API, is a full WDM driver.

This message is not actually an error message and is not an indication of

any problem in the installation process or with the driver. This message is

issued by Microsoft’s Windows XP to indicate that the driver was not tested

and digitally signed by Microsoft’s Windows Hardware Quality Labs (WHQL).

To avoid this message you can contact Microsoft in order to get your driver

digitally signed. For more information

Click Here.

WinDriver is fully WHQL-compliant. The driver you develop with WinDriver

for Windows can be submitted to Microsoft’s Windows Hardware Quality Labs (WHQL)

testing in order to digitally sign the driver with Microsoft. Several WinDriver

customers have already successfully signed their WinDriver-based drivers with

Microsoft.

For more information on Microsoft’s WHQL testing and how to get a WHQL

certification for your hardware and WinDriver-based driver, refer to to the

“WHQL Certification” section in the

WinDriver User’s Manual and

to Microsoft’s documentation, for example:

http://www.microsoft.com/whdc/whql/default.mspx/.

For further assistance, contact us via our

Secured Support Center

(or the Non-Secured Support Center).

Set the PciCfgRwCompat registry key flag in the WinDriver driver

INF file (v10.3.1 and higher) to 1 to enable the legacy PCI configuration

space read/write method, as explained in Technical Document #2.

Yes — the Debug Monitor utility is also

available on Windows CE (including Windows Mobile). For more information, refer to Technical Document #13.

Yes. In Windows CE, device drivers, including NDIS drivers, are DLLs. So a

NDIS network driver can use the WinDriver CE API to talk to the hardware.

Yes. In Windows CE, device drivers, including NDIS drivers, are DLLs. So a

NDIS network driver can use the WinDriver CE API to talk to the hardware.

Make sure to install the WinDriver kernel module — windrvr6.o/.ko

(or windrvr.o — in v5.2.2 or below) —

before installing your Kernel PlugIn module, since the

Kernel PlugIn driver depends on the WinDriver driver module for

its operation.
For detailed Kernel PlugIn installation

instructions, refer to the

WinDriver User’s Manual for

your WinDriver version and to

Technical Document #62.

This is a limitation in Linux kernels — by default you can allocate a maximum

of 128KB for kernel buffer allocation. However, it is possible to recompile

the kernel to get larger sizes and there is also a path that enables this

— as explained in

Technical Document #64.

Yes. You can use the WinDriver PCI tool-kit and API to develop a

CardBus driver, as explained in

Technical Document #94.

Note that on Plug-and-Play (PnP) Windows operating systems, you need to

generate and install an INF file for your device in order to successfully

handle it with WinDriver (you can use the DriverWizard to generate the INF

file, as explained in the WinDriver documentation). The INF file will register

your device to work with WinDriver’s kernel driver (windrvr6.sys or

windrvr.sys — in v5.2.x /

wdpnp.sys/wdusb.sys — in previous versions).

This might be a hardware problem, due to BIOS-specific implementations of

parallel port modes on various computers. WinDriver cannot control this

behavior, since it is programmed into the BIOS. We advise you to follow the

brand of computer or BIOS that you have observed works correctly.

The user-mode interrupts handler can service up to 10,000 interrupts per second

(although we cannot commit to a specific number, since this is dependent upon

many factors). A latency of approximately 25ms should generally not happen, but

it can from time to time. Using WinDriver’s

Kernel PlugIn feature will

ensure that this will not happen. However, nothing can protect against some

badly written device drivers that sometimes disable interrupts for long

periods. Such offending drivers should be identified and upgraded or removed.

For more information regarding WinDriver’s interrupt latency, refer to

Technical Document #48

When a PCI interrupt occurs, WinDriver writes/reads the interrupt status

register in order to clear (acknowledge) the level sensitive interrupt. This

is performed directly in the kernel, according to the information that was set

up in the code, beforehand, when enabling the interrupt. To read and save

the value of the interrupt register before the interrupt is cleared,

so that you can later reference this value from within your interrupt handler

routine, you need to set up a relevant read command in the interrupt transfer

commands that are set up in the dwCmd

field of the WD_INTERRUPT structure,

which is passed to InterruptEnable()

(/InterruptThreadEnable() in earlier

versions)/WD_IntEnable(), and set the

INTERRUPT_CMD_COPY flag in the

dwOptions field of the

WD_INTERRUPT structure

(int.dwOptions |= INTERRUPT_CMD_COPY).

This is documented in the “Interrupt Handling” section of the

WinDriver User’s Manual and

in Technical Documents #104

and #75.

PCI uses level sensitive interrupts, which must be acknowledged and cleared

in the kernel immediately when they are received. Therefore, WinDriver

requires you to define an interrupt status register, which should be

read/written in order to clear the interrupt. This is a precautionary

feature, because a level sensitive interrupt that is not acknowledged can

hang your PC. Please refer to

Technical Document #105 for a

detailed explanation on how to listen to PCI interrupts with WinDriver’s

DriverWizard. Please also refer to

Technical Document #75 and to

the WinDriver User’s Manual

for a general explanation regarding the handling of PCI interrupts with

WinDriver.

NOTE that as specified in the WinDriver documentation, in order to

handle PCI interrupts correctly with WinDriver on Plug-and-Play (PnP) Windows

operating systems, you must first install an INF file for the device, which

registers it to work with WinDriver’s PnP driver (windrvr6.sys in the

latest WinDriver versions; in previous versions —

windrvr.sys/wdpnp.sys/wdusb.sys, depending on the

version).

Yes. Beginning with version 9.1.0 WinDriver supports Message Signaled-Interrupts

(MSI) and Enhanced Message-Signaled Interrupts (MSI-X) on Windows

Vista and higher and Linux.

Support for additional operating systems will be added in future versions of

WinDriver.

NOTE: Support for MSI/MSI-X on Windows is provided only on Windows Vista and

higher, because earlier versions of Windows do not support these types of

interrupt.

For more information on WinDriver’s MSI/MSI-X support, refer to the

WinDriver User’s Manual.

To lock a large DMA buffer (more than 1MB) for Scatter/Gather (S/G) DMA

(i.e., when the KERNEL_BUFFER_ALLOC DMA options flag is not

set), using WD_DMALock() function, perform the following steps.

1. Set the DMA_LARGE_BUFFER flag in the

   dwOptions field of the WD_DMA structure whose

   address is passed as the pDma parameter of

   WD_DMALock() (“the WD_DMA structure”).

   (Note: This flag is required only when performing Scatter/Gather DMA,

   as opposed to Contiguous Buffer DMA.)

1. Calculate the number of pages you need to lock, in the following

   manner, and assign it to the dwPages field of the

   WD_DMA structure:

   dwPagesNeeded = transferCount / 4096 + 2;

   where transferCount is the number of bytes that you want

   to lock.

1. NOTE: By default, the WD_DMA structure can hold

   information of up to 256 pages (= WD_DMA_PAGES, defined in

   WinDriver/include/windrvr.h). If you wish to

   lock more than 256 pages, you need to have enough memory to hold the

   information of all the pages. To allocate memory for

   the additional pages’ information, you can do the following:

   WD_DMA *pDma;

   pDma = (WD_DMA *)malloc(sizeof(WD_DMA) +

   sizeof(WD_DMA_PAGE)*(dwPagesNeeded - WD_DMA_PAGES));

If the memory allocation still fails (using either

WDC_DMASGBufLock(), or WD_DMALock() in the manner

outlined above), verify that there are sufficient system resources for the

attempted memory allocation (both in the kernel and in the user mode address

space to which the memory is mapped).

On Windows, you may need to increase the size of the non-paged pool (from

which the memory is allocated), as explained in Technical Document #58.

If you still cannot lock the entire buffer, try locking a smaller buffer.

For more information regarding performing DMA with WinDriver, please see the

section regarding “Performing DMA” in the “WinDriver Implementations Issues”

chapter of the WinDriver PCI User’s Manual, and to the description of the

WinDriver DMA APIs in the “Function Reference” chapter of the manual.

“Regular” memory (stack, heap, etc.) is cached by the operating system. When

using WD_DMALock(), the data is non-cached, in order to make it

DMA-safe. Therefore, the memory access is slower. Note that this is the correct

behavior for DMA.

When performing Contiguous Buffer DMA, you can set the

DMA_ALLOW_CACHE flag in the dwOptions paramer of

WDC_DMAContigBufLock, or directly in the dwOptions field of the WD_DMA structure that is passed to

WD_DMALock() (when using the low-level WinDriver API), in order to

allocate a cached DMA buffer. When working on Windows x86 and x86_64 platforms,

it is recommended to always set this flag.

(Note: The DMA_ALLOW_CACHE flag is available beginning with

version 5.2.1 of WinDriver.)

If you have allocated the memory in the user mode and then passed its address

to WDC_DMASGBufLock() or to the low-level WD_DMALock()

function in order to lock a Scatter/Gather DMA buffer, then calling

WD_DMAUnlock() will unlock the memory buffer and it will now

function like other “regular” memory in terms of access speed.