The only reliable way is to move your interrupt handler
to the driver. I can do this for you if you have purchased
the TVicHW32 Commercial License.
This license also lets you order a custom device driver.
TVicHW32 FAQ
NOTE: Please check this FAQ and the Home Page, before requesting support by email.
If you don't find an answer here or on the Home
Page, then send your question(s) by e-mail.
We add the interesting or frequently asked questions to this document.
You've just written an application to control a custom
or system hardware device under DOS or Win16. Now comes the
task of porting your software to Win32. You know this is a
major undertaking because no single programming language contains
the constructions or functions for Win32 hardware access,
i.e. port I/O operations, physical memory accessing, hardware
interrupt handling or DMA functions. Up to now, your only
choice was to write your own device driver. You also know
this means:
you must have the Microsoft Driver Development Kit (DDK)
installed on your PC,
you must examine the driver structures—which are
quite different for Windows 95/98/ME (VxD) and for Windows
NT/2000 (kernel-mode driver),
if you don't know C then you'll have to learn this programming
language and very likely the assembler instructions for
each processor that will use your app,
you'll need to learn driver debugging methods and probably
have to purchase a high-cost debugging tool,
be prepared to lose data from your hard drive because
even small driver bugs produce the Blue Screen of Death.
Fortunately, you now have a much simpler choice. TVicHW32
is a general purpose device driver that can be used by practically
any programming language. It lets you access and control
hardware directly from any Win32 application under Windows
95/98/ME/NT/2000/2003/XP/XP 64-bit without having to use
the Windows DDK.
Under Plug&Play operation systems you can
not. Please notice, that TVicHW32 is not a device
driver, it is a toolkit based on NT-styled driver and
used only for accessing PC Hardware. However, you are able
to use it as a device driver under Windows NT4 and partly
under Windows 98.
If you wish to install a device driver
for your device under Windows 98, 2000,
XP and 2003, you should refer
to our RapidDriver - it is based on WDM Plug-and-Play
drivers, which can be installed as native device drivers
for your custom USB, PCI, ISA or LPT devices.
TVicHW32 demo version is fully functional so
you can write and debug your application before you buy
a license to use or distribute the driver.
TVicHW32 licensed version has only one difference: it includes
the drivers tvichw32.vxd for Windows 95/98/ME and
tvichw32.sys for Windows NT/2000 without nag screens.
In addition, users who have purchased the TVicHW32 Commercial License receive the
TVicHW32.DLL source code written in MSVC++ 6.0.
Driver source code is not available for any kind of
license.
Single License: Once registered,
you are granted a non-exclusive license to use TVicHW32
on one computer at a time, for any legal purpose. The registration
fee is $99 U.S. Purchase
online. Commercial License: You are
granted the license to distribute TVicHW32 drivers and DLL's
as part of your software without having to pay royalties.
Optionally includes your own custom driver/dll names. In
addition we can include the "time critical" code
to the driver's body (one additional function or an interrupt
handler). The registration fee is $297 U.S. Purchase
online. Site License:For teams of developers.
The cost of this license depends on how many are using the
software. Please contact us for the
specific price.
After registration we provide special *.inf files to
reinstall TVicHW32. After rebooting your PC you can log
on to NT/2000 as a user without any privileges. Note:
you must be logged on as an Administrator to install
TVicHW32!
We have tested TVicHW32 with the following programming
systems:
Microsoft Visual C++ 6.0
Microsoft Visual Basic 6.0
Inprise (Borland) Delphi versions 2 to 5
Inprise (Borland) C++ Builder versions 1.0, 3.0, 4.0,
5.0
Borland C++ 5.0
In general, you can use TVicHW32 with any programming language
if it allows calls to DLL functions. We know that TVicHW32
can be used with Borland Power Builder and with Forth but
please don't ask us how!
The VCL component is just a convenient wrapper around
a DLL so using the DLL directly achieves a little better
performance. It's mainly a matter of your convenience or
habit as a programmer.
It is almost
true that you can reach all ports under Windows 95/98/ME.
Windows is a multitasking system where any device can be
used by more than one device concurrently, so Windows has
a way to protect devices from getting more than one instruction
at the same time. To control access to I/O addresses Windows
9X uses a bit-mapped list of ports called an I/O Permission
Map (IOPM). A 1 bit on this list means 'access denied"
and a 0 bit means "access granted". It is no problem
to access a port from a Win32 application if an access is
granted in the IOPM, but it is not simple if access is denied.
The drivers (VxD's) call a system service to trap a particular
port and register a callback function, called a "port
trap handler". The system responds by setting the port's
byte in the IOPM. When a Win32 application accesses that
port and causes a fault, the system fault handler calls
the VxD's registered port trap handler. This port trap handler
can do anything in response to the I/O access from a Win32
application: the VxD may ignore the instruction, may execute
the instruction or may substitute a value instead of the
one you are sending!
Windows 9x and its component VxD's trap almost all standard
PC I/O addresses but never traps non-standard I/O addresses.
So it is necessary to be careful if you are working with
the standard system devices. On other hand, the system cannot
trap the I/O access from another VxD and this is why you
need a device driver for reliable access
to the ports under Windows 95/98/ME.
"Soft" mode provides a higher performance
access to ports, but the access may fail if the ports addressed
are already in use by another driver (see preceding). "Hard" access
provides a more reliable access to ports but it is slower
due to its increased overhead for the DeviceIOContol() calls.
TVicHW32 runs perfectly up to 10 KHz on a 450 MHz Pentium
II. For very stable results we recommend TVicHW32 be used
with interrupt periods less than 10 milliseconds. TVicHW32
handles all
interrupts at higher frequencies, but it starts to influence
the delays that occur when interrupts are delivered to the
application level. This is possible only when Windows makes
TVicHW32's thread active. For TVicHW32 to have this indirect
delay effect its priority class must be REALTIME_PRIORITY_CLASS
and its thread priority set at THREAD_PRIORITY_TIME_CRITICAL.
In this extreme case we start to have problems with the
keyboard and mouse which can even be blocked.
The only reliable way is to move your interrupt handler
to the driver. We can do this for you if you have purchased
the TVicHW32 Commercial License. This license
also lets you order a custom device driver.
No, this is not possible. The system timer (IRQ 0) is
used by the system for system scheduling and cannot be used
for any other purpose. Also, under Windows NT/2000 we cannot
use the RTC timer (IRQ 9).
In general, precision timing under Windows is an unsolvable
problem because Windows was not developed
as a realtime system. Developers requiring high precision
timers can call the Win32 API function timeSetEvent(),
which is accurate to 1 milliseconds (ms). However, in Windows'
multithreaded environment, this accuracy is not reliable
when other high-priority threads are demanding processor
time.
If you need to measure a time-critical algorithm then do
not use the GetTickCount() function. Instead, use the Win32
API functions QueryPerformanceCounter() and QueryPerformanceFrequency().
If TVicHW32 cannot help you solve your problem, we can
write a driver for you and send you its source code. E-mail us to get the
price—which depends on your particular needs—and
delivery time.
TVicHW32 is not recommend for serial communications.
There are much easier and cheaper ways to do the same job
with the standard API calls. Just open the Win32 help file
and search for "communications".
You can also use MSCOMM32 OCX or you can find many shareware
or even freeware tools and components on the Internet.
The interrupt frequency is set too high. You can reduce
this frequency or tweak your interrupt handler to work
faster. Also see above.
Your device generates "level sensitive" interrupts
rather than "edge triggered" ones. If the interrupt
level at the bus is not dropped at the end of an interrupt
handling, the system calls the interrupt handler again
and again and this will cause the system to hang. To prevent
this situation use the UnmaskIRQEx() function to
install an interrupt handler instead of UnmaskIrq().
By calling this new function you can provide the information
for how the TVicHW32 driver should clear an interruption
inside of the primary interrupt handler. Note: You
do not need to clear the interrupt level in your interrupt
handler since this was already done by the TVicHW32 driver!
Unfortunately TVicHW32 cannot help you. The problem
is that Windows NT/2000 has no kernel or user level functions
to do this in any documented way. Windows NT/2000 was initially
developed for many types of CPUs, not just Intel's, so we
cannot make any recommendations about the BIOS or DOS.
TVicHW32 includes a lot of standard functions to work
with the LPT port. Visit www.lvr.com/parport.htm
for their very useful tips and information, books, FAQs,
links, software tools, etc.
TVicHW32 is a tool for accessing hardware and, like
any tool, it does not do the job for one. One does the job
with the help of the tool. In other words, to use any tool
expertly, one needs to know what he or she is doing with
it. It is possible that we can suggest something to help
you but in most cases the solution is really that you learn
more about the hardware you are accessing, especially if
you are working with "non-standard" devices.
No! Please do not. We don't have enough free
time even to become acquainted with your project before
attempting to debug it. See if you can narrow down the exact
area that's causing the problem and include several source
code lines in an e-mail and we'll try to help if possible.
Toolkits
German
page
