I was watching some random YouTube stream and then heard a voice telling me to do this.
This can run wglgears on wow, though there's plenty of missing pieces which I don't have any idea how to fix (like buffer mapping, etc.). Opening it as a draft for now to show the whole thing, if it seems alright I'll send it in batches.
--
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1010
Various notes:
- LowestStartingAddress is still unsupported;
- Patch 5 ("wow64: Set HighestEndingAddress in wow64_NtAllocateVirtualMemoryEx() if it is absent") is fixing existing WOW issue: NtAllocateVirtualMemoryEx() called from wow64 currently does not constraing the allocation to 32 bit address space (wow64_NtAllocateVirtualMemory() passes zero_bits for that).
- I initially thought of using a single inter process APC but added a different one due to zero_bits handling which is easier to convert in the target process.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1025
Fixes inconsistent function (or function pointer) declation and implementation.
(favoring non long types).
Fixes errouneous format specifier in printf-like function for arguments of type
DWORD_PTR (or SIZE_T or equiv).
This serie could be a starting point for enabling long type compilation in wined3d.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1014
--
v2: mshtml: Enumerate document elements with name.
mshtml: Do not enumerate internal dynamic props.
mshtml: Fix enumerating first custom prop after builtins.
jscript: Refill the props at end of enumeration in html mode and retry.
jscript: Fill the builtin props for enumeration on prototypes as well.
https://gitlab.winehq.org/wine/wine/-/merge_requests/965
--
v2: vkd3d-shader/hlsl: Pass a location pointer to init_node().
vkd3d-shader/hlsl: Use hlsl_new_expr() in add_expr().
vkd3d-shader/hlsl: Write SM4 reinterpret instructions.
vkd3d-shader/hlsl: Parse the asuint() intrinsic.
tests: Add a test for asuint().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/25
clean up of code:
- remove usage of wine_dbgstr_longlong()
- remove some FIXME
- remove stabs's only stuff
clean up of mistake:
- partially revert one of previous commits
(messed up with the tests)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1013
On Thu Oct 6 11:01:58 2022 +0000, Rémi Bernon wrote:
> Well, I believe it is not necessary in general when using standard X
> server, as I described in
> <https://www.winehq.org/pipermail/wine-devel/2020-October/175561.html>,
> but that doesn't cover more exotic use cases where the X scancodes
> aren't fixed.
> Like @julliard replied in that thread, when using VNC X server for
> instance the scancodes aren't fixed anymore and we need that logic to
> figure them out. The problem, in my opinion, comes from VNC simulating
> incorrect scancodes, as it recomputes them from the VKey it received
> (the protocol only sends VKey and and it then assumes its client
> keyboard layout is US), but I agree that nothing in the X specification
> guarantees that the scancodes are fixed and that it makes some sense to
> do that kind of detection.
> Maybe an acceptable solution would be to make that layout detection
> optional, and configurable through a `winecfg` option, so that by
> default we'd assume a standard X server with fixed scancodes, and
> optionally we'd keep support for layout detection (or the other way
> around but I think improving the most common case as a default would be better).
I just went through the email thread (I'm still new to navigating pipermail/mailing list archives) and I see the point, although I don't think I can entirely grasp what VNC does. But the way I understand it is that even if we used XKB names for the scan codes as in this MR, those would be messed up just as well when using a VNC X server, as it maps backwards from vkeys to scan codes?
In the XKB specification/documentation, "The key name links keys with similar functions or in similar positions on keyboards that report different scan codes", which gets me wondering how Windows actually handles exotic keyboards or rather what is common practice in the drivers for said exotic keyboards.
In any case, I agree, I suppose optional layout detection would be the most compatible solution for now at least.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_10036
On Thu Oct 6 11:01:52 2022 +0000, Timo Zuccarello wrote:
> After last day's discussion, I don't think anymore that it's necessary
> to use XKB names to map to scancodes. @rbernon says the keycodes are
> fixed across keyboard layouts and this seems to be the case for me as
> well even with exotic and custom layouts. Rather something about the
> keyboard layout detection may be broken and assigns incorrect scancodes.
> I'll take another look at this and try to figure something out.
Well, I believe it is not necessary in general when using standard X server, as I described in <https://www.winehq.org/pipermail/wine-devel/2020-October/175561.html>, but that doesn't cover more exotic use cases where the X scancodes aren't fixed.
Like @julliard replied in that thread, when using VNC X server for instance the scancodes aren't fixed anymore and we need that logic to figure them out. The problem, in my opinion, comes from VNC simulating incorrect scancodes, as it recomputes them from the VKey it received (the protocol only sends VKey and and it then assumes its client keyboard layout is US), but I agree that nothing in the X specification guarantees that the scancodes are fixed and that it makes some sense to do that kind of detection.
Maybe an acceptable solution would be to make that layout detection optional, and configurable through a `winecfg` option, so that by default we'd assume a standard X server with fixed scancodes, and optionally we'd keep support for layout detection (or the other way around but I think improving the most common case as a default would be better).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_10034
After last day's discussion, I don't think anymore that it's necessary to use XKB names to map to scancodes. @rbernon says the keycodes are fixed across keyboard layouts and this seems to be the case for me as well even with exotic and custom layouts. Rather something about the keyboard layout detection may be broken and assigns incorrect scancodes. I'll take another look at this and try to figure something out.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/182#note_10032
relative optional parameter will now be handled by setting the RelativeName of the relative struct to NT converted and collapsed relative path and the ContainingDirectory to an open handle of current working directory. CurDir is currently not implemented.
--
v5: ntdll/tests: Tests for RtlDosPathNameToRelativeNtPathName_U_WithStatus
ntdll: Implement handling of relative in RtlDosPathNameToRelativeNtPathName_U_WithStatus
https://gitlab.winehq.org/wine/wine/-/merge_requests/1004
relative optional parameter will now be handled by setting the RelativeName of the relative struct to NT converted and collapsed relative path and the ContainingDirectory to an open handle of current working directory. CurDir is currently not implemented.
--
v4: ntdll/tests: Corrected and refactored tests
https://gitlab.winehq.org/wine/wine/-/merge_requests/1004
This patch set is based upon [patches from Wine Staging](https://github.com/wine-staging/wine-staging/tree/master/patches/n… by Erich E. Hoover (@ehoover), and implements support for the `SYSTEM`, `HIDDEN` and `READONLY` DOS file attributes. These can implemented in various ways depending upon the capabilities of the operating system and the file system. However, this initial patch-set focusses on just one method: Samba-formatted Extended File Attributes.
Modern filesystems generally support Extended File Attributes - auxiliary blobs of binary data that can be attached to a file. Samba uses the `user.DOSATTRIB` attribute to store DOS attribute information in the form of a hexadecimal value, and this patch-set implements a compatible mechanism.
Support for additional storage methods to increase operating system and filesystem compatibility is planned for later patch submissions.
This effort is part of a larger project I have been working on to get Msys2 and Cygwin working properly on Wine. The absence of DOS fule attribute support prevents one of the modes that Cygwin and Msys2 can use to emulate symbolic links from working correctly, which causes the Cygwin installer to fail: https://bugs.winehq.org/show_bug.cgi?id=15679
See Also
* https://bugs.winehq.org/show_bug.cgi?id=9158
--
v4: ntdll: Implement storing DOS attributes in NtCreateFile.
ntdll: Implement retrieving DOS attributes in NtQueryInformationFile
ntdll: Implement storing DOS attributes in NtSetInformationFile.
ntdll: Implement retrieving DOS attributes in [fd_]get_file_info().
https://gitlab.winehq.org/wine/wine/-/merge_requests/951
This patch set is based upon [patches from Wine Staging](https://github.com/wine-staging/wine-staging/tree/master/patches/n… by Erich E. Hoover (@ehoover), and implements support for the `SYSTEM`, `HIDDEN` and `READONLY` DOS file attributes. These can implemented in various ways depending upon the capabilities of the operating system and the file system. However, this initial patch-set focusses on just one method: Samba-formatted Extended File Attributes.
Modern filesystems generally support Extended File Attributes - auxiliary blobs of binary data that can be attached to a file. Samba uses the `user.DOSATTRIB` attribute to store DOS attribute information in the form of a hexadecimal value, and this patch-set implements a compatible mechanism.
Support for additional storage methods to increase operating system and filesystem compatibility is planned for later patch submissions.
This effort is part of a larger project I have been working on to get Msys2 and Cygwin working properly on Wine. The absence of DOS fule attribute support prevents one of the modes that Cygwin and Msys2 can use to emulate symbolic links from working correctly, which causes the Cygwin installer to fail: https://bugs.winehq.org/show_bug.cgi?id=15679
See Also
* https://bugs.winehq.org/show_bug.cgi?id=9158
--
v3: ntdll: Implement storing DOS attributes in NtCreateFile.
ntdll: Implement retrieving DOS attributes in NtQueryInformationFile
ntdll: Implement storing DOS attributes in NtSetInformationFile.
ntdll: Implement retrieving DOS attributes in [fd_]get_file_info().
https://gitlab.winehq.org/wine/wine/-/merge_requests/951
relative optional parameter will now be handled by setting the RelativeName of the relative struct to NT converted and collapsed relative path and the ContainingDirectory to an open handle of current working directory. CurDir is currently not implemented.
--
v3: ntdll/tests: Handle relative paths for windows 7
https://gitlab.winehq.org/wine/wine/-/merge_requests/1004
relative optional parameter will now be handled by setting the RelativeName of the relative struct to NT converted and collapsed relative path and the ContainingDirectory to an open handle of current working directory. CurDir is currently not implemented.
--
v2: ntdll: Implement handling of relative parameter for RtlDosPathNameToRelativeNtPathName_U_WithStatus
ntdll/tests: Add tests to verify relative pathname and container directory filling. Also additional entries to test more relative pathname cases
https://gitlab.winehq.org/wine/wine/-/merge_requests/1004
Add the ability to disconnect nested node providers, and return element properties for nested nodes.
--
v6: uiautomationcore: Add UIAutomationType_Element property support for nested node providers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/908
relative optional parameter will now be handled by setting the RelativeName of the relative struct to NT converted and collapsed relative path and the ContainingDirectory to an open handle of current working directory. CurDir is currently not implemented.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1004
Ensure IOSB Information (InternalHigh) is loaded after Status (Internal)
to avoid reading stale value from the Information (InternalHigh) field.
--
v2: kernelbase: Fix reading stale information from IOSB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/881
Enforce proper atomic update so that other threads do not read stale
data from IO_STATUS_BLOCK.
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
--
v6: ntdll: Fix reading stale Information from IOSB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/155
XWayland tablet devices have the Wayland seat ID appended to the end of
them, preceded by a colon. This prevents match_token from properly
detecting XWayland devices and causes Wintab32 to fail to initialize.
This change allows a matched token to end in a colon, and thus allows
XWayland tablet devices to be detected correctly.
Signed-off-by: John Chadwick <john(a)jchw.io>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1000
The only way to actually set these properties is via the ICommandProperties interface
found on ICommandText(eg rowset->caller).
Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/999
On ARM and ARM64, each SEH opcode is supposed to map to exactly one
instruction; the operation of writing x29+x30 with a stack offset
with writeback is called ".seh_save_fplr_x".
Using the right opcode would fix inconsistent unwinding if we would
unwind from near the end of the prologue (which is implausible here).
However, clang/LLVM might also get checking for mismatches between
SEH opcodes and the prolog/epilog ranges
(https://reviews.llvm.org/D131394), mainly to guard against
inconsistencies in the unwind info generated by the compiler, but
that would trigger on this handwritten function too.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/998
--
v6: comctl32: Don't pass PROPSHEETPAGE to SetWindowSubclass in PROPSHEET_CreatePage.
comctl32/tests: Test passing PropertySheetPage as HPROPSHEETPAGE.
comctl32/tests: Add more PROPSHEETPAGE tests inside callback.
comctl32/tests: Test passing extra data in PROPSHEETPAGE structure.
comctl32/tests: Test PROPERTYSHEETPAGE passed in WM_INITDIALOG.
https://gitlab.winehq.org/wine/wine/-/merge_requests/932
This patch series has gotten quite big
I don't expect this to be approved but I think it would be good if you review this approach so I start sending this patch series in fragments
Because there are design decisions with long term effects
Includes:
* Many small fixes to corner cases I have stumbled upon.
* For SM1, the tex2D and tex3D intrinsics, inferring generic samplers dimension from usage, writing sampler declarations, and writing sample instructions.
* Support for arrays of resources for both SM1 and SM4.
* Support for synthetic combined samplers for SM1 and synthetic separated samplers for SM4, considering that they can be arrays or members of other structs.
All of this considering that the assignment of register indexes on allocation for each object component has to match match
Some design changes are important in the long run
Long reach of support to make sure this changes were in the right direction
(I had to discard several approaches before reaching this one)
Resource allocation is challenging because it is done at array level even if array is a member within a struct.
because
While I doubt this will be accepted quickly, I think it is a good thing
Among the most complex things is ensuring that allocated
I have tested with ps_3_0 and ps_5_0
These are some of the tests I have been running both for SM1 and SM4 (with -GeC) flag, so that the allocated registers matches the ones of the native compiler.
[sm1-separated-samplers.hlsl](/uploads/5cfe4c4b64c208e3528c9b8e45959e0a/sm1-separated-samplers.hlsl)
[sm1-separated-samplers-array.hlsl](/uploads/08734623aa930ec2f40f254824ffbb5b/sm1-separated-samplers-array.hlsl)
[sm1-separated-samplers-2.hlsl](/uploads/32018666a2d4400f5fa8ec5f9edbac4d/sm1-separated-samplers-2.hlsl)
[sm1-reserves-and-arrays.hlsl](/uploads/f8be8a59c818aea2ebc176d92b6de80d/sm1-reserves-and-arrays.hlsl)
[sm1-reserves-and-dims.hlsl](/uploads/346087313ab21849ff20da3f9449b80f/sm1-reserves-and-dims.hlsl)
[sm1-combined-order.hlsl](/uploads/4d77c5b68df1b365d4ec0a61d25e8d2d/sm1-combined-order.hlsl)
[sm1-separated-and-combined-samplers.hlsl](/uploads/d9d337839642a29793358a86e31b8d40/sm1-separated-and-combined-samplers.hlsl)
This patch series doesn't include these tests nor at automated way of testing them yet.
--
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/26
Prints 'int a[10]' (instead of 'int[10] a').
Ditto for variables/fields of type function pointer.
And for pure type printing, no longer prints --none-- for
arrays and function pointers.
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/977
This patch set is based upon [patches from Wine Staging](https://github.com/wine-staging/wine-staging/tree/master/patches/n… by Erich E. Hoover (@ehoover), and implements support for the `SYSTEM`, `HIDDEN` and `READONLY` DOS file attributes. These can implemented in various ways depending upon the capabilities of the operating system and the file system. However, this initial patch-set focusses on just one method: Samba-formatted Extended File Attributes.
Modern filesystems generally support Extended File Attributes - auxiliary blobs of binary data that can be attached to a file. Samba uses the `user.DOSATTRIB` attribute to store DOS attribute information in the form of a hexadecimal value, and this patch-set implements a compatible mechanism.
Support for additional storage methods to increase operating system and filesystem compatibility is planned for later patch submissions.
This effort is part of a larger project I have been working on to get Msys2 and Cygwin working properly on Wine. The absence of DOS fule attribute support prevents one of the modes that Cygwin and Msys2 can use to emulate symbolic links from working correctly, which causes the Cygwin installer to fail: https://bugs.winehq.org/show_bug.cgi?id=15679
See Also
* https://bugs.winehq.org/show_bug.cgi?id=9158
--
v2: ntdll: Implement storing DOS attributes in NtCreateFile.
ntdll: Implement retrieving DOS attributes in NtQueryInformationFile
ntdll: Implement storing DOS attributes in NtSetInformationFile.
ntdll: Implement retrieving DOS attributes in [fd_]get_file_info().
https://gitlab.winehq.org/wine/wine/-/merge_requests/951