Hello All,
We are trying to build Wine Source on Linux with native wchar_t size 4 bytes (instead of 2 bytes), is there any way it can be done? I started with doing following changes:
diff --git a/tools/winapi/winapi_test b/tools/winapi/winapi_test
index b9628e8..91daac3 100644
--- a/tools/winapi/winapi_test
+++ b/tools/winapi/winapi_test
@@ -206,7 +206,11 @@ sub _find_align_kind_size($) {
$align = 2;
$kind = "signed";
$size = 2;
- } elsif (/^(?:char16_t|wchar_t|USHORT|WCHAR|WORD)$/) {
+ } elsif (/^(?:wchar_t|WCHAR)$/) {
+ $align = 4;
+ $kind = "unsigned";
+ $size = 4;
+ } elsif (/^(?:char16_t|USHORT|WORD|WCHAR_nt)$/) {
$align = 2;
$kind = "unsigned";
$size = 2;
Also started changing some of headers e.g. winnt.h - removed "typedef unsigned short WCHAR;" Any pointers/suggestion are welcome. Thanking you.
regards,
Mahin
Wine has many unreliable tests which makes it hard to know whether a
patch causes new failures. So one proposal was to mark unreliable tests
as flaky, and have a mode where flaky failures can ignored by setting
$WINETEST_ALLOW_FLAKY.
So one would be able to apply a patch, run 'WINETEST_ALLOW_FLAKY=1 make
test' and if that fails that means the patch introduces a new failure.
The way it works is that when a flaky test fails the message is 'Flaky
failed...' instead of 'Test failed...'. I also added the count of flaky
failures to the summary line. So the flaky failures are not totally
swept under the rug. The main difference is that if
$WINETEST_ALLOW_FLAKY is set, the exit code is 0 if the only failures
are flaky ones.
That still leaves some open questions though:
* Should the message be 'Test failed' instead of 'Flaky failed' when
$WINETEST_ALLOW_FLAKY is not set? I opted for the latter because it
adds information that the failed test has been marked as flaky.
* Should tests that fail systematically on some platforms but not others
(for instance specific Windows versions, specific locales, specific
GPUs) be marked as flaky? Or should flaky be reserved for tests that
fail randomly?
* What about failures where the message is different every time so
that the failure always looks new? Should these not be marked as flaky
since it only impacts the TestBot?
* On a related note the patch below has flaky_windows and flaky_wine
macros. Is that too fine grained? Maybe we don't want to run the risk
of marking a test as flaky_windows only to discover later that it can
also fail in Wine? But conversely, wouldn't it be valuable to know
that a test is only flaky in Wine and not in Windows?
Note: flaky_windows is a bit long but I was worried that flaky_win
would be too similar to flaky_wine.
* I decided having flaky_{windows,wine}_if() macros would be overkill.
* How does one know a flaky directive can be removed?
* Is it allowed to submit a patch that contains new flaky directives?
* Also the flaky directive cannot deal with tests that randomly crash,
prematurely exit, or time out. These issues are rarer so maybe we can
hope they can all be fixed?
* How does this impact bug 48912, aka "Allow blacklisting unreliable
and always new failures"?
https://bugs.winehq.org/show_bug.cgi?id=48912
* test.winehq.org and the TestBot will need to be updated to highlight
the new messages and, more importantly, to recognize the new summary
line.
The patch is below and I bundled it with tweaks to a few tests for
illustration purposes:
d3d8:device - Failure happens on Windows (rarely) and Wine.
dinput:mouse - Failure happens on Windows 7 and Wine.
mmdevapi:render - Timing issue.
schedsvc:atsvcapi - Wine-only failure.
---
dlls/d3d8/tests/device.c | 2 +-
dlls/dinput/tests/mouse.c | 2 +-
dlls/mmdevapi/tests/render.c | 2 +-
dlls/schedsvc/tests/atsvcapi.c | 2 +-
include/wine/test.h | 78 +++++++++++++++++++++++++++++-----
5 files changed, 72 insertions(+), 14 deletions(-)
diff --git a/dlls/d3d8/tests/device.c b/dlls/d3d8/tests/device.c
index cb1e83b64b3..f0e8c27fafd 100644
--- a/dlls/d3d8/tests/device.c
+++ b/dlls/d3d8/tests/device.c
@@ -3356,7 +3356,7 @@ static void test_wndproc(void)
expect_messages = sc_maximize_messages;
SendMessageA(focus_window, WM_SYSCOMMAND, SC_MAXIMIZE, 0);
- ok(!expect_messages->message, "Expected message %#x for window %#x, but didn't receive it.\n",
+ flaky ok(!expect_messages->message, "Expected message %#x for window %#x, but didn't receive it.\n",
expect_messages->message, expect_messages->window);
expect_messages = NULL;
flush_events();
diff --git a/dlls/dinput/tests/mouse.c b/dlls/dinput/tests/mouse.c
index 8be808e5da6..dcb5453a825 100644
--- a/dlls/dinput/tests/mouse.c
+++ b/dlls/dinput/tests/mouse.c
@@ -156,7 +156,7 @@ static void test_acquire(IDirectInputA *pDI, HWND hwnd)
SetActiveWindow( hwnd );
hr = IDirectInputDevice_Acquire(pMouse);
- ok(hr == S_OK, "Acquire() failed: %#lx\n", hr);
+ flaky ok(hr == S_OK, "Acquire() failed: %#lx\n", hr);
mouse_event(MOUSEEVENTF_MOVE, 10, 10, 0, 0);
cnt = 1;
diff --git a/dlls/mmdevapi/tests/render.c b/dlls/mmdevapi/tests/render.c
index 4e19b91c5f5..882be89b7ff 100644
--- a/dlls/mmdevapi/tests/render.c
+++ b/dlls/mmdevapi/tests/render.c
@@ -1098,7 +1098,7 @@ static void test_clock(int share)
ok(pos == 0, "GetPosition returned non-zero pos before being started\n");
hr = IAudioClient_Start(ac); /* #1 */
- ok(hr == S_OK, "Start failed: %08lx\n", hr);
+ flaky ok(hr == S_OK, "Start failed: %08lx\n", hr);
Sleep(100);
slept += 100;
diff --git a/dlls/schedsvc/tests/atsvcapi.c b/dlls/schedsvc/tests/atsvcapi.c
index 3aaad8b5cfe..83774804b40 100644
--- a/dlls/schedsvc/tests/atsvcapi.c
+++ b/dlls/schedsvc/tests/atsvcapi.c
@@ -168,7 +168,7 @@ START_TEST(atsvcapi)
skip_tests_delete:
ret = NetrJobDel(server_name, jobid, jobid);
- ok(ret == ERROR_SUCCESS, "NetrJobDel error %lu\n", ret);
+ flaky_wine ok(ret == ERROR_SUCCESS, "NetrJobDel error %lu\n", ret);
skip_tests:
SetUnhandledExceptionFilter(old_exception_filter);
diff --git a/include/wine/test.h b/include/wine/test.h
index 01ba81f4857..422ba3dce38 100644
--- a/include/wine/test.h
+++ b/include/wine/test.h
@@ -50,6 +50,9 @@ extern int winetest_time;
/* running in interactive mode? */
extern int winetest_interactive;
+/* always count flaky tests as successful (BOOL) */
+extern int winetest_allow_flaky;
+
/* report successful tests (BOOL) */
extern int winetest_report_success;
@@ -117,6 +120,13 @@ extern void winetest_pop_context(void);
#define trace trace_(__FILE__, __LINE__)
#define wait_child_process wait_child_process_(__FILE__, __LINE__)
+#define flaky_if(is_flaky) for (winetest_start_flaky(is_flaky); \
+ winetest_loop_flaky(); \
+ winetest_end_flaky())
+#define flaky flaky_if(1)
+#define flaky_windows flaky_if(!strcmp(winetest_platform, "windows"))
+#define flaky_wine flaky_if(!strcmp(winetest_platform, "wine"))
+
#define todo_if(is_todo) for (winetest_start_todo(is_todo); \
winetest_loop_todo(); \
winetest_end_todo())
@@ -200,6 +210,9 @@ int winetest_interactive = 0;
/* current platform */
const char *winetest_platform = "windows";
+/* always count flaky tests as successful (BOOL) */
+int winetest_allow_flaky;
+
/* report successful tests (BOOL) */
int winetest_report_success = 0;
@@ -214,6 +227,7 @@ static const struct test *current_test; /* test currently being run */
static LONG successes; /* number of successful tests */
static LONG failures; /* number of failures */
+static LONG flaky_failures; /* number of failures inside flaky block */
static LONG skipped; /* number of skipped test chunks */
static LONG todo_successes; /* number of successful tests inside todo block */
static LONG todo_failures; /* number of failures inside todo block */
@@ -229,6 +243,8 @@ struct tls_data
{
const char* current_file; /* file of current check */
int current_line; /* line of current check */
+ unsigned int flaky_level; /* current flaky nesting level */
+ int flaky_do_loop;
unsigned int todo_level; /* current todo nesting level */
int todo_do_loop;
char *str_pos; /* position in debug buffer */
@@ -355,9 +371,18 @@ int winetest_vok( int condition, const char *msg, va_list args )
{
if (condition)
{
- winetest_print_context( "Test succeeded inside todo block: " );
- vprintf(msg, args);
- InterlockedIncrement(&todo_failures);
+ if (data->flaky_level)
+ {
+ winetest_print_context( "Flaky succeeded inside todo block: " );
+ vprintf(msg, args);
+ InterlockedIncrement(&flaky_failures);
+ }
+ else
+ {
+ winetest_print_context( "Test succeeded inside todo block: " );
+ vprintf(msg, args);
+ InterlockedIncrement(&todo_failures);
+ }
return 0;
}
else
@@ -381,9 +406,18 @@ int winetest_vok( int condition, const char *msg, va_list args )
{
if (!condition)
{
- winetest_print_context( "Test failed: " );
- vprintf(msg, args);
- InterlockedIncrement(&failures);
+ if (data->flaky_level)
+ {
+ winetest_print_context( "Flaky failed: " );
+ vprintf(msg, args);
+ InterlockedIncrement(&flaky_failures);
+ }
+ else
+ {
+ winetest_print_context( "Test failed: " );
+ vprintf(msg, args);
+ InterlockedIncrement(&failures);
+ }
return 0;
}
else
@@ -456,6 +490,27 @@ void winetest_win_skip( const char *msg, ... )
va_end(valist);
}
+void winetest_start_flaky( int is_flaky )
+{
+ struct tls_data *data = get_tls_data();
+ data->flaky_level = (data->flaky_level << 1) | (is_flaky != 0);
+ data->flaky_do_loop=1;
+}
+
+int winetest_loop_flaky(void)
+{
+ struct tls_data *data = get_tls_data();
+ int do_flaky=data->flaky_do_loop;
+ data->flaky_do_loop=0;
+ return do_flaky;
+}
+
+void winetest_end_flaky(void)
+{
+ struct tls_data *data = get_tls_data();
+ data->flaky_level >>= 1;
+}
+
void winetest_start_todo( int is_todo )
{
struct tls_data *data = get_tls_data();
@@ -601,14 +656,16 @@ static int run_test( const char *name )
printf( "%04x:%s:%s Silenced %d todos, %d skips and %d traces.\n",
(UINT)GetCurrentProcessId(), test->name, winetest_elapsed(),
(UINT)muted_todo_successes, (UINT)muted_skipped, (UINT)muted_traces);
- printf( "%04x:%s:%s %d tests executed (%d marked as todo, %d %s), %d skipped.\n",
+ printf( "%04x:%s:%s %d tests executed (%d marked as todo, %d as flaky, %d %s), %d skipped.\n",
(UINT)GetCurrentProcessId(), test->name, winetest_elapsed(),
- (UINT)(successes + failures + todo_successes + todo_failures),
- (UINT)todo_successes, (UINT)(failures + todo_failures),
+ (UINT)(successes + failures + flaky_failures + todo_successes + todo_failures),
+ (UINT)todo_successes, (UINT)flaky_failures, (UINT)(failures + todo_failures),
(failures + todo_failures != 1) ? "failures" : "failure",
(UINT)skipped );
}
- status = (failures + todo_failures < 255) ? failures + todo_failures : 255;
+ status = failures + todo_failures;
+ if (!winetest_allow_flaky) status += flaky_failures;
+ if (status > 255) status = 255;
return status;
}
@@ -665,6 +722,7 @@ int main( int argc, char **argv )
if (GetEnvironmentVariableA( "WINETEST_DEBUG", p, sizeof(p) )) winetest_debug = atoi(p);
if (GetEnvironmentVariableA( "WINETEST_INTERACTIVE", p, sizeof(p) )) winetest_interactive = atoi(p);
+ if (GetEnvironmentVariableA( "WINETEST_ALLOW_FLAKY", p, sizeof(p) )) winetest_allow_flaky = atoi(p);
if (GetEnvironmentVariableA( "WINETEST_REPORT_SUCCESS", p, sizeof(p) )) winetest_report_success = atoi(p);
if (GetEnvironmentVariableA( "WINETEST_TIME", p, sizeof(p) )) winetest_time = atoi(p);
winetest_last_time = winetest_start_time = GetTickCount();
--
2.30.2
Hi All,
In the wake of the new WOW64 implementation (recent explanation [1]),
there has been discussion in informal channels about how to we are going
to handle pointers to mapped graphics resource memory which we receive
from the graphics API, as the possibility exists that it will fall
outside of the 32-bit address space.
Over time, a few creative solutions have been proposed and discussed,
with a common theme being that we need changes in either the kernel or
the graphics drivers to do this properly. As we already know the
requirements for a solution to this problem, I think it would be
responsible to hash this out now and then work with the relevant project
maintainers earlier as to avoid blocking work on the wine side too long
and to possibly allow more users to test the new path earlier.
The solutions which I've seen laid out so far:
- Use the mremap(2) interface, allowing us to duplicate the mapping we
receive into the 32-bit address space. This solution would match what
is already done for Crossover Mac's 32on64 support using Mac's
mach_vm_remap functionality [2]. However, right now it is not possible
to use the MREMAP_DONTUNMAP flag with mappings that aren't private and
anonymous, which rules out there use on mapped FDs from libdrm. Due to
this, a kernel change would be necessary.
Pro: A uniform solution across all APIs, which could help in the
future with any unforeseen need to access host-allocated memory in
32-bit windows code.
Cons: Requires a kernel change, which of all the options may take
the longest to get up-streamed and in the hands of users.
- Work with Khronos to introduce extensions into the relevant APIs
enabling us to tell drivers where in the address space we want resources
mapped.
Pro: Wouldn't require going around the backs of the driver,
resulting in a more hardened solution. (Out there, but what if a
creative driver returns a mapping without read or write permission and
handles accesses through a page fault handler?)
Cons: The extension would have to be implemented by each individual
vendor for every relevant API. This would implicitly drop support for
those with cards whose graphics drivers are no longer being updated.
- Hook the driver's mmap call when we invoke memory mappings function,
overriding the address to something in the 32-bit address space.
Pro: Unlike the other solutions, this wouldn't require any
changes to other projects, and shares the advantage of the first solution.
Cons: Susceptible to breakage if the driver uses their own
mapping mechanism separate from mmap. (Custom IOCTL, CPU driver
returning something from the heap)
1: https://www.winehq.org/pipermail/wine-devel/2022-April/213677.html
2: https://www.codeweavers.com/crossover/source - see function
`remap_memory` in `wine/dlls/winemac.drv/opengl.c`
From: Angelo Haller <angelo(a)szanni.org>
The following patches fix sending of the LVN_ODSTATECHANGED notification for
LVS_OWNERDATA list views, adding more refined tests in the process and
fixing various bugs.
This is v4 fixing the log buffer overflow on the debian test machine by
moving some of the up/down key sequences to a later patch. Patch 1/7
still includes the necessary up/down key sequences to validate the fixes
in the following patches. The matching up/down key sequences for 1/7
are then introduced in 7/7. I was sadly unable to introduce the test
sequence with each fix, as this would require inventing entirely new
test sequences, just to work around the debian 32KB log buffer limit.
I hope this is ok as it stands.
I am also attaching the my remarks from v3, as I don't know if they got
ignored due to failing tests:
I was sadly not able to trigger any deselect sequences through emulating
mouse clicks. I was actually completely unable even send a lef mouse
button down at all. Both SendMessage and SendInput fail, on wind and
windows.
I am unsure if programmatic mouse clicks are even supported in list
views? Some forums seem to suggest, that this is only the case for
buttons and similar elements. I was following the code snippets in
other parts of the comctl32 tests.
The other thing might be that the signal is getting caught somewhere in
the test code. If anybody has any more insight in this regard, I'd be
happy to add additional mouse click tests as well.
The other thing I was unable to do is activate the single select tests
via SHIFT/+COMMAND to show we need patch 6/6.
Windows weirdly informs about the selected item twice, once to inform
the item has been selected and then in another call later about the
item being focused as well. This seemingly only affects
LVS_OWNERDATA listviews from my tests.
Warning: I have had access to the Windows Research Kernel (WRK) 1.2
~10 years ago. These changes are regarding comctrl32 & tests which are NOT
part of the WRK. As outlined in https://wiki.winehq.org/Developer_FAQ this
should therefore satisfy the requirement of ONLY submitting patches to
components I have NOT had access to.
Angelo Haller (7):
Add more test cases to ownderdata listviews:
comctl32/listview: Fix deselect on LVS_OWNERDATA.
comctl32/listview: Move sending LVN_ODSTATECHANGED notifications to a
function.
comctl32/listview: Send LVN_ODSTATECHANGED only for virtual lists.
comctl32/listview: Send LVN_ODSTATECHANGED notification.
comctl32/listview: Send LVN_ODSTATECHANGED only for true ranges.
comctl32/tests: Expand ownerdata listview tests.
dlls/comctl32/listview.c | 55 ++++---
dlls/comctl32/tests/listview.c | 253 +++++++++++++++++++++++++++++++--
2 files changed, 281 insertions(+), 27 deletions(-)
Signed-off-by: Angelo Haller <angelo(a)szanni.org>
--
2.36.1
Folks,
Here's a summary of the Gitlab experiment discussion, with some
additional comments. Thanks to everybody who sent their feedback!
* Things that people like:
- Fetching commits directly with git instead of applying patches from
emails (Huw, Jacek, Paul, Zeb). Indeed that's a major help for me as
well.
- Better tracker, easy to see the list of pending reviews (Huw).
- Possibility to host more Wine projects, as well as private Wine trees
to share WIP patches (Jacek). Indeed it would be nice to have all Wine
projects in one place instead of the current mix of
github/sourceforge/etc.
- Potential for automation (Jacek). Gitlab offers many services that we
will be able to take advantage of, the most obvious being CI for the
testbot. Having all the data in a proper database instead of free-form
emails should make it possible to do other interesting things as well.
* Some other things I like:
- Updating status doesn't need to go through me, people can assign
reviewers, supersede patches, etc. directly. That reduces my workload
and improves the bus factor. Once we have figured out how to make
testbot results reliable, we could also have maintainers merge commits
directly.
- The full discussion thread for a given MR is readily accessible, it
doesn't require hunting down the multiple revisions of a patch and
associated threads in the mailman archive.
* Things that could be improved:
- Signoffs are a bit cumbersome (Rémi). We should change the
requirements to something better adapted to Gitlab.
- It's only possible to approve the whole MR, not individual commits
(Huw, Zeb). I think that's an acceptable trade-off, but we could
imagine other approaches.
- The mailing list gateway creates too much noise; mixing comments from
Gitlab and mailing list isn't very clean (Jacek, Rémi, Alex). We can
make some tweaks, or use a separate list, or even rethink the approach
of the mail gateway.
- Gitlab threading support is limited, nested comment threads are not
supported (Zeb). That's true, but looking through the past few months
of patch reviews, it seems that we almost never use nested threads, so
I think we can live with that limitation.
- Reviewers can push fixups to commits, but that requires the author to
grant explicit permission (Jacek). Hopefully we can tweak access
rights to allow this by default.
* Conclusion
I think Gitlab is working well for us, and most people seem generally
happy with it. So my plan is to go forward and make Gitlab the main
development platform for Wine.
I'll start working on the transition, and on the improvements mentioned
above. Any help will be welcome! I'll be posting a roadmap shortly.
--
Alexandre Julliard
julliard(a)winehq.org
Hey everyone,
during the course of implementing WinRT / UWP stuff, I regularly come
across missing IDL 3.0 features in our Widl compiler.
Unfortunately, Widl's code seems to have grown in a rater unpleasant
direction and is sometimes a real burden to understand and maintain. I
think some refactoring to its code would be very well fitting and make
things a lot easier for everyone, but refactoring can also bring
breakage and makes tracking down errors with Git harder. Additionally,
as the code is already not that small, errors have an easy way to slip
in without noticing.
So to me, the ideal solution seems to add a testing system to the
compiler, like most of Wine's components already have.
Rémi and I already outlined some ideas:
- Port the Winetest system to Unix programs
- Make a libwidl or Widl.exe and test against that with our current test system
- Add the tests into Widl itself as callable parameter
What do you think is the best solution?
Getting some suggestions would be great. :)
Thanks,
Bernhard
--
v5: winegstreamer: Use an atomic queue for wg_transform input buffers.
winegstreamer: Release requested samples if they are too small.
winegstreamer: Introduce a new wg_allocator_set_next_sample helper.
winegstreamer: Use the GstObject lock instead of a new allocator mutex.
mf/tests: Add todo_wine for newer FFmpeg versions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/302