December 2023 - Wine-gitlab

Re: [PATCH v8 0/6] MR4507: Add coml2 and start migrating a few functions from ole32
by Fabian Maurer (＠DarkShadow44) 01 Dec '23

01 Dec '23

On Fri Dec 1 17:22:55 2023 +0000, Nikolay Sivov wrote: > @DarkShadow44, sorry for confusion, turns out it's not either -import or > a forward. You can also simply have no forward and no -import, and it > still does the right thing. Please update to remove forwarding to coml2. Oh I see, I didn't know that was possible. Sorry for that, and thanks for your patience! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4507#note_54601

1 0

[PATCH v7 0/6] MR4507: Add coml2 and start migrating a few functions from ole32
by Fabian Maurer (＠DarkShadow44) 01 Dec '23

01 Dec '23

Split off from https://gitlab.winehq.org/wine/wine/-/merge_requests/3106 -- v7: coml2: Move WriteClassStg from ole32 coml2: Move WriteClassStm from ole32 coml2: Move ReadClassStg from ole32 coml2: Move ReadClassStm from ole32 coml2: Move GetConvertStg from ole32 coml2: Add dll and move code from ole32/memlockbytes.c https://gitlab.winehq.org/wine/wine/-/merge_requests/4507

2 6

[PATCH v4 0/1] MR4319: gdiplus: Use CRT allocation functions.
by Alex Henrie (＠alexhenrie) 01 Dec '23

01 Dec '23

-- v4: gdiplus: Use CRT allocation functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/4319

3 5

[PATCH 0/5] MR4574: mshtml: Improve detached documents handling.
by Jacek Caban (＠jacek) 01 Dec '23

01 Dec '23

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

3 6

[PATCH v4 0/4] MR4551: Server-side thread priorities implementation (Part 1)
by Marc-Aurel Zent (＠mzent) 01 Dec '23

01 Dec '23

This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on. I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit). A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change. Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here. -- v4: server: Check wineserver privileges on init with -20 server: Use setpriority to update thread niceness when safe. ntdll: Set RLIMIT_NICE to its hard limit and inform the server. https://gitlab.winehq.org/wine/wine/-/merge_requests/4551

3 5

Re: [PATCH v7 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 01 Dec '23

01 Dec '23

On Thu Nov 30 22:05:10 2023 +0000, Zebediah Figura wrote: > If you've tested manually, that's probably fine. My concern is primarily > that we're actually translating formats correctly; GStreamer and > DirectShow don't always store them in the same way, and it's too easy to > make assumptions (cf. [1]). > [1] https://gitlab.winehq.org/wine/wine/-/merge_requests/3636#note_45288 Honestly, I didn't test manually, I just did whatever gets the videos working. But you're right, [I should.](/uploads/ad88bf935e5bcd7a42c0219894294215/main.cpp) ``` Wine { majortype } { subtype } {fixSzSmp } {tempComp } {sampSize } { formattype } ........... { pUnk } { cbFormat} ........... { pbFormat } { rcSource } { rcTarget } {dwBitRate} {BitErrRte} { AvgTimePerFrame } { biSize } { biWidth } {biHeight } {pln} {btc} {compress } {sizeImage} {xPerMeter} {yPerMeter} {dwClrUsed} {clrImptnt} ?? ?? ?? ?? ?? 76 69 64 73 00 00 10 00 80 00 00 aa 00 38 9b 71 57 4d 56 33 00 00 10 00 80 00 00 aa 00 38 9b 71 00 00 00 00 01 00 00 00 00 00 00 00 80 9f 58 05 56 c3 ce 11 bf 01 00 aa 00 55 59 5a 00 00 00 00 00 00 00 00 00 00 00 00 5d 00 00 00 00 00 00 00 48 f6 2f fe ff 7f 00 00 00 00 00 00 00 00 00 00 00 05 00 00 d0 02 00 00 00 00 00 00 00 00 00 00 00 05 00 00 d0 02 00 00 00 00 00 00 00 00 00 00 15 16 05 00 00 00 00 00 28 00 00 00 00 05 00 00 d0 02 00 00 01 00 18 00 57 4d 56 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4f f1 08 01 00 61 75 64 73 00 00 10 00 80 00 00 aa 00 38 9b 71 63 01 00 00 00 00 10 00 80 00 00 aa 00 38 9b 71 01 00 00 00 00 00 00 00 3f 34 00 00 81 9f 58 05 56 c3 ce 11 bf 01 00 aa 00 55 59 5a 00 00 00 00 00 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00 48 f6 2f fe ff 7f 00 00 63 01 02 00 44 ac 00 00 80 32 02 00 3f 34 10 00 12 00 10 00 03 00 00 00 00 00 00 00 00 00 00 00 a1 01 00 00 { majortype } { subtype } {fixSzSmp } {tempComp } {sampSize } { formattype } ........... { pUnk } { cbFormat} ........... { pbFormat } {fmt} {chn} {sampleSec} {avgBySec } {ali} {bps} {cbs} ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Native { majortype } { subtype } {fixSzSmp } {tempComp } {sampSize } { formattype } ........... { pUnk } { cbFormat} ........... { pbFormat } {fmt} {chn} {sampleSec} {avgBySec } {ali} {bps} {cbs} ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 61 75 64 73 00 00 10 00 80 00 00 aa 00 38 9b 71 63 01 00 00 00 00 10 00 80 00 00 aa 00 38 9b 71 01 00 00 00 00 00 00 00 3f 34 00 00 81 9f 58 05 56 c3 ce 11 bf 01 00 aa 00 55 59 5a 00 00 00 00 00 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00 e8 f3 2e 00 00 00 00 00 63 01 02 00 44 ac 00 00 80 32 02 00 3f 34 10 00 12 00 10 00 03 00 00 00 00 00 00 00 00 00 00 00 a1 01 00 00 76 69 64 73 00 00 10 00 80 00 00 aa 00 38 9b 71 57 4d 56 33 00 00 10 00 80 00 00 aa 00 38 9b 71 00 00 00 00 01 00 00 00 00 00 00 00 80 9f 58 05 56 c3 ce 11 bf 01 00 aa 00 55 59 5a 00 00 00 00 00 00 00 00 00 00 00 00 5d 00 00 00 00 00 00 00 e8 f3 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 00 d0 02 00 00 00 00 00 00 00 00 00 00 00 05 00 00 d0 02 00 00 08 d7 56 00 00 00 00 00 15 16 05 00 00 00 00 00 2d 00 00 00 00 05 00 00 d0 02 00 00 01 00 18 00 57 4d 56 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4f f1 08 01 00 { majortype } { subtype } {fixSzSmp } {tempComp } {sampSize } { formattype } ........... { pUnk } { cbFormat} ........... { pbFormat } { rcSource } { rcTarget } {dwBitRate} {BitErrRte} { AvgTimePerFrame } { biSize } { biWidth } {biHeight } {pln} {btc} {compress } {sizeImage} {xPerMeter} {yPerMeter} {dwClrUsed} {clrImptnt} ?? ?? ?? ?? ?? ``` Like the WMAs, the codec data is just concatenated to the struct, as I guessed. (Though apparently I put wrong value in bmiHeader.biSize. Fixed.) The streams are in opposite order in Wine vs native, but that's a separate question. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54581

1 0

Re: [PATCH v7 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 01 Dec '23

01 Dec '23

On Thu Nov 30 22:00:38 2023 +0000, Zebediah Figura wrote: > This cast should be unnecessary. I'd also make this an ERR or FIXME. My thinking was that uint32_t is unsigned long, so it needs a cast. But you're right, that's wrong. This is Unix side code, so uint32_t is not unsigned long. Fixed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54576

1 0

Re: [PATCH v7 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 01 Dec '23

01 Dec '23

On Thu Nov 30 22:00:39 2023 +0000, Zebediah Figura wrote: > I don't like this pattern; in cases like this we should instead just > split up the init_stream() helper to the part that's done on > initialization and the part that's done on recreation. That said I would > imagine more of this should be done on initialization...? They're a bit intertwined; reader->streams can't be allocated before stream_count is known, which requires creating the wg_parser. But yes, creating the reader from two places is cleaner than these conditionals, even if it's a few more lines of code. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54577

1 0

Re: [PATCH v7 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 01 Dec '23

01 Dec '23

On Thu Nov 30 22:00:44 2023 +0000, Zebediah Figura wrote: > "if (x) ok(0)" should almost always be "ok(!x)". It does more than just ok(0). I did it like this to ensure that everything is in order except exactly one unexpected rewind. Would you prefer if I just tell the tests to explicitly rewind the stream when changing compression mode? [As mentioned in wm_reader.c](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winegst…, no plausible program reconfigures streams dynamically anyways. Always hard to know which tests are important, and which are safe to relax... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54578

1 0

Re: [PATCH v7 0/7] MR4449: winegstreamer: WMReader compressed output
by Alfred Agrell (＠Alcaro) 01 Dec '23

01 Dec '23

On Thu Nov 30 22:00:46 2023 +0000, Zebediah Figura wrote: > I don't think you need the if (winetest_platform_is_wine) here. Native doesn't rewind anything when the stream is switched to or from compressed mode. I could remove it, and the ok(!callback->todo_rewind) below, but then we won't notice if someone fixes the rewinding and the todo_rewind stuff becomes unnecessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54579

1 0