Style Question

[CaiB]

Hello,

This project looks interesting, but I wanted to ask about one of your general goals moving forward.

From the DirectN readme:

one of its main objective is to use exactly the same names and types than the native concepts

Will this also be the case for DirectNAot, or will there eventually be some transformation of the API names/enums/etc to be more "correct" C# style?

Thanks!

[smourier]

Hi,

Keeping same names and types as native concepts is a still a strong objective, ie: I have zero plan to build DirectN as a full fancy and nice C# object model (like you could have with SharpDX) because:

1) I find that quite counter productive to mask underlying layers, DirectX is already quite complicated, and being able to use exising C/C++ code to write C# corresponding code is very important. That's actually the main reason why I started DirectN, I used SharpDX and couldn't easily match the official doc with the relevant .NET classes. 2) it's a huge amount of work, while using a 95% automatic generator is more reasonable. Hey, we're talking about ~8000 types here. 3) it's not realistically sustainable in the long term (SharpDX is not maintained anymore maybe for these two last reasons, too much work)

That doesn't mean you cannot build nice wrappers over DirectN, in fact I do this, for example: WicNet is a nice C# wrapper over WIC but I keep DirectN "raw" if you will. Wice is also an example of using DirectN for a full .NET-style project.

Also, there are some DXGI, D3D11, D3D12, D2D, MF utilities/extensions in the DirectN.Extensions project. It also contains basic interop addons for COM, memory, etc.

[CaiB]

Thanks for the quick response. Understood.

I can totally understand the reason why you'd want to keep names equal, it definitely would make porting and the generator easier.

I personally value the readability and style of the code (i.e. capitalization, redundant enum prefixes, etc) more highly than having names be exactly the same as native, and find that this other project https://github.com/amerkoleci/Vortice.Win32 achieves a good balance. It doesn't really abstract/objectify anything away, just mostly does some name transformations to fit in a C# environment better. However, it makes no attempt to provide "friendly" wrappers, everything is left as unsafe structs and pointers.

Hence I've been on the lookout for something that is the best of both worlds, C#-style naming conventions, with minimal source generated low-level wrappers that do little more than get away from directly unsafe code. I now understand this doesn't line up with your objectives. Thanks for clarifying.

[smourier]

Yes, I probably know all projects around this, including Vortice, Terrafx, etc, but honestly don't know how they will keep doing this for free (TerraFx is in fact made by a Microsoft guy) on the long term, keeping with changes, etc. and be complete and thorough for all native capabilities (ie: expose everything that can be needed) unless they make a living on it, which I don't think it's the case today.

For example, Vortice doesn't have a C# wrapper over DirectX Shader Reflection API, and this is super useful.

PS: full AOT is a real challenge.

[CaiB]

I find it utterly baffling that Microsoft doesn't publish first-party .NET low-level (LibraryImport, ComWrapper) interop libraries for Win32. To me it feels nearly as important and impactful as providing the C++ headers, given that .NET is seemingly their poster child now.

With it being such a huge task, the OSS options are (very understandably) in eternal churn, never getting to the point where they even feel stable before going unmaintained.

[smourier]

They do now with CsWin32 but IMHO it has its set of issues too, that's why I don't use it (I use a similar system Win32InteropBuilder). But I do use what CsWin32 is based on, which is the invaluable win32metada