how to compile NDIS using mingw,

I want to use layer 2 to create and receive raw sockets on a network adapter on my laptop. Yet I do not want to use Visual Studio… It is not my favorite… Are there header files for ndis to be compiled using mingw32 or 64 ? ndis 6.0+ is preffered, and I would also look for ndis 5.1 for NT family, (if the code syntax doesnt change, I can compile for both.)
Thank you in advance

I do not know where to start which ndis on mingw(gcc), if there is any files you can forward me with sample startup codes, would be appreciated.

You don’t have to use the IDE. I never run the Visual Studio IDE – I do all my editing in gvim or VSCode, and then compile on the command line. Really, you don’t want to use another compiler. Microsoft does not support drivers compiled with other compilers, so if you file a support event that ends up being compiler-related, they won’t help.

@Tim_Roberts Thank you for the answer. what compiler do you use ? do you use mingw as well? if you don’t mind sharing, what would an example command of your compilation?
such as gcc myDriver.c -lndis or something like that ?

also any tips on where i can get ddk/ ndis headers for mingw 32/64 bits… thank you very much

I also found this library by Jeffrey Tippet, what would be a sample compilation command by mingw using this. Seems a very good one https://github.com/microsoft/ndis-driver-library

I don’t use gcc because, as I said, Microsoft doesn’t support it. I use the Visual Studio compilers. I just don’t use the IDE.

User the EWDK toolchain. It is specifically geared toward command line builds, it is free, etc. As Tim said, the only supported compilers are the microsoft ones., and as he noted vscode is free and super easy top get to work with the EWDK. You are just going to increase the cost/effort to do whatever it is you are trying to do by at least a factor of 10, and then it will likely never work correctly anyway.

@Mark_Roddy Is there any tutorial on where to get started, because I can’t find useful source for this subject… It is like I can write code but I cannot compile them. That is why I asked for a sample command line to compile NDIS. EWDK comes with VS components, yes ? what do I need to do to compile my template (from command line)? Do you ever use cmake ?Thank you for all the help @Tim_Roberts @Mark_Roddy

The EWDK comes with the Visual C++ toolchain, compilers, includes, and libraries, but not the IDE.

cmake is perfectly happy to create Visual Studio project files, but typical driver projects vary only slightly from each other. Once you have a project file that works, you can just edit that one for the slight differences. Just type “msbuild” at a command line.

A numeric comparison was attempted on “$(_NT_TARGET_VERSION)” that evaluates to “” instead of a number, in condition "$(_NT_TARGET_VERSION) < $(_NT_TARGET_VERSION_WIN7)

I try to compile https://github.com/microsoft/Windows-driver-samples/tree/main/network/ndis/filter this with msbuild, hence I get the error above, is it due to missing libraries, or something else ?

My Command: msbuild.exe ndislwf.vcxproj /t:build /p:TargetVersion=“Windows10”

Thanks for all the help…

also, in this link, it says WDK requires visual studio and EWDK doesn’t apparently. https://learn.microsoft.com/tr-tr/windows-hardware/drivers/download-the-wdk

Insight question, why is it that, EWDK is 15 GB whereas WDK is only 2? Also it says, Mount the ISO file for EWDK, where do I mount it exactly? @Mark_Roddy

Thank you for giving me start push.

The ‘WDK’ is not a full tool chain, it is an extension to the full visual studio tool chain. The EWDK is a full toolchain without support for the VS IDE and C#.
You can mount an iso file on a windows system using a lot of different methods. Here is how to do it with powershell:

$iso = "C:\Users\foo\Downloads\EWDK_vb_release_svc_prod1_19041_201201-2105.iso"
$vol = mount-diskimage -ImagePath $iso -PassThru
(Get-DiskImage -DevicePath $vol.DevicePath | Get-Volume).DriveLetter
1 Like

This thread points out just how awful the EWDK documentation is. It’s too bad as it really is, in my opinion, a much better way to build drivers. No mystery updates, no massive bloat, easy to build identically on dev and build systems, simple to switch to new versions, easy to integrate into VSCode.

@turmuka you need to have a whole set of environment variables set before your build from the command line will work. Unfortunately the EWDK does not support powershell directly, so you need to use the awful DOS command shell and run ‘LaunchBuildEnv.cmd’ from the root of the EWDK volume first, then you should be able to run ‘msbuild.exe ndislwf.vcxproj /t:build /p:TargetVersion=“Windows10”’ and not have it fail. (Actually that ‘/p:TargetVersion=“Windows10”’ looks wrong to me.)

Someday I’ll make my buildtools repo on github public. Sigh…

2 Likes

@Mark_Roddy said:

@turmuka you need to have a whole set of environment variables set before your build from the command line will work. Unfortunately the EWDK does not support powershell directly, so you need to use the awful DOS command shell and run ‘LaunchBuildEnv.cmd’ from the root of the EWDK volume first, then you should be able to run ‘msbuild.exe ndislwf.vcxproj /t:build /p:TargetVersion=“Windows10”’ and not have it fail. (Actually that ‘/p:TargetVersion=“Windows10”’ looks wrong to me.)

All true, though you can mitigate that a bit by running powershell (or better yet, pwsh) from the resulting CMD and get the best of both worlds …

Phil Barila
Not speaking for AMD

It’s worth pointing out that, if you have the time, all of the driver documentation is in a git repository, and they accept pull requests with improvements. I’ve had a number of my suggested rewrites merged in, and rather quickly.

It’s too bad as it really is, in my opinion, a much better way to build drivers

And, even better… If you’re one of those (like me) who are inclined to use Visual Studio, I’ve been told that you can use it from within the EWDK environment… I’ve been meaning to try this and write a blog post about it.

I have friends a MSFT who SWEAR this is THE best way to write drivers.