dos application not working in windows
Denny Evans
run a dos application and I get the message "this program
can not be run on Windows" how can I correct this or is
this even possible to correct?
A l e x A n g e l o p o u l o s
What application?
How are you running it? (typing in to the command ine, etc.)
Where did it come from?
"Denny Evans" <denn...@yahoo.com> wrote in message
news:93d701c154da$eed2ca40$19ef2ecf@tkmsftngxa01...
Star Fleet Admiral Q
won't allow that - period - no work around, except dual boot with a
Win9x/DOS OS and run the application there.
--
Star Fleet Admiral "Q"
"Q" Continuum
Just somebody who likes to help,
no MVP, MCP, MCSE, etc....
Remove the Obvious from E-Mail to reply directly:
email: doomsdayma...@startrekmail.com
"Denny Evans" <denn...@yahoo.com> wrote in message
news:93d701c154da$eed2ca40$19ef2ecf@tkmsftngxa01...
Jonathan de Boyne Pollard
DE> "this program can not be run on Windows" how can I correct
DE> this or is this even possible to correct?
Rewrite the application.
Some DOS applications attempt to detect whether they are running on
DOS-Windows and, if they detect that they are, print an error message and
terminate without doing anything. The motivations for writing DOS programs
that do this are varied, but more often than not involve preventing a DOS
program from pulling the rug out from underneath DOS-Windows by accessing a
piece of hardware directly in some way (as would be done to modify the
firmware in its non-volatile memory, for example).
The ways that these DOS programs attempt to detect DOS-Windows also vary, so
there is no single way to evade their detection mechanisms. (Semi-)Officially,
there is an INT 2Fh call that DOS programs can issue that reports the presence
of DOS-Windows (or, more specifically, the presence of the VMM and VxDs). The
"allow MS-DOS programs to detect Windows" setting in PIF files supported by
DOS-Windows controls the behaviour of this INT 2Fh call. (Windows NT
4/2000/XP does not support this PIF file setting.) However, not all DOS
programs use this call, and so not all DOS programs can have their detection
bypassed using this setting. For example, one of the widely circulated BASIC
programming FAQ documents includes a snippet of BASIC code to detect
DOS-Windows that scans the environment looking for the presence of any of
%WINDIR%, %WINBOOTDIR%, and %WIN95% environment variables. Other DOS programs
use equally shaky, and equally different, methods of detection.
On the gripping hand, bypassing the detection mechanism is pointless. This
newsgroup is not about DOS-Windows. It is about Windows NT 4/2000/XP. A DOS
program that fiddles with hardware directly is, quite simply, a piece of
useless junk on Windows NT. Windows NT doesn't allow DOS programs to access
hardware directly. Even if one bypassed whatever detection mechanism the
program was using, or excised the detection mechanism from the application
entirely, the program would very likely be unable to perform the actual task
that it was intended to perform.
One has three choices, therefore. One can boot MS/DR/PC-DOS, instead of
Windows NT or DOS-Windows, and run the original DOS application; one can
rewrite the DOS application as a Win32 application that talks to the device's
native Windows NT device driver; or one can rewrite the DOS application as a
native application of some other operating system and boot that operating
system.
Some hardware manufacturers have long since woken up to the notion that people
no longer boot MS/PC/DR-DOS. They have adopted various approaches. Some
manufacturers continue to write DOS programs for controlling their hardware,
and simply supply a bootable DOS floppy disc (usually DR-DOS or FreeDOS) along
with their utilities. Other manufacturers have chosen to write linux or
FreeBSD programs, and supply a bootable linux or FreeBSD floppy disc. No
manufacturer ships bootable Windows NT discs, because (aside from what would
almost certainly be crippling licencing terms from Microsoft) whilst a
bootable Windows NT system *could* probably be persuaded to fit onto a modern
120MiB LS-120 floppy disc, there is no way that it could fit onto an
old-fashioned 1.4MiB floppy disc - as DR-DOS, FreeDOS, linux, and FreeBSD all
can. However, some manufacturers do write Win32 programs (that talk to the
Windows NT driver for the device) to do things such as firmware updates.
(Those that provide *only* Windows NT programs lock themselves out of the
wider market, of course.)
A l e x A n g e l o p o u l o s
"Jonathan de Boyne Pollard" <J.deBoyn...@tesco.net> wrote in message
news:3BCD4318...@tesco.net...
> DE> I am trying to run a dos application and I get the message
> DE> "this program can not be run on Windows" how can I correct
> DE> this or is this even possible to correct?
>
> Rewrite the application.
LOL - I love that answer! Just out of curiosity about one fairly far-fetched
workaround...
How "nicely" do legacy MS-DOS applications tend to play with Linux DOS
emulations? Do the same problems tend to show up (excessive CPU utilization,
etc)?
Jonathan de Boyne Pollard
AA> DOS emulations? Do the same problems tend to show up (excessive
AA> CPU utilization, etc)?
Excessive CPU utilisation shows up, yes. When a DOS program sits in a busy
wait loop polling the keyboard, it doesn't matter *what* operating system is
running. The code for that loop is still going to be executed. All that
operating systems can do is attempt to detect such busy wait loops. The
differences between the various operating systems are in the degree to which
they can perform this detection, and how much control the user is given over
detection thresholds and scheduling parameters. (OS/2 Warp's Virtual DOS
Machines are the best at such detection, for example, and place the most
control in the hands of the user.)
Many of the problems encountered with DOS applications are exactly the same
for linux's DOSEMU, OS/2 Warp's Virtual DOS Machines, and Windows NT's NTVDM.
Many of them are simply due to the nature of running a DOS program in a
multitasking system, or on top of a disc cache, or with non-FAT disc volumes;
and so will occur equally with linux, OS/2 Warp, Windows NT, or anything
else. DOS programs that want to directly manipulate raw FAT volume
structures, or that perform access to hardware devices where timing is
important, or that busy wait, are going to be troublesome everywhere, for
example.
There _are_ some things that do vary from operating system to operating
system. Parallel port support is one example. The DOS version of LapLink
will work using a parallel port in an OS/2 Warp Virtual DOS Machine, but will
not work using a parallel port in NTVDM in Windows NT.