Hello. I have this problem, that IMHO might be a bug. The exact description
of the problem follows.

I have a new laptop with Vista Home Basic, connected to an old parallel
dot-matrix printer (Epson FX-80 compatible) via an USB-to-LPT adapter cable.
The printer is recognized without trouble and prints the Test Page correctly.
Next, I share the printer, say, under the name EPSON, and the computer name
is USER-PC. I install the Microsoft Loopback network adapter to ensure the
"network" will always be up. I have an old DOS application that I want to run
on the laptop and I want it to print to that printer. Let's suppose that
application is named APP.EXE. I compose a batch file with the following
contents:

net use LPT2 \\USER-PC\EPSON /YES
C:\APP\APP.EXE

The applications runs properly, but doesn't want to print, but gives an
error message instead. It is configured to use port LPT2 for printing. The
error message is:

DOS Error 5: Access Denied
printing to LPT2 FAILED!

The fun part is that the MS-DOS editor EDIT prints to that printer properly.
Under Windows XP Pro SP2 with exactly the same configuration everything works
fine.

After some fiddling with debuggers/disassemblers I was able to determine the
possible source of this problem. The MS-DOS editor EDIT uses the 0x716C
function of interrupt 0x21 (Extended Open/Create, LFN support, DOS 7+) to
open the port LPT2 and the port opens successfully, but if an older DOS API
function is used, such as the 0x6C function of interrupt 0x21 (Extended
Open/Create, DOS 4+), the port does not open and an error is returned
instead. IMHO, this is a bug in the NTVDM. Can someone look into this?

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

[url]http://windowshelp.microsoft.com/communities/newsgroups/en-us/default.mspx?mid=d2b3a79e-c4e0-42f2-bc90-f414e88b1a88&dg=microsoft.public.windows.vista.general[/url]

Vassil Daskalov wrote:[color=blue]
> Hello. I have this problem, that IMHO might be a bug. The exact description
> of the problem follows.[/color]

(snippage)

Something is only a bug if what you are trying to do is natively
supported by the operating system and it doesn't work correctly. MS-DOS
has been dead for many years, has never been a part of an NT operating
system (NT, Win2k, XP, Vista), and is therefore not supported in Vista.
I don't work for Microsoft but I'm sure they aren't working on getting
DOS printing to be successful in Vista. If it is important to you, a
better solution would be for you to have a computer running Win9x just
for your program. However, it will get harder to find drivers for modern
hardware that support these very much older operating systems, so you
should consider replacing the application with something written for a
modern operating system.

Good luck,


Malke
--
Elephant Boy Computers
[url]www.elephantboycomputers.com[/url]
"Don't Panic!"
MS-MVP Windows - Shell/User

"Vassil Daskalov" <Vassil [email]Daskalov@discussions.microsoft.com[/email]> wrote ...[color=blue]
> possible source of this problem. The MS-DOS editor EDIT uses the 0x716C
> function of interrupt 0x21 (Extended Open/Create, LFN support, DOS 7+) to
> open the port LPT2 and the port opens successfully, but if an older DOS
> API
> function is used, such as the 0x6C function of interrupt 0x21 (Extended
> Open/Create, DOS 4+), the port does not open and an error is returned
> instead. IMHO, this is a bug in the NTVDM. Can someone look into this?[/color]

Hi Vassil,

Well, I can't find my old MS-DOS Programmer's Reference :-) but, yes, this
sounds like strange behaviour.

The LFN version of the service is the same as the "old" DOS service, except
0x71 is in AH. So if 0x716C works in AX, I'd expect 0x6C in AL to also work.
But, seems it does not ...

I have voted in support of your suggestion. However, to get maximum exposure
for the issue, I recommned you also send feedback direct to Microsoft. You
cen send feedback using this URL (mind the wrap):

Vista Feedback:
[url]http://feedback.windowsvista.microsoft.com/eform.aspx?productkey=winvista&mkt=en-us&backurl=http://support.microsoft.com/gp/cp_vista_master[/url]

DOS apps cannot run on 64-bit Windows. Since nearly all CPUs are now 64 bit,
the days of DOS applications are definitely numbered ... but I guess you
already know that!

Regards,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

Thank you for the link. I didn't know about it :)

The function 6C should really be called 6C00, because this is really the
value of AX... I'm sorry for this little confusion :)

"Andrew McLaren" wrote:
[color=blue]
> "Vassil Daskalov" <Vassil [email]Daskalov@discussions.microsoft.com[/email]> wrote ...[color=green]
> > possible source of this problem. The MS-DOS editor EDIT uses the 0x716C
> > function of interrupt 0x21 (Extended Open/Create, LFN support, DOS 7+) to
> > open the port LPT2 and the port opens successfully, but if an older DOS
> > API
> > function is used, such as the 0x6C function of interrupt 0x21 (Extended
> > Open/Create, DOS 4+), the port does not open and an error is returned
> > instead. IMHO, this is a bug in the NTVDM. Can someone look into this?[/color]
>
> Hi Vassil,
>
> Well, I can't find my old MS-DOS Programmer's Reference :-) but, yes, this
> sounds like strange behaviour.
>
> The LFN version of the service is the same as the "old" DOS service, except
> 0x71 is in AH. So if 0x716C works in AX, I'd expect 0x6C in AL to also work.
> But, seems it does not ...
>
> I have voted in support of your suggestion. However, to get maximum exposure
> for the issue, I recommned you also send feedback direct to Microsoft. You
> cen send feedback using this URL (mind the wrap):
>
> Vista Feedback:
> [url]http://feedback.windowsvista.microsoft.com/eform.aspx?productkey=winvista&mkt=en-us&backurl=http://support.microsoft.com/gp/cp_vista_master[/url]
>
> DOS apps cannot run on 64-bit Windows. Since nearly all CPUs are now 64 bit,
> the days of DOS applications are definitely numbered ... but I guess you
> already know that!
>
> Regards,
> --
> Andrew McLaren
> amclar (at) optusnet dot com dot au
>
>[/color]