I wrote this patch some time ago, and I'm not really sure why I did. I don't
think it was necessary for any refactoring.
Looking at it again, though, I think it does make sense. Device validation is a
high-level operation, and I think it's clearer if we're checking the d3d states
directly here. This also means we're not unnecessarily applying the stateblock
here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3864
Make functions ntlea needs to patch hotpatchable. And add a asm wrapper for `GetWindowLongA` to workaround an assumption ntlea made.
--
v2: user32: add hotpatchable wrapper for GetWindowLongA
https://gitlab.winehq.org/wine/wine/-/merge_requests/3855
This patch-set adds the definitions and struct modifications required to eventually implement `FileRenameInformationEx` and `FileLinkInformationEx`.
The initial tests are copies of the tests for `FileRenameInformation` and `FileLinkInformation`, but with the `ReplaceIfExists` field replaced with the equivalient `Flag` value: `FILE_RENAME_REPLACE_IF_EXISTS` or `FILE_LINK_REPLACE_IF_EXISTS` respectively.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3836
--
v2: cryptui: Use CertNameToStr(CERT_NAME_STR_NO_QUOTING_FLAG) to disable quoting.
crypt32: Add support for CERT_NAME_STR_NO_QUOTING_FLAG to CertNameToStr().
crypt32/tests: Add some tests for quoted RDN values.
crypt32: Avoid truncating unicode chars.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3729
It can be unnecessary at best and unsupported at worst (e.g. no ARB_texture_multisample).
--
v4: wined3d: Don't skip ARB fragment program selection when fog state is dirty.
wined3d: Skip acquiring a context for an offscreen resource in texture2d_read_from_framebuffer().
wined3d: Don't force going through a texture when downloading from renderbuffers.
wined3d: Handle depth textures in texture2d_read_from_framebuffer().
wined3d: Rename wined3d_context_gl_apply_fbo_state_blit() function.
wined3d: Don't setup FBO and draw buffers in wined3d_context_gl_apply_blit_state().
wined3d: Don't call wined3d_texture_load() from wined3d_context_gl_apply_blit_state().
wined3d: Don't bind the FBO to GL_READ_FRAMEBUFFER in wined3d_context_gl_apply_blit_state().
wined3d: Prepare/load the destination resource location in arbfp_blitter_blit().
wined3d: Prepare/load the destination resource location in ffp_blitter_blit().
wined3d: Don't call wined3d_context_gl_apply_blit_state() from texture2d_read_from_framebuffer().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3211
--
v2: winepulse: Ensure unixlib function tables and enum stay in sync.
wineoss: Ensure unixlib function tables and enum stay in sync.
winecoreaudio: Ensure unixlib function tables and enum stay in sync.
winealsa: Ensure unixlib function tables and enum stay in sync.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3848
With recent changes leave_handler writes to some of its parameter's
fields (via DS_sig and ES_sig) on FreeBSD and NetBSD - which fails
since it is declared const. Accordingly strip const-ness.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3845
...nope, my VM no longer works. I'm just getting nonsensical errors (why would IVMRSurfaceAllocatorNotify9_SetD3DDevice return E_NOINTERFACE), even from programs that worked last time I tried. I'd suspect some broken update somewhere, GPU stuff has always been finicky in VMs.
I'd be happy to fix this test if I could, but without access to a functional Windows installation, there's not much I can do :/
Though I have done some manual testing with some real-world programs, so I'm confident that it's better than the previous stub, at least.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3792#note_45450
> HLSL_IR_STORE and HLSL_IR_RESOURCE_STORE exist though. I don't think you can use those as HLSL_IR_EXPR sources (right?), but that might not necessarily be obvious.
As this MR proves, we're not in an overabundance of documentation about the HLSL IR, that's sure.
In my interpretation, the fact that `HLSL_IR_STORE` and `HLSL_IR_RESOURCE_STORE` don't evaluate to a value is of little relevance. Even if they did, they are executed if the control flow reach them, not if their result is used.
I realize that my sentence "Nodes purely forward a value and have no side effects" has probably a poor choice of words: of course nodes, which we use essentially as a synonym for "instructions", of course do have side effects (in general, at least). What I wanted to say is probably more like "References purely forward a value [etc]": the act of recalling the value produced by an earlier node/instruction has no side effect, therefore the question if `MOVC` evaluates the operand which is not selected is empty: the operand doesn't bear any side effect, be it selected or not; and the referenced node/instruction is evaluated (possibly with side effects) independently of its value being selected by `MOVC` or not, simply by virtue of being in the control flow; it would have been evaluated even if `MOVC` didn't have it as an operand at all.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/340#note_45445