Latest bin_tools dlls not working with C#

[Nuklon]

The dlls from 3.4.8 aren't working correctly with C#'s dllimport (the previous versions were OK). All native calls return C#'s default.

[wiresock]

The package found at this link, which was built using Visual Studio 2012, contains the DLL that you had success with previously. It's puzzling why the DLLs built with Visual Studio 2022 do not work properly. I will need to conduct some research to pinpoint the exact problem and find a suitable solution.

[Nuklon]

Thanks, I'll give it a try later. Can you also add arm64 in that version? I don't understand why the VS2022 version doesn't work. Usually .NET runtime gives some error that calling failed, but it's just doing its thing and returning the default (false for bool, 0 for int, etc).

[wiresock]

Visual Studio 2012 lacks the capability to build ARM64 targets. The peculiar behavior of the DLL is also baffling to me. This issue might be connected to whether the Visual Studio runtime is linked dynamically or statically, but I'll need to examine it closely to understand the specifics.

[Nuklon]

If you have an update, I'm interested in it 😁

[wiresock]

The key distinction between the Visual Studio 2012 and Visual Studio 2022 projects centered around string encoding: the former utilized an ANSI string for the OpenFilterDriver parameter, while the latter required a UNICODE string. To address this incompatibility, I have enhanced the ndisapi.net project with a new optional string type parameter, which defaults to UNICODE, aligning with the modern builds of ndisapi.dll.

[Nuklon]

Interesting... but one question remains, why does OpenFilterDriver still return a "valid" handle with the wrong encoding? Isn't the DLL checking whether a driver with the passed in name exists?

[wiresock]

It returns an object that encapsulates the driver handle, irrespective of the driver's presence. To verify its validity, you can invoke the IsDriverLoaded method.

[Nuklon]

It returns an object that encapsulates the driver handle, irrespective of the driver's presence. To verify its validity, you can invoke the IsDriverLoaded method.

That makes little sense. OpenFilterDriver should return a valid handle only if there's a driver present with the given name. On your website: This function opens driver object, but if there's no driver, nothing can be opened?

[wiresock]

I don't usually use ndisapi.net in my projects, so I'm not entirely sure of the best approach. However, if you think it's more semantically appropriate to validate the OpenFilterDriver return object within the Open method itself, you're welcome to propose a change through a pull request.

[Nuklon]

I don't usually use ndisapi.net in my projects, so I'm not entirely sure of the best approach. However, if you think it's more semantically appropriate to validate the OpenFilterDriver return object within the Open method itself, you're welcome to propose a change through a pull request.

I mean a behavior change for the DLL, or do you mean that as well?

[wiresock]

The OpenFilterDriver function inside the DLL is responsible for creating a new CNdisApi object and provides an opaque pointer in return. Given that this implementation has been in place for more than a decade, revising it seems unnecessary and might introduce unforeseen issues.