video reset kills beep in DOS box

N

nutso fasst

Hello, all.

My workstation runs Win2K. I wrote a DOS program that beeps the PC speaker
by sending a BEL character (7) to the console. When I first open a DOS
prompt and run the program, the speaker beeps. But if I run any programs
that set the video mode--such as the DOS edit program, debug or an old
game--the speaker no longer beeps. It doesn't matter if I beep the speaker
with Int 21h function 2 or with Int 10h function 0Eh, the fact is that
running most any old executable will kill sound from the speaker. To get the
speaker sound back I have to open another DOS box.

I just checked a system running XP, and it's got the same problem.

Any way to get the beep back?

nf
 
P

Pegasus \(MVP\)

nutso fasst said:
Hello, all.

My workstation runs Win2K. I wrote a DOS program that beeps the PC speaker
by sending a BEL character (7) to the console. When I first open a DOS
prompt and run the program, the speaker beeps. But if I run any programs
that set the video mode--such as the DOS edit program, debug or an old
game--the speaker no longer beeps. It doesn't matter if I beep the speaker
with Int 21h function 2 or with Int 10h function 0Eh, the fact is that
running most any old executable will kill sound from the speaker. To get the
speaker sound back I have to open another DOS box.

I just checked a system running XP, and it's got the same problem.

Any way to get the beep back?

nf

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?
- 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.
- 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?
- 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
 
N

nutso fasst

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
 
P

Pegasus \(MVP\)

nutso fasst said:
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

You obviously know a great deal about DOS, interrupts
and assembly language, and you are entitled to believe
that there is a "DOS (Disk Operating System) under NT/2K/XP,
called the MS-DOS subsystem" (your words). To me it
is just the NTVDM (as you mention too), which emulates
some DOS functions but is certainly not the real thing.

Your attempts to access the hardware directly rather
than through the proper NT system calls highlight the
difference between one and the other. I suspect you're on
a doomed mission.
 
N

nutso fasst

Your attempts to access the hardware directly rather
than through the proper NT system calls highlight the
difference between one and the other. I suspect you're on
a doomed mission.

A silly mission for sure.

Using DOS function calls does not constitute direct hardware access. By
declaring itself as DOS version 5.0, the NTVDM is obliged to support all DOS
5 functions, and actually supports long filename functions from DOS 7+
(Win95 DOS). It is not, however obliged to fully support BIOS calls or
hardware interrupts, and it doesn't. But PC speaker sound is clearly
supported somehow, as old PC games beep merrily. So to check the futility of
actual direct hardware access, I wrote a function that directly accesses the
system timer hardware registers to generate a tone to the speaker. This
works, with one caveat: it doesn't work the first time it is called!
Subsequent calls generate a tone. Of course, I could call it with a
frequency of 20Hz or so and miniscule duration to silently 'prime' it, but
I'm thinking it ain't worth adding the bytes. Silence is golden, right?

nf
 
G

Gary Smith

In microsoft.public.win2000.general nutso fasst said:
My workstation runs Win2K. I wrote a DOS program that beeps the PC speaker
by sending a BEL character (7) to the console. When I first open a DOS
prompt and run the program, the speaker beeps. But if I run any programs
that set the video mode--such as the DOS edit program, debug or an old
game--the speaker no longer beeps. It doesn't matter if I beep the speaker
with Int 21h function 2 or with Int 10h function 0Eh, the fact is that
running most any old executable will kill sound from the speaker. To get the
speaker sound back I have to open another DOS box.

Testing with the debug script you provided, I do not see the beep disabled
after running debug or edit.com. However, my system is not using the PC
speaker to generate the tone when I execute the program. It's using
Windows' default beep sound, which would be a .wav file. The sound
generated from the PC speaker in response to echoing a Ctrl-G character is
quite different. Nothing I do seems to disable that sound either. I
don't know whether this helps or just complicates the issue.
 
N

nutso fasst

Gary Smith said:
Testing with the debug script you provided, I do not see the beep disabled
after running debug or edit.com. However, my system is not using the PC
speaker to generate the tone when I execute the program. It's using
Windows' default beep sound, which would be a .wav file. The sound
generated from the PC speaker in response to echoing a Ctrl-G character is
quite different. Nothing I do seems to disable that sound either. I
don't know whether this helps or just complicates the issue.

Thanks for taking the time to test and reply, Gary. That certainly _changed_
the issue. WinXP and 98 are on a dual-boot system used only for testing.
Your result prompted me to discover that speakers were not plugged into that
system. I now find that Win98 does indeed play a .wav file for a beep. Win
XP beeps the same for both beep.com and Ctrl+G until some program is
executed (such as debug) after which beep.com sounds the .wav file. (The NT
system, which changes beep tone after debug is executed, has no sound board
installed.)

So then I had to figure out what was odd about my Win2K system (which does
have speakers attached). Looking in Control Panel\Sounds and Multimedia
Properties I saw that there was no entry for Default Beep. So I checked the
registry. There is a .Default key in HKEY_CURRENT_USER\AppEvents\Event
Labels, but there was no corresponding key in Schemes (where'd it go?). So I
added one, and to that added .Current and .Default keys w/value of ding.wav.
Eureka!, the beep! However, as with XP, the beep is still the same as Ctrl+G
until some program is run, after which it becomes ding.wav.

So there's still the question why your system always plays the default .wav
file and mine don't. But since the default .wav will play after my program
sets display mode, the problem is sufficiently solved.

Thanks again,
nf

BTW, I'm not seeing my messages in the windowsxp group so I started posting
only to the win2000 group. Unsure which group you replied from, I'll try
crossposting again.
 
G

Gary Smith

In microsoft.public.win2000.general nutso fasst said:
So there's still the question why your system always plays the default .wav
file and mine don't. But since the default .wav will play after my program
sets display mode, the problem is sufficiently solved.

Testing a bit more, I discovered that my system behaves the same as yours:
it uses the system speaker for the beep until something like edit or debug
is run; after that it plays the default .wav file. I didn't notice that
the first time because I'd apparently already run such a program before I
tried beep.com.

Opening a new command prompt windows or killing the NTVDM process resets
things so that the PC speaker is again used.
Thanks again,

I'm glad I could help.
BTW, I'm not seeing my messages in the windowsxp group so I started posting
only to the win2000 group. Unsure which group you replied from, I'll try
crossposting again.

I'm posting from the win2000 group.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top