jaredpar / pinvoke-interop-assistant Goto Github PK

Some #defines are left out of the C# result code produced by sigimp.exe. Among them are:

• STATUS_INVALID_HANDLE
• STATUS_NO_MEMORY

These defines look similar to others that aren't dropped. So I don't know why these are dropped, or how many others are.

Many of the APIs have the following pattern:

• TryGet
• TryGetOrLoad

The distinction is mostly uninteresting. Need to remove it.

what to do when structure uses types from stdint.h

// Warning: <unknown> 1-2: Could not locate include file stdint.h
// Error: Failed to resolve name 'int32_t'

Try translating this struct:

typedef struct
{
	unsigned long Layer : 8;
	unsigned long Event : 8;
	unsigned long Outbound : 1;
	unsigned long Loopback : 1;
	unsigned long Impostor : 1;
	unsigned long IPv6 : 1;
	unsigned long PseudoIPChecksum : 1;
	unsigned long PseudoTCPChecksum : 1;
	unsigned long PseudoUDPChecksum : 1;
	unsigned long Reserved : 41;
} LOL;

It will make the program eat gigs and gigs of memory, ever increasing till out of memory.

The #region directives have their place but in this code base I abused them quite a bit. Need to get rid of the regions and split code files up appropriately.

I want to pull this into https://github.com/quozd/awesome-dotnet/ but same time I want to pull https://github.com/AArnott/pinvoke

Application generates this marshal : UnmanagedType.LPStr

I had to make a custom Marshaler like in this thread to get it to work:
Why can't I return a char* string from C++ to C#

Hope this will be implemented in the future.

This project was started right as I was joining the Visual Basic Language team. In many ways I used this as a tool to help me learn the language and get involved in my team. I had a ton of fun doing it and it did teach me a lot about the language.

Over the years though it's become apparent that the chance of community participation here will increase if the code is C#. Not because of any issues with VB, but instead because this is a very low level area of .Net. Developers who are interested in this tend to be working in C# already and it's a more natural fit for this code base. Hence I decided to take a bit of time and port the logic over to C#.

Port Status:

• PInvoke
• PInvokeTests
• StorageGenerator

This is causing the symbols to be hard wired to a XSD storage mechanism. Need this to be more flexible.

I suggest to at least create a release that includes the last version before moved to github (ideally by tagging the imported version, if it is identical) and one newer one that is considered to work (or is even considered to be stable).

The postbuild script needs double quotes around both filenames to support spaces in filenames.

The NativeEnum type is highly special cased by the code base compared to other global symbols. The code base treats it as a container but in reality the values contained within it are global (in C enum doesn't introduce a scope).

No other global symbol has a container and it creates an odd problem to deal with in the code base. When adding a NativeEnum to a container do you either:

1. Add the NativeEnum only and do nothing with the nested NativeEnumValue members.
2. Add the NativeEnum and all NativeEnumValue members.

The code base today chooses the second option. Ideally it should be the first but it's much too hard to work through at the moment (creates some deeper API problems). Will come back to it later.

The core library contains a large mix of components that really need to be broken up to make it easier to consume. In particular it should probably be broken up into three parts:

• PInvoke.Core: all parsing and type resolution logic
• PInvoke.CodeDom: portion of parser which spits out to CodeDom
• PInvoke.Controls: the WinForm controls

Hello! What's the license of:

• the code in this project,
• the database files with the list of the APIs? (i.e. StorageGenerator/Data/*)

Should be straight forward. Need to get it done in order to help validate PRs.

A chocolatey package to help installing/distribution would be helpful.