Skip to content
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

Cases where non-local methods are defined in the interface generated by GetModule #604

Open
junkmd opened this issue Aug 25, 2024 · 0 comments

Comments

@junkmd
Copy link
Collaborator

junkmd commented Aug 25, 2024

I noticed the following while investigating structured storage and monikers and verifying with the Python wrapper module for msvidctl.dll, which defines those interfaces.

When retrieving the FUNCDESC that holds the information of vtbl-mapped methods from ITypeInfo, which contains the interface information, there are cases where the method has the call_as IDL attribute instead of the local IDL attribute.
The methods defined in the interface of the module generated by GetModule are based on the information from these FUNCDESCs.

However, the parameters of the methods defined for remote procedure calls with the call_as attribute may not match the parameters of the methods defined for local use with the local attribute.
As a result, attempting to call these methods from the client side may result in errors.

This issue is different from the one discussed in #474 and resolved by @jonschz in #578 for ISequentialStream.RemoteRead, where calling low-level functions with preallocation was the solution.

  • As seen in the IDL file, the methods RemoteRead and Read had the same parameters, differing only in name.

However, in cases like IStorage's RemoteOpenStream and OpenStream, where there are parameter differences, calling low-level functions won't resolve the problem.

Furthermore, since IEnumMoniker has RemoteNext defined as call_as(Next), RemoteNext is defined instead of Next. This results in the interface not meeting the conditions for defining __iter__, __next__, and __getitem__ by the codegenerator, making it unusable as an iterator.

To differentiate between local and call_as, using ITypeInfo2 in tlbparser or codegenerator might be a possible solution.
However, careful implementation is required to avoid losing backward compatibility or unnecessarily complicating the current codegenerator or tlbparser.

For individual interfaces, this issue could be resolved by statically defining the interface (and its dependent structures) with the local methods and adding them to __known_symbols__.
I think that specific issues should be submitted for each interface or framework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant