Martin Storsjö (@mstorsjo) commented about libs/ldap/include/portable.h:
> +/* #undef HAVE_GETHOSTBYADDR_R */
> +
> +/* Define to 1 if you have the `gethostbyname_r' function. */
> +/* #undef HAVE_GETHOSTBYNAME_R */
> +
> +/* Define to 1 if you have the `gethostname' function. */
> +#define HAVE_GETHOSTNAME 1
> +
> +/* Define to 1 if you have the `getnameinfo' function. */
> +#define HAVE_GETNAMEINFO 1
> +
> +/* Define to 1 if you have the `getopt' function. */
> +#define HAVE_GETOPT 1
> +
> +/* Define to 1 if you have the <getopt.h> header file. */
> +#define HAVE_GETOPT_H 1
This ends up including getopt.h in PE builds, while that header isn't provided by wine itself (and isn't available if building with Clang in MSVC mode). See https://bugs.winehq.org/show_bug.cgi?id=53930 for a full bug report on this issue.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1372#note_15987
Block records are not processed; only the bitcode is validated.
--
v5: vkd3d-shader/dxil: Read and validate global abbreviated operands.
vkd3d-shader/dxil: Read and validate local abbreviated operands.
vkd3d-compiler: Introduce a dxil-asm target type.
vkd3d-compiler: Introduce a dxbc-dxil source type.
vkd3d-shader/dxil: Read and validate DXIL bitcode unabbreviated blocks.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/44
Also unifies hidden file handling.
Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826).
--
v11: ntdll: Try to avoid requesting the file name for a handle.
ntdll: Ensure that attributes are kept the same when renaming or hard-linking a file.
ntdll: Set xattr in NtCreateFile if inferred and requested attributes don't match.
ntdll: Only infer hidden attribute from file name if xattr is not present.
ntdll: Handle hidden file names in fd_get_file_info.
ntdll: Pass file path into fd_get_file_info if available.
ntdll: Do not compute file attributes for info classes that don't need them.
ntdll: Handle hidden file names inside get_file_info instead of after it.
ntdll: Do not open-code hidden file handling in get_dir_data_entry.
ntdll/tests: Add test for file attributes of files with names beginning with a dot.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1148
On Tue Nov 15 21:40:55 2022 +0000, Rémi Bernon wrote:
> Because this is a blocking call, which can call application callbacks,
> or otherwise also blocking until there's a sample ready.
> We want to be able to deliver samples from the callback thread, on other
> streams, without being blocked and without blocking the reader. There's
> no point in making all this asynchronous otherwise.
GetNextSample() already calls callbacks with the lock held. I.e. this is basically doing the same thing as described above. I also don't see how delivering samples can block this, or the reverse, since we drop the CS in order to deliver samples. What deadlock results from not dropping the CS here?
I would guess that AllocateForOutput() is blocking in IMemAllocator::GetBuffer(), but if that's the case, according to my reading of 2/4, we should either be inside of IWMReaderCallback::OnSample() or still holding the CS and about to call it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15909
On Tue Nov 15 21:40:55 2022 +0000, Rémi Bernon wrote:
> The most common case where this happens is on EOS, I don't think we want
> to print error. When streams are deselected this would happen as well if
> it interrupts the wait on buffer.
Sure, but then we probably should avoid printing a WARN either, since that's expected behaviour.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15908
On Tue Nov 15 20:31:00 2022 +0000, Zebediah Figura wrote:
> I guess, but it depends on the fact that "read_result" is
> zero-initialized and never written, which seems non-obvious and a little
> fragile. In fact, I think it can already break if a stream was selected
> and then later becomes deselected, even if the filter was stopped in
> between. Checking "stream->read_requested" would be more obvious but I
> think still broken for the same reasons (but simple enough to fix.)
> Note that if you do that then read_result becomes superfluous and
> doesn't really need to be stored anywhere.
`read_result` is written to E_PENDING whenever a read is requested. Every requested read will eventually be completed, writing the result to `read_result`, either `S_OK` or an error.
If a stream was selected and a read requested to it, then later becomes deselected, we will consider it a valid thread wrt sample delivery until it completes its read and writes to `read_result`. It may complete it with a sample if the deselection happened late, or with an error if its read was interrupted.
`read_requested` is a one way flag to tell reader to start reading. It needs to be reset before the `GetNextSample` call, and checked again on return to correctly synchronize flush and read requests from the callback thread, for instance when seeking.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15905
On Tue Nov 15 20:31:01 2022 +0000, Zebediah Figura wrote:
> Linux cuts off thread names at 15 characters (not counting the null
> terminator), which somewhat unfortunately makes all of these identical
> to each other and the deliver threads. Thus far I think Brendan had been
> trying to make the thread names distinct, if not per se trying to fit
> the entire name within 15 characters.
Unfortunate...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15906
On Tue Nov 15 20:31:01 2022 +0000, Zebediah Figura wrote:
> > We need the read threads to always be running and returning their next
> sample because we then deliver them in PTS order.
> Somewhat out of curiosity, did you check whether this still applies when
> DedicatedDeliveryThread is set?
I believe I did and it still applies (with the same offset as without threads, when samples are decoded), and there's another setting named `DeliverOnReceive` that is the one which changes that behavior (though I don't think we need it).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15901
On Tue Nov 15 20:30:58 2022 +0000, Zebediah Figura wrote:
> Similarly to the earlier question about IWMSyncReader locking, do we
> need to drop the CS here?
Because this is a blocking call, which can call application callbacks, or otherwise also blocking until there's a sample ready.
We want to be able to deliver samples from the callback thread, on other streams, without being blocked and without blocking the reader. There's no point in making all this asynchronous otherwise.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15902
On Tue Nov 15 20:30:59 2022 +0000, Zebediah Figura wrote:
> Missed this the first time, but: I'd make this an ERR, personally. (An
> application can trigger it, but it's one of those cases where it's a
> sign that something went catastrophically wrong, and also we're pretty
> much guessing how to handle it if not.)
The most common case where this happens is on EOS, I don't think we want to print error. When streams are deselected this would happen as well if it interrupts the wait on buffer.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15903
On Tue Nov 15 20:30:59 2022 +0000, Zebediah Figura wrote:
> What's the point of this? We never check the return code of
> async_reader_get_next_sample(), only whether it FAILED().
No, it's checked outside of the loop to see if all streams have received EOS (in which case `hr == NS_E_NO_MORE_SAMPLES`), or if there's still some streams with pending requests or pending samples to deliver (`hr == E_PENDING`).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15904
This video codec is used by games such as Richman 4, and Zwei: The Arges Adventure.
The decoder logic is based on code from the FFmpeg project.
--
v2: loader/wine.inf: Enable ir50_32 video codec.
ir50_32: Implement decompression to 15-bit RGB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1301
Made changes to comdlg32/itemdlg.c to add missing controls, which are the address bar and the up button.
Updated bitmaps in comctl32 and SVG files for history icons.
My changes help to resolve this bug: https://bugs.winehq.org/show_bug.cgi?id=50338.
--
v16: comdlg32: Add missing controls and their functionality to IFileDialog, or the common item dialog.
https://gitlab.winehq.org/wine/wine/-/merge_requests/672
Zebediah Figura (@zfigura) commented about dlls/wmvcore/async_reader.c:
> struct stream *stream = arg;
> struct async_reader *reader = stream->reader;
> struct sample *sample;
> + WCHAR buffer[256];
> HRESULT hr;
>
> TRACE("reader %p, number %u\n", reader, stream->number);
>
> + swprintf(buffer, ARRAY_SIZE(buffer), L"wine_wmreader_stream_%u_read", stream->number);
> + SetThreadDescription(GetCurrentThread(), buffer);
Linux cuts off thread names at 15 characters (not counting the null terminator), which somewhat unfortunately makes all of these identical to each other and the deliver threads. Thus far I think Brendan had been trying to make the thread names distinct, if not per se trying to fit the entire name within 15 characters.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15868
> We need the read threads to always be running and returning their next sample because we then deliver them in PTS order.
Somewhat out of curiosity, did you check whether this still applies when DedicatedDeliveryThread is set?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15869
On Mon Nov 14 12:05:16 2022 +0000, Rémi Bernon wrote:
> I don't think we need to check it here anymore with the latest version.
> Deselected streams will never have pending read requests (or they will
> shortly complete it after deselection, with either error or a last sample).
I guess, but it depends on the fact that "read_result" is zero-initialized and never written, which seems non-obvious and a little fragile. In fact, I think it can already break if a stream was selected and then later becomes deselected, even if the filter was stopped in between. Checking "stream->read_requested" would be more obvious but I think still broken for the same reasons (but simple enough to fix.)
Note that if you do that then read_result becomes superfluous and doesn't really need to be stored anywhere.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15867
Zebediah Figura (@zfigura) commented about dlls/wmvcore/async_reader.c:
> +
> + LeaveCriticalSection(&reader->callback_cs);
> + hr = IWMSyncReader2_GetNextSample(reader->reader, stream->number,
> + &sample->buffer, &sample->pts, &sample->duration,
> + &sample->flags, &sample->output, &sample->stream);
> + EnterCriticalSection(&reader->callback_cs);
> + }
> +
> + if (SUCCEEDED(stream->read_result = hr))
> + {
> + TRACE("Got stream %u buffer with pts %I64d.\n", stream->number, sample->pts);
> + stream->next_sample = sample;
> + }
> + else
> + {
> + WARN("Failed to get stream %u sample, hr %#lx.\n", stream->number, stream->read_result);
Missed this the first time, but: I'd make this an ERR, personally. (An application can trigger it, but it's one of those cases where it's a sign that something went catastrophically wrong, and also we're pretty much guessing how to handle it if not.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15865
Zebediah Figura (@zfigura) commented about dlls/wmvcore/async_reader.c:
> }
>
> if (!first_sample)
> - return NS_E_NO_MORE_SAMPLES;
> + return pending ? E_PENDING : NS_E_NO_MORE_SAMPLES;
What's the point of this? We never check the return code of async_reader_get_next_sample(), only whether it FAILED().
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15866
Tests show that Global / Local functions are more robust and catch invalid pointers, to the contrary to heap functions.
I'd like to relax a bit the heap quick pointer validation, in order to avoid looping over the heap regions on every call, and to reduce the locking requirements, though this would then break the globalmem invalid pointer tests, unless they validate the pointers beforehand.
They should maybe use exception handlers rather than pointer validation, but the result is the same. I can change that if it matters.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1361
The drag and drop helpers are mainly used for providing visual feedback for drag and drop operations. While they do not actually influence the dragging process, some applications may expect it to succeed before initiating dragging. If the functions are not implemented, however, then dragging may fail.
This patch set contains tests for basic functionality of the functions involved. It does not account for displaying the drag-image, it just tests for enough functionality to create a basic implementation and allow dragging operations to carry on. Drag-image handling will be added later.
The patch set contains only the tests. The implementation will be added in a separate MR.
--
v2: shell32/tests: Add tests for drag and drop helpers
shell32/tests: Add, initialize and release new variables
shell32/tests: add mock IDataObject instances
https://gitlab.winehq.org/wine/wine/-/merge_requests/1371
The drag and drop helpers are mainly used for providing visual feedback for drag and drop operations. While they do not actually influence the dragging process, some applications may expect it to succeed before initiating dragging. If the functions are not implemented, however, then dragging may fail.
This patch set contains tests for basic functionality of the functions involved. It does not account for displaying the drag-image, it just tests for enough functionality to create a basic implementation and allow dragging operations to carry on. Drag-image handling will be added later.
The patch set contains only the tests. The implementation will be added in a separate MR.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1371
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v15: user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
wineandroid.drv: Route kernel callbacks through user32.
opengl32: Route kernel callbacks through user32.
winevulkan: Route kernel callbacks through user32.
user32: Add NtUserDispatchCallback kernel callback.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
Block records are not processed; only the bitcode is validated.
--
v4: vkd3d-shader/dxil: Read and validate global abbreviated operands.
vkd3d-shader/dxil: Read and validate local abbreviated operands.
vkd3d-compiler: Introduce a dxil-asm target type.
vkd3d-compiler: Introduce a dxbc-dxil source type.
vkd3d-shader/dxil: Read and validate DXIL bitcode unabbreviated blocks.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/44
v2: Fixed test failures on earlier l3codecx.ax versions.
--
v2: winegstreamer: Set allocator properties for MPEG layer-3 decoder source.
quartz/tests: Add tests for MPEG layer-3 decoder source allocator.
winegstreamer: Check whether transform is supported when creating MPEG layer-3 decoder.
winegstreamer: Implement output media type enumeration in MPEG layer-3 decoder.
quartz/tests: Add tests for MPEG layer-3 decoder output media type enumeration.
quartz/tests: Add tests for MPEG layer-3 decoder sink allocator.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1298
--
v4: mshtml: Handle cNames > 1 in GetIDsOfNames properly.
mshtml: Forward IDispatchEx to the document node.
mshtml: Forward toString to the document node.
mshtml: Expose IEventTarget on HTMLDocumentObj and forward it to the doc node.
mshtml/tests: Implement IServiceProvider and few other interfaces needed
https://gitlab.winehq.org/wine/wine/-/merge_requests/1317
--
v3: mshtml: Handle cNames > 1 in GetIDsOfNames properly.
mshtml: Forward IDispatchEx to the document node.
mshtml: Forward toString to the document node.
mshtml: Expose IEventTarget on HTMLDocumentObj and forward it to the doc node.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1317
On Mon Nov 14 13:31:36 2022 +0000, **** wrote:
> Marvin replied on the mailing list:
> ```
> Hi,
> It looks like your patch introduced the new failures shown below.
> Please investigate and fix them before resubmitting your patch.
> If they are not new, fixing them anyway would help a lot. Otherwise
> please ask for the known failures list to be updated.
> The tests also ran into some preexisting test failures. If you know how
> to fix them that would be helpful. See the TestBot job for the details:
> The full results can be found at:
> https://testbot.winehq.org/JobDetails.pl?Key=126137
> Your paranoid android.
> === debian11 (32 bit report) ===
> crypt32:
> cert.c:4191: Test failed: success
> cert.c:4192: Test failed: got 00000000
> cert.c:4193: Test failed: got 00000000
> qasf:
> asfreader.c:943: Test failed: blocking 0: Wait timed out.
> asfreader.c:955: Test failed: blocking 0: got wrong thread
> asfreader: Timeout
> === debian11 (32 bit de report) ===
> wmvcore:
> wmvcore.c:2981: Test failed: Wait timed out.
> ```
The asfreader failures look genuine, I'll have a look.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15719
This seems to be more correct than what we previously had with fewer lines of code, so I like that. I still don't really like the extra flag I had to add for Nt{Create,Open}Key, but I couldn't find a way to make things work without it. I also checked that Windows doesn't use a similar flag (by iterating over all bit masks).
--
v5: ntdll/tests: Refactor the Software\Classes tests.
ntdll/tests: Factor out the NtEnumerateKey() tests.
server: Don't return the actual 32-bit Software\Classes key.
ntdll/tests: Add some some Software\Classes query and enumerate tests.
ntdll/tests: Test that NtCreateKeyEx() also recursively obtains the Wow6432Node parent.
server: Recursively obtain the Wow6432Node parent.
ntdll/tests: Add some Software\Classes subkey tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/966
--
v2: mshtml: Handle cNames > 1 in GetIDsOfNames properly.
mshtml: Forward IDispatchEx to the document node.
mshtml: Forward toString to the document node.
mshtml: Expose IEventTarget on HTMLDocumentObj and forward it to the doc node.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1317