Is there any way to avoid compiling two FS drivers for 2k and XP? Should a
XP ddk compiled FS driver work in 2k?
Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
linker and do the compilers(VS.NET 2003 and DDK build 3790) now come from
seperated sources?
Thanks for any input?
There is no guarantee that an XP compiled kernel component will work on an
earlier platform.
You might be able to build your w2k FS driver to work on either platform,
but you would get a better answer from NTFSD.
The simple answer is YES you have to use the ddk compiler, and no the
current ddk supplies one version of the compilation tools that are
documented as working for w2k/xp/w2k3. Of course you could probably hack
together some other build system that didn’t use any of the tools, but why
would you do that?
-----Original Message-----
From: Gerg [mailto:xxxxx@hotmail.com]
Sent: Friday, May 23, 2003 11:26 AM
To: NT Developers Interest List
Subject: [ntdev] XP DDK Compiling
Is there any way to avoid compiling two FS drivers for 2k and XP? Should a
XP ddk compiled FS driver work in 2k?
Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
linker and do the compilers(VS.NET 2003 and DDK build 3790) now come from
seperated sources?
Thanks for any input?
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
I don’t really know why the DDK team decided that branching the comiplers
would give them a positive return on their investment?
It also seems that the build utility has changed a bit from build 2600 to
3790. This is a minor pain…
----- Original Message -----
From: “Roddy, Mark”
To: “NT Developers Interest List”
Sent: Friday, May 23, 2003 8:37 AM
Subject: [ntdev] RE: XP DDK Compiling
> There is no guarantee that an XP compiled kernel component will work on an
> earlier platform.
> You might be able to build your w2k FS driver to work on either platform,
> but you would get a better answer from NTFSD.
>
> The simple answer is YES you have to use the ddk compiler, and no the
> current ddk supplies one version of the compilation tools that are
> documented as working for w2k/xp/w2k3. Of course you could probably hack
> together some other build system that didn’t use any of the tools, but why
> would you do that?
>
> -----Original Message-----
> From: Gerg [mailto:xxxxx@hotmail.com]
> Sent: Friday, May 23, 2003 11:26 AM
> To: NT Developers Interest List
> Subject: [ntdev] XP DDK Compiling
>
>
> Is there any way to avoid compiling two FS drivers for 2k and XP? Should
a
> XP ddk compiled FS driver work in 2k?
>
> Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
> linker and do the compilers(VS.NET 2003 and DDK build 3790) now come from
> seperated sources?
>
> Thanks for any input?
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
I don’t think it was ‘branching’ exactly, more like a snapshot of the VS
compilation tools was frozen as the ‘kernel development toolset’. The
kernel/ddk team do not develop the compilation tools. At any rate, I think
it was a hugely positive step to end the uncontrolled ad hoc mixing of
various versions of the VS compiler and various versions of the DDK. The
build process prior to the XP ddk was simply out of control, and did not
guarantee correct results.
The endless minor semi-documented changes to the build environment are
indeed a major pain the butt.
-----Original Message-----
From: Gerg [mailto:xxxxx@hotmail.com]
Sent: Friday, May 23, 2003 12:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling
I don’t really know why the DDK team decided that branching the comiplers
would give them a positive return on their investment?
It also seems that the build utility has changed a bit from build 2600 to
3790. This is a minor pain…
----- Original Message -----
From: “Roddy, Mark”
To: “NT Developers Interest List”
Sent: Friday, May 23, 2003 8:37 AM
Subject: [ntdev] RE: XP DDK Compiling
> There is no guarantee that an XP compiled kernel component will work
> on an earlier platform. You might be able to build your w2k FS driver
> to work on either platform, but you would get a better answer from
> NTFSD.
>
> The simple answer is YES you have to use the ddk compiler, and no the
> current ddk supplies one version of the compilation tools that are
> documented as working for w2k/xp/w2k3. Of course you could probably
> hack together some other build system that didn’t use any of the
> tools, but why would you do that?
>
> -----Original Message-----
> From: Gerg [mailto:xxxxx@hotmail.com]
> Sent: Friday, May 23, 2003 11:26 AM
> To: NT Developers Interest List
> Subject: [ntdev] XP DDK Compiling
>
>
> Is there any way to avoid compiling two FS drivers for 2k and XP?
> Should
a
> XP ddk compiled FS driver work in 2k?
>
> Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
> linker and do the compilers(VS.NET 2003 and DDK build 3790) now come
> from seperated sources?
>
> Thanks for any input?
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Well “freezing” does make sense.
1 change in build utility:
“BROWSER_INFO=1” in sources no longer generates bsc files
----- Original Message -----
From: “Roddy, Mark”
To: “NT Developers Interest List”
Sent: Friday, May 23, 2003 9:43 AM
Subject: [ntdev] RE: XP DDK Compiling
> I don’t think it was ‘branching’ exactly, more like a snapshot of the VS
> compilation tools was frozen as the ‘kernel development toolset’. The
> kernel/ddk team do not develop the compilation tools. At any rate, I think
> it was a hugely positive step to end the uncontrolled ad hoc mixing of
> various versions of the VS compiler and various versions of the DDK. The
> build process prior to the XP ddk was simply out of control, and did not
> guarantee correct results.
>
> The endless minor semi-documented changes to the build environment are
> indeed a major pain the butt.
>
> -----Original Message-----
> From: Gerg [mailto:xxxxx@hotmail.com]
> Sent: Friday, May 23, 2003 12:27 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: XP DDK Compiling
>
>
> I don’t really know why the DDK team decided that branching the comiplers
> would give them a positive return on their investment?
>
> It also seems that the build utility has changed a bit from build 2600 to
> 3790. This is a minor pain…
>
>
> ----- Original Message -----
> From: “Roddy, Mark”
> To: “NT Developers Interest List”
> Sent: Friday, May 23, 2003 8:37 AM
> Subject: [ntdev] RE: XP DDK Compiling
>
>
> > There is no guarantee that an XP compiled kernel component will work
> > on an earlier platform. You might be able to build your w2k FS driver
> > to work on either platform, but you would get a better answer from
> > NTFSD.
> >
> > The simple answer is YES you have to use the ddk compiler, and no the
> > current ddk supplies one version of the compilation tools that are
> > documented as working for w2k/xp/w2k3. Of course you could probably
> > hack together some other build system that didn’t use any of the
> > tools, but why would you do that?
> >
> > -----Original Message-----
> > From: Gerg [mailto:xxxxx@hotmail.com]
> > Sent: Friday, May 23, 2003 11:26 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] XP DDK Compiling
> >
> >
> > Is there any way to avoid compiling two FS drivers for 2k and XP?
> > Should
> a
> > XP ddk compiled FS driver work in 2k?
> >
> > Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
> > linker and do the compilers(VS.NET 2003 and DDK build 3790) now come
> > from seperated sources?
> >
> > Thanks for any input?
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
You know, this is not a compiler issue, or at least it shouldn’t be. A
compiler generates machine code, period ! The issue is controlling the API,
and well, when we get to the point where we demand one particular version of
a compiler or else, gee whiz, I wonder if it isn’t time to restructure the
whole thing. Ideally a driver should compile and build under any compiler,
heck, that’s why we have standards in place, no ?
Alberto
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Friday, May 23, 2003 12:43 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling
I don’t think it was ‘branching’ exactly, more like a snapshot of the VS
compilation tools was frozen as the ‘kernel development toolset’. The
kernel/ddk team do not develop the compilation tools. At any rate, I think
it was a hugely positive step to end the uncontrolled ad hoc mixing of
various versions of the VS compiler and various versions of the DDK. The
build process prior to the XP ddk was simply out of control, and did not
guarantee correct results.
The endless minor semi-documented changes to the build environment are
indeed a major pain the butt.
-----Original Message-----
From: Gerg [mailto:xxxxx@hotmail.com]
Sent: Friday, May 23, 2003 12:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling
I don’t really know why the DDK team decided that branching the comiplers
would give them a positive return on their investment?
It also seems that the build utility has changed a bit from build 2600 to
3790. This is a minor pain…
----- Original Message -----
From: “Roddy, Mark”
To: “NT Developers Interest List”
Sent: Friday, May 23, 2003 8:37 AM
Subject: [ntdev] RE: XP DDK Compiling
> There is no guarantee that an XP compiled kernel component will work
> on an earlier platform. You might be able to build your w2k FS driver
> to work on either platform, but you would get a better answer from
> NTFSD.
>
> The simple answer is YES you have to use the ddk compiler, and no the
> current ddk supplies one version of the compilation tools that are
> documented as working for w2k/xp/w2k3. Of course you could probably
> hack together some other build system that didn’t use any of the
> tools, but why would you do that?
>
> -----Original Message-----
> From: Gerg [mailto:xxxxx@hotmail.com]
> Sent: Friday, May 23, 2003 11:26 AM
> To: NT Developers Interest List
> Subject: [ntdev] XP DDK Compiling
>
>
> Is there any way to avoid compiling two FS drivers for 2k and XP?
> Should
a
> XP ddk compiled FS driver work in 2k?
>
> Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
> linker and do the compilers(VS.NET 2003 and DDK build 3790) now come
> from seperated sources?
>
> Thanks for any input?
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
The question of compilers isn’t necessarily that simple. For example,
optimization may be more or less safe and so more or less suitable for
use in kernel routines. Next, there may be intrinsics developed
specifically for the kernel environment and not likely to be of much
value elsewhere; _byteswap_ulong is probably one such.
I admit that compiler behavior in creating kernel executables can, even
in cases like the above, be constrained by parameters that the build
process sets up. But maybe it’s a little bit safer to hardcode some
parameters into a special distribution of a general-purpose compiler.
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
It does for me. With or without Mark’s ddkbuild.
Philip D. Barila
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
“Gerg” wrote in message news:xxxxx@ntdev…
>
> Well “freezing” does make sense.
>
> 1 change in build utility:
> “BROWSER_INFO=1” in sources no longer generates bsc files
> ----- Original Message -----
> From: “Roddy, Mark”
> To: “NT Developers Interest List”
> Sent: Friday, May 23, 2003 9:43 AM
> Subject: [ntdev] RE: XP DDK Compiling
>
>
> > I don’t think it was ‘branching’ exactly, more like a snapshot of the VS
> > compilation tools was frozen as the ‘kernel development toolset’. The
> > kernel/ddk team do not develop the compilation tools. At any rate, I
think
> > it was a hugely positive step to end the uncontrolled ad hoc mixing of
> > various versions of the VS compiler and various versions of the DDK. The
> > build process prior to the XP ddk was simply out of control, and did not
> > guarantee correct results.
> >
> > The endless minor semi-documented changes to the build environment are
> > indeed a major pain the butt.
> >
> > -----Original Message-----
> > From: Gerg [mailto:xxxxx@hotmail.com]
> > Sent: Friday, May 23, 2003 12:27 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: XP DDK Compiling
> >
> >
> > I don’t really know why the DDK team decided that branching the
comiplers
> > would give them a positive return on their investment?
> >
> > It also seems that the build utility has changed a bit from build 2600
to
> > 3790. This is a minor pain…
> >
> >
> > ----- Original Message -----
> > From: “Roddy, Mark”
> > To: “NT Developers Interest List”
> > Sent: Friday, May 23, 2003 8:37 AM
> > Subject: [ntdev] RE: XP DDK Compiling
> >
> >
> > > There is no guarantee that an XP compiled kernel component will work
> > > on an earlier platform. You might be able to build your w2k FS driver
> > > to work on either platform, but you would get a better answer from
> > > NTFSD.
> > >
> > > The simple answer is YES you have to use the ddk compiler, and no the
> > > current ddk supplies one version of the compilation tools that are
> > > documented as working for w2k/xp/w2k3. Of course you could probably
> > > hack together some other build system that didn’t use any of the
> > > tools, but why would you do that?
> > >
> > > -----Original Message-----
> > > From: Gerg [mailto:xxxxx@hotmail.com]
> > > Sent: Friday, May 23, 2003 11:26 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] XP DDK Compiling
> > >
> > >
> > > Is there any way to avoid compiling two FS drivers for 2k and XP?
> > > Should
> > a
> > > XP ddk compiled FS driver work in 2k?
> > >
> > > Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
> > > linker and do the compilers(VS.NET 2003 and DDK build 3790) now come
> > > from seperated sources?
> > >
> > > Thanks for any input?
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
It still works if you put a copy of the program that creates the BSC
files where the DDK can find it. This has been discussed before in this
list.
----- Original Message -----
From: “Gerg”
To: “NT Developers Interest List”
Sent: Friday, May 23, 2003 1:06 PM
Subject: [ntdev] RE: XP DDK Compiling
> Well “freezing” does make sense.
>
> 1 change in build utility:
> “BROWSER_INFO=1” in sources no longer generates bsc files
> ----- Original Message -----
> From: “Roddy, Mark”
> To: “NT Developers Interest List”
> Sent: Friday, May 23, 2003 9:43 AM
> Subject: [ntdev] RE: XP DDK Compiling
>
>
> > I don’t think it was ‘branching’ exactly, more like a snapshot of
the VS
> > compilation tools was frozen as the ‘kernel development toolset’.
The
> > kernel/ddk team do not develop the compilation tools. At any rate, I
think
> > it was a hugely positive step to end the uncontrolled ad hoc mixing
of
> > various versions of the VS compiler and various versions of the DDK.
The
> > build process prior to the XP ddk was simply out of control, and did
not
> > guarantee correct results.
> >
> > The endless minor semi-documented changes to the build environment
are
> > indeed a major pain the butt.
> >
> > -----Original Message-----
> > From: Gerg [mailto:xxxxx@hotmail.com]
> > Sent: Friday, May 23, 2003 12:27 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: XP DDK Compiling
> >
> >
> > I don’t really know why the DDK team decided that branching the
comiplers
> > would give them a positive return on their investment?
> >
> > It also seems that the build utility has changed a bit from build
2600 to
> > 3790. This is a minor pain…
> >
> >
> > ----- Original Message -----
> > From: “Roddy, Mark”
> > To: “NT Developers Interest List”
> > Sent: Friday, May 23, 2003 8:37 AM
> > Subject: [ntdev] RE: XP DDK Compiling
> >
> >
> > > There is no guarantee that an XP compiled kernel component will
work
> > > on an earlier platform. You might be able to build your w2k FS
driver
> > > to work on either platform, but you would get a better answer from
> > > NTFSD.
> > >
> > > The simple answer is YES you have to use the ddk compiler, and no
the
> > > current ddk supplies one version of the compilation tools that are
> > > documented as working for w2k/xp/w2k3. Of course you could
probably
> > > hack together some other build system that didn’t use any of the
> > > tools, but why would you do that?
> > >
> > > -----Original Message-----
> > > From: Gerg [mailto:xxxxx@hotmail.com]
> > > Sent: Friday, May 23, 2003 11:26 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] XP DDK Compiling
> > >
> > >
> > > Is there any way to avoid compiling two FS drivers for 2k and XP?
> > > Should
> > a
> > > XP ddk compiled FS driver work in 2k?
> > >
> > > Finally for ddk build 3790 does one HAVE to use the DDK’s compiler
and
> > > linker and do the compilers(VS.NET 2003 and DDK build 3790) now
come
> > > from seperated sources?
> > >
> > > Thanks for any input?
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@stratus.com
To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Alberto,
The issue of which compiler to use has been beaten to death on this list. We
already know where you stand on it.
Jim A
From: “Moreira, Alberto”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: XP DDK Compiling
>Date: Fri, 23 May 2003 13:06:56 -0400
>
>You know, this is not a compiler issue, or at least it shouldn’t be. A
>compiler generates machine code, period ! The issue is controlling the API,
>and well, when we get to the point where we demand one particular version
>of
>a compiler or else, gee whiz, I wonder if it isn’t time to restructure the
>whole thing. Ideally a driver should compile and build under any compiler,
>heck, that’s why we have standards in place, no ?
>
>Alberto
>
>
>-----Original Message-----
>From: Roddy, Mark [mailto:xxxxx@stratus.com]
>Sent: Friday, May 23, 2003 12:43 PM
>To: NT Developers Interest List
>Subject: [ntdev] RE: XP DDK Compiling
>
>
>I don’t think it was ‘branching’ exactly, more like a snapshot of the VS
>compilation tools was frozen as the ‘kernel development toolset’. The
>kernel/ddk team do not develop the compilation tools. At any rate, I think
>it was a hugely positive step to end the uncontrolled ad hoc mixing of
>various versions of the VS compiler and various versions of the DDK. The
>build process prior to the XP ddk was simply out of control, and did not
>guarantee correct results.
>
>The endless minor semi-documented changes to the build environment are
>indeed a major pain the butt.
>
>-----Original Message-----
>From: Gerg [mailto:xxxxx@hotmail.com]
>Sent: Friday, May 23, 2003 12:27 PM
>To: NT Developers Interest List
>Subject: [ntdev] RE: XP DDK Compiling
>
>
>I don’t really know why the DDK team decided that branching the comiplers
>would give them a positive return on their investment?
>
>It also seems that the build utility has changed a bit from build 2600 to
>3790. This is a minor pain…
>
>
>----- Original Message -----
>From: “Roddy, Mark”
>To: “NT Developers Interest List”
>Sent: Friday, May 23, 2003 8:37 AM
>Subject: [ntdev] RE: XP DDK Compiling
>
>
> > There is no guarantee that an XP compiled kernel component will work
> > on an earlier platform. You might be able to build your w2k FS driver
> > to work on either platform, but you would get a better answer from
> > NTFSD.
> >
> > The simple answer is YES you have to use the ddk compiler, and no the
> > current ddk supplies one version of the compilation tools that are
> > documented as working for w2k/xp/w2k3. Of course you could probably
> > hack together some other build system that didn’t use any of the
> > tools, but why would you do that?
> >
> > -----Original Message-----
> > From: Gerg [mailto:xxxxx@hotmail.com]
> > Sent: Friday, May 23, 2003 11:26 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] XP DDK Compiling
> >
> >
> > Is there any way to avoid compiling two FS drivers for 2k and XP?
> > Should
>a
> > XP ddk compiled FS driver work in 2k?
> >
> > Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
> > linker and do the compilers(VS.NET 2003 and DDK build 3790) now come
> > from seperated sources?
> >
> > Thanks for any input?
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@stratus.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@compuware.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>The contents of this e-mail are intended for the named addressee only. It
>contains information that may be confidential. Unless you are the named
>addressee or an authorized designee, you may not copy or use it, or
>disclose
>it to anyone else. If you received it in error please notify us immediately
>and then destroy it.
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
The issue is not which compiler to use. The issue is the looseness of the
API. As I see it, every driver should be compiled with the ANSI-strict
switch on. Needing a specific compiler to build a program - ANY compiler and
ANY program - is a sign of weakness of the ennvironment.
Alberto.
-----Original Message-----
From: James A [mailto:xxxxx@hotmail.com]
Sent: Friday, May 23, 2003 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling
Alberto,
The issue of which compiler to use has been beaten to death on this list. We
already know where you stand on it.
Jim A
From: “Moreira, Alberto”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] RE: XP DDK Compiling
>Date: Fri, 23 May 2003 13:06:56 -0400
>
>You know, this is not a compiler issue, or at least it shouldn’t be. A
>compiler generates machine code, period ! The issue is controlling the API,
>and well, when we get to the point where we demand one particular version
>of
>a compiler or else, gee whiz, I wonder if it isn’t time to restructure the
>whole thing. Ideally a driver should compile and build under any compiler,
>heck, that’s why we have standards in place, no ?
>
>Alberto
>
>
>-----Original Message-----
>From: Roddy, Mark [mailto:xxxxx@stratus.com]
>Sent: Friday, May 23, 2003 12:43 PM
>To: NT Developers Interest List
>Subject: [ntdev] RE: XP DDK Compiling
>
>
>I don’t think it was ‘branching’ exactly, more like a snapshot of the VS
>compilation tools was frozen as the ‘kernel development toolset’. The
>kernel/ddk team do not develop the compilation tools. At any rate, I think
>it was a hugely positive step to end the uncontrolled ad hoc mixing of
>various versions of the VS compiler and various versions of the DDK. The
>build process prior to the XP ddk was simply out of control, and did not
>guarantee correct results.
>
>The endless minor semi-documented changes to the build environment are
>indeed a major pain the butt.
>
>-----Original Message-----
>From: Gerg [mailto:xxxxx@hotmail.com]
>Sent: Friday, May 23, 2003 12:27 PM
>To: NT Developers Interest List
>Subject: [ntdev] RE: XP DDK Compiling
>
>
>I don’t really know why the DDK team decided that branching the comiplers
>would give them a positive return on their investment?
>
>It also seems that the build utility has changed a bit from build 2600 to
>3790. This is a minor pain…
>
>
>----- Original Message -----
>From: “Roddy, Mark”
>To: “NT Developers Interest List”
>Sent: Friday, May 23, 2003 8:37 AM
>Subject: [ntdev] RE: XP DDK Compiling
>
>
> > There is no guarantee that an XP compiled kernel component will work
> > on an earlier platform. You might be able to build your w2k FS driver
> > to work on either platform, but you would get a better answer from
> > NTFSD.
> >
> > The simple answer is YES you have to use the ddk compiler, and no the
> > current ddk supplies one version of the compilation tools that are
> > documented as working for w2k/xp/w2k3. Of course you could probably
> > hack together some other build system that didn’t use any of the
> > tools, but why would you do that?
> >
> > -----Original Message-----
> > From: Gerg [mailto:xxxxx@hotmail.com]
> > Sent: Friday, May 23, 2003 11:26 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] XP DDK Compiling
> >
> >
> > Is there any way to avoid compiling two FS drivers for 2k and XP?
> > Should
>a
> > XP ddk compiled FS driver work in 2k?
> >
> > Finally for ddk build 3790 does one HAVE to use the DDK’s compiler and
> > linker and do the compilers(VS.NET 2003 and DDK build 3790) now come
> > from seperated sources?
> >
> > Thanks for any input?
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@stratus.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@compuware.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>The contents of this e-mail are intended for the named addressee only. It
>contains information that may be confidential. Unless you are the named
>addressee or an authorized designee, you may not copy or use it, or
>disclose
>it to anyone else. If you received it in error please notify us immediately
>and then destroy it.
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
I agree. The various undocumented compiler and linker switches needed to
build a driver with the Microsoft compiler trouble me. I’m the kind of
engineer who wants to know EXACTLY what inputs there are to my
development environment, and EXACTLY how they affect my product. The
best thing Microsoft can do right now for the productivity of its
developers is to take four people from the DDK and VisualC teams and
give them the following tasks:
Fold the separate (and prehistoric even by UNIX standards) DDK
development environment into Visual C .NET. Drivers are no longer 10 C
files and a header. They include multiple external libraries and shared
code between user-mode and kernel-mode projects. This sort of thing is
impossible to do within the limitations of the DDK. It forces us to
manually migrate compiler and linker settings into native Visual C
projects, which requires an expert hand to say the least.
Clarify what versions of the OS a given driver built using given
options will work on. No, it is NOT an option for us to build separate
binaries for 2k, XP, WNET, etc., when one is possible. I can build a
Win32 app that runs on anything from NT4 SP3 to 3790. Right now I’m
building a driver binary that works perfectly on everything from W2K SP0
to 3790. This makes QA much happier and vastly reduces the size of our
installer.
Either remove the undocumented options from the Visual C compiler and
linker or document them. We are responsible to our managers for the
content of the binaries we product. How can we do our job properly if we
don’t know what goes into these binaries?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
Moreira, Alberto
Sent: Friday, May 23, 2003 11:58 AM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK CompilingThe issue is not which compiler to use. The issue is the
looseness of the API. As I see it, every driver should be
compiled with the ANSI-strict switch on. Needing a specific
compiler to build a program - ANY compiler and ANY program -
is a sign of weakness of the ennvironment.Alberto.
-----Original Message-----
From: James A [mailto:xxxxx@hotmail.com]
Sent: Friday, May 23, 2003 2:49 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK CompilingAlberto,
The issue of which compiler to use has been beaten to death
on this list. Wealready know where you stand on it.
Jim A
>From: “Moreira, Alberto”
> >Reply-To: “NT Developers Interest List”
> >To: “NT Developers Interest List”
> >Subject: [ntdev] RE: XP DDK Compiling
> >Date: Fri, 23 May 2003 13:06:56 -0400
> >
> >You know, this is not a compiler issue, or at least it
> shouldn’t be. A
> >compiler generates machine code, period ! The issue is
> controlling the
> >API, and well, when we get to the point where we demand one
> particular
> >version of a compiler or else, gee whiz, I wonder if it
> isn’t time to
> >restructure the whole thing. Ideally a driver should compile
> and build
> >under any compiler, heck, that’s why we have standards in place, no ?
> >
> >Alberto
> >
> >
> >-----Original Message-----
> >From: Roddy, Mark [mailto:xxxxx@stratus.com]
> >Sent: Friday, May 23, 2003 12:43 PM
> >To: NT Developers Interest List
> >Subject: [ntdev] RE: XP DDK Compiling
> >
> >
> >I don’t think it was ‘branching’ exactly, more like a
> snapshot of the
> >VS compilation tools was frozen as the ‘kernel development toolset’.
> >The kernel/ddk team do not develop the compilation tools. At
> any rate,
> >I think it was a hugely positive step to end the uncontrolled ad hoc
> >mixing of various versions of the VS compiler and various
> versions of
> >the DDK. The build process prior to the XP ddk was simply out of
> >control, and did not guarantee correct results.
> >
> >The endless minor semi-documented changes to the build
> environment are
> >indeed a major pain the butt.
> >
> >-----Original Message-----
> >From: Gerg [mailto:xxxxx@hotmail.com]
> >Sent: Friday, May 23, 2003 12:27 PM
> >To: NT Developers Interest List
> >Subject: [ntdev] RE: XP DDK Compiling
> >
> >
> >I don’t really know why the DDK team decided that branching the
> >comiplers would give them a positive return on their investment?
> >
> >It also seems that the build utility has changed a bit from
> build 2600
> >to 3790. This is a minor pain…
> >
> >
> >----- Original Message -----
> >From: “Roddy, Mark”
> >To: “NT Developers Interest List”
> >Sent: Friday, May 23, 2003 8:37 AM
> >Subject: [ntdev] RE: XP DDK Compiling
> >
> >
> > > There is no guarantee that an XP compiled kernel
> component will work
> > > on an earlier platform. You might be able to build your w2k FS
> > > driver to work on either platform, but you would get a
> better answer
> > > from NTFSD.
> > >
> > > The simple answer is YES you have to use the ddk compiler, and no
> > > the current ddk supplies one version of the compilation
> tools that
> > > are documented as working for w2k/xp/w2k3. Of course you could
> > > probably hack together some other build system that
> didn’t use any
> > > of the tools, but why would you do that?
> > >
> > > -----Original Message-----
> > > From: Gerg [mailto:xxxxx@hotmail.com]
> > > Sent: Friday, May 23, 2003 11:26 AM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] XP DDK Compiling
> > >
> > >
> > > Is there any way to avoid compiling two FS drivers for 2k and XP?
> > > Should
> >a
> > > XP ddk compiled FS driver work in 2k?
> > >
> > > Finally for ddk build 3790 does one HAVE to use the DDK’s
> compiler
> > > and linker and do the compilers(VS.NET 2003 and DDK build
> 3790) now
> > > come from seperated sources?
> > >
> > > Thanks for any input?
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> xxxxx@stratus.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> >—
> >You are currently subscribed to ntdev as: xxxxx@stratus.com To
> >unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >—
> >You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> >To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >The contents of this e-mail are intended for the named
> addressee only.
> >It contains information that may be confidential. Unless you are the
> >named addressee or an authorized designee, you may not copy
> or use it,
> >or disclose it to anyone else. If you received it in error please
> >notify us immediately and then destroy it.
> >
> >
> >
> >—
> >You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> >unsubscribe send a blank email to xxxxx@lists.osr.com
>
> _________________________________________________________________
> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@compuware.com To unsubscribe send a blank
> email to xxxxx@lists.osr.com
>
>
>
> The contents of this e-mail are intended for the named
> addressee only. It contains information that may be
> confidential. Unless you are the named addressee or an
> authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify
> us immediately and then destroy it.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> ----------
From: xxxxx@nryan.com[SMTP:xxxxx@nryan.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, May 23, 2003 9:20 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] RE: XP DDK Compiling
- Fold the separate (and prehistoric even by UNIX standards) DDK
development environment into Visual C .NET.
Horrible idea. I’d probably give up if have to use this ugly monster.
Current approach is flexible, you can use any environment you want, command
line, any professional editor, older VS and even .NET without real problems.
Don’t forget about automated night builds. It is no problem to integrate DDK
build to any engine but there are big problems with VS project. One example:
how to create pre-defined settings for all apps at one place? I’m speaking
about tens or hundreds modules built at once and settings like delayed load
for a set of DLLs. We created such an engine; the result is similar to DDK
build although more flexible (we didn’t use DDK build because was poorly
documented then, needed some special things and integration with Perforce).
Drivers are no longer 10 C
files and a header. They include multiple external libraries and shared
code between user-mode and kernel-mode projects. This sort of thing is
impossible to do within the limitations of the DDK.
Impossible? I should know before did it 
It is no problem to build any
DLL using DDK and encapsulate user <-> kernel communication into a DLL isn’t
a bad idea. For shared code, headers and libraries good VCS and client views
can be used. No, I don’t mean VSS, something like Perforce.
It forces us to
manually migrate compiler and linker settings into native Visual C
projects, which requires an expert hand to say the least.
That’s the reason why not use VS for build as I mentioned above. And if you
really convert DDK project to VS… Well it was discussed too many times
here.
BTW, I quite agree with your other points.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
You and Alberto are smoking something or highly naive, see comments inline:
From: “Nick Ryan”
I agree. The various undocumented compiler and linker switches needed to
build a driver with the Microsoft compiler trouble me. I’m the kind of
engineer who wants to know EXACTLY what inputs there are to my
development environment, and EXACTLY how they affect my product. The
best thing Microsoft can do right now for the productivity of its
developers is to take four people from the DDK and VisualC teams and
give them the following tasks:
- Fold the separate (and prehistoric even by UNIX standards) DDK
development environment into Visual C .NET. Drivers are no longer 10 C
files and a header. They include multiple external libraries and shared
code between user-mode and kernel-mode projects. This sort of thing is
impossible to do within the limitations of the DDK. It forces us to
manually migrate compiler and linker settings into native Visual C
projects, which requires an expert hand to say the least.
The Visual Studio team is targeting 100,000+ developers and users, the
DDK team is supporting ~5000. where is the business sense in this!
Even if there was a business sense, you either have to lock down the
options (see more in my comments on Alberto’s post below), but that
is not what someone using Visual Studio expects.
- Clarify what versions of the OS a given driver built using given
options will work on. No, it is NOT an option for us to build separate
binaries for 2k, XP, WNET, etc., when one is possible. I can build a
Win32 app that runs on anything from NT4 SP3 to 3790. Right now I’m
building a driver binary that works perfectly on everything from W2K SP0
to 3790. This makes QA much happier and vastly reduces the size of our
installer.
I concur with the basic concept, and I believe the DDK team is trying to let
people know how to do this with the Win2k3 DDK.
- Either remove the undocumented options from the Visual C compiler and
linker or document them. We are responsible to our managers for the
content of the binaries we product. How can we do our job properly if we
don’t know what goes into these binaries?
Except for GNU (and there you have to study the sources, not documentation)
I’ve never heard of a compiler without some level of undocumented support.
Gee, as a former compiler writer am I supposed to tell you all my
optimization rules and code generation patterns, I don’t think so.
From: Moreira, Alberto
>
> The issue is not which compiler to use. The issue is the
> looseness of the API. As I see it, every driver should be
> compiled with the ANSI-strict switch on. Needing a specific
> compiler to build a program - ANY compiler and ANY program -
> is a sign of weakness of the ennvironment.
>
Wow, lets see what this means, well no exception handling since the calling
conventions
are not part of the ANSI standard, for that matter calling convention isn’t
either. Of course that won’t matter since ANSI compilers don’t define the
size of any base types (such as char, short, or int). Well, maybe Alberto
mean’t an ABI (application binary interface) this is
what vendors define for calling conventions, of course most ABI’s still
don’t specify exception handling, since there is a lot of compiler smarts in
that.
This would also make debugging interesting, there is a ton of data you have
to define to support debugging especially if you try to support debugging
with any optimization. Of
course with the large customer base of 5000 people it makes perfect sense
for every
compiler vendor to build a kernel debugger for their compiler.
I have been the project lead on compilers for OS development, and an
architect for multiple OS’es, this stuff is hard and you do go out of your
way to make it harder by giving up control of the development environemt for
pieces that plug into your OS.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
The problem is the interface with the external world. If we’re talking about
generating code for the CPU, it works the way it works, and although I’d
love to see every optimization documented, I’m not that worried that they
are, as long as they don’t come back to bite me. However, I want to have the
option of choosing my own optimization level - the pattern of use where all
I am entitled to do is to type “build -c” is not very palatable.
As far as extensions go, a computer language is what a computer language is.
What exception handling does the standard require ? If the compiler’s
standard, it’d better supply that standard to me, user or kernel mode, and
I’d like to be able to take for granted that it works. The same goes with
STL or anything else that makes its way into the language standard, I expect
the compiler provider to give me a standard compiler with a standard level
of support for kernel mode software: I see no reason except money that I
shouldn’t be able to get a fully working kernel-side standard set of C and
C++ libraries with every compiler release. The best thing to do with
language extensions is, don’t use them - they’re messy enough, stick to the
standard ! Or, even better, get them into the standard so that everybody
supports them. If extensions to the runtime semantics are desired, they
should be implemented as libraries with a very clear and sharp API, leave
them out of the compiler.
Now, about sizes of data types. They should only matter at the lowest level,
when the driver talks to the iron. The upper edges should be such that I can
take it for granted that if an API says “unsigned long” on the OS side, I
then get a compatible representation when I write “unsigned long” in my
driver ! And I find it verging the unacceptable that any interface from the
OS down to the upper edge specifies any data type that’s not either a
standard C type or a class or structure based on standard C types. So, don’t
say WORD or DWORD, say short or int, and assume that the OS and the compiler
generate compatible types -and DOCUMENT those types, please. And here,
again, the lowest level is well served by run-time support, be it in the
form of library routines or pseudo-calls that are expanded into machine
language by the compiler.
I don’t know, I detest compile-time gimmicks. Compilers should concentrate
on generating code that works.
Alberto.
-----Original Message-----
From: Don Burn [mailto:xxxxx@acm.org]
Sent: Friday, May 23, 2003 4:09 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling
You and Alberto are smoking something or highly naive, see comments inline:
From: “Nick Ryan”
I agree. The various undocumented compiler and linker switches needed to
build a driver with the Microsoft compiler trouble me. I’m the kind of
engineer who wants to know EXACTLY what inputs there are to my
development environment, and EXACTLY how they affect my product. The
best thing Microsoft can do right now for the productivity of its
developers is to take four people from the DDK and VisualC teams and
give them the following tasks:
- Fold the separate (and prehistoric even by UNIX standards) DDK
development environment into Visual C .NET. Drivers are no longer 10 C
files and a header. They include multiple external libraries and shared
code between user-mode and kernel-mode projects. This sort of thing is
impossible to do within the limitations of the DDK. It forces us to
manually migrate compiler and linker settings into native Visual C
projects, which requires an expert hand to say the least.
The Visual Studio team is targeting 100,000+ developers and users, the
DDK team is supporting ~5000. where is the business sense in this!
Even if there was a business sense, you either have to lock down the
options (see more in my comments on Alberto’s post below), but that
is not what someone using Visual Studio expects.
- Clarify what versions of the OS a given driver built using given
options will work on. No, it is NOT an option for us to build separate
binaries for 2k, XP, WNET, etc., when one is possible. I can build a
Win32 app that runs on anything from NT4 SP3 to 3790. Right now I’m
building a driver binary that works perfectly on everything from W2K SP0
to 3790. This makes QA much happier and vastly reduces the size of our
installer.
I concur with the basic concept, and I believe the DDK team is trying to let
people know how to do this with the Win2k3 DDK.
- Either remove the undocumented options from the Visual C compiler and
linker or document them. We are responsible to our managers for the
content of the binaries we product. How can we do our job properly if we
don’t know what goes into these binaries?
Except for GNU (and there you have to study the sources, not documentation)
I’ve never heard of a compiler without some level of undocumented support.
Gee, as a former compiler writer am I supposed to tell you all my
optimization rules and code generation patterns, I don’t think so.
From: Moreira, Alberto
>
> The issue is not which compiler to use. The issue is the
> looseness of the API. As I see it, every driver should be
> compiled with the ANSI-strict switch on. Needing a specific
> compiler to build a program - ANY compiler and ANY program -
> is a sign of weakness of the ennvironment.
>
Wow, lets see what this means, well no exception handling since the calling
conventions
are not part of the ANSI standard, for that matter calling convention isn’t
either. Of course that won’t matter since ANSI compilers don’t define the
size of any base types (such as char, short, or int). Well, maybe Alberto
mean’t an ABI (application binary interface) this is
what vendors define for calling conventions, of course most ABI’s still
don’t specify exception handling, since there is a lot of compiler smarts in
that.
This would also make debugging interesting, there is a ton of data you have
to define to support debugging especially if you try to support debugging
with any optimization. Of
course with the large customer base of 5000 people it makes perfect sense
for every
compiler vendor to build a kernel debugger for their compiler.
I have been the project lead on compilers for OS development, and an
architect for multiple OS’es, this stuff is hard and you do go out of your
way to make it harder by giving up control of the development environemt for
pieces that plug into your OS.
Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
> Is there any way to avoid compiling two FS drivers for 2k and XP?
Should a
XP ddk compiled FS driver work in 2k?
Better to do this vice versa. w2k-DDK-compiled FS driver will work on
XP.
Always use the oldest DDK for such cross-version compiles. This works,
and other approaches can have issues.
Max
> 1. Fold the separate (and prehistoric even by UNIX standards) DDK
development environment into Visual C .NET. Drivers are no longer 10
C
files and a header. They include multiple external libraries and
shared
code between user-mode and kernel-mode projects. This sort of thing
is
impossible to do within the limitations of the DDK.
IIRC MS builds the whole core OS tree by BUILD.
MSVC’s project management has only 1 advantage. It is simpler for
beginners. Nothing more.
building a driver binary that works perfectly on everything from W2K
SP0
to 3790.
I have the binary working from NT4-no-SPs to some Win2003 builds.
Max
Nobody says you can’t use external editors to edit C files included
in a VisualC project. I know people who do it all the time.
Automated nightly builds are incredibly simple with VS NET .2003’s
new solution configurations. I build half-a-million lines of source code
(some as user-mode, some as kernel-mode, some as both) with these three
commands:
devenv.com /rebuild “Release” client.sln
devenv.com /rebuild “Release 2kDrv” client.sln
devenv.com /rebuild “Release Nt4Drv” client.sln
You can even force VisualC to use your batch file’s environment instead
of its own directory search paths (in the GUI options) with the /useenv
switch.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, May 23, 2003 1:02 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling> ----------
> From: xxxxx@nryan.com[SMTP:xxxxx@nryan.com]
> Reply To: xxxxx@lists.osr.com
> Sent: Friday, May 23, 2003 9:20 PM
> To: xxxxx@lists.osr.com
> Subject: [ntdev] RE: XP DDK Compiling
>
> 1. Fold the separate (and prehistoric even by UNIX standards) DDK
> development environment into Visual C .NET.
>
Horrible idea. I’d probably give up if have to use this ugly
monster. Current approach is flexible, you can use any
environment you want, command line, any professional editor,
older VS and even .NET without real problems. Don’t forget
about automated night builds. It is no problem to integrate
DDK build to any engine but there are big problems with VS
project. One example: how to create pre-defined settings for
all apps at one place? I’m speaking about tens or hundreds
modules built at once and settings like delayed load for a
set of DLLs. We created such an engine; the result is similar
to DDK build although more flexible (we didn’t use DDK build
because was poorly documented then, needed some special
things and integration with Perforce).> Drivers are no longer 10 C
> files and a header. They include multiple external libraries and
> shared code between user-mode and kernel-mode projects.
This sort of
> thing is impossible to do within the limitations of the DDK.
>
Impossible? I should know before did it
to build any DLL using DDK and encapsulate user <-> kernel
communication into a DLL isn’t a bad idea. For shared code,
headers and libraries good VCS and client views can be used.
No, I don’t mean VSS, something like Perforce.> It forces us to
> manually migrate compiler and linker settings into native Visual C
> projects, which requires an expert hand to say the least.
>
That’s the reason why not use VS for build as I mentioned
above. And if you really convert DDK project to VS… Well it
was discussed too many times here.BTW, I quite agree with your other points.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Max, how do you manage to call APIs exported only by post-NT OS’s using
a common binary? NT doesn’t support MmGetSystemRoutineAddress. I
considered wrapping MmGetSystemRoutineAddress as a call into a
kernel-mode .dll that I would build and install separately, but decided
it was just easier to split the binary as a whole.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Friday, May 23, 2003 1:45 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling> 1. Fold the separate (and prehistoric even by UNIX standards) DDK
> development environment into Visual C .NET. Drivers are no longer 10
C
> files and a header. They include multiple external libraries and
shared
> code between user-mode and kernel-mode projects. This sort of thing
is
> impossible to do within the limitations of the DDK.IIRC MS builds the whole core OS tree by BUILD.
MSVC’s project management has only 1 advantage. It is simpler
for beginners. Nothing more.> building a driver binary that works perfectly on everything from W2K
SP0
> to 3790.I have the binary working from NT4-no-SPs to some Win2003 builds.
Max
You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
There are plently of features, classes, wizards, and generally large
pieces of functionality within VisualC that I’m sure are targeted to an
equally small audience of developers. Why can’t the DDK be one more such
piece of functionality?
If code optimization is the only thing that some weird undocumented
switch ‘/foo’ changes, for example, this is less of a concern to me than
if ‘/foo’ causes calls to be inserted to OS routines that are only
available on XP, for example, and would cause my driver to fail under
Win2k.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, May 23, 2003 1:09 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK CompilingYou and Alberto are smoking something or highly naive, see
comments inline:From: “Nick Ryan”
> I agree. The various undocumented compiler and linker
switches needed
> to build a driver with the Microsoft compiler trouble me.
I’m the kind
> of engineer who wants to know EXACTLY what inputs there are to my
> development environment, and EXACTLY how they affect my
product. The
> best thing Microsoft can do right now for the productivity of its
> developers is to take four people from the DDK and VisualC
teams and
> give them the following tasks:
>
> 1. Fold the separate (and prehistoric even by UNIX standards) DDK
> development environment into Visual C .NET. Drivers are no
longer 10 C
> files and a header. They include multiple external libraries and
> shared code between user-mode and kernel-mode projects.
This sort of
> thing is impossible to do within the limitations of the
DDK. It forces
> us to manually migrate compiler and linker settings into
native Visual
> C projects, which requires an expert hand to say the least.The Visual Studio team is targeting 100,000+ developers and
users, the DDK team is supporting ~5000. where is the
business sense in this! Even if there was a business sense,
you either have to lock down the options (see more in my
comments on Alberto’s post below), but that is not what
someone using Visual Studio expects.> 2. Clarify what versions of the OS a given driver built using given
> options will work on. No, it is NOT an option for us to
build separate
> binaries for 2k, XP, WNET, etc., when one is possible. I
can build a
> Win32 app that runs on anything from NT4 SP3 to 3790. Right now I’m
> building a driver binary that works perfectly on everything
from W2K
> SP0 to 3790. This makes QA much happier and vastly reduces
the size of
> our installer.I concur with the basic concept, and I believe the DDK team
is trying to let people know how to do this with the Win2k3 DDK.> 3. Either remove the undocumented options from the Visual C
compiler
> and linker or document them. We are responsible to our managers for
> the content of the binaries we product. How can we do our
job properly
> if we don’t know what goes into these binaries?Except for GNU (and there you have to study the sources, not
documentation) I’ve never heard of a compiler without some
level of undocumented support. Gee, as a former compiler
writer am I supposed to tell you all my optimization rules
and code generation patterns, I don’t think so.From: Moreira, Alberto
> >
> > The issue is not which compiler to use. The issue is the
looseness
> > of the API. As I see it, every driver should be compiled with the
> > ANSI-strict switch on. Needing a specific compiler to build a
> > program - ANY compiler and ANY program - is a sign of weakness of
> > the ennvironment.
> >Wow, lets see what this means, well no exception handling
since the calling conventions are not part of the ANSI
standard, for that matter calling convention isn’t either.
Of course that won’t matter since ANSI compilers don’t define
the size of any base types (such as char, short, or int).
Well, maybe Alberto mean’t an ABI (application binary
interface) this is what vendors define for calling
conventions, of course most ABI’s still don’t specify
exception handling, since there is a lot of compiler smarts in that.This would also make debugging interesting, there is a ton of
data you have to define to support debugging especially if
you try to support debugging with any optimization. Of
course with the large customer base of 5000 people it makes
perfect sense for every compiler vendor to build a kernel
debugger for their compiler.I have been the project lead on compilers for OS development,
and an architect for multiple OS’es, this stuff is hard and
you do go out of your way to make it harder by giving up
control of the development environemt for pieces that plug
into your OS.Don Burn
Windows 2k/XP/2k3 Filesystem and Driver Consulting
You are currently subscribed to ntdev as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com