We won't be able to do it later on otherwise as get_dc_ptr will fail
with a disabled DC, and release_dce will then not clear the drawable.
This will delay the drawable release until the dce is later reused, for
instance for a different window, which may cause a complicated deadlock.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8694
On Thu Jul 31 18:58:30 2025 +0000, Tim Clem wrote:
> Ah, interesting. Thanks for looking in to that. I can't speak to any of
> that, really - I'm not very familiar with winegstreamer at all. I was
> more wondering if we needed to explicitly set `byte-stream`, and maybe
> we don't?: tclem/wine!8. Not sure if the tests cover the initial issue
> you were addressing though. And I guess if it fixates to AVC but doesn't
> have the required `codec_data` then maybe `byte-stream` is the only
> option. But like I said, that has broken h.264 on macOS.
Yeah, sorry. I took a look yesterday in the hope of finding answers, but instead came away with more questions.
But, as you probably already noticed, we do need that `stream-format=byte-stream` for `avdec_h264` to work. Otherwise we get a bunch of failed tests in `mf:transform`:
https://gitlab.winehq.org/tclem/wine/-/jobs/178373#L2122
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8532#note_111763
These do not do anything currently, since we don't support FILE_OPEN_REPARSE_POINT on the Unix side yet. However, they are correct, as demonstrated by the recently committed tests, and it seems prudent to get these out of the way for now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8540
https://store.steampowered.com/app/638930/Dal_Segno/ occasionally calls IDirectSoundBuffer::Lock() with writecursor == buflen and writebytes == 0.
This is illegal, so Lock() returns DSERR_INVALIDPARAM - but the game doesn't notice, and does a memcpy to fill the returned buffer.
On native, the out params are zeroed on failure, so the memcpy ends up doing the right thing.
On Wine, the out params are left unchanged on failure, resulting in memcpy(STACK GARBAGE, src, STACK GARBAGE); after a few minutes of gameplay or idling (when the size isn't coincidentally zero), it crashes.
```
6518.932:0130:01b8:trace:dsound:IDirectSoundBufferImpl_GetCurrentPosition (01FF9BC0,090BEE94,00000000)
6518.932:0130:01b8:trace:dsound:IDirectSoundBufferImpl_GetCurrentPosition playpos = 20674080, writepos = -1, buflen=20709376 (01FF9BC0, time=6518932)
6518.932:0130:01b8:trace:dsound:IDirectSoundBufferImpl_Lock (01FF9BC0,20709376,0,090BEEA0,090BEE90,090BEE9C,090BEE98,0x00000000) at 6518932
6518.932:0130:01b8:warn:dsound:IDirectSoundBufferImpl_Lock Invalid parameter, writecursor: 20709376 >= buflen: 20709376
6518.932:0130:01b8:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00444C5C ip=00444c5c
6518.932:0130:01b8:trace:seh:dispatch_exception info[0]=00000001
6518.932:0130:01b8:trace:seh:dispatch_exception info[1]=0042d0b5
6518.932:0130:01b8:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised
6518.932:0130:01b8:trace:seh:dispatch_exception eax=0000008e ebx=7aa539c0 ecx=00000008 edx=00000000 esi=004dcf10 edi=0042d0b5
6518.932:0130:01b8:trace:seh:dispatch_exception ebp=090bee68 esp=090bee60 cs=0023 ss=002b ds=002b es=002b fs=0063 gs=006b flags=00010246
```
(The game is poorly written in several other ways - the segfault is caught in a SEH handler that also segfaults, repeat until stack overflow; it repeatedly unlocks critical section 004A4A28, which nothing ever locks; there's a homemade spinlock implementation at 0042CAB2; probably some more weirdness I didn't discover. But those have little or no user-visible impact, they just look ugly in the PROTON_LOG and/or game disassembly. Let's ignore them.)
...is there such a thing as too many tests? Nobody's gonna try most of what these tests do.
--
v2: dsound: Improve IDirectSoundBufferImpl_Lock handling of invalid arguments.
dsound/tests: Add tests for IDirectSoundBuffer_Lock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8632
I think this dates from a time where every window had its own window surface, and unless I'm missing something this isn't needed anymore. My intention is to refactor the client surfaces, so that they can be manipulated directly from win32u, and unify GL/VK client surfaces. This would make the code simpler, in preparation for that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8504