On implementing the 'beep' escape code in conhost

[Barath Rk]

This is in reference to https://bugs.winehq.org/show_bug.cgi?id=50109

Looking at Windows 10, the console 'beep' sound is represented in the
registry under the respective key as a path i.e.
C:\Windows\media\sound.wav. So the implementation should be as simple
as getting the value from this key and calling PlaySound on the
retrieved path.

Is this the expected way to implement the beep?

Also, would it be alright to simply get the .wav files from a Windows
10 install and store them in a windows\media folder when the wine
prefix is created or will there be (legal)issues lifting the .wav
files from Win10?

Regards
Barath Kannan

[Stian Low]

Beeps are very simple and should probably just be recreated similarly via
one of wine's multimedia libs.

Windows sounds are probably not redistributable which are regardless also
not included with wine for legal purposes hence winetricks.

Search repo for WAV files for tests/examples:

./dlls/dmime/tests/resource.rc:21:/* ffmpeg -f lavfi -i
"sine=frequency=600" -t 0.1 -ar 44100 -f wav -acodec pcm_u8 test.wav */

Code generated sounds are probably better for simplicity vs using more
elaborate sound tools such as LMMS.

Suggested impl seems reasonable otherwise.


On Tue, Jul 21, 2026 at 5:02 PM Barath Rk via Wine-Devel <
[e-mail]> wrote:
> This is in reference to https://bugs.winehq.org/show_bug.cgi?id=50109
>
> Looking at Windows 10, the console 'beep' sound is represented in the
> registry under the respective key as a path i.e.
> C:\Windows\media\sound.wav. So the implementation should be as simple
> as getting the value from this key and calling PlaySound on the
> retrieved path.
>
> Is this the expected way to implement the beep?
>
> Also, would it be alright to simply get the .wav files from a Windows
> 10 install and store them in a windows\media folder when the wine
> prefix is created or will there be (legal)issues lifting the .wav
> files from Win10?
>
> Regards
> Barath Kannan

[Barath Rk]

Hmm alright. Thanks for the detailed response

Regards
Barath Kannan

On Wed, 22 Jul, 2026, 12:19 am Stian Low via Wine-Devel, <
[e-mail]> wrote:
> Beeps are very simple and should probably just be recreated similarly via
> one of wine's multimedia libs.
>
> Windows sounds are probably not redistributable which are regardless also
> not included with wine for legal purposes hence winetricks.
>
> Search repo for WAV files for tests/examples:
>
> ./dlls/dmime/tests/resource.rc:21:/* ffmpeg -f lavfi -i
> "sine=frequency=600" -t 0.1 -ar 44100 -f wav -acodec pcm_u8 test.wav */
>
> Code generated sounds are probably better for simplicity vs using more
> elaborate sound tools such as LMMS.
>
> Suggested impl seems reasonable otherwise.
>
> On Tue, Jul 21, 2026 at 5:02 PM Barath Rk via Wine-Devel <
> [e-mail]> wrote:
> > This is in reference to https://bugs.winehq.org/show_bug.cgi?id=50109
> >
> > Looking at Windows 10, the console 'beep' sound is represented in the
> > registry under the respective key as a path i.e.
> > C:\Windows\media\sound.wav. So the implementation should be as simple
> > as getting the value from this key and calling PlaySound on the
> > retrieved path.
> >
> > Is this the expected way to implement the beep?
> >
> > Also, would it be alright to simply get the .wav files from a Windows
> > 10 install and store them in a windows\media folder when the wine
> > prefix is created or will there be (legal)issues lifting the .wav
> > files from Win10?
> >
> > Regards
> > Barath Kannan

[Eric Pouech]

Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
> Hmm alright. Thanks for the detailed response

MessageBeep shall be used

[Barath Rk]

Using MessageBeep for the implementation works on XWayland, but using
Wayland I don't get the Beep as it is not implemented in the
winewayland driver. How would the workflow look for implementing this?
Would I have to open a separate MR or can I just add the Wayland Beep
implementation as another commit in the same MR as the console Beep
implementation?

Regards
Barath Kannan

On Wed, Jul 22, 2026 at 1:45 PM Eric Pouech <[e-mail]> wrote:
> Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
> > Hmm alright. Thanks for the detailed response
>
> MessageBeep shall be used

[Eric Pouech]

Le 23/07/2026 à 08:15, Barath Rk via Wine-Devel a écrit :
> Using MessageBeep for the implementation works on XWayland, but using
> Wayland I don't get the Beep as it is not implemented in the
> winewayland driver. How would the workflow look for implementing this?
> Would I have to open a separate MR or can I just add the Wayland Beep
> implementation as another commit in the same MR as the console Beep
> implementation?

both approaches are valid

using 1MR+2commits make clean why you're adding code to wayland driver

but has the drawback of involving several maintainers

[Barath Rk]

Then would it be fine to create 2 MRs at the same time? I was a little
biased towards 1 MR 2 Commits because of the wiki stating that multiple
outstanding MRs from an individual are discouraged.

On Thu, 23 Jul, 2026, 1:16 pm Eric Pouech, <[e-mail]> wrote:
> Le 23/07/2026 à 08:15, Barath Rk via Wine-Devel a écrit :
> > Using MessageBeep for the implementation works on XWayland, but using
> > Wayland I don't get the Beep as it is not implemented in the
> > winewayland driver. How would the workflow look for implementing this?
> > Would I have to open a separate MR or can I just add the Wayland Beep
> > implementation as another commit in the same MR as the console Beep
> > implementation?
>
> both approaches are valid
>
> using 1MR+2commits make clean why you're adding code to wayland driver
>
> but has the drawback of involving several maintainers

[Jinoh Kang]

On Thu, Jul 23, 2026, 17:19 Barath Rk via Wine-Devel <
[e-mail]> wrote:
> Then would it be fine to create 2 MRs at the same time? I was a little
> biased towards 1 MR 2 Commits because of the wiki stating that multiple
> outstanding MRs from an individual are discouraged.

The same principle applies to one MR encompassing multiple functionalities.

The rule isn't clear cut, and is intended to discourage overflowing
reviewer resources by e.g., making the same mistake across multuple MRs. If
your MRs have distinct maintainers, and you get their approval, then you
should be fine.
>

-- 
Jinoh

[Barath Rk]

> If your MRs have distinct maintainers, and you get their approval, then you should be fine

Should I have to ping the maintainer beforehand to get their opinion
on opening an MR?

If so, any idea who I am supposed to ping for the Wayland MR? I know
Eric deals with console related stuff but I don't see any entry in the
MAINTAINERS file for the wayland driver maintainer.

On Thu, Jul 23, 2026 at 2:45 PM Jinoh Kang <[e-mail]> wrote:
> On Thu, Jul 23, 2026, 17:19 Barath Rk via Wine-Devel <[e-mail]> wrote:
> > Then would it be fine to create 2 MRs at the same time? I was a little biased towards 1 MR 2 Commits because of the wiki stating that multiple outstanding MRs from an individual are discouraged.
>
> The same principle applies to one MR encompassing multiple functionalities.
>
> The rule isn't clear cut, and is intended to discourage overflowing reviewer resources by e.g., making the same mistake across multuple MRs. If your MRs have distinct maintainers, and you get their approval, then you should be fine.
>
> --
> Jinoh

[Stian Low]

Probably simpler for you to get started at this point and ask forgiveness
for minor mistakes rather than permission.

Git history/logs for files touched is often reliable for determining
maintainers if not updated elsewhere yet.


On Thu, Jul 23, 2026 at 9:59 AM Barath Rk via Wine-Devel <
[e-mail]> wrote:
> > If your MRs have distinct maintainers, and you get their approval, then
> > you should be fine
>
> Should I have to ping the maintainer beforehand to get their opinion
> on opening an MR?
>
> If so, any idea who I am supposed to ping for the Wayland MR? I know
> Eric deals with console related stuff but I don't see any entry in the
> MAINTAINERS file for the wayland driver maintainer.
>
> On Thu, Jul 23, 2026 at 2:45 PM Jinoh Kang <[e-mail]>
> wrote:
> > On Thu, Jul 23, 2026, 17:19 Barath Rk via Wine-Devel <
>
> [e-mail]> wrote:
> > > Then would it be fine to create 2 MRs at the same time? I was a little
> >
> > biased towards 1 MR 2 Commits because of the wiki stating that multiple
> > outstanding MRs from an individual are discouraged.
> > >
> >
> > The same principle applies to one MR encompassing multiple
> > functionalities.
> >
> > The rule isn't clear cut, and is intended to discourage overflowing
> > reviewer resources by e.g., making the same mistake across multuple MRs. If
> > your MRs have distinct maintainers, and you get their approval, then you
> > should be fine.
> >
> > --
> > Jinoh

[Barath Rk]

Fair enough lol. Thanks

On Thu, 23 Jul, 2026, 4:15 pm Stian Low via Wine-Devel, <
[e-mail]> wrote:
> Probably simpler for you to get started at this point and ask forgiveness
> for minor mistakes rather than permission.
>
> Git history/logs for files touched is often reliable for determining
> maintainers if not updated elsewhere yet.
>
> On Thu, Jul 23, 2026 at 9:59 AM Barath Rk via Wine-Devel <
> [e-mail]> wrote:
> > > If your MRs have distinct maintainers, and you get their approval,
> > > then you should be fine
> >
> > Should I have to ping the maintainer beforehand to get their opinion
> > on opening an MR?
> >
> > If so, any idea who I am supposed to ping for the Wayland MR? I know
> > Eric deals with console related stuff but I don't see any entry in the
> > MAINTAINERS file for the wayland driver maintainer.
> >
> > On Thu, Jul 23, 2026 at 2:45 PM Jinoh Kang <[e-mail]>
> > wrote:
> > > On Thu, Jul 23, 2026, 17:19 Barath Rk via Wine-Devel <
> >
> > [e-mail]> wrote:
> > > > Then would it be fine to create 2 MRs at the same time? I was a little
> > >
> > > biased towards 1 MR 2 Commits because of the wiki stating that multiple
> > > outstanding MRs from an individual are discouraged.
> > > >
> > >
> > > The same principle applies to one MR encompassing multiple
> > > functionalities.
> > >
> > > The rule isn't clear cut, and is intended to discourage overflowing
> > > reviewer resources by e.g., making the same mistake across multuple MRs. If
> > > your MRs have distinct maintainers, and you get their approval, then you
> > > should be fine.
> > >
> > > --
> > > Jinoh

[Elizabeth Figura]

On Wednesday, 22 July 2026 03:15:12 CDT Eric Pouech via Wine-Devel wrote:
> Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
> > Hmm alright. Thanks for the detailed response
>
> MessageBeep shall be used

Isn't MessageBeep a higher level API?

[Eric Pouech]

Le 23/07/2026 à 17:06, Elizabeth Figura via Wine-Devel a écrit :
> On Wednesday, 22 July 2026 03:15:12 CDT Eric Pouech via Wine-Devel wrote:
> > Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
> > > Hmm alright. Thanks for the detailed response
> >
> > MessageBeep shall be used
>
> Isn't MessageBeep a higher level API?

higher than what?

(it's supposed to be called from conhost.exe, so I don't see too much 
trouble here)

and I tried to avoid calling kernel32.Beep from conhost (it would 
require calling some MM apis from kernel32, which doesn't seem great either)

-Eric

[Senthil Lewituz]

Please unsubscribe

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Eric Pouech via Wine-Devel <[e-mail]>
Sent: Thursday, 23 July 2026 19:34:37
To: [e-mail] <[e-mail]>
Cc: Barath Rk <[e-mail]>; Elizabeth Figura <[e-mail]>; Eric Pouech <[e-mail]>
Subject: Re: On implementing the 'beep' escape code in conhost

Le 23/07/2026 à 17:06, Elizabeth Figura via Wine-Devel a écrit :

On Wednesday, 22 July 2026 03:15:12 CDT Eric Pouech via Wine-Devel wrote:


Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :


Hmm alright. Thanks for the detailed response



MessageBeep shall be used




Isn't MessageBeep a higher level API?





higher than what?

(it's supposed to be called from conhost.exe, so I don't see too much trouble here)

and I tried to avoid calling kernel32.Beep from conhost (it would require calling some MM apis from kernel32, which doesn't seem great either)

-Eric

[Stian Low]

You may unsubscribe yourself from wine-devel via:

https://gitlab.winehq.org/wine/wine/-/wikis/Forums#developer-mailing-lists


On Thu, Jul 23, 2026 at 4:00 PM Senthil Lewituz via Wine-Devel <
[e-mail]> wrote:
> Please unsubscribe
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* Eric Pouech via Wine-Devel <[e-mail]>
> *Sent:* Thursday, 23 July 2026 19:34:37
> *To:* [e-mail] <[e-mail]>
> *Cc:* Barath Rk <[e-mail]>; Elizabeth Figura <
> [e-mail]>; Eric Pouech <[e-mail]>
> *Subject:* Re: On implementing the 'beep' escape code in conhost
>
> Le 23/07/2026 à 17:06, Elizabeth Figura via Wine-Devel a écrit :
>
> On Wednesday, 22 July 2026 03:15:12 CDT Eric Pouech via Wine-Devel wrote:
>
> Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
>
> Hmm alright. Thanks for the detailed response
>
> MessageBeep shall be used
>
> Isn't MessageBeep a higher level API?
>
> higher than what?
>
> (it's supposed to be called from conhost.exe, so I don't see too much
> trouble here)
>
> and I tried to avoid calling kernel32.Beep from conhost (it would require
> calling some MM apis from kernel32, which doesn't seem great either)
>
> -Eric

[Elizabeth Figura]

On Thursday, 23 July 2026 10:34:37 CDT Eric Pouech via Wine-Devel wrote:
> Le 23/07/2026 à 17:06, Elizabeth Figura via Wine-Devel a écrit :
> > On Wednesday, 22 July 2026 03:15:12 CDT Eric Pouech via Wine-Devel wrote:
> > > Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
> > > > Hmm alright. Thanks for the detailed response
> > >
> > > MessageBeep shall be used
> >
> > Isn't MessageBeep a higher level API?
>
> higher than what?
>
> (it's supposed to be called from conhost.exe, so I don't see too much 
> trouble here)

Higher than Beep(). I thought that MessageBeep() was supposed to call Beep() in fact.

I guess with conhost maybe it is the other way around.
> and I tried to avoid calling kernel32.Beep from conhost (it would 
> require calling some MM apis from kernel32, which doesn't seem great either)
>
> -Eric

[Barath Rk]

> Higher than Beep()
> From what I have seen, MessageBeep and Beep appear to be pretty
> different the way they have been implemented right now. MessageBeep
> calls the respective Beep method defined for the particular display
> server protocol being used. Currently only X11/XWayland is
> supported(look at pBeep in x11drv_funcs present in
> dlls/winex11.drv/init.c which is basically just a call to XBell). A
> Beep method for Wayland needs to be implemented.
> MessageBeep() was supposed to call Beep() in fact.
> MSDN claims that Beep is the fallback:
> https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messa...
> But as it stands MessageBeep doesn't fallback to Beep and in any case
> lBeep isn't even properly implemented. No tone generation seems to be
> in place; it just forwards the request to conhost with the
> IOCTL_CONDRV_BEEP code, which essentially calls the terminal's
> configured beep(only if it is a unix terminal or else it does nothing
> lol). So I suppose Beep should also be properly implemented at some
> point, if desired.

On Thu, Jul 23, 2026 at 10:09 PM Elizabeth Figura
<[e-mail]> wrote:
> On Thursday, 23 July 2026 10:34:37 CDT Eric Pouech via Wine-Devel wrote:
> > Le 23/07/2026 à 17:06, Elizabeth Figura via Wine-Devel a écrit :
> > > On Wednesday, 22 July 2026 03:15:12 CDT Eric Pouech via Wine-Devel wrote:
> > > > Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
> > > > > Hmm alright. Thanks for the detailed response
> > > >
> > > > MessageBeep shall be used
> > >
> > > Isn't MessageBeep a higher level API?
> >
> > higher than what?
> >
> > (it's supposed to be called from conhost.exe, so I don't see too much
> > trouble here)
>
> Higher than Beep(). I thought that MessageBeep() was supposed to call Beep() in fact.
>
> I guess with conhost maybe it is the other way around.
> > and I tried to avoid calling kernel32.Beep from conhost (it would
> > require calling some MM apis from kernel32, which doesn't seem great either)
> >
> > -Eric

[Elizabeth Figura]

On Thursday, 23 July 2026 11:56:38 CDT Barath Rk wrote:
> > Higher than Beep()
> > From what I have seen, MessageBeep and Beep appear to be pretty
> > different the way they have been implemented right now. MessageBeep
> > calls the respective Beep method defined for the particular display
> > server protocol being used. Currently only X11/XWayland is
> > supported(look at pBeep in x11drv_funcs present in
> > dlls/winex11.drv/init.c which is basically just a call to XBell). A
> > Beep method for Wayland needs to be implemented.
> > MessageBeep() was supposed to call Beep() in fact.
> > MSDN claims that Beep is the fallback:
> > https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messa...
> > But as it stands MessageBeep doesn't fallback to Beep and in any case
> > lBeep isn't even properly implemented. No tone generation seems to be
> > in place; it just forwards the request to conhost with the
> > IOCTL_CONDRV_BEEP code, which essentially calls the terminal's
> > configured beep(only if it is a unix terminal or else it does nothing
> > lol). So I suppose Beep should also be properly implemented at some
> > point, if desired.

Well if MessageBeep() might fall back to Beep(), and Beep() calls IOCTL_CONDRV_BEEP, then the latter shouldn't call MessageBeep().
> On Thu, Jul 23, 2026 at 10:09 PM Elizabeth Figura
> <[e-mail]> wrote:
> > On Thursday, 23 July 2026 10:34:37 CDT Eric Pouech via Wine-Devel wrote:
> > > Le 23/07/2026 à 17:06, Elizabeth Figura via Wine-Devel a écrit :
> > > > On Wednesday, 22 July 2026 03:15:12 CDT Eric Pouech via Wine-Devel wrote:
> > > > > Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
> > > > > > Hmm alright. Thanks for the detailed response
> > > > >
> > > > > MessageBeep shall be used
> > > >
> > > > Isn't MessageBeep a higher level API?
> > >
> > > higher than what?
> > >
> > > (it's supposed to be called from conhost.exe, so I don't see too much
> > > trouble here)
> >
> > Higher than Beep(). I thought that MessageBeep() was supposed to call Beep() in fact.
> >
> > I guess with conhost maybe it is the other way around.
> > > and I tried to avoid calling kernel32.Beep from conhost (it would
> > > require calling some MM apis from kernel32, which doesn't seem great either)
> > >
> > > -Eric

[Barath Rk]

> then the latter shouldn't call MessageBeep().
> yeah, Beep doesn't call MessageBeep. the beep I am attempting to
> implement will be done by a change in conhost where if '\a'(int 7) is
> encountered we call MessageBeep(MB_OK), that's about it

On Thu, Jul 23, 2026 at 10:29 PM Elizabeth Figura
<[e-mail]> wrote:
> On Thursday, 23 July 2026 11:56:38 CDT Barath Rk wrote:
> > > Higher than Beep()
> > > From what I have seen, MessageBeep and Beep appear to be pretty
> > > different the way they have been implemented right now. MessageBeep
> > > calls the respective Beep method defined for the particular display
> > > server protocol being used. Currently only X11/XWayland is
> > > supported(look at pBeep in x11drv_funcs present in
> > > dlls/winex11.drv/init.c which is basically just a call to XBell). A
> > > Beep method for Wayland needs to be implemented.
> > > MessageBeep() was supposed to call Beep() in fact.
> > > MSDN claims that Beep is the fallback:
> > > https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-messa...
> > > But as it stands MessageBeep doesn't fallback to Beep and in any case
> > > lBeep isn't even properly implemented. No tone generation seems to be
> > > in place; it just forwards the request to conhost with the
> > > IOCTL_CONDRV_BEEP code, which essentially calls the terminal's
> > > configured beep(only if it is a unix terminal or else it does nothing
> > > lol). So I suppose Beep should also be properly implemented at some
> > > point, if desired.
>
> Well if MessageBeep() might fall back to Beep(), and Beep() calls IOCTL_CONDRV_BEEP, then the latter shouldn't call MessageBeep().
> > On Thu, Jul 23, 2026 at 10:09 PM Elizabeth Figura
> > <[e-mail]> wrote:
> > > On Thursday, 23 July 2026 10:34:37 CDT Eric Pouech via Wine-Devel wrote:
> > > > Le 23/07/2026 à 17:06, Elizabeth Figura via Wine-Devel a écrit :
> > > > > On Wednesday, 22 July 2026 03:15:12 CDT Eric Pouech via Wine-Devel wrote:
> > > > > > Le 22/07/2026 à 03:31, Barath Rk via Wine-Devel a écrit :
> > > > > > > Hmm alright. Thanks for the detailed response
> > > > > >
> > > > > > MessageBeep shall be used
> > > > >
> > > > > Isn't MessageBeep a higher level API?
> > > >
> > > > higher than what?
> > > >
> > > > (it's supposed to be called from conhost.exe, so I don't see too much
> > > > trouble here)
> > >
> > > Higher than Beep(). I thought that MessageBeep() was supposed to call Beep() in fact.
> > >
> > > I guess with conhost maybe it is the other way around.
> > > > and I tried to avoid calling kernel32.Beep from conhost (it would
> > > > require calling some MM apis from kernel32, which doesn't seem great either)
> > > >
> > > > -Eric

[Elizabeth Figura]

On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote:
> > then the latter shouldn't call MessageBeep().
> > yeah, Beep doesn't call MessageBeep. the beep I am attempting to
> > implement will be done by a change in conhost where if '\a'(int 7) is
> > encountered we call MessageBeep(MB_OK), that's about it

Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep().

[Barath Rk]

Well, I was under the impression that Eric was referring to the part
in write_console that deals with the '\a' case, which was the subject
matter of the bug that I linked at the start as well.
> deals with write_console that deals with the '\a' case,
> in this case, I don't think Beep will be called, and the
> IOCTRL_CONDRV_BEEP handling needn't be touched. only a call to
> MessageBeep needs to be made.
> The implementation of Beep and consequently the handling of
> IOCTRL_CONDRV_BEEP should be taken up as a separate issue I think.

On Thu, Jul 23, 2026 at 10:44 PM Elizabeth Figura
<[e-mail]> wrote:
> On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote:
> > > then the latter shouldn't call MessageBeep().
> > > yeah, Beep doesn't call MessageBeep. the beep I am attempting to
> > > implement will be done by a change in conhost where if '\a'(int 7) is
> > > encountered we call MessageBeep(MB_OK), that's about it
>
> Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep().

[Eric Pouech]

Le 23/07/2026 à 19:14, Elizabeth Figura a écrit :
> On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote:
> > > then the latter shouldn't call MessageBeep().
> > > yeah, Beep doesn't call MessageBeep. the beep I am attempting to
> > > implement will be done by a change in conhost where if '\a'(int 7) is
> > > encountered we call MessageBeep(MB_OK), that's about it
> > > Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep().

in fact, I did propose MessageBeep to avoid calling Beep from conhost 
(as our current MessageBeep implementation doesn't fallbck to Beep) and 
to make the patch simpler

but I don't have strong objection for playing a predefined sound instead 
directly from conhost

-Eric

[Barath Rk]

> but I don't have strong objection for playing a predefined sound instead
> directly from conhost

If that is the case, would it be better to first create a proper
implementation of Beep(that doesn't rely on forwarding to conhost. I
suppose this should be possible with whatever winmm provides right now) and
then use that here?

This would also avoid having to implement a beep for the wayland driver. I
guess that it wasn't done at the start because it isn't as straightforward
to implement as it is in X11(where you just call XBell) and while looking
into it, I figured that the simplest way to implement the wayland driver
would be with a previous sound, so we might as well just do that in conhost.

On Thu, 23 Jul, 2026, 11:08 pm Eric Pouech, <[e-mail]> wrote:
> Le 23/07/2026 à 19:14, Elizabeth Figura a écrit :
>
> On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote:
>
> then the latter shouldn't call MessageBeep().
>
> yeah, Beep doesn't call MessageBeep. the beep I am attempting to
> implement will be done by a change in conhost where if '\a'(int 7) is
> encountered we call MessageBeep(MB_OK), that's about it
>
> Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep().
>
> in fact, I did propose MessageBeep to avoid calling Beep from conhost (as
> our current MessageBeep implementation doesn't fallbck to Beep) and to make
> the patch simpler
>
> but I don't have strong objection for playing a predefined sound instead
> directly from conhost
>
> -Eric

[Elizabeth Figura]

On Thursday, 23 July 2026 12:49:32 CDT Barath Rk via Wine-Devel wrote:
> > but I don't have strong objection for playing a predefined sound instead
> > directly from conhost
>
> If that is the case, would it be better to first create a proper
> implementation of Beep(that doesn't rely on forwarding to conhost. I
> suppose this should be possible with whatever winmm provides right now) and
> then use that here?

The trouble with that is layering; it's surely wrong to call winmm or anything audio from kernelbase. It may be that it calls out to a service.

[Barath Rk]

Could you explain what you mean by it being a layering issue? the
waveOut* functions of winmm essentially call the respective audio
drivers. By "service" do you mean pulse/ALSA?

If we were to implement Beep without calls to winmm from kernelbase, I
suppose we would have to forward the request like it is already being
done, but to something more agnostic than conhost. How would one go
about this though? I thought of a server request, but I realize server
changes are quite rare.

On Fri, Jul 24, 2026 at 1:31 AM Elizabeth Figura
<[e-mail]> wrote:
> On Thursday, 23 July 2026 12:49:32 CDT Barath Rk via Wine-Devel wrote:
> > > but I don't have strong objection for playing a predefined sound instead
> > > directly from conhost
> >
> > If that is the case, would it be better to first create a proper
> > implementation of Beep(that doesn't rely on forwarding to conhost. I
> > suppose this should be possible with whatever winmm provides right now) and
> > then use that here?
>
> The trouble with that is layering; it's surely wrong to call winmm or anything audio from kernelbase. It may be that it calls out to a service.

[Eric Pouech]

Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit :
> Could you explain what you mean by it being a layering issue? the
> waveOut* functions of winmm essentially call the respective audio
> drivers. By "service" do you mean pulse/ALSA?

from an architecture point of view, kernel(base|32) is at a "layer" 
below winmm (and any other sound related DLLs)

so winmm is allowed to call into kernel(base[32), but not the other way 
around

Zeb suggests we have a service responding to a beep ctl command (and 
that service could call into winmm)

yes to decide if we reuse and existing service or add a new one

[Barath Rk]

> from an architecture point of view, kernel(base|32) is at a "layer"
> below winmm (and any other sound related DLLs)

Hm right
> yes to decide if we reuse and existing service or add a new one
> yeah fair enough. I think I'll just generate my own beep effect using
> winmm for this fix though. simplest option currently

On Fri, Jul 24, 2026 at 12:58 PM Eric Pouech <[e-mail]> wrote:
> Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit :
> > Could you explain what you mean by it being a layering issue? the
> > waveOut* functions of winmm essentially call the respective audio
> > drivers. By "service" do you mean pulse/ALSA?
>
> from an architecture point of view, kernel(base|32) is at a "layer"
> below winmm (and any other sound related DLLs)
>
> so winmm is allowed to call into kernel(base[32), but not the other way
> around
>
> Zeb suggests we have a service responding to a beep ctl command (and
> that service could call into winmm)
>
> yes to decide if we reuse and existing service or add a new one

[Barath Rk]

https://gitlab.winehq.org/wine/wine/-/merge_requests/11469

I have created an MR for this issue. This produces a simple double
beep as the bell.

I haven't added any tests as I was unsure about them.

On Fri, Jul 24, 2026 at 1:08 PM Barath Rk <[e-mail]> wrote:
> > from an architecture point of view, kernel(base|32) is at a "layer"
> > below winmm (and any other sound related DLLs)
>
> Hm right
> > yes to decide if we reuse and existing service or add a new one
> > yeah fair enough. I think I'll just generate my own beep effect using
> > winmm for this fix though. simplest option currently
>
> On Fri, Jul 24, 2026 at 12:58 PM Eric Pouech <[e-mail]> wrote:
> > Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit :
> > > Could you explain what you mean by it being a layering issue? the
> > > waveOut* functions of winmm essentially call the respective audio
> > > drivers. By "service" do you mean pulse/ALSA?
> >
> > from an architecture point of view, kernel(base|32) is at a "layer"
> > below winmm (and any other sound related DLLs)
> >
> > so winmm is allowed to call into kernel(base[32), but not the other way
> > around
> >
> > Zeb suggests we have a service responding to a beep ctl command (and
> > that service could call into winmm)
> >
> > yes to decide if we reuse and existing service or add a new one

[Barath Rk]

Any updates on this?

I realized that if we will be working towards implementing Beep, this
MR won't even be necessary lol(after implementing Beep, it would be
one line change in conhost to implement the \a code for write_console)

On Fri, Jul 24, 2026 at 4:38 PM Barath Rk <[e-mail]> wrote:
> https://gitlab.winehq.org/wine/wine/-/merge_requests/11469
>
> I have created an MR for this issue. This produces a simple double
> beep as the bell.
>
> I haven't added any tests as I was unsure about them.
>
> On Fri, Jul 24, 2026 at 1:08 PM Barath Rk <[e-mail]> wrote:
> > > from an architecture point of view, kernel(base|32) is at a "layer"
> > > below winmm (and any other sound related DLLs)
> >
> > Hm right
> > > yes to decide if we reuse and existing service or add a new one
> > > yeah fair enough. I think I'll just generate my own beep effect using
> > > winmm for this fix though. simplest option currently
> >
> > On Fri, Jul 24, 2026 at 12:58 PM Eric Pouech <[e-mail]> wrote:
> > > Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit :
> > > > Could you explain what you mean by it being a layering issue? the
> > > > waveOut* functions of winmm essentially call the respective audio
> > > > drivers. By "service" do you mean pulse/ALSA?
> > >
> > > from an architecture point of view, kernel(base|32) is at a "layer"
> > > below winmm (and any other sound related DLLs)
> > >
> > > so winmm is allowed to call into kernel(base[32), but not the other way
> > > around
> > >
> > > Zeb suggests we have a service responding to a beep ctl command (and
> > > that service could call into winmm)
> > >
> > > yes to decide if we reuse and existing service or add a new one

[Jacek Caban]

On 7/23/26 19:14, Elizabeth Figura via Wine-Devel wrote:
> On Thursday, 23 July 2026 12:02:19 CDT Barath Rk wrote:
> > > then the latter shouldn't call MessageBeep().
> > > yeah, Beep doesn't call MessageBeep. the beep I am attempting to
> > > implement will be done by a change in conhost where if '\a'(int 7) is
> > > encountered we call MessageBeep(MB_OK), that's about it
> > > Huh? Beep() calls IOCTL_CONDRV_BEEP, and Eric is proposing that IOCTL_CONDRV_BEEP should call MessageBeep().

FWIW, I think that calling IOCTL_CONDRV_BEEP from Beep is not exactly 
right. As the FIXME in Beep says, it should work when no console is 
attached, which means that it should not depend on conhost. If we'd get 
that right, we could use Beep from conhost.


Jacek