-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved code for supporting multiple Windows versions #93
base: feature/windows-10-support
Are you sure you want to change the base?
Improved code for supporting multiple Windows versions #93
Conversation
@Lej77 Hi, how do you get the |
@eythaann Unfortunately I didn't figure that out myself. I just used the same Under the |
oh I understand, I though that we can made the exposed api functions returns and error edit: Also this won't be a breaking change, because the functions already return a Result enum. |
I guess you want to check if the hardcoded This PR does have code to detect the current Windows version and that might be useful to return an error when a too old Windows version is used. We can't really return errors for too new versions since we don't know in advance when the interfaces will change. |
oh sure, I'm sure that windows-rs crate have a way to test if a IID is valid as a COM object before create it. so it could be the solution, In my case I'm using this crate for a module on my last project Seelen-UI and some users report crash on last 24h2. I for now I just will disable the Virtual desktop module for 24h2 and later I will try to do some changes in my fork to later be added to this PR, mostly to avoid cases where the program may crash without allowing the client to handle the error. |
FWIW, I know this doesn't sound helpful, but to me ideal multiple-version support is different DLLs. On your application code look Windows version and LoadLibrary older DLL. Windows 11 has already had 6 backward incompatible IIDs, and they are not just IIDs, they change the interfaces. Managing multiple old interfaces in one code base is quite difficult. Ideally, I would keep only the latest code in the codebase and have old DLLs available. |
@Ciantic I can understand that perspective but I disagree that the tradeoff isn't worth it. This is your library of course so I will just continue to maintain a fork with my changes. There are many advantages to supporting multiple versions in the same library:
The only disadvantage to supporting multiple versions is that it complicates the library code. That is quite a large issue but I think it is worth it, at least for me. It is quite self contained so it is really only the |
Hi again, I read your comment in my previous PR #92 and supporting multiple Windows versions definitively complicates the code so it makes sense to limit the scope of the project.
Anyway, I made some improvements to the code for supporting multiple Windows versions and I guess you can merge them into the same branch as the other Windows 10 support:
multiple-windows-versions
feature flag without which the code uses the previous approach of only supporting the latest COM interfaces.interfaces.rs
(compared to the code in therust
branch).interfaces_multi.rs
which works as a drop in replacement forinterfaces.rs
when the feature flag is used.interfaces_multi.rs
reusable_com_interface
macro to easily re-use the interface definitions from a previous version, like inbuild_22631_3155.rs
comobjects.rs
or the other files uses new methods then add those to the definitions inbuild_dyn.rs
.DLL Size
I checked the size of the DLL (built in release mode) with and without the
multiple-windows-versions
feature:Tests
I also ran all the tests and they did pass on Windows 10 (well, except for the ones using features that weren't supported):