Compiling for NT4

Hi
I’m aware that this topic has been extensively discussed before, however I
could not find in the archives what I was looking for.
In a recent message, Neal Christiansen stated that to build sfilter for NT4
one must not use the recent versions of ntifs.h. I have compiled drivers for
NT4 using the latest ntifs.h, and the only problem I found (other than lack
of useful #defines) was that ExAllocatePoolWithTag do not exists in NT4 and
ExAllocatePool is defined as ExAllocatePoolWithTag for checked builds in
recent versions of ntifs.h. This was easily solved. So my question is: What
are the known problems that make it inconvenient to compile for NT4 with
recent versions of ntifs.h?
Also, out of curiosity, are there known problems that prevent the MS C++
compiler (the one distributed with VS now freely available) from being used
to build drivers? In other words, the decision not to support it, is
motivated by known problems with this compiler?
It would be nice to add files to a VS project without having to modify the
sources file…

Best regards
Jorge

The problem with the VS compiler is that changes on the schedule of the
Visual Studio group. Having run groups that delivered compilers for
building OS’es in the minicomputer days, there is a ton of testing that
needs to be done to validate a compiler is safe to build an OS and is
compatible with previous compilers. Given that fact any sane OS group,
does not try to bless every version of the compiler.

I do know for a fact that a customer of mine was having some weird problems
and in the process of trying to fix them I admonished that they use the DDK
compiler not VS.NET. They decided that this was the right thing to do after
some testing.

If you want VS support, ask Microsoft. I know it is on their list to
consider, if it truly important enough I suspect they will. Of course at
least once I know they asked a group of experts where to rank it vesus a lot
of powerful tools they were considering and it did not get near the top in
that list.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting

“Jorge Lodos” wrote in message news:xxxxx@ntfsd…
> Hi
> I’m aware that this topic has been extensively discussed before, however I
> could not find in the archives what I was looking for.
> In a recent message, Neal Christiansen stated that to build sfilter for
NT4
> one must not use the recent versions of ntifs.h. I have compiled drivers
for
> NT4 using the latest ntifs.h, and the only problem I found (other than
lack
> of useful #defines) was that ExAllocatePoolWithTag do not exists in NT4
and
> ExAllocatePool is defined as ExAllocatePoolWithTag for checked builds in
> recent versions of ntifs.h. This was easily solved. So my question is:
What
> are the known problems that make it inconvenient to compile for NT4 with
> recent versions of ntifs.h?
> Also, out of curiosity, are there known problems that prevent the MS C++
> compiler (the one distributed with VS now freely available) from being
used
> to build drivers? In other words, the decision not to support it, is
> motivated by known problems with this compiler?
> It would be nice to add files to a VS project without having to modify the
> sources file…
>
> Best regards
> Jorge
>
>
>
>

> of useful #defines) was that ExAllocatePoolWithTag do not exists in NT4

It exists. ExFreePoolWithTag does not exist though.

are the known problems that make it inconvenient to compile for NT4 with
recent versions of ntifs.h?

Please use NT4 IFS kit for NT4-compatible binaries.

Also, out of curiosity, are there known problems that prevent the MS C++
compiler (the one distributed with VS now freely available) from being used
to build drivers? In other words, the decision not to support it, is
motivated by known problems with this compiler?

Maybe just because it is not needed at all, and why lose time and ask for
issues for a completely unnecessary thing which gives nothing good?

Use DDKBUILD.BAT if you want to build the huge project from the VS, which also
includes the driver.

It would be nice to add files to a VS project without having to modify the
sources file…

Nothing nice. The same thing absolutely, and editing the build options and
macros in SOURCES is by far simpler then using this multi-tabbed build options
dialog in the VS.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

I agree.

With open source software, there are “stable” and “current” branches, or
odd or even Linux kernel versions.

Looks like MS follows the same path, shipping the “current” compiler with
Visual Studio and “stable” one with SDK/DDK.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Don Burn”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, July 29, 2004 5:00 PM
Subject: Re:[ntfsd] Compiling for NT4

> The problem with the VS compiler is that changes on the schedule of the
> Visual Studio group. Having run groups that delivered compilers for
> building OS’es in the minicomputer days, there is a ton of testing that
> needs to be done to validate a compiler is safe to build an OS and is
> compatible with previous compilers. Given that fact any sane OS group,
> does not try to bless every version of the compiler.
>
> I do know for a fact that a customer of mine was having some weird problems
> and in the process of trying to fix them I admonished that they use the DDK
> compiler not VS.NET. They decided that this was the right thing to do after
> some testing.
>
> If you want VS support, ask Microsoft. I know it is on their list to
> consider, if it truly important enough I suspect they will. Of course at
> least once I know they asked a group of experts where to rank it vesus a lot
> of powerful tools they were considering and it did not get near the top in
> that list.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>
>
>
> “Jorge Lodos” wrote in message news:xxxxx@ntfsd…
> > Hi
> > I’m aware that this topic has been extensively discussed before, however I
> > could not find in the archives what I was looking for.
> > In a recent message, Neal Christiansen stated that to build sfilter for
> NT4
> > one must not use the recent versions of ntifs.h. I have compiled drivers
> for
> > NT4 using the latest ntifs.h, and the only problem I found (other than
> lack
> > of useful #defines) was that ExAllocatePoolWithTag do not exists in NT4
> and
> > ExAllocatePool is defined as ExAllocatePoolWithTag for checked builds in
> > recent versions of ntifs.h. This was easily solved. So my question is:
> What
> > are the known problems that make it inconvenient to compile for NT4 with
> > recent versions of ntifs.h?
> > Also, out of curiosity, are there known problems that prevent the MS C++
> > compiler (the one distributed with VS now freely available) from being
> used
> > to build drivers? In other words, the decision not to support it, is
> > motivated by known problems with this compiler?
> > It would be nice to add files to a VS project without having to modify the
> > sources file…
> >
> > Best regards
> > Jorge
> >
> >
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

For those who will read this thread in the future, it is of course
ExFreePoolWithTag the function that does not exist in NT. Thanks Maxim, for
your correction.
To compile for NT4 with the latest ntifs.h we do:

// ExFreePoolWithTag does not exist in NT4.
#if (_WIN32_WINNT < 0x0500)
// ExFreePool is defined to ExFreePoolWithTag in w2k3 ntifs.h
// if pool tagging is enabled.
#undef ExFreePool
#define ExFreePoolWithTag( a, b ) ExFreePool( (a) )
#endif

You must link with NT4 libraries, as explained very well somewhere else in
the archives.

Regarding this:

> It would be nice to add files to a VS project without having to modify
the
> sources file…

Nothing nice. The same thing absolutely, and editing the build options and
macros in SOURCES is by far simpler then using this multi-tabbed build
options dialog in the VS.

Even without questioning “the same thing” or “simpler”, which depend on each
one preferences, the problem is that you have to do it twice. One in the
sources, the other in the IDE. DDKBuid.bat does not solve this problem. We
have tools to convert from sources to VC projects, but I’m not aware of any
to do the opposite.

Best regards
Jorge

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, July 29, 2004 11:31 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Compiling for NT4

of useful #defines) was that ExAllocatePoolWithTag do not exists in NT4

It exists. ExFreePoolWithTag does not exist though.

are the known problems that make it inconvenient to compile for NT4 with
recent versions of ntifs.h?

Please use NT4 IFS kit for NT4-compatible binaries.

Also, out of curiosity, are there known problems that prevent the MS C++
compiler (the one distributed with VS now freely available) from being
used
to build drivers? In other words, the decision not to support it, is
motivated by known problems with this compiler?

Maybe just because it is not needed at all, and why lose time and ask for
issues for a completely unnecessary thing which gives nothing good?

Use DDKBUILD.BAT if you want to build the huge project from the VS, which
also
includes the driver.

It would be nice to add files to a VS project without having to modify the
sources file…

Nothing nice. The same thing absolutely, and editing the build options and
macros in SOURCES is by far simpler then using this multi-tabbed build
options
dialog in the VS.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@segurmatica.com
To unsubscribe send a blank email to xxxxx@lists.osr.com