Converting to XP build ...

Yesterday I began the process of converting my 2000 build environment to XP.
Mostly it was a push, but there are a few errors and warnings that I am
getting that are undocumented … at least I can’t find them. Some of them
are easy enough to understand from the error/warning comments, but others
are rather embedded in gobbledy-gook; e.g. LNK4231.

They are listed as follows:

C4296
C4242
LNK4224
LNK4216
LNK4231

Are there XP compiler docs that document these errors/warnings, and if so
where are they?

Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net

Gary,

they are documented in the latest MSDN for .NET compiler. All but LNK4231
are there. Do you have it or want copy/paste from docs?

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]


From: xxxxx@broadstor.com[SMTP:xxxxx@broadstor.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, April 30, 2002 7:27 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Converting to XP build …

Yesterday I began the process of converting my 2000 build environment to
XP.
Mostly it was a push, but there are a few errors and warnings that I am
getting that are undocumented … at least I can’t find them. Some of them
are easy enough to understand from the error/warning comments, but others
are rather embedded in gobbledy-gook; e.g. LNK4231.

They are listed as follows:

C4296
C4242
LNK4224
LNK4216
LNK4231

Are there XP compiler docs that document these errors/warnings, and if so
where are they?

Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net


You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to %%email.unsub%%

Thanks Michal. that explains it, and the fact that I was insisting on using
VS 6.0 and have not installed the .NET MSDN since it is not compatible with
.NET. Using Marks DDKBUILD took care of the warnings and error codes.

It appears that an upgrade to the new Visual Studio .NET may happen sooner
than I expected.


Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
>
> Gary,
>
> they are documented in the latest MSDN for .NET compiler. All but LNK4231
> are there. Do you have it or want copy/paste from docs?
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: xxxxx@broadstor.com[SMTP:xxxxx@broadstor.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Tuesday, April 30, 2002 7:27 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] Converting to XP build …
> >
> > Yesterday I began the process of converting my 2000 build environment to
> > XP.
> > Mostly it was a push, but there are a few errors and warnings that I am
> > getting that are undocumented … at least I can’t find them. Some of
them
> > are easy enough to understand from the error/warning comments, but
others
> > are rather embedded in gobbledy-gook; e.g. LNK4231.
> >
> > They are listed as follows:
> >
> > C4296
> > C4242
> > LNK4224
> > LNK4216
> > LNK4231
> >
> > Are there XP compiler docs that document these errors/warnings, and if
so
> > where are they?
> > –
> > Gary G. Little
> > xxxxx@broadstor.com
> > xxxxx@inland.net
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>

Well I’ve been sort of ‘side-by-side’ comparing the .net ide with visual
studio, and while there are some things that are really nice about .net, the
one thing I HATE is that the source browser refuses to give me a
caller/callee/referenced-by LIST that I can navigate. Other than that it
works fine for driver development.

On the other hand, in general .net seems to be a lot more flexible and user
friendly in terms of project management and has tons of auto-assist stuff
that I am just starting to appreciate. Besides, sooner or later either I’m
going to lose my last good vs6 cd or my development platform will not be
compatible, so I figure its best to get used to the .net way of doing
things.

Were you not using ddkbuild under vs6? Otherwise I don’t understand why my
stupid shell script got rid of your errors and warnings.

Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032
For Windows Driver training see www.azius.com

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
>
> Thanks Michal. that explains it, and the fact that I was insisting on
using
> VS 6.0 and have not installed the .NET MSDN since it is not compatible
with
> .NET. Using Marks DDKBUILD took care of the warnings and error codes.
>
> It appears that an upgrade to the new Visual Studio .NET may happen sooner
> than I expected.
>
> –
> Gary G. Little
> xxxxx@broadstor.com
> xxxxx@inland.net
>
> “Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> >
> > Gary,
> >
> > they are documented in the latest MSDN for .NET compiler. All but
LNK4231
> > are there. Do you have it or want copy/paste from docs?
> >
> > Best regards,
> >
> > Michal Vodicka
> > STMicroelectronics Design and Application s.r.o.
> > [michal.vodicka@st.com, http:://www.st.com]
> >
> > > ----------
> > > From: xxxxx@broadstor.com[SMTP:xxxxx@broadstor.com]
> > > Reply To: xxxxx@lists.osr.com
> > > Sent: Tuesday, April 30, 2002 7:27 PM
> > > To: xxxxx@lists.osr.com
> > > Subject: [ntdev] Converting to XP build …
> > >
> > > Yesterday I began the process of converting my 2000 build environment
to
> > > XP.
> > > Mostly it was a push, but there are a few errors and warnings that I
am
> > > getting that are undocumented … at least I can’t find them. Some of
> them
> > > are easy enough to understand from the error/warning comments, but
> others
> > > are rather embedded in gobbledy-gook; e.g. LNK4231.
> > >
> > > They are listed as follows:
> > >
> > > C4296
> > > C4242
> > > LNK4224
> > > LNK4216
> > > LNK4231
> > >
> > > Are there XP compiler docs that document these errors/warnings, and if
> so
> > > where are they?
> > > –
> > > Gary G. Little
> > > xxxxx@broadstor.com
> > > xxxxx@inland.net
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
>
>
>
>

Mark,

I’m one of those died in the wool “Build? I don’t got’s no build! I don’t
need no SHTINKING BUILD” types. Until now … and XP … and it’s
“special compiler” … and those errors I got from doing F7 to build a
project under VS6. I did a test build with your DDKBUILD and low and behold
… same source … no errors.

Right now my problem is the learning curve on VS .NET. I tried to build a
new “solution” and “project” using the method you outlined for VS 6. Got an
update, or suggestions for doing that?

First shock — F7 don’t work. Rebuild Project gives me an Error spawning ".
I can do Rebuild Solution and generate a new SYS file, using DDKBUILD. It
seems that the problem in invoking Rebuild is how to do a clean.
Rebuild Solution works, but Rebuild doesn’t. It’s that learning
curve … gotta learn how to do it.

Nice utility, though. Thanks.


Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net

“Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> Well I’ve been sort of ‘side-by-side’ comparing the .net ide with visual
> studio, and while there are some things that are really nice about .net,
the
> one thing I HATE is that the source browser refuses to give me a
> caller/callee/referenced-by LIST that I can navigate. Other than that it
> works fine for driver development.
>
> On the other hand, in general .net seems to be a lot more flexible and
user
> friendly in terms of project management and has tons of auto-assist stuff
> that I am just starting to appreciate. Besides, sooner or later either I’m
> going to lose my last good vs6 cd or my development platform will not be
> compatible, so I figure its best to get used to the .net way of doing
> things.
>
> Were you not using ddkbuild under vs6? Otherwise I don’t understand why my
> stupid shell script got rid of your errors and warnings.
>
> –
> ===
> Mark Roddy
> Consultant, Microsoft DDK MVP
> Hollis Technology Solutions
> xxxxx@hollistech.com
> www.hollistech.com
> 603-321-1032
> For Windows Driver training see www.azius.com
> ===
>
>
> “Gary G. Little” wrote in message
> news:xxxxx@ntdev…
> >
> > Thanks Michal. that explains it, and the fact that I was insisting on
> using
> > VS 6.0 and have not installed the .NET MSDN since it is not compatible
> with
> > .NET. Using Marks DDKBUILD took care of the warnings and error codes.
> >
> > It appears that an upgrade to the new Visual Studio .NET may happen
sooner
> > than I expected.
> >
> > –
> > Gary G. Little
> > xxxxx@broadstor.com
> > xxxxx@inland.net
> >
> > “Michal Vodicka” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > Gary,
> > >
> > > they are documented in the latest MSDN for .NET compiler. All but
> LNK4231
> > > are there. Do you have it or want copy/paste from docs?
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > STMicroelectronics Design and Application s.r.o.
> > > [michal.vodicka@st.com, http:://www.st.com]
> > >
> > > > ----------
> > > > From: xxxxx@broadstor.com[SMTP:xxxxx@broadstor.com]
> > > > Reply To: xxxxx@lists.osr.com
> > > > Sent: Tuesday, April 30, 2002 7:27 PM
> > > > To: xxxxx@lists.osr.com
> > > > Subject: [ntdev] Converting to XP build …
> > > >
> > > > Yesterday I began the process of converting my 2000 build
environment
> to
> > > > XP.
> > > > Mostly it was a push, but there are a few errors and warnings that I
> am
> > > > getting that are undocumented … at least I can’t find them. Some
of
> > them
> > > > are easy enough to understand from the error/warning comments, but
> > others
> > > > are rather embedded in gobbledy-gook; e.g. LNK4231.
> > > >
> > > > They are listed as follows:
> > > >
> > > > C4296
> > > > C4242
> > > > LNK4224
> > > > LNK4216
> > > > LNK4231
> > > >
> > > > Are there XP compiler docs that document these errors/warnings, and
if
> > so
> > > > where are they?
> > > > –
> > > > Gary G. Little
> > > > xxxxx@broadstor.com
> > > > xxxxx@inland.net
> > > >
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > > > To unsubscribe send a blank email to %%email.unsub%%
> > > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>

Guys,

Just to let you know, the new version of our Src2Dsp utility that
comes with DriverStudio 2.7 can generate a .sln file that you can
use to develop your driver under .net. I don’t know if people can
download it from the web site free, but let me work on that and see
if I can get them to let me do it.

Alberto.

==================

On 1 May 2002, at 12:04, Mark Roddy wrote:

Well I’ve been sort of ‘side-by-side’ comparing the .net ide with visual
studio, and while there are some things that are really nice about .net, the
one thing I HATE is that the source browser refuses to give me a
caller/callee/referenced-by LIST that I can navigate. Other than that it
works fine for driver development.

On the other hand, in general .net seems to be a lot more flexible and user
friendly in terms of project management and has tons of auto-assist stuff
that I am just starting to appreciate. Besides, sooner or later either I’m
going to lose my last good vs6 cd or my development platform will not be
compatible, so I figure its best to get used to the .net way of doing
things.

Were you not using ddkbuild under vs6? Otherwise I don’t understand why my
stupid shell script got rid of your errors and warnings.

Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032
For Windows Driver training see www.azius.com

“Gary G. Little” wrote in message
> news:xxxxx@ntdev…
> >
> > Thanks Michal. that explains it, and the fact that I was insisting on
> using
> > VS 6.0 and have not installed the .NET MSDN since it is not compatible
> with
> > .NET. Using Marks DDKBUILD took care of the warnings and error codes.
> >
> > It appears that an upgrade to the new Visual Studio .NET may happen sooner
> > than I expected.
> >
> > –
> > Gary G. Little
> > xxxxx@broadstor.com
> > xxxxx@inland.net
> >
> > “Michal Vodicka” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > Gary,
> > >
> > > they are documented in the latest MSDN for .NET compiler. All but
> LNK4231
> > > are there. Do you have it or want copy/paste from docs?
> > >
> > > Best regards,
> > >
> > > Michal Vodicka
> > > STMicroelectronics Design and Application s.r.o.
> > > [michal.vodicka@st.com, http:://www.st.com]
> > >
> > > > ----------
> > > > From: xxxxx@broadstor.com[SMTP:xxxxx@broadstor.com]
> > > > Reply To: xxxxx@lists.osr.com
> > > > Sent: Tuesday, April 30, 2002 7:27 PM
> > > > To: xxxxx@lists.osr.com
> > > > Subject: [ntdev] Converting to XP build …
> > > >
> > > > Yesterday I began the process of converting my 2000 build environment
> to
> > > > XP.
> > > > Mostly it was a push, but there are a few errors and warnings that I
> am
> > > > getting that are undocumented … at least I can’t find them. Some of
> > them
> > > > are easy enough to understand from the error/warning comments, but
> > others
> > > > are rather embedded in gobbledy-gook; e.g. LNK4231.
> > > >
> > > > They are listed as follows:
> > > >
> > > > C4296
> > > > C4242
> > > > LNK4224
> > > > LNK4216
> > > > LNK4231
> > > >
> > > > Are there XP compiler docs that document these errors/warnings, and if
> > so
> > > > where are they?
> > > > –
> > > > Gary G. Little
> > > > xxxxx@broadstor.com
> > > > xxxxx@inland.net
> > > >
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > > > To unsubscribe send a blank email to %%email.unsub%%
> > > >
> > >
> > >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to %%email.unsub%%
>

wrote in message news:xxxxx@ntdev…
>
>
> Just to let you know, the new version of our Src2Dsp utility that
>

And as I’ve said MANY times, please don’t do this. You really need to build
with the compiler and library that comes with the DDK.


You can build from within the VS IDE… just please use a command file, like
the one that we or Mr. Roddy make available, as an “external build
procedure”.

This is nothing against DriverStudio. I just really feel that encouraging
people to try to mimic the build environment from within the VS IDE, by
setting the right switches and all, is a very dangerous thing to do. Heck,
you’re not even using the “right” version of the compiler or linker when you
do that.


Sorry for the rant, but this (along with people doing DMA without using the
NT/HAL abstractions) is among my favorite topics,

Peter
OSR

>And as I’ve said MANY times, please don’t do this.

It’s already done. :slight_smile:

[snip…]

Peter, by now you should know us better than that ! If we put something like
this out, there’s a good chance it’ll work fine. And maybe we should let
individual users decide when to switch from the IDE to the batch build ?

Alberto.

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.

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> >And as I’ve said MANY times, please don’t do this.
> [snip…]
>
> Peter, by now you should know us better than that ! If we put something
like
> this out, there’s a good chance it’ll work fine. And maybe we should let
> individual users decide when to switch from the IDE to the batch build ?
>

Oh, NO disrespect intended, Alberto! Seriously. I’m sure it works
perfectly correctly.

But either I misunderstand what this verison of your utility does, or you’re
not hearing my argument: People CAN and SHOULD build within the IDE. I
think that’s a great idea. Never bring up a DDK command window. That’s
fine.

But if you DO build within the IDE, you really DO need to build using
BUILD.EXE and the compiler, linker, and libraries shipped with the DDK –
and you must NOT the compiler, linker, and/or libraries shipped with VS
.NET.

You can do the right thing trivially, by using a command procedure invoked
from within VS as part of an “external build procedure.” And you still get
to build by clicking the little icon in VS IDE, and you still get every
single feature of the IDE, including browsing and all that.

So: YES, by all means build from within the IDE. But, NO… PLEASE don’t
try to repro the settings that makefile.def uses in the IDE. Please just
run build.exe from within the IDE. This ensure that your driver will work,
AND you get to use the IDE.

That’s all I’m saying… I’m merely trying to help people avoid the problems
that many of us have previously seen with using the wrong compiler/linker
combinations.

Peter
OSR

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Thursday, May 02, 2002 3:33 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Converting to XP build …

But either I misunderstand what this verison of your utility does, or
you’re
not hearing my argument: People CAN and SHOULD build within the IDE. I
think that’s a great idea. Never bring up a DDK command window. That’s
fine.

The utility indeed does what you suspect it does: it sets up a “solution”
file for use within .net. It can also generate a project file for VC6, and
that functionality has been there for a while.

But if you DO build within the IDE, you really DO need to build using
BUILD.EXE and the compiler, linker, and libraries shipped with the DDK –
and you must NOT the compiler, linker, and/or libraries shipped with VS
.NET.

Well, I can see the point, but hey, it’s the same compiler. We will tweak
the .net framework to use the ddk compiler, just give us a bit more time. On
the other hand, I find it a real bad idea to tie up something as broad as
driver development and implementation to specific versions of compilers and
linkers. When that happens, I feel like hanging the compiler, not the
toolmaker ! In an ideal world, I would refuse to ship anything that can’t be
compiled by at least two different compilers from two different vendors,
heck, that’s why we’re supposed to have standards and what not. My take on
this is, *do not* depend on a specific compiler version, that’s bad news.

You can do the right thing trivially, by using a command procedure invoked
from within VS as part of an “external build procedure.” And you still get
to build by clicking the little icon in VS IDE, and you still get every
single feature of the IDE, including browsing and all that.

This is true, and you can do that trivially too. But then, maybe we don’t
want to be limited to what build.exe can do ? After all, build.exe is just a
shell around nmake. At some point in time we may want to depart from this
old-fashioned C-xterm-dosbox model, eh ? Or I’ll never be able to ship my
drivers in bytecode. :slight_smile:

So: YES, by all means build from within the IDE. But, NO… PLEASE don’t
try to repro the settings that makefile.def uses in the IDE. Please just
run build.exe from within the IDE. This ensure that your driver will work,
AND you get to use the IDE.

That’s all I’m saying… I’m merely trying to help people avoid the
problems
that many of us have previously seen with using the wrong compiler/linker
combinations.

That driver will work, it goes without saying. We’ve been doing it for a
while now with VC6, no problems so far ! But I’ll give you, we’re not known
for being conservative. Watch this space, one of these days you may get to
see me writing a driver in C#. :wink:

Alberto.

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.

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> Well, I can see the point, but hey, it’s the same compiler.
>

That’s the point. It’s NOT the same compiler. Check the version numbers
reported by CL…

> On
> the other hand, I find it a real bad idea to tie up something as broad as
> driver development and implementation to specific versions of compilers
and
> linkers.
>

You can’t expect to compile and link something with a NEWer compiler than
what the o/s knows about. We’ve seen precisely this problem in the past.
People building drivers that the O/S cannot load…

> When that happens, I feel like hanging the compiler, not the
> toolmaker ! In an ideal world, I would refuse to ship anything that can’t
be
> compiled by at least two different compilers from two different vendors,
>

Ideally, I would agree with you. Especially for applications. For drivers,
well, we can’t even get NTDDK.H to COMPILE with a compiler other than MS
VC++… Well, you can but it’s real work, akin to removing your lung with a
steak knife.

> >that many of us have previously seen with using the wrong compiler/linker
> >combinations.
>
> That driver will work, it goes without saying. We’ve been doing it for a
> while now with VC6, no problems so far ! But I’ll give you, we’re not
known
> for being conservative. Watch this space, one of these days you may get to
> see me writing a driver in C#. :wink:
>

Well, as long as you link using the VC6 libraries… Remember, exception
handling changed from V6 to V7!

So, don’t try to build in V6 and link against the V7 (XP DDK) libraries!!

And, of course, if you build with V6, you don’t get cool stuff like stack
buffer overflow checking…

Peter
OSR

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
>
>
> >And as I’ve said MANY times, please don’t do this.
>
> It’s already done. :slight_smile:
>
> [snip…]
>
> Peter, by now you should know us better than that ! If we put something
like
> this out, there’s a good chance it’ll work fine. And maybe we should let
> individual users decide when to switch from the IDE to the batch build ?

If you really want to make that thing useful, make it a real AppWizard that
can update the SOURCES file when the DSP (or sln) file is changed. Do a
proper DIRS file for root directories with source directories below them.
Then call build instead of cl. Now that’s integration!

Until then, I cast my lot with the DDKBUILD folks.

Phil

It’s called DriverWorks. It automates the way you build drivers. Look it up
!

Alberto.

-----Original Message-----
From: Phil Barila [mailto:xxxxx@Seagate.com]
Sent: Thursday, May 02, 2002 4:53 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Converting to XP build …

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
>
>
> >And as I’ve said MANY times, please don’t do this.
>
> It’s already done. :slight_smile:
>
> [snip…]
>
> Peter, by now you should know us better than that ! If we put something
like
> this out, there’s a good chance it’ll work fine. And maybe we should let
> individual users decide when to switch from the IDE to the batch build ?

If you really want to make that thing useful, make it a real AppWizard that
can update the SOURCES file when the DSP (or sln) file is changed. Do a
proper DIRS file for root directories with source directories below them.
Then call build instead of cl. Now that’s integration!

Until then, I cast my lot with the DDKBUILD folks.

Phil


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

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.

-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Thursday, May 02, 2002 4:29 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Converting to XP build …

You can’t expect to compile and link something with a NEWer compiler than
that the o/s knows about. We’ve seen precisely this problem in the past.
People building drivers that the O/S cannot load…

A compiler generates machine code, invokes libraries that come with the
compiler, and links the code to any imported routine that adheres to the
same calling sequence standard. The problem starts when the linkage is not
standardized enough, so that the OS relies on specific versions of compilers
to link into their stuff, or when development teams are too sloppy to make
sure that their code adheres to the standard compiler conventions. If the
code I write is ANSI Standard C, it should compile with any ANSI Standard C
compiler and it should link with the library that comes with that compiler.
If that library is well written, it should work just as well in the kernel
side as it does in the user side, give or take a few sharp turnings which we
are all aware of. If the compiler generates standard linkages, and if the
code that’s linked with one’s program also follows those standard linkages,
again, the code should compile and link independent of the OS. The problem
starts when people begin to assume that they have the freedom to do whatever
they want with their code and not to commit to a solid, frozen, public
interface - relying instead on specific compiler or tool versions to mask
away the problems generated by not sticking to the standard.

Ideally, I would agree with you. Especially for applications. For
drivers,
well, we can’t even get NTDDK.H to COMPILE with a compiler other than MS
VC++… Well, you can but it’s real work, akin to removing your lung with a
steak knife.

Which, by the way, totally invalidates that big blue sky debate about
quality. If I can’t even trust that a .h file adheres to a well established
standard, what then ?

Well, as long as you link using the VC6 libraries… Remember, exception
handling changed from V6 to V7!

So, don’t try to build in V6 and link against the V7 (XP DDK) libraries!!

But that’s the point, no ? A compiler comes with its own libraries. We
compile code with compiler X, then we link it with libraries that come with
compiler X. What’s left is the imported stuff - as long as that code abides
to a standard interface, we’re safe.

And, of course, if you build with V6, you don’t get cool stuff like stack
buffer overflow checking…

Every new compiler brings in new goodies!

Alberto.

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.

Copa cabana (!?) Mea Capra (???) (Hey I’m southern Baptist … wadda ya
expect?)

I am building a properly proper build environment based on DDKBUILD for
Visual Studio .NET. Not to painful, just tedious.


Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net

“Peter Viscarola” wrote in message news:xxxxx@ntdev…
>
> wrote in message news:xxxxx@ntdev…
> >
> >
> > Just to let you know, the new version of our Src2Dsp utility that
> >
>
> And as I’ve said MANY times, please don’t do this. You really need to
build
> with the compiler and library that comes with the DDK.
>
>
> You can build from within the VS IDE… just please use a command file,
like
> the one that we or Mr. Roddy make available, as an “external build
> procedure”.
>
> This is nothing against DriverStudio. I just really feel that encouraging
> people to try to mimic the build environment from within the VS IDE, by
> setting the right switches and all, is a very dangerous thing to do.
Heck,
> you’re not even using the “right” version of the compiler or linker when
you
> do that.
>
>
> Sorry for the rant, but this (along with people doing DMA without using
the
> NT/HAL abstractions) is among my favorite topics,
>
> Peter
> OSR
>
>
>
>
>
>