I had a bugreport here: https://bugs.winehq.org/show_bug.cgi?id=56161
This pull req fixes the bug that programs that do VirtualAlloc(placeholder)/VirtualFree(keep placeholder)/MapViewOfFile3(replace placeholder), do not run. Like the dotnet pe loader in .net 7 for example.
It was not clear to me at first, because i didnt notice it on msdn, but the way that Dmitry Timoshkov "hacked" it in https://bugs.winehq.org/show_bug.cgi?id=56122 is actually (nearly) how it is supposed to happen according to msdn.
From here: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-… ![image](/uploads/58614927d38c15d4c23517aa5dc09d77/image.png)
So thanks to Dmitry Timoshkov. If you are interested you could also look into the thing i mentioned in the bug report, that MapViewOfFile3 doesn't round down to 64k, but, i don't think this is a serious problem yet.
Edit: I found out that under windows, the alignment constraint is not fully lifted but, it is only required to be pagesize aligned if MEM_REPLACE_PLACEHOLDER is present in the flags.
To clarify why i want this in wine. The PE Loader of .net (see here https://github.com/dotnet/runtime/blob/f21dc6c3dceb6ea76bef73e2a026c770aaed…) does align with page size. Not with 64k. This breaks a .net 7 app during load up, that will execute otherwise just execute fine.
--
v18: kernelbase: Added a test for MapViewOfFile3 with MEM_REPLACE_PLACEHOLDER
https://gitlab.winehq.org/wine/wine/-/merge_requests/4822
Affected games: Phasmophobia, Lethal Company.
The games do not use joystick input but Unity Input subsystem is initialized and that's enough to cause stack overflow when it tries to parse 8 bit hat switches. Most joysticks and some mice have hats.
I own 2 Thrustmaster devices and this fixes the problem with them plugged in. I've also seen [report descriptors shared by Proton users](https://github.com/ValveSoftware/Proton/issues/7284) that reported the crash. The real devices always use 4 bits only.
This MR was tested using a few dinput test programs (upstream Wine) and Elite Dangerous (change was applied on top of the Proton tree). Singular hat works. I don't have anything with more than that though.
--
v4: winebus.sys: Use 4 bits for hat switches.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4964
When cross-compiling on macOS, like building on ARM64 to target x86_64 [1], `make install` would fail with `winebuild: cannot find the 'ar' tool`. `winebuild` was looking for `x86_64-apple-darwin-ar`, but macOS does not install prefixed tools. As a last step before failing in `find_tool()`, search for the un-prefixed tool name.
[1]: with a `configure` invocation like: `../configure --enable-archs=i386,x86_64 --host=x86_64-apple-darwin CC="clang -arch x86_64"`
--
v2: winebuild: As a last resort, search for tools un-prefixed using clang.
winebuild: Refactor find_tool().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4966
For temporary registers, SM1-SM3 integer types are internally
represented as floating point, so, in order to perform a cast
from ints to floats we need a mere MOV.
By the same token, casts from floats to ints can also be implemented with a FLOOR + MOV,
where the FLOOR is then lowered by the lower_floor() pass.
For constant integer registers "iN" there is no operation for casting
from a floating point register to them. For address registers "aN", and
the loop counting register "aL", vertex shaders have the "mova" operation
but we haven't used these registers in any way yet.
We probably would want to introduce these as synthetic variables
allocated in a special register set. In that case we have to remember to
use MOVA instead of MOV in the store operations, but they shouldn't be src
or dst of CAST operations.
Regarding constant integer registers, in some shaders, constants are
expected to be received formatted as an integer, such as:
int m;
float4 main() : sv_target
{
float4 res = {0, 0, 0, 0};
for (int k = 0; k < m; ++k)
res += k;
return res;
}
which compiles as:
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// m i0 1
//
ps_3_0
def c0, 0, 1, 0, 0
mov r0, c0.x
mov r1.x, c0.x
rep i0
add r0, r0, r1.x
add r1.x, r1.x, c0.y
endrep
mov oC0, r0
but this only happens if the integer constant is used directly in an
instruction that needs it, and as I said there is no instruction that
allows converting them to a float representation.
Notice how a more complex shader, that performs operations with this
integer variable "m":
int m;
float4 main() : sv_target
{
float4 res = {0, 0, 0, 0};
for (int k = 0; k < m * m; ++k)
res += k;
return res;
}
gives the following output:
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// m c0 1
//
ps_3_0
def c1, 0, 0, 1, 0
defi i0, 255, 0, 0, 0
mul r0.x, c0.x, c0.x
mov r1, c1.y
mov r0.y, c1.y
rep i0
mov r0.z, r0.x
break_ge r0.y, r0.z
add r1, r0.y, r1
add r0.y, r0.y, c1.z
endrep
mov oC0, r1
Meaning that the uniform "m" is just stored as a floating point in
"c0", the constant integer register "i0" is just set to 255 (hoping
it is a high enough value) using "defi", and the "break_ge"
involving c0 is used to break from the loop.
We could potentially use this approach to implement loops from SM3
without expecting the variables being received as constant integer
registers.
According to the D3D documentation, for SM1-SM3 constant integer
registers are only used by the 'loop' and 'rep' instructions.
--
v3: vkd3d-shader/hlsl: Lower casts to int for SM1.
tests: Add simple test for implicit cast to int.
vkd3d-shader/d3dbc: Implement casts from ints to floats as a MOV.
tests: Remove [require] directives for tests that use int and bool uniforms.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/608
Instead of creating the TTS voice engine directly in SetVoice, we save
the specified voice token, and only create them in speak_proc when
necessary.
--
v2: sapi: Create a new engine only when needed in ISpVoice.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4932