Pegasus (MVP) said:
I'm uneasy with several items in your post:
- You keep speaking of DOS, but DOS is an operating system.
There is no DOS under Win2000. Do you mean the Command
Prompt? How do you invoke it? Do you use cmd.exe, or
command.com?
There is DOS (Disk Operating System) under NT/2K/XP. It's called the MS-DOS
subsystem.
Cmd.exe is the NT 32-bit command processor. At the cmd.exe prompt, the
environment variable ComSpec=C:\WINNT\system32\cmd.exe. When I issue a
command that runs a 16-bit DOS program, a Virtual DOS Machine (NTVDM) is
created. I speculate that the 16-bit command.com is invoked to process
MS-DOS commands in the 16-bit program, because the program's environment
block has COMSPEC=C:\WINNT\SYSTEM32\COMMAND.COM. If, in the 16-bit program,
you issue an Int 21h with AX==30h (MS-DOS command: Get MS-DOS version
number), DOS returns a major version number of 5, a minor version number of
0.
In any case, it doesn't matter whether I run the program from a cmd.exe
prompt, a command.com prompt, or directly from the Run... box with commands
of cmd /c myprog.exe or command /c myprog.exe, the problem occurs
regardless.
- How do you set the video mode? The "mode" command
under Win2000 offers a fairly extensive range of options,
and should be used in preference of 16-bit legacy commands.
The program I'm writing must be compatible with real-mode MS-DOS. The mode
is set using BIOS Int 10h, function 0. I tried DOS Int 21h IOCTL command:
Set Display Information to no avail, I got a 'function not supported' error
on two systems.
- You write that you're using edit.com. This is a 16-bit legacy
program, with lots of known problems. Have you considered
using notepad.exe instead?
I wrote that Edit and Debug screw the speaker output. Perhaps I wasn't clear
that this was simply testing to find out if the problem was specific to my
program. The real problem is that my program must set the video mode to
ensure that the display is 80x25 color text. Doing this with Int 10h,
function 0 (the only programmatic way that works consistently) kills speaker
output. So...places in my program where I want to beep the user to indicate
a bad move on their part are silent.
- You say you wrote a program to send $07 to the console.
What language is this written in? Have you considered using
a single line batch file, such as
@echo ^G
My program is written in MASM. ^G is supposed to generate a BEL (ASCI 7)
character. Writing a 7 to the console (stdout) with Int 21h, function 40h
(write to file or device) should be equivalent, but it isn't. As with the
other methods of generating a beep, it fails to work if the program sets or
gets the display mode with Int 10h.
Here's an interesting twist: In NT 4, the speaker is not killed if display
mode is gotten or set, but the beep is a high frequency tone if the video
mode has not been set, a low frequency tone if it has. And at a Windows 98
MS-DOS prompt, the speaker doesn't beep at all, period! (In real mode DOS,
or if I exit to DOS from Win98, the speaker beeps as it should.)
Anyway, this certainly seems to be a compatibility bug in Windows NTVDM. I
was hoping there might be some way to overcome it.
Anyone who wants to check this out can assemble a 8-byte beeper pgm with
debug. Just enter debug at the prompt, then enter the following 11 lines at
the debug prompt:
a 100
mov ah,2
mov dl,7
int 21
int 20
[enter blank line]
r cx
8
n beep.com
w 100
q
You'll have to open a fresh Win2K/XP command prompt to hear the beep, as
debug disables it.
Thanks for the reply.
nf