The PInvoke problem

I have been talking to the CLR interop team recently about some ideas to make life easier for developers using PInvoke. My hope is that with WinFx PInvoking out to the Win32 will be much more rare, but we have a while to go before we get there. In the meantime, we'd like your feedback:

Several times in the past, we’ve got feedback that it’s hard to write pinvoke declarations. We were asked to either provide a tool that would take an unmanaged C header file and produce pinvoke declarations in C# and/or VB.NET or to publish pinvoke declarations for the Win32 APIs. The first ask is unfortunately impossible to do 100% correctly since unmanaged header files are too ambiguous to be automatically convertible. For example, how would such tool convert char* parameter? As String, StringBuilder, ref char or char[]? It’s hard to know unless you read docs for that win32 function. The second ask was technically possible of course but we would always run into issue of resources and benefits i.e. is it really worth doing?

Currently, we are investigating variation of the second solution, which is publishing all pinvoke declarations we have in our code base in some searchable form (both C# and VB.NET variations). We are also planning to possibly allow community to post their own pinvoke declarations and grow database of declarations over time.

We are interested to know if this would be useful. Even though we couldn’t publish all the Win32 API declarations (or any other 3^rd party API declarations) we hope that a) there would be reasonable chance you could find declarations you need, b) you would be able to use the database to learn how to write your own declarations, and c) you would be able to submit missing declarations and help other developers.

Please let us know if you have any feedback about this. Is this indeed an issue for you? Would such database help or even solve your issues with writing pinvoke declarations?

Comments

• Anonymous
  February 06, 2004
  Seems like a good first step would be to buy the rights to reprint the appendixes from Adam Nathan's book.

• Anonymous
  February 06, 2004
  I, for one, would definately welcome a internet updatable win32 api declaration database application ;-)

• Anonymous
  February 06, 2004
  I find this utility a great help in this area:
  
  http://www.activevb.de/rubriken/apiviewer/index-apiviewereng.html

• Anonymous
  February 06, 2004
  The comment has been removed

• Anonymous
  February 06, 2004
  
  1) It's more than the function signature I am afraid. Not only all structs, enums and symbols have to be pre-marshalled as well and made searchable in some database, you'll also have to provide code samples most of the time. Why? simply because often, custom marshalling is the only way to go, and this requires code.
  
  2) A lot of signatures will end up with IntPtr and Object. How is it supposed to tell the developer what they are supposed to give to it?
  
  3) As for the 2nd solution, I think an AUTOMATIC CONVERTER is the way to go. Copy your C/C++ code, click Convert, and paste the result in your managed code. It would take advantage of that existing database and would work most of the time. It would work perfectly for all wellknown uses, and would do 80% of the work otherwise.
  
  4) Regarding automatic converters, there are a few out there already.
  
  5) I don't know if that question was really open. People like ANathan have more than their share already about what developers need in this area. And if you wondered, devsites message boards are waiting for you.
  

• Anonymous
  February 06, 2004
  
  Of course I forgot the obvious one : favor managed C++ since you need not P/Invoke. The amazing thing would be, instead of forcing them to create an assembly only to store the unmanaged stuff, it would be an order to magnitude simpler if a managed C++ code snippet could be inserted right into managed code, just like an asm block can be inserted right into regular C/C++ code.
  

• Anonymous
  February 06, 2004
  It would be easier to just copy and paste a few declarations rather than trying to figure them out for yourself.
  
  The main problem I have is the documentation for PInvoke is (IMO) pretty confusing, and doesn't really tell you what you need to know. So you're left with trial and error. Which is hard to do, since you don't have a lot of tool support in VS to really be able to tell if what you're doing is working right (or more to the point, to figure out why it's not working).
  

• Anonymous
  February 06, 2004
  I could never understand why .NET 1.0 shipped without prepackaged pinvoke declarations for most common APIs.
  
  J++ had this stuff (known as com.ms.win32 package) back in 1997 and it's sad that .NET programmers are still struggling with manual J/Dire^H^H^H PInvoke declarations in 2004.
  
  Check out for example this article from 1997:
  
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnguion/html/msdn_drguinat.asp
  
  [quote]
  You're probably looking at this and saying, "Nice—but I don't want to have to write these funky comment directives for each Windows function I want to use." Fortunately, you don't have to declare the entire Windows API yourself—Microsoft provides handy classes that contain these declarations. All you have to do is import the correct class(es).
  [/quote]
  
  Well... I always thought J++ was ahead of its time.
  
  

• Anonymous
  February 06, 2004
  This is of course a good community project. An "open" readable and modifiable repository on GotDotNet would be good. Only problem: some volunteer moderator would be necessary.

• Anonymous
  February 06, 2004
  Absolutely helpful, PInvoke declaration (especially on strings) is one of the area where devs usually get lost (I see many VB6'er using same VB6 declarations on .NET)
  So it will Definitely help (something like APIGuide but integrated into VS)
  It is also very hard to get messages defines even from MSDN

• Anonymous
  February 06, 2004
  My personal feeling is that MS will benefit from such a project To do so would 1) get ISVs moved over faster to the managed environment 2) reduce the bugs in ISV code 3) improve ISV code security because managed code is safer code. All of this makes money for Microsoft.
  
  I think an MS managed open source solution is a second tier solution as it will be harder for non-MS folks to ask the necessary questions to get it "right".
  
  However if MS is not willing to eat the whole pie, an MS managed community project is workable. Figuring that, collectively, there is a rather broad coverage of the API, we can get a rather large body of solutions.
  
  I see that starting with the nucleus of MS P/Invoke code as essential, as is having a MS managed process and MS quality control. A grab-bag approach is the worst possible result. Don’t let the Software Development process devolve into the hip-shooting culture of much of the open-software community.
  

• Anonymous
  February 06, 2004
  "2) A lot of signatures will end up with IntPtr and Object. How is it supposed to tell the developer what they are supposed to give to it?"
  
  That's what the Platform SDK docs are for. While you can't use only the Platform SDK or only these PInvoke declarations seperately to know what to do from managed code, but together you'll be able to use the Win32 API correctly from managed code.

• Anonymous
  February 07, 2004
  >>> Currently, we are investigating variation of the second solution, which is publishing all pinvoke declarations we have in our code base in some searchable form (both C# and VB.NET variations). <<<
  
  I think that would be a solid start. Can you be sure to include P/Invoke declarations for the CE database APIs? :)
  

• Anonymous
  February 07, 2004
  Brad,
  
  The painful part about P/Invoke is declaring the structs. Yet that's something that can be produced from the header files automatically.
  
  As for the definitions of individual functions, the more you give us the better.
  
  Dejan

• Anonymous
  February 07, 2004
  If Microsoft is doing it: The teams that maintain the code should provide a Pirmary Interop Assembly (PIA) that can be used to invoke the functions. There probably won't be time to do this except for Longhorn. Of course, even better would be full managed wrappers on top of the API.
  
  If the community is doing it: Pick one of the existing sites and work from there. You'll probably want code rather than an assembly from some unknown party, but that's OK. Group the code into public files though, and inside classes, so that all you have to do is build the code into your project - after you've reviewed it, of course.
  
  Like others, I'm surprised that Microsoft didn't do it, but I'm sure it was a schedule thing. Next best would be having MSDN document the PInvoke declaration on the smae web page that describes the Win32 function/struct. Just as the managed code pages have info for C#, VB and C++, the Win32 functions could have C and Managed code listings for each API. This means that the dev team has less work, but your documentation team will have to grow...
  

• Anonymous
  February 07, 2004
  Examples of more complicated p/invoke in the documentation might be enough for some. The current examples are pretty light. I lost quite a bit of hair trying to write the p/invoke for InitializeSecurityContext; the pInout and phNewContext are strange in/out parameters, and I gave up on SecBufferDesc and just did everything manually and used a lot of IntPtr.

• Anonymous
  February 07, 2004
  The comment has been removed

• Anonymous
  February 07, 2004
  Not only would this be helpful as a resource in its own right, but it would also give a large list of samples that people could work off when writing their own P/Invoke declarations. Providing fish to eat and bait to catch more, so to speak.

• Anonymous
  February 08, 2004
  The comment has been removed

• Anonymous
  February 08, 2004
  The comment has been removed

• Anonymous
  February 09, 2004
  +1 for a community PInvoke resource.

• Anonymous
  February 13, 2004
  We would definitely like to see prepackaged (pretested) Win32 API P/Invoke declarations. Actually, Borland has already had to figure out a boatload of these things to implement VCL for .NET in Delphi 8. These are all in Delphi syntax, of course. ;> But we need more, much more than we have resources to dump on this task.
  
  -Danny
  
  

• Anonymous
  February 13, 2004
  The comment has been removed

• Anonymous
  April 23, 2004
  pinvoke.net, a PInvoke community Wiki, pinvoke.net, maintained by the PInvoke deity Adam Nathan.

• Anonymous
  May 18, 2004
  SWIG is an open source wrapper generator with support for C# as well as many other languages. We have used it extensively over the past several months to generate C# wrappers for our proprierary C++ API.
  
  I have not used it to wrap Win32 API functions, although I think it should be a good tool for this purpose.
  

• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=brad-abrams-the-pinvoke-problem

• Anonymous
  June 19, 2009
  PingBack from http://debtsolutionsnow.info/story.php?id=10642