v2 activities and refactorings

dotnet / pinvoke

A library containing all P/Invoke code so you don't have to import it every time. Maintained and updated to support the latest Windows OS.

MIT License

2.12k stars 222 forks source link

v2 activities and refactorings #288

Closed arlm closed 1 year ago

arlm commented 8 years ago

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 commented 8 years ago

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

arlm commented 8 years ago

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 #272
[ ] Close and act on #270
[ ] Close and act on #271
[ ] Close and act on #203
[ ] Close and act on #50

AArnott commented 8 years ago

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--- commented 7 years ago

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

arlm commented 7 years ago

@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 commented 7 years ago

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 commented 4 years ago

[ ] Close and act on #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 commented 4 years ago

[ ] 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.