Add native pointer overloads of methods that accept IntPtr

[AArnott]

IntPtr parameters are harder to deal with than native pointer types (in C# anyway), and they express less in terms of type safety than pointers can.

We should consider changing our policy and code to use pointers instead of IntPtr.

One possibility is that we maintain two overloads of applicable P/Invoke methods: one that takes IntPtr and one that takes pointers, so that folks can call without using unsafe code. I don't have much sympathy for any anxiety over writing unsafe code since it's actually simpler, and partial trust is irrelevant for consumers of this library anyway. So the only reason to keep IntPtr around is for languages that don't support pointers (e.g. Powershell).

• AdvApi32
• BCrypt
• DbgHelp
• Gdi32
• Hid
• ImageHlp
• Kernel32
• NCrypt
• Psapi
• SetupApi
• User32

[AArnott]

CC: @vbfox

[vbfox]

Yes we need a list of all the pro/cons.

On the list of languages :

• ✅ C# (unsafe / T* foo)
• ✅ C++ (T* foo)
• ✅ F# (let foo : nativeptr<'T>)
• ✅ Boo (unsafe foo as T) didn't test myself but they had a unit test about unsafe (Language is now considered dead)
• 🔵 VB.Net
• 🔵 PowerShell
• 🎱 Nemerle (?)
• 🎱 IronSheme (?)
• 🎱 IronPython (?)

✅: Can call pointer exposing method
🔵: Can call IntPtr overload even if pointer version exists
⁉️ Doesn't support the IntPtr overload if the pointer version is present
🎱: Didn't find anythging / not searched

Also for the two overloads solutions it's pretty easy to codegen the IntPtr overloads if we write the pointer ones.

[AArnott]

Can you add a legend for these icons above?

[vbfox]

Ok I differentiated between VB that doesn't allow unsafe but can call the IntPtr version if also present with the same name and languages that support it natively.

Turn out that powershell is able to call an IntPtr version too if it exists (Just tested) with the same name so no problem here either.

Everything seem to point that the dual pointer/IntPtr is the good way to go, but we need to codegen it or it will be problematic pretty fast.

[vbfox]

Also if we decide to go the "dual" way it's not really needed for a 0.x release, as we will only add overloads that aren't compatible and don't risk being picked by previously existing code.
But It would be nice to have that in 1.0 along with some variant of #70.

[AArnott]

Thanks, @vbfox. I agree: let's go for dual mode. Until we have the code gen going, we should at least offer IntPtr versions so we don't block out use by VB.
Presumably when we start code gen that converts IntPtr to pointers, we can remove any manually created pointer overloads.

[AArnott]

I just found out that unsafe code isn't allowed in C# iterator methods. That means that pointers aren't allowed in them, making it less convenient to call these methods even in a language that would otherwise allow it.

[AArnott]

An open question on resolving some of these is what to do about struct fields that are pointers. Should they be IntPtr or a native pointer type? Can we perhaps use native pointers, but offer properties that expose them as IntPtrs for the VB folks?

[AArnott]

Progress on fixing kernel32 is blocked on AArnott/CodeGeneration.Roslyn#1

[jmelosegui]

Well, if we want to be consistent, struct fields should be native pointer types and the codegen should inject property wrappers of those fields.

So I am leaning toward native pointer type and properties that expose them as IntPtrs.

[AArnott]

Agreed.

[AArnott]

#130 tracks the struct fields now.