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|…
[View More]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
[View Less]
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 …
[View More]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`
[View Less]
All of the new tests that are marked todo_wine fail because Wine's
PathCombineW does not handle ".", "...", "....", or "foobar." correctly.
They will pass once PathCombineW is fixed.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52506
Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com>
--
v3: shell32: Sanitize Program Manager icon and group names
https://gitlab.winehq.org/wine/wine/-/merge_requests/23
Fixes ClaDun X2 missing rendering parts on AMD. The GL game uses stencil and requests pixel format with depth 16, stencil 8. On Wine / AMD that ends up with 16x0 format as there is no 16x8 advertised (16x0 only) and depth takes absolute priority. On the same Windows machine I see both 16x0 and 16x8 formats, but when 16x8 is requested 24x8 is returned (and 16x0 if 16x0 is requested).
That currently works under Wine / Nvidia because there is no 16 bit depth formats advertised at all and it ends …
[View More]up with 24x8 without this patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/132
[View Less]
Commit 15483b1a126 (server: Allow calling async_handoff() with status
code STATUS_ALERTED., 2022-02-10) introduced the set_async_direct_result
handler which calls async_set_initial_status().
However, the async_set_initial_status() call does nothing since
async->terminated is set, leaving the async in a confusing state
(unknown_status = 1 but pending/completed).
So far, this issue is unlikely to have been a problem in practice for
the following reasons:
1. async_set_initial_status() would …
[View More]have unset unknown_status, but it
remains set instead. This is usually not a problem, since
unknown_status is usually ever read by code paths effectively
unreachable for non-device (e.g. socket) asyncs.
It would still potentially allow set_async_direct_result to be called
multiple times, but it wouldn't actually happen in practice unless
something goes wrong.
2. async_set_initial_status() would have set initial_status; however,
it is left with the default value STATUS_PENDING. If the actual
status is something other than that, the handler closes the wait
handle and async_satisfied (the only realconsumer of initial_status)
would never be called anyway.
For reasons above, this issue is not effectively observable or testable.
Nonetheless, the current code does leave the async object in an
inconsistent state.
Fix this by removing the !async->terminated check in
async_set_initial_status().
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
---
Notes:
v1 -> v2: no changes
v2 -> v3: no changes
v3 -> v4: reuse async_set_initial_status() per feedback
server/async.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/server/async.c b/server/async.c
index 7d0ff10f7a4..e92d4583c1e 100644
--- a/server/async.c
+++ b/server/async.c
@@ -303,11 +303,8 @@ struct async *create_async( struct fd *fd, struct thread *thread, const async_da
void async_set_initial_status( struct async *async, unsigned int status )
{
assert( async->unknown_status );
- if (!async->terminated)
- {
- async->initial_status = status;
- async->unknown_status = 0;
- }
+ async->initial_status = status;
+ async->unknown_status = 0;
}
void set_async_pending( struct async *async )
--
2.34.1
[View Less]
Signed-off-by: Chip Davis <cdavis5x(a)gmail.com>
--
v2: wined3d: Record format UAV capabilities.
d3d11: Support D3D11_FEATURE_FORMAT_SUPPORT2.
d3d11: Support D3D11_FEATURE_FORMAT_SUPPORT.
d3d11: Reimplement ID3D11Device::CheckFormatSupport() using wined3d_device_check_format_support().
wined3d: Introduce wined3d_device_check_format_support().
https://gitlab.winehq.org/wine/wine/-/merge_requests/131
Folks,
The Gitlab experiment seems to be going well. For the last release, more
than half the patches were submitted as Gitlab merge requests, so that
seems to be working well for us.
There are still improvements we can make, and of course many more
Gitlab features that we could start using, but before investing more
effort we need to decide whether we want to use it going forward.
So now that you have had a chance to try it, what do you people think?
Should we adopt Gitlab as our …
[View More]development platform?
--
Alexandre Julliard
julliard(a)winehq.org
[View Less]
From: Angelo Haller <angelo(a)szanni.org>
The following patches fix sending of the LVN_ODSTATECHANGED notification for
LVS_OWNERDATA list views. A few more refined tests have been added, some
wine_todos removed, and bugs fixed.
This is a v2 resend.
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 …
[View More]satisfy the requirement of ONLY submitting patches to
components I have NOT had access to.
Angelo Haller (6):
comctl32/tests: Expand ownerdata listview tests.
comctl32/listview: Move LVN_ODSTATECHANGED notification to 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/listview: Fix deselect on LVS_OWNERDATA.
dlls/comctl32/listview.c | 55 +++++++++++++++++++++----------
dlls/comctl32/tests/listview.c | 59 +++++++++++++++++++++++++++++-----
2 files changed, 89 insertions(+), 25 deletions(-)
Signed-off-by: Angelo Haller <angelo(a)szanni.org>
--
2.36.0
[View Less]