build.exe to msbuild.exe migration advice

NTDEV
1

Hi,

I just rejoined list after a few years away from NT driver dev… Hi
Tony, Peter, and others that I still know on this list. :slight_smile:

I need to get an open source project, which includes an NT driver[1],
working with Win10 WDK, it was last working with a Win7-era WDK.

There are 2 drivers, one for x86 and one for x64, C and asm.

They are old-style drivers, not UMDF, KMDF, using ntddk.h. The driver is
very simple, it responds to IOCtl requests from user-mode code (a Python
app) and issues specific Intel instructions to get firmware security
data back down to user-mode.

The driver is setup to work with Win7 WDK, using build.exe-style build
files, MAKEFILE and SOURCES.

It appears that the WDK has changed around Win8 to use msbuild.exe-style
build files, an XML format. And rely more on Visual Studio and less on
command lines. :frowning:

I’m trying to find a Win10 WDK sample build file for a simple
ntddk.h-style kernel driver, that I can modify for use for the CHIPSEC
driver. Which WDK sample would you suggest I look at?

Is there a tool I missed that’ll generate the XML build files that
msbuild.exe/Visual Studio require?

I can use latest Visual Studio Community GUI to build, but would prefer
to use a command line to build.

Are people still using Win7 WDKs on Win10 and targetting Win10, to avoid
the migration from build.exe to msbuild.exe?

As you can tell, I missed out on the build.exe->msbuild.exe fun earlier,
this is my first exposure to it. Any advice appreciated.

Thanks,
Lee Fisher

[1] https://github.com/chipsec/chipsec/tree/master/drivers/win7

2

On Sat, Jun 23, 2018 at 4:09 PM, xxxxx@preossec.com wrote:
>
> Hi,
>
> I just rejoined list after a few years away from NT driver dev… Hi
> Tony, Peter, and others that I still know on this list. :slight_smile:
>
> I need to get an open source project, which includes an NT driver[1],
> working with Win10 WDK, it was last working with a Win7-era WDK.
>
> There are 2 drivers, one for x86 and one for x64, C and asm.
>
> They are old-style drivers, not UMDF, KMDF, using ntddk.h. The driver is
> very simple, it responds to IOCtl requests from user-mode code (a Python
> app) and issues specific Intel instructions to get firmware security
> data back down to user-mode.
>
> The driver is setup to work with Win7 WDK, using build.exe-style build
> files, MAKEFILE and SOURCES.
>
> It appears that the WDK has changed around Win8 to use msbuild.exe-style
> build files, an XML format. And rely more on Visual Studio and less on
> command lines. :frowning:
>
> I’m trying to find a Win10 WDK sample build file for a simple
> ntddk.h-style kernel driver, that I can modify for use for the CHIPSEC
> driver. Which WDK sample would you suggest I look at?
>

There should be a previous post of mine that has a (potentially
malformed) XML file I was asking about. No one was able to help.

> Is there a tool I missed that’ll generate the XML build files that
> msbuild.exe/Visual Studio require?
>
> I can use latest Visual Studio Community GUI to build, but would prefer
> to use a command line to build.
>

You will need to install VS at least once, but afterwards you can use the EWDK.

> Are people still using Win7 WDKs on Win10 and targetting Win10, to avoid
> the migration from build.exe to msbuild.exe?
>
> As you can tell, I missed out on the build.exe->msbuild.exe fun earlier,
> this is my first exposure to it. Any advice appreciated.
>

If you go into VS you should be able to create a WDK driver project.
It will give you a solution with (I think) one C file filled with
everything necessary to make a driver which does nothing. But, most
importantly, it will generate an XML file that MSBuild will accept.
The XML format is not documented. After you have this XML file you
should be able to figure out how to add your files to it by hand, but
you could move the existing driver files to the project using the GUI.
That may be easiest.

From here you can give the solution file to the MSBuild supplied with
the EWDK. This is a more easily scriptable interface but still not
great compared to what I was reading about from old tutorials using
the NTDDK circa Windows XP. It seems like all of those tools were
abandoned for some reason.

Depending on when you resubscribed you should be able to see a thread
about better automating toolchain deployments and driver builds. There
is a docker-based solution that may help you. In my case I am trying
to automate deployments to computers (which may then use docker) as
setting this all up is so time consuming and there are hard
requirements for dedicated hardware.

Cheers,
R0b0t1

3

I went through this not long ago and found OSR?s MSBUILD 101 article pretty helpful:
https://www.osr.com/nt-insider/2013-issue1/msbuild-101/

Dave

4

Hi Lee. Always a pleasure to see you ?round these parts.

What R0b0t1 said. Install VS + WDK (use the latest of every thing). Then just use the new project wizard to create an empty WDM driver project. Add your source files. And you should be pretty much done.

AND read that article on MSBUILD that Mr. Ruske mentioned.

Hope that helps,

Peter
OSR
@OSRDrivers

5

Thanks, R0b0t1, Dave, and Peter, for the advise.

Looks like I finally have to learn MSBuild.

I guess I was hoping someone would point out where WDK’s build.exe (and
the other related files) and SDK’s SetEnv.cmd were hidden in Win10,
and/or that DDKbuild had been updated for Win10, so I would not have to
migrate to new build files.

I have yet to figure out EWDK -vs- WDK in build abilities, as well as
the pre-assembled Windows dev VMs that MS is now making available.

If someone is aware of a WDK sample msbuild file of a driver that has an
.asm file (i.e., how to integrate MASM to a msbuild-based WDK build), or
how to do that with MSBuild [via the VS GUI], please let me know.

From the old SOURCES file:
    AMD64_SOURCES=amd64\cpu.asm
    I386_SOURCES=i386\cpu.asm
    SOURCES=driver.c chipsec_hlpr.rc

Thanks,
Lee

6

msbuild works on the vcxproj file so you need to generate one with the
appropriate asm sources. You need to add the asm files to the project file
like this:



Alternatively you can build an example VS project and include the masm file
and then view the corresponding vcxproj to see how it is organized.

The CHIPSEC driver is quite small so perhaps it may be faster to just
create a new driver project in VS and add the files manually.

On Sun, Jun 24, 2018 at 11:42 AM xxxxx@preossec.com
wrote:

> Thanks, R0b0t1, Dave, and Peter, for the advise.
>
> Looks like I finally have to learn MSBuild.
>
> I guess I was hoping someone would point out where WDK’s build.exe (and
> the other related files) and SDK’s SetEnv.cmd were hidden in Win10,
> and/or that DDKbuild had been updated for Win10, so I would not have to
> migrate to new build files.
>
> I have yet to figure out EWDK -vs- WDK in build abilities, as well as
> the pre-assembled Windows dev VMs that MS is now making available.
>
> If someone is aware of a WDK sample msbuild file of a driver that has an
> .asm file (i.e., how to integrate MASM to a msbuild-based WDK build), or
> how to do that with MSBuild [via the VS GUI], please let me know.
>
> From the old SOURCES file:
> AMD64_SOURCES=amd64\cpu.asm
> I386_SOURCES=i386\cpu.asm
> SOURCES=driver.c chipsec_hlpr.rc
>
> Thanks,
> Lee
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

7

Mr. Dang to the rescue!

MY question is: How do I tell VS which of my ASM files is for each given platform (x86 vs x64, for example)?

Peter
OSR
@OSRDrivers

8

Condition=“‘$(Platform)’==‘x64’” ?

On Mon, Jun 25, 2018 at 10:22 AM xxxxx@osr.com
wrote:

>


>
> Mr. Dang to the rescue!
>
> MY question is: How do I tell VS which of my ASM files is for each given
> platform (x86 vs x64, for example)?
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

9

There might be a fancier way to do this, but I’ve used the ExcludedFromBuild
property (there’s a GUI option also). For example, 64-bit ASM file that I
don’t want in the 32-bit build:



Condition=“‘$(Platform)’==‘Win32’”>true

-scott
OSR
@OSRDrivers

10

On Mon, Jun 25, 2018 at 9:36 AM, Scott Noone
wrote:
>


>
> There might be a fancier way to do this, but I’ve used the ExcludedFromBuild
> property (there’s a GUI option also). For example, 64-bit ASM file that I
> don’t want in the 32-bit build:
>
>
>
> > Condition=“‘$(Platform)’==‘Win32’”>true
>
>
>

This is probably the fancier way. What VS does is create larger groups
based on the architecture and bitness tuple. E.g. if you select x86
and ARM you will get 4 groupings, for x86, x86_64, ARM, and ARM64.

The VS method may be easier to maintain - I could see someone coming
into a project and missing a single line like that. It might be a good
idea to call attention to it in source or documentation.

Cheers,
R0b0t1

11

One thing to consider about the VS way is that when you make changes in the GUI, the vcxproj will always be rewritten in the VS pattern, regardless of what you had before for conditionals. Might not be a wholesale file rewrite, but probably the section you worked on by hand :slight_smile:

f

Bent from my phone

From: 30511622200n behalf of
Sent: Monday, June 25, 2018 9:12 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] build.exe to msbuild.exe migration advice

On Mon, Jun 25, 2018 at 9:36 AM, Scott Noone
wrote:
>


>
> There might be a fancier way to do this, but I’ve used the ExcludedFromBuild
> property (there’s a GUI option also). For example, 64-bit ASM file that I
> don’t want in the 32-bit build:
>
>
>
> > Condition=“‘$(Platform)’==‘Win32’”>true
>
>
>

This is probably the fancier way. What VS does is create larger groups
based on the architecture and bitness tuple. E.g. if you select x86
and ARM you will get 4 groupings, for x86, x86_64, ARM, and ARM64.

The VS method may be easier to maintain - I could see someone coming
into a project and missing a single line like that. It might be a good
idea to call attention to it in source or documentation.

Cheers,
R0b0t1

—
NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>