v2 activities and refactorings

[arlm]

This is an issue to register the activities and refactoring needed for the v2 milestone. Here are some:

• Remove Gdi32.GetDeviceCaps(User32.SafeDCHandle hdc, int nIndex)
• Remove Kernel32.QueryFullProcessImageName(SafeObjectHandle hProcess, QueryFullProcessImageNameFlags dwFlags, StringBuilder lpExeName, ref int lpdwSize);
• Remove Kernel32.GetNamedPipeClientComputerName(SafeObjectHandle Pipe, StringBuilder ClientComputerName, int ClientComputerNameLength)
• Remove Kernel32.GetNamedPipeHandleState(SafeObjectHandle hNamedPipe, out PipeMode lpState, int* lpCurInstances, int* lpMaxCollectionCount, int* lpCollectDataTimeout, StringBuilder lpUserName, int nMaxUserNameSize)

[AArnott]

Thanks for starting this. I've wondered how to track this. :)

[arlm]

You are welcome. There are some generic tasks also:

• Change all ref and out parameters to pointers
• Change all StringBuffer parameters to char* pointers
• Change all cbSize items in structs to int type
• Normalize static Create() methods on structs
• Close and act on Review and improve our Handle and SafeHandle policies #272
• Close and act on Refactoring on WindowHook functions #270
• Close and act on Kernel32.ACCESS_MASK could be more "open" to being extended #271
• Close and act on Methods used in SafeHandles 'ReleaseHandle' should have a ReliabilityContract #203
• Close and act on Enable CA1414 for all projects #50

[AArnott]

Change all ref and out parameters to pointers

This one could use some discussion first, I think. While use of [Friendly] certainly brings back those convenient keywords, if no caller is ever conceivably going to use the pointer version, I'm ok with just using ref or out in the primary definition. For example, if it's a flags enum passed by ref so the method can adjust flags for the caller to see, I can't imagine a pointer would ever be useful in that case. It's just too trivial to think a pointer would be used. But we could certainly review all uses and see if we can get closer to an ideal.
BTW, that probably doesn't need to wait for 2.0. As switching to pointers isn't a breaking change so long as the code generator is applied to recreate the friendly variety.

[NN---]

@arlm Does it mean that I must use pointers in my code to use PInvoke library ?

[arlm]

@NN--- No, the library generates automatically other options for consuming the API without pointers with the use of the [Friendly] attribute during the library codification, which we do on all pointers.

[AArnott]

Correct. So for example wherever you see a pointer, you can use IntPtr. And sometimes char* gets a StringBuilder option, etc.

That said, once I had to write a bit of code twice, once with IntPtr and once with pointers, I found the pointer one was much easier to get right.

[AArnott]

• Close and act on Kernel32 -> Ntdll dependency is opposite what's in Win32 #439
• Consider moving 'common' header file structures/enums as top-level types in the PInvoke namespace instead of nested types. This will make 'promoting' them to Windows.Core or other 'upstream' projects possible with type forwarders.

[AArnott]

• Revise all structs to make sure they are blittable. Blittable types are structs whose fields have no [MarshalAs] attribute and whose type are also blittable.