Someone eats LPT port access of a DOS box occationally

NTDEV
1

I’m writing a Virtual Device Driver (VDD) for DOS applications.
When I use VDDInstallIoHook() to catch I/O access, everything works fine as expected,

but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three well-known LPT port adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE) will fail to go to the hook procedure!
Looks independently on whether there is a true parallel port installed in the system or not.
Test system: Windows XP Prof. 32bit DE.

While inspecting ntvdm.exe, I found lots of code dealing with those addresses, so the question is - again - how to disable ntvdm.exe’s built-in port trapping feature (if so)?

Obviously, for my problem (redirecting parallel port access to a USB->ParallelPrinter converter), hooking the well-known LPT addresses is mantadory, I cannot move to other addresses.

Does someone know the relationships and how to break into? Does someone experienced this behaviour with true parallel ports?

2

On 26-Apr-2013 11:08, henrik.haftmann@mb.tu-chemnitz.de wrote:

I’m writing a Virtual Device Driver (VDD) for DOS applications.
When I use VDDInstallIoHook() to catch I/O access, everything works fine as expected,

but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three well-known LPT port adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE) will fail to go to the hook procedure!
Looks independently on whether there is a true parallel port installed in the system or not.
Test system: Windows XP Prof. 32bit DE.

While inspecting ntvdm.exe, I found lots of code dealing with those addresses, so the question is - again - how to disable ntvdm.exe’s built-in port trapping feature (if so)?

Obviously, for my problem (redirecting parallel port access to a USB->ParallelPrinter converter), hooking the well-known LPT addresses is mantadory, I cannot move to other addresses.

Does someone know the relationships and how to break into? Does someone experienced this behaviour with true parallel ports?

What is your goal: to run a legacy DOS program under XP, or toggle LPT
port pins directly (but not necessarily from a DOS program)?

– pa

3

henrik.haftmann@mb.tu-chemnitz.de wrote:

I’m writing a Virtual Device Driver (VDD) for DOS applications.

It’s hard to imagine anyone doing so these days. Remember that 16-bit
support is completely gone in the 64-bit systems.

When I use VDDInstallIoHook() to catch I/O access, everything works fine as expected,
but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three well-known LPT port adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE) will fail to go to the hook procedure!

Interesting. How do you know this?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

> On 26-Apr-2013 11:08, henrik.haftmann@mb.tu-chemnitz.de wrote:

> I’m writing a Virtual Device Driver (VDD) for DOS applications.
> When I use VDDInstallIoHook() to catch I/O access, everything works fine
> as expected,
>
> but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three
> well-known LPT port adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE)
> will fail to go to the hook procedure!
> Looks independently on whether there is a true parallel port installed
> in the system or not.
> Test system: Windows XP Prof. 32bit DE.
>
> While inspecting ntvdm.exe, I found lots of code dealing with those
> addresses, so the question is - again - how to disable ntvdm.exe’s
> built-in port trapping feature (if so)?
>
> Obviously, for my problem (redirecting parallel port access to a
> USB->ParallelPrinter converter), hooking the well-known LPT addresses is
> mantadory, I cannot move to other addresses.
>
> Does someone know the relationships and how to break into? Does someone
> experienced this behaviour with true parallel ports?

What is your goal: to run a legacy DOS program under XP, or toggle LPT
port pins directly (but not necessarily from a DOS program)?

– pa

What is surprising to me is the idea that writing to those ports could be
intercepted by any kind of hook. You have to do exotic things with the
hardware debug registers to capture operations to ports, which AFAIK
WinDbg does not support (although it was supported by SoftICE and was very
handy for reverse-engineering drivers, particularly malfunctioning
drivers).

You can, and I have, opened LPT: and written to it; I converted a legacy
DOS app that controlled a printer by sending the actual ESC sequences to
change font and do graphics. So yes, what are you trying to do, why do
you care about the physical port addresses at all, and what do you mean by
“hooking well-known LPT addreses”, since (a) the concept does not exist
and (b) what may have been “well-known” addresses in MS-DOS environments
are, for most purposes, irrelevant in Windows. Since you are asking for
an impossible solution to a problem that should not exist, you need to be
a LOT clearer on what you are trying to accomplish.

I think you have been badly warped by having direct access to the hardware
under primitive “operating systems” (MS-DOS was a disk-space manager and
program loader). There are many possible answers to your question, nearly
all of which begin “WTF? Throw that code away…” and a few that might
suggest interfaces that already exist. If, as suggested, you are
twiddling bits because the thing on the other side of the plug is not an
actual printer, you will have to go through some serious contortions to
get yout driver to be the “printer” driver, and in addition, on many
machined there IS NO built-in LPT hardware interfacr; The LPT port may be
on a PCI card, and you will need to ask Windows what the port addresses
are, and use those. And if there are precise timing requirements, your
choices would be (a) continue to use MS-DOS or (b) redesign the hardware
joe

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

>What is surprising to me is the idea that writing to those ports could be
intercepted by any kind of hook. You have to do >exotic things with the
hardware debug registers to capture operations to ports, which AFAIK WinDbg
does not support >(although it was supported by SoftICE and was very handy
for reverse-engineering drivers, particularly malfunctioning >drivers).

I think windbg does support this on x86 only.

Not sure why.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Friday, April 26, 2013 3:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Someone eats LPT port access of a DOS box occationally

On 26-Apr-2013 11:08, henrik.haftmann@mb.tu-chemnitz.de wrote:
> I’m writing a Virtual Device Driver (VDD) for DOS applications.
> When I use VDDInstallIoHook() to catch I/O access, everything works
> fine as expected,
>
> but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the
> three well-known LPT port adresses (0x378…0x37A, 0x278…0x27A,
> 0x3BC…0x3BE) will fail to go to the hook procedure!
> Looks independently on whether there is a true parallel port
> installed in the system or not.
> Test system: Windows XP Prof. 32bit DE.
>
> While inspecting ntvdm.exe, I found lots of code dealing with those
> addresses, so the question is - again - how to disable ntvdm.exe’s
> built-in port trapping feature (if so)?
>
> Obviously, for my problem (redirecting parallel port access to a
> USB->ParallelPrinter converter), hooking the well-known LPT addresses
> USB->is
> mantadory, I cannot move to other addresses.
>
> Does someone know the relationships and how to break into? Does
> someone experienced this behaviour with true parallel ports?

What is your goal: to run a legacy DOS program under XP, or toggle LPT
port pins directly (but not necessarily from a DOS program)?

– pa

What is surprising to me is the idea that writing to those ports could be
intercepted by any kind of hook. You have to do exotic things with the
hardware debug registers to capture operations to ports, which AFAIK WinDbg
does not support (although it was supported by SoftICE and was very handy
for reverse-engineering drivers, particularly malfunctioning drivers).

You can, and I have, opened LPT: and written to it; I converted a legacy DOS
app that controlled a printer by sending the actual ESC sequences to change
font and do graphics. So yes, what are you trying to do, why do you care
about the physical port addresses at all, and what do you mean by “hooking
well-known LPT addreses”, since (a) the concept does not exist and (b) what
may have been “well-known” addresses in MS-DOS environments are, for most
purposes, irrelevant in Windows. Since you are asking for an impossible
solution to a problem that should not exist, you need to be a LOT clearer on
what you are trying to accomplish.

I think you have been badly warped by having direct access to the hardware
under primitive “operating systems” (MS-DOS was a disk-space manager and
program loader). There are many possible answers to your question, nearly
all of which begin “WTF? Throw that code away…” and a few that might
suggest interfaces that already exist. If, as suggested, you are twiddling
bits because the thing on the other side of the plug is not an actual
printer, you will have to go through some serious contortions to get yout
driver to be the “printer” driver, and in addition, on many machined there
IS NO built-in LPT hardware interfacr; The LPT port may be on a PCI card,
and you will need to ask Windows what the port addresses are, and use those.
And if there are precise timing requirements, your choices would be (a)
continue to use MS-DOS or (b) redesign the hardware
joe

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

The x86 has debug registers you can set to trap port accesses. I have not
examined the more exotic aspects of the x64; it might be tat such
registers were not included.

I know that years ago when I had to debug an errant driver, I hauled out
my antique SoftICE, and to my amazement it still worked. At that time,
WinDbg had no comparable capability. But that was a long tine ago, in
another country,and in any case the motherboard is dead.

But unless the OP is willing to risk total meltdown from playing in the
minefield, there is no way a driver is going to be able to “hook” the port
read/write operations, which is why the description of the problem appears
to make no sense.

And there are other obvious questions, such as how such actions could
possibly work if a printer driver is “live”.

Which is why we need more explanation of what is going on.
joe

>What is surprising to me is the idea that writing to those ports could be
intercepted by any kind of hook. You have to do >exotic things with the
hardware debug registers to capture operations to ports, which AFAIK
WinDbg
does not support >(although it was supported by SoftICE and was very handy
for reverse-engineering drivers, particularly malfunctioning >drivers).

I think windbg does support this on x86 only.

Not sure why.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@flounder.com
Sent: Friday, April 26, 2013 3:05 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Someone eats LPT port access of a DOS box occationally

> On 26-Apr-2013 11:08, henrik.haftmann@mb.tu-chemnitz.de wrote:
>> I’m writing a Virtual Device Driver (VDD) for DOS applications.
>> When I use VDDInstallIoHook() to catch I/O access, everything works
>> fine as expected,
>>
>> but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the
>> three well-known LPT port adresses (0x378…0x37A, 0x278…0x27A,
>> 0x3BC…0x3BE) will fail to go to the hook procedure!
>> Looks independently on whether there is a true parallel port
>> installed in the system or not.
>> Test system: Windows XP Prof. 32bit DE.
>>
>> While inspecting ntvdm.exe, I found lots of code dealing with those
>> addresses, so the question is - again - how to disable ntvdm.exe’s
>> built-in port trapping feature (if so)?
>>
>> Obviously, for my problem (redirecting parallel port access to a
>> USB->ParallelPrinter converter), hooking the well-known LPT addresses
>> USB->is
>> mantadory, I cannot move to other addresses.
>>
>> Does someone know the relationships and how to break into? Does
>> someone experienced this behaviour with true parallel ports?
>
> What is your goal: to run a legacy DOS program under XP, or toggle LPT
> port pins directly (but not necessarily from a DOS program)?
>
> – pa
>
>
What is surprising to me is the idea that writing to those ports could be
intercepted by any kind of hook. You have to do exotic things with the
hardware debug registers to capture operations to ports, which AFAIK
WinDbg
does not support (although it was supported by SoftICE and was very handy
for reverse-engineering drivers, particularly malfunctioning drivers).

You can, and I have, opened LPT: and written to it; I converted a legacy
DOS
app that controlled a printer by sending the actual ESC sequences to
change
font and do graphics. So yes, what are you trying to do, why do you care
about the physical port addresses at all, and what do you mean by “hooking
well-known LPT addreses”, since (a) the concept does not exist and (b)
what
may have been “well-known” addresses in MS-DOS environments are, for most
purposes, irrelevant in Windows. Since you are asking for an impossible
solution to a problem that should not exist, you need to be a LOT clearer
on
what you are trying to accomplish.

I think you have been badly warped by having direct access to the hardware
under primitive “operating systems” (MS-DOS was a disk-space manager and
program loader). There are many possible answers to your question, nearly
all of which begin “WTF? Throw that code away…” and a few that might
suggest interfaces that already exist. If, as suggested, you are
twiddling
bits because the thing on the other side of the plug is not an actual
printer, you will have to go through some serious contortions to get yout
driver to be the “printer” driver, and in addition, on many machined there
IS NO built-in LPT hardware interfacr; The LPT port may be on a PCI card,
and you will need to ask Windows what the port addresses are, and use
those.
And if there are precise timing requirements, your choices would be (a)
continue to use MS-DOS or (b) redesign the hardware
joe
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

> I’m writing a Virtual Device Driver (VDD) for DOS applications.

When I use VDDInstallIoHook() to catch I/O access, everything works fine
as expected,

but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three
well-known LPT port adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE)
will fail to go to the hook procedure!
Looks independently on whether there is a true parallel port installed in
the system or not.
Test system: Windows XP Prof. 32bit DE.

While inspecting ntvdm.exe, I found lots of code dealing with those
addresses, so the question is - again - how to disable ntvdm.exe’s
built-in port trapping feature (if so)?

Obviously, for my problem (redirecting parallel port access to a
USB->ParallelPrinter converter), hooking the well-known LPT addresses is
mantadory, I cannot move to other addresses.

I think there is something seriously flaed in your approach. Replacing a
printer driver with anoter that goes to USB has absolutely NOTHING to do
with intercepting port writes. You are doing this completely upside-down.
What you need to do is write a WDF USB driver and have it be recognized
as the printer.

WTF is a VDD? Sounds like a leftover from Win16, and I don’t see how it
has anything to do with Windows in 2013.
joe

Does someone know the relationships and how to break into? Does someone
experienced this behaviour with true parallel ports?

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

8

> I’m writing a Virtual Device Driver (VDD) for DOS applications.

When I use VDDInstallIoHook() to catch I/O access, everything works fine
as expected,

but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three
well-known LPT port adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE)
will fail to go to the hook procedure!
Looks independently on whether there is a true parallel port installed in
the system or not.
Test system: Windows XP Prof. 32bit DE.

While inspecting ntvdm.exe, I found lots of code dealing with those
addresses, so the question is - again - how to disable ntvdm.exe’s
built-in port trapping feature (if so)?

Obviously, for my problem (redirecting parallel port access to a
USB->ParallelPrinter converter), hooking the well-known LPT addresses is
mantadory, I cannot move to other addresses.

I think there is something seriously failed in your approach. Replacing a
printer driver with another that goes to USB has absolutely NOTHING to do
with intercepting port writes. You are doing this completely upside-down.
What you need to do is write a WDF USB driver and have it be recognized
as the printer.

WTF is a VDD? Sounds like a leftover from Win16, and I don’t see how it
has anything to do with Windows in 2013.
joe

Does someone know the relationships and how to break into? Does someone
experienced this behaviour with true parallel ports?

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

9

Dr. Newcomer: a VDD is indeed a Windows driver model… An old one, an odd one, but a model nonetheless. So, cut the OP some slack.

Herr Haftmann: Are you sure you need to follow this path? As Mr. Roberts said, it won’t work on 64-bit machines, and IIRC you never could intercept ports that Windows already had a built-in facility to intercept. IIRC. I think.

Tell us more about what you’re trying to do…

Peter
OSR

10

> > Obviously, for my problem (redirecting parallel port access to a

> USB->ParallelPrinter converter), hooking the well-known LPT addresses is
> mantadory, I cannot move to other addresses.
>
I think there is something seriously flaed in your approach. Replacing a
printer driver with anoter that goes to USB has absolutely NOTHING to do
with intercepting port writes. You are doing this completely upside-down.
What you need to do is write a WDF USB driver and have it be recognized
as the printer.

WTF is a VDD? Sounds like a leftover from Win16, and I don’t see how it
has anything to do with Windows in 2013.

It’s quite unsettling the amount of industrial hardware still exists that runs on a 16 bit framework, but it does exist and some of us have to work with it. If I were to take a guess at the OP’s reasoning, he has a piece of industrial equipment driven by a 16 bit app and the PC it is running on is failing and he wants to run it on modern hardware which doesn’t have a parallel port. The industrial equipment is probably in perfect working order, but would need to be either completely replaced (at great expense) or have an interface board replace (also at great expense) to support a modern OS, which would do the job no better than win 3.x did 20 years ago.

If this is the case then I also agree that the OP is doing it upside-down - if it were me I’d run it all in a VM (Xen probably - easy enough to add io passthrough there if required) and trap the IO writes there - leave the original environment as-is as much as possible (except for putting it in a VM box of course).

James

11

Joe

Obviously you have never had to play in the fun world on VDDs! These are
drivers after a fashion, but nothing like the ones we all know and love.
Introduced twenty years ago give or take, they are now obsolete, but I can’t
tell you how much fun I had with them on NT4. There may even be some MSDN
documentation on them still as 32-bit client operating systems are still
supported and the XP VM is still quite common

wrote in message news:xxxxx@ntdev…

I’m writing a Virtual Device Driver (VDD) for DOS applications.
When I use VDDInstallIoHook() to catch I/O access, everything works fine
as expected,

but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three
well-known LPT port adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE)
will fail to go to the hook procedure!
Looks independently on whether there is a true parallel port installed in
the system or not.
Test system: Windows XP Prof. 32bit DE.

While inspecting ntvdm.exe, I found lots of code dealing with those
addresses, so the question is - again - how to disable ntvdm.exe’s
built-in port trapping feature (if so)?

Obviously, for my problem (redirecting parallel port access to a
USB->ParallelPrinter converter), hooking the well-known LPT addresses is
mantadory, I cannot move to other addresses.

I think there is something seriously failed in your approach. Replacing a
printer driver with another that goes to USB has absolutely NOTHING to do
with intercepting port writes. You are doing this completely upside-down.
What you need to do is write a WDF USB driver and have it be recognized
as the printer.

WTF is a VDD? Sounds like a leftover from Win16, and I don’t see how it
has anything to do with Windows in 2013.
joe

Does someone know the relationships and how to break into? Does someone
experienced this behaviour with true parallel ports?

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

12

I know that in NT4 it was possible to use 16-bit drivers, but i thought
that went away with Win2K, about 14 years ago. Trapping reads and rites
to I/O ports sounds so completely bizarre in a modern system (well, any
ststem) that I can’t see the point to it. Besides, if the ports simply
don’t exist, how can you trap operations on them at all?

It seems to me that it would be more effective to define a device that
supports the abstract interface and talks to USBD.
joe

Joe

Obviously you have never had to play in the fun world on VDDs! These are
drivers after a fashion, but nothing like the ones we all know and love.
Introduced twenty years ago give or take, they are now obsolete, but I
can’t
tell you how much fun I had with them on NT4. There may even be some MSDN
documentation on them still as 32-bit client operating systems are still
supported and the XP VM is still quite common

wrote in message news:xxxxx@ntdev…

> I’m writing a Virtual Device Driver (VDD) for DOS applications.
> When I use VDDInstallIoHook() to catch I/O access, everything works fine
> as expected,
>
> but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three
> well-known LPT port adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE)
> will fail to go to the hook procedure!
> Looks independently on whether there is a true parallel port installed
> in
> the system or not.
> Test system: Windows XP Prof. 32bit DE.
>
> While inspecting ntvdm.exe, I found lots of code dealing with those
> addresses, so the question is - again - how to disable ntvdm.exe’s
> built-in port trapping feature (if so)?
>
> Obviously, for my problem (redirecting parallel port access to a
> USB->ParallelPrinter converter), hooking the well-known LPT addresses is
> mantadory, I cannot move to other addresses.
>
I think there is something seriously failed in your approach. Replacing a
printer driver with another that goes to USB has absolutely NOTHING to do
with intercepting port writes. You are doing this completely upside-down.
What you need to do is write a WDF USB driver and have it be recognized
as the printer.

WTF is a VDD? Sounds like a leftover from Win16, and I don’t see how it
has anything to do with Windows in 2013.
joe
> Does someone know the relationships and how to break into? Does someone
> experienced this behaviour with true parallel ports?
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

13

>

I know that in NT4 it was possible to use 16-bit drivers, but i thought
that went away with Win2K, about 14 years ago. Trapping reads and rites
to I/O ports sounds so completely bizarre in a modern system (well, any
ststem) that I can’t see the point to it. Besides, if the ports simply
don’t exist, how can you trap operations on them at all?

I don’t believe the OP mentioned the words “modern system” anywhere.

It seems to me that it would be more effective to define a device that
supports the abstract interface and talks to USBD.

Given the choice between adding USB access to a 16 bit app or trapping writes to a hardware port to make it think it was poking the ports of a real LPT interface, I’d go with the latter.

Have a think about how you would write a dos emulator if it took your fancy to do so. Any program that wants to directly fiddle with the bits of a parallel port is going to use io port access. The BIOS calls might do for simple unidirectional printing but for anything else it’s io ports. Are you going to trap that access and then simulate the action over the USB parallel port, or are you going to dig up the developers of the application (maybe even literally dig them up!) and ask them to rewrite their app to conform with your idea of how the world should work?

James

14

>>

> I know that in NT4 it was possible to use 16-bit drivers, but i thought
> that went away with Win2K, about 14 years ago. Trapping reads and rites
> to I/O ports sounds so completely bizarre in a modern system (well, any
> ststem) that I can’t see the point to it. Besides, if the ports simply
> don’t exist, how can you trap operations on them at all?
>

I don’t believe the OP mentioned the words “modern system” anywhere.

*****

Actually, it was implied. The issue is how to rediect physical LPT
operations to a USB printer interface. It may have been possible in
Win2K, but my memory says that USB was not supported in Windows until XP.
XP will not run at all on legacy hardware, so it is an XP+ OS running on a
modern system.

*****

> It seems to me that it would be more effective to define a device that
> supports the abstract interface and talks to USBD.

Given the choice between adding USB access to a 16 bit app or trapping
writes to a hardware port to make it think it was poking the ports of a
real LPT interface, I’d go with the latter.

*****
I will admit that it has been many years since I looked at the debug
registers that trapped port operations. So I don’t know if they support
trapping operations to nonexistent ports. The te question arises about
how much of MS-DOS is /really/ implemented in NTVDM. I know that a lot of
hairy operations I would do with disk and video INT calls, and most of INT
21h are explicitly NOT supported. Now, if we put an NTVDM running under a
hypervisor, exactly how much of the old MS-DOS is supported? If 20% of
the operations are not trapped, that might be because (a) that feature was
deliberately unsupported (b) it was supposed to be supported, but this is
the first time someone has exercised it on the parallel port adresses If
(b) it could be a bug in NTVDM, in which case (a) 16-bit support is dead,
and it will never be fixed, and (b)… wait a moment…I don’t think there
is a (b) here!

Then, of course, if it is being run under a hypervisor, we have a whole
new world of hurt, and what are the chances the hypervisor would be fixed
to support 16-bit apps…

If you have a printer driver that supports te full XXX capability of a
legacy printer card that supports XXX (and I have forgotten te TLA that
designates such drivers, then simply opening LPT and sending te right
commands (most likely, DeviceIoControl) to it should have the correct
effect whether it s a real, physical port with one of te “well-known”
hardware port address ranges, or something tat has a USB interface. My
memory is that MS-DOS only supported a very limited set of operations on
parallel ports, and you could not read or write all status bits, ad could
not read data bits. So a VDD (which I always thought of as te positive
voltage supply to a NMOS chip) would have been required to get these
capabilities. Then users started needing to handle messages being sent
back by printers, and a third-party market for XXX interface boards and
fully-compatible XXX drivers grew around the needs. I stopped worrying
about parallel ports when I discovered tat all my printers only supported
serial interfaces (well, OK, two were 10-baseT and one is 100-baseT serial
iterfaces) and lost interest in the problem, but I have this menory that
Microsoft started supporting the full XXX capabilities for Win2K, or maybe
XP–perhaps someone who cares about parallel ports can confirm or deny
this memory. That being so, the need for a complex driver to support what
is already supported seems to be a lot of work for no particular gain.
And it does raise the question about whether or not te USB-to-parralel
adapter supports te XXX featured.

Now, if I’m running NTVDM and open LPT, and te “real” LPT device is a USB
adapter, what happens?

So te question I would ask of this group, if I had this problem, would be:

“I have a legacy app that uses a VDD under NTVDM to manipulate the full
capabilities of an XXX parallel port. I need to change this so te app,
running under NTVDM, can access the device capabilities for a
USB-to-parallel interface. The operations I need to support are operations here>. What is the best way to achieve this?”

Note that nowhere did I refer to an implementation detail such as port
traps. That may be how MS-DOS had to implement it, but I’m working in a
richer environment. The solution may be far easier than trying to
discover why port writes are not being trapped. Yes, quarter-round and
putty can disguise a multitude of sins, but it may not be necessary to
commit them in te first place.
*****
>
> Have a think about how you would write a dos emulator if it took your
> fancy to do so. Any program that wants to directly fiddle with the bits of
> a parallel port is going to use io port access. The BIOS calls might do
> for simple unidirectional printing but for anything else it’s io ports.
> Are you going to trap that access and then simulate the action over the
> USB parallel port, or are you going to dig up the developers of the
> application (maybe even literally dig them up!) and ask them to rewrite
> their app to conform with your idea of how the world should work?
>
****
Since we have no actual description of the problem, except one that says
“port trapping does not appear to work”, we don’t know what the VDD specs
are, so it is very hard to guess at te correct answer. We don’t know if
an app is writing to physical ports and the purpose of te VDD is to trap
such actions, or what the interface is that is attempting to be supported.

Too many times in my life I have been in the “We can’t change te app”
constraint, only to discover, after many weeks of stressful effort (read:
90-hour weeks) I expended to solve the problem, that the actual source
code required only FOUR LINES be changed. No mention of this as a
parameter of the problem space appeared.

Sort of like “What’s the best way to glue wings to a pig” fails to specify
that the “wings” are a 20-foot aluminum wing from a small aircraft and the
pig is one of those miniature pigs. In that case, the answer might be
“use bungee cords to strap the pig on the top of the wing” (which may
cause problems with airflow and change the stall speed or L/D ratio, or
annoy the pig), or “cut a hole in the center, create a cockpit for te pig,
and make a cover for the hole that does not affect the aerodynamic
properties”.

So your above description is just guesswork, anf may or may not reflect
the actual situation. In addition, if the VDD intercepts 100% of the port
operations, how does it call the host OS USB support (and by “host” I mean
“the 32-bit OS which is running the NTVDM”)
joe

> James
>
>
> —
> NTDEV is sponsored by OSR
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

15

>

Actually, it was implied. The issue is how to rediect physical LPT
operations to a USB printer interface. It may have been possible in
Win2K, but my memory says that USB was not supported in Windows until
XP.
XP will not run at all on legacy hardware, so it is an XP+ OS running on a
modern system.

Okay I guess we’re talking different things. I was inferring that they were running a legacy application (system) on modern hardware, so I was disagreeing with a point you weren’t making…

So your above description is just guesswork, anf may or may not reflect
the actual situation. In addition, if the VDD intercepts 100% of the port
operations, how does it call the host OS USB support (and by “host” I mean
“the 32-bit OS which is running the NTVDM”)

Well this is the main problem I guess… the OP gave a vague description of the point he was stuck on and without any further information about what he was trying to do, any subsequent discussion is just for shits and giggles.

James

16

> Win2K, but my memory says that USB was not supported in Windows until XP.

Until Win98.

For NT line, it was w2k.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

17

To the OP:

Have you ever written a virtual CPU program? this used to be one of the
standard assignments in computer science courses, but I have no idea what is
taught now or when / where you went to school.

Assuming that performance is not an issue, which we do not expect given that
the program was likely written for 486 or slower machines, you could write a
wrapper program that interpreted the 16 bit code instead of NTVDM. You
would be guaranteed to have complete control over the program’s execution
and depending on what the program does it isn’t that much more complex then
what you are already doing. The big part is decoding the instructions, but
once you have that, it is just a lot of typing to support all of the
instructions and other operations used by your particular program

As Joe mentions though, if you do have the source code, it may be simpler to
alter the program

“James Harper” wrote in message news:xxxxx@ntdev…

Actually, it was implied. The issue is how to rediect physical LPT
operations to a USB printer interface. It may have been possible in
Win2K, but my memory says that USB was not supported in Windows until
XP.
XP will not run at all on legacy hardware, so it is an XP+ OS running on a
modern system.

Okay I guess we’re talking different things. I was inferring that they were
running a legacy application (system) on modern hardware, so I was
disagreeing with a point you weren’t making…

So your above description is just guesswork, anf may or may not reflect
the actual situation. In addition, if the VDD intercepts 100% of the port
operations, how does it call the host OS USB support (and by “host” I mean
“the 32-bit OS which is running the NTVDM”)

Well this is the main problem I guess… the OP gave a vague description of
the point he was stuck on and without any further information about what he
was trying to do, any subsequent discussion is just for shits and giggles.

James

18

> but SOME (10 to 20 %) I/O transfer (both OUT and IN) to ANY of the three well-known LPT port

adresses (0x378…0x37A, 0x278…0x27A, 0x3BC…0x3BE) will fail to go to the hook procedure!

I think the NTVDM DOS app shortcut (called .pif usually) has Properties (right-click in a shell) which governs the ports available to the VM. Try playing with these settings.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

19

> the program was likely written for 486 or slower machines, you could write a

wrapper program that interpreted the 16 bit code instead of NTVDM.

This is what DosBox does.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

20

Win98 was not Windows. It was MS-DOS with a GUI interface.
joe

> Win2K, but my memory says that USB was not supported in Windows until
> XP.

Until Win98.

For NT line, it was w2k.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer