More in Win32 Signtures


A while back I posted some thoughts on Win32 signatures… The CLR interop team has been hard at work figuring out the right solution, expect to see more soon.  In the mean time check out these PInvoke signatures the C# team posttest a while back.  Looks like they address at least part of the issue. 


 


http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=f1dd70e4-c212-4a6f-bff7-c82e34c8836f.

Comments (7)

  1. Stephane Rodriguez says:

    I wonder when thoughts about interop will ever end.

    1) Interop is hard. It’s hard to figure out the signatures, especially when you are dealing with multiple structs, void* and that kind of things.

    2) Interop is harder. It’s hard to figure out how the memory gets used/released or not. Although a typical developer would dismiss the issue given the automatic GC@Work feature, I think it’s an essential concern when it comes to reliable applications.

    3) Interop is even harder than you think. The signatures is one thing, a use of an API call or COM call that doesn’t fail miserably is a different thing. What matters to developers? an elegant signature, or something that just works? Obviously, for all simple flat API scenarios, why Microsoft doesn’t educate people with managed C++ extensions instead? Doesn’t it solve the "P/Invoke" signature problem as well as helps people figure out proper parameters to pass and to release the memory from?

    A LPTSTR in some API function declaration doesn’t provide any metadata telling who is supposed to allocate/release the buffer. Because of that, providing P/Invoke signatures is not equivalent to solving the problem of native function call, at all.

    4) Interop is a lot harder than even harder. Since CAS applies, an application that does a single P/Invoke or COM call is bound to fail miserably unless a proper deployment scenario has been anticipated. This anticipation requires a lot more understanding of the internals than predicted, and may be arguably not something applicable with typical developer skills. Would be interesting to know, given the lack of .NET tools aimed to check deployment issues in the VS.NET studio package, how much time or even business opportunities are lost because of that. Or, in other words, when will the people at MS understand that the faster they provide a support to the full development cycle, including deployment, the faster people will realize the product is serious at doing it.

  2. Stephane Rodriguez says:

    – Even if you guys come up with fully preinteroped assemblies for gdi, user32, shell32 and the like, it won’t solve the problem in itself. Signature is just one thing. Returning a generic error whenever the user does not make a proper usage of interoped native call is of more concern.

    – the .NET ecosystem closure, who wins in the end ? isn’t interop the evidence that you are willing to offer developers incentives to reuse code and hopefully migrate or rewrite it in the long run, while the mere existence of interop brings a design hole in the ecosystem and, as such, prevents the development platform from existing by itself, and that’s where it diverges so much from the Java VM.

  3. Sam Gentile says:

    > Obviously, for all simple flat API scenarios, why Microsoft doesn’t educate people with managed C++ extensions instead? Doesn’t it solve the "P/Invoke" signature problem as well as helps people figure out proper parameters to pass and to release the memory from?

    Yes, this is the case MC++ was made for. See http://www.iunknown.com/000425.html