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

[junkmd]

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.