[RFC] WinAdapter: Export helper functions to interact with shimmed types#3265
[RFC] WinAdapter: Export helper functions to interact with shimmed types#3265MarijnS95 wants to merge 3 commits intomicrosoft:mainfrom
Conversation
MarijnS95
force-pushed
the
winadapter-export-helper-functions
branch
from
55ffd35 to
74f1588
Compare
|
❌ Build DirectXShaderCompiler 1.0.3888 failed (commit 94e7cdcc99 by @MarijnS95) |
MarijnS95
force-pushed
the
winadapter-export-helper-functions
branch
from
74f1588 to
40e6cee
Compare
|
❌ Build DirectXShaderCompiler 1.0.3889 failed (commit 91a1745251 by @MarijnS95) |
MarijnS95
force-pushed
the
winadapter-export-helper-functions
branch
from
40e6cee to
76e5193
Compare
MarijnS95
force-pushed
the
winadapter-export-helper-functions
branch
from
76e5193 to
3c42468
Compare
|
Still an RFC as per #3250 (comment), not sure if we actually want this - probably not worth the hassle as we're following the implementation of |
|
This PR was closed as it has not been updated in the last two years. Please feel free to reopen if this PR should be merged and is in a reviewable state. |
|
@damyanp A contributor cannot reopen a PR after it has been closed by a collaborator or member. If I were to rebase and (force)push to the branch GitHub dissociates it from the PR, never allowing it to be reopened again. If you were to reopen this and I were to rebase it, do you think this change has any chance of being reviewed and considered? It's still something I want to have to get rid of the Linux-specific implementation details in downstream code. |
|
This one seems a little more involved, or least touches on areas I'm less familiar with. I'll have a look around to see if anyone's able to pick this up. |
github-project-automation
bot
moved this from Done
to In Progress
in Open-Source contributions
|
I think we might be able to get this through, thanks! |
jenatali
left a comment
jenatali
left a comment
There was a problem hiding this comment.
This makes sense to me and seems relatively scoped. My only concerns would be interposition of other components exporting these same functions, but on Linux I don't expect that to be a real concern.
The implementation of these support types completely depends on DXC. As such applications using libdxcompiler.so have to guess and/or look at the source code to understand how they are implemented (eg prefix size for BSTR), and assume this is not going to change. Applications using these newly exported symbols can do it "the right way" as if they are on Windows.
Some functions return lists allocated with CoTaskMemAlloc. Applications using libdxcompiler.so currently have to look into the code to understand that these should be deallocated with free() instead of delete[]. Export the CoTaskMemFree function so that there is no guesswork involved anymore: the application can now call this function and always free it in the right way.
MarijnS95
force-pushed
the
winadapter-export-helper-functions
branch
from
3c42468 to
77363bf
Compare
4 participants
For #3250 (comment)
WinAdapter shims some types and constructs that returned to applications interacting with
libdxcompiler.so. Currently these applications have to "guess" or look into the code to understand how to work with these without provoking incorrect or unexpected behaviour. Even though they are unlikely to change, exporting these functions allow applications to work with Windows APIs "as normal" on Linux, without having to define fallback paths with heavily implementation dependent code.For example, my usecase of DXC currently has to define these monstrosities:
https://github.com/Traverse-Research/hassle-rs/blob/5cfd0f545e27c54f592e54f73214d129ebfab1a8/src/os.rs#L26-L54