DDKs and MFC applications, what is going on

NTDEV
1

I hope someone at MS is listening becuase I am getting really
frustrated with build. For years I have been writing Driver
community tools with MFC and have been using the DDK to build them
since a lot of the tools I build include drivers. Recently in the
process of upgrading the utilities I have moved to later versions of
MFC and visual studio (Yes, I am using 2005) and have used some of the
new classes or functions in classes. Well, now I can no longer get
my stuff to build with the DDK because all that is in there is MFC42.
I’ve spent countless hours trying to get MFC_INCLUDES, MFC_LIB_PATH,
and MFC_LIBS to work, but while I can get it to compile, I have linker
MFC undefines up the wazoo. Has anyone else run into this? I
have appended the sources file that I have been working with. I
should point out that I had additions lines in the TARGETLIBS section
to include MFC71UD.LIB ,etc… But I still had problems… I’d
love to go back to using only build to getting my applications built.

BTW, I created the MFC8 directory in my DDK directory becuase I know
how much build loves spaces in directory names…

TARGETNAME=ObjView
TARGETTYPE=PROGRAM
TARGETPATH=.\lib$(BUILD_ALT_DIR)
#INCLUDES=F:\MSSDK\INCLUDE;$(DDK_INC_PATH);.
INCLUDES=$(DDK_INC_PATH);F:\MSSDK\INCLUDE
TARGETLIBS= $(SDK_LIB_PATH)\comctl32.lib \
$(SDK_LIB_PATH)\Comdlg32.lib \
$(SDK_LIB_PATH)\ole32.lib \
$(SDK_LIB_PATH)\oleaut32.lib \
$(SDK_LIB_PATH)\version.lib \
$(SDK_LIB_PATH)\htmlhelp.lib \
$(SDK_LIB_PATH)\shell32.lib \
$(SDK_LIB_PATH)\comctl32.lib \
$(SDK_LIB_PATH)\SHLWAPI.lib \
$(SDK_LIB_PATH)\ntdll.lib \
$(SDK_LIB_PATH)\kernel32.lib \
$(SDK_LIB_PATH)\setupapi.lib \
$(SDK_LIB_PATH)\aclui.lib \
$(SDK_LIB_PATH)\htmlhelp.lib \
$(SDK_LIB_PATH)\uuid.lib

MFC_VER=71
#MSVCRT=1
#PLATFORM_MFC_VER=0x0600
MFC_INCLUDES=d:\WINDDK\3790.1830\inc\mfc8\include
MFC_LIB_PATH=d:\WINDDK\3790.1830\inc\mfc8\lib*\
MFC_LIBS=d:\WINDDK\3790.1830\inc\mfc8\lib*\
USE_MFCUNICODE=1
#USE_STATIC_MFC=1
#USE_LIBCMT=1
#USE_STL=1
USE_ATL=1

#MSC_WARNING_LEVEL=/W1

C_DEFINES=$(C_DEFINES) -D_UNICODE=1

#DEBUG_CRTS=1
#MSC_OPTIMIZATION=/Od

UMTYPE=windows

#BUFFER_OVERFLOW_CHECKS=NTDLL

LANGUAGE_NEUTRAL=0

LINKER_FLAGS=$(LINKER_FLAGS)

PRECOMPILED_CXX = 1
PRECOMPILED_INCLUDE = stdafx.h
PRECOMPILED_SOURCEFILE = stdafx.cpp

SOURCES= \
objdir.rc \
mainfrm.cpp \
ntobject.cpp \
objectdirectoryview.cpp \
objectview.cpp \
privobji.cpp \
security.cpp \
objdir.cpp \
objdirdoc.cpp \
objdirview.cpp

2

So I gave up on that approach a long time ago. If I’m building gui apps
I’m building using the VS environment, not the DDK environment. The
headers and libraries in the ddk for luser mode gui apps are as close to
useless as you can get. Besides, everything luser mode has to be managed
code these days - didn’t you get the memo? None of that stuff is in the
ddk.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark J. Cariddi
Sent: Friday, January 06, 2006 10:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DDKs and MFC applications, what is going on

I hope someone at MS is listening becuase I am getting really
frustrated with build. For years I have been writing Driver
community tools with MFC and have been using the DDK to build them
since a lot of the tools I build include drivers. Recently in the
process of upgrading the utilities I have moved to later versions of
MFC and visual studio (Yes, I am using 2005) and have used some of the
new classes or functions in classes. Well, now I can no longer get
my stuff to build with the DDK because all that is in there is MFC42.
I’ve spent countless hours trying to get MFC_INCLUDES, MFC_LIB_PATH,
and MFC_LIBS to work, but while I can get it to compile, I have linker
MFC undefines up the wazoo. Has anyone else run into this? I
have appended the sources file that I have been working with. I
should point out that I had additions lines in the TARGETLIBS section
to include MFC71UD.LIB ,etc… But I still had problems… I’d
love to go back to using only build to getting my applications built.

BTW, I created the MFC8 directory in my DDK directory becuase I know
how much build loves spaces in directory names…

TARGETNAME=ObjView
TARGETTYPE=PROGRAM
TARGETPATH=.\lib$(BUILD_ALT_DIR)
#INCLUDES=F:\MSSDK\INCLUDE;$(DDK_INC_PATH);.
INCLUDES=$(DDK_INC_PATH);F:\MSSDK\INCLUDE
TARGETLIBS= $(SDK_LIB_PATH)\comctl32.lib \
$(SDK_LIB_PATH)\Comdlg32.lib \
$(SDK_LIB_PATH)\ole32.lib \
$(SDK_LIB_PATH)\oleaut32.lib \
$(SDK_LIB_PATH)\version.lib \
$(SDK_LIB_PATH)\htmlhelp.lib \
$(SDK_LIB_PATH)\shell32.lib \
$(SDK_LIB_PATH)\comctl32.lib \
$(SDK_LIB_PATH)\SHLWAPI.lib \
$(SDK_LIB_PATH)\ntdll.lib \
$(SDK_LIB_PATH)\kernel32.lib \
$(SDK_LIB_PATH)\setupapi.lib \
$(SDK_LIB_PATH)\aclui.lib \
$(SDK_LIB_PATH)\htmlhelp.lib \
$(SDK_LIB_PATH)\uuid.lib

MFC_VER=71
#MSVCRT=1
#PLATFORM_MFC_VER=0x0600
MFC_INCLUDES=d:\WINDDK\3790.1830\inc\mfc8\include
MFC_LIB_PATH=d:\WINDDK\3790.1830\inc\mfc8\lib*\
MFC_LIBS=d:\WINDDK\3790.1830\inc\mfc8\lib*\
USE_MFCUNICODE=1
#USE_STATIC_MFC=1
#USE_LIBCMT=1
#USE_STL=1
USE_ATL=1

#MSC_WARNING_LEVEL=/W1

C_DEFINES=$(C_DEFINES) -D_UNICODE=1

#DEBUG_CRTS=1
#MSC_OPTIMIZATION=/Od

UMTYPE=windows

#BUFFER_OVERFLOW_CHECKS=NTDLL

LANGUAGE_NEUTRAL=0

LINKER_FLAGS=$(LINKER_FLAGS)

PRECOMPILED_CXX = 1
PRECOMPILED_INCLUDE = stdafx.h
PRECOMPILED_SOURCEFILE = stdafx.cpp

SOURCES= \
objdir.rc \
mainfrm.cpp \
ntobject.cpp \
objectdirectoryview.cpp \
objectview.cpp \
privobji.cpp \
security.cpp \
objdir.cpp \
objdirdoc.cpp \
objdirview.cpp

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

I still use DDK BUILD for our product core, which is not UI (just the
processing engine which executes some tasks).

COM and ATL code can also be built fine using BUILD.

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

----- Original Message -----
From: “Roddy, Mark”
To: “Windows System Software Devs Interest List”
Sent: Friday, January 06, 2006 6:55 PM
Subject: RE: [ntdev] DDKs and MFC applications, what is going on

So I gave up on that approach a long time ago. If I’m building gui apps
I’m building using the VS environment, not the DDK environment. The
headers and libraries in the ddk for luser mode gui apps are as close to
useless as you can get. Besides, everything luser mode has to be managed
code these days - didn’t you get the memo? None of that stuff is in the
ddk.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark J. Cariddi
Sent: Friday, January 06, 2006 10:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DDKs and MFC applications, what is going on

I hope someone at MS is listening becuase I am getting really
frustrated with build. For years I have been writing Driver
community tools with MFC and have been using the DDK to build them
since a lot of the tools I build include drivers. Recently in the
process of upgrading the utilities I have moved to later versions of
MFC and visual studio (Yes, I am using 2005) and have used some of the
new classes or functions in classes. Well, now I can no longer get
my stuff to build with the DDK because all that is in there is MFC42.
I’ve spent countless hours trying to get MFC_INCLUDES, MFC_LIB_PATH,
and MFC_LIBS to work, but while I can get it to compile, I have linker
MFC undefines up the wazoo. Has anyone else run into this? I
have appended the sources file that I have been working with. I
should point out that I had additions lines in the TARGETLIBS section
to include MFC71UD.LIB ,etc… But I still had problems… I’d
love to go back to using only build to getting my applications built.

BTW, I created the MFC8 directory in my DDK directory becuase I know
how much build loves spaces in directory names…

TARGETNAME=ObjView
TARGETTYPE=PROGRAM
TARGETPATH=.\lib$(BUILD_ALT_DIR)
#INCLUDES=F:\MSSDK\INCLUDE;$(DDK_INC_PATH);.
INCLUDES=$(DDK_INC_PATH);F:\MSSDK\INCLUDE
TARGETLIBS= $(SDK_LIB_PATH)\comctl32.lib <br> $(SDK_LIB_PATH)\Comdlg32.lib <br> $(SDK_LIB_PATH)\ole32.lib <br> $(SDK_LIB_PATH)\oleaut32.lib <br> $(SDK_LIB_PATH)\version.lib <br> $(SDK_LIB_PATH)\htmlhelp.lib <br> $(SDK_LIB_PATH)\shell32.lib <br> $(SDK_LIB_PATH)\comctl32.lib <br> $(SDK_LIB_PATH)\SHLWAPI.lib <br>$(SDK_LIB_PATH)\ntdll.lib <br>$(SDK_LIB_PATH)\kernel32.lib <br>$(SDK_LIB_PATH)\setupapi.lib <br>$(SDK_LIB_PATH)\aclui.lib <br>$(SDK_LIB_PATH)\htmlhelp.lib <br>$(SDK_LIB_PATH)\uuid.lib
#
MFC_VER=71
#MSVCRT=1
#PLATFORM_MFC_VER=0x0600
MFC_INCLUDES=d:\WINDDK\3790.1830\inc\mfc8\include
MFC_LIB_PATH=d:\WINDDK\3790.1830\inc\mfc8\lib*<br>MFC_LIBS=d:\WINDDK\3790.1830\inc\mfc8\lib*<br>USE_MFCUNICODE=1
#USE_STATIC_MFC=1
#USE_LIBCMT=1
#USE_STL=1
USE_ATL=1

#MSC_WARNING_LEVEL=/W1

C_DEFINES=$(C_DEFINES) -D_UNICODE=1

#DEBUG_CRTS=1
#MSC_OPTIMIZATION=/Od

UMTYPE=windows

#BUFFER_OVERFLOW_CHECKS=NTDLL

LANGUAGE_NEUTRAL=0

LINKER_FLAGS=$(LINKER_FLAGS)

PRECOMPILED_CXX = 1
PRECOMPILED_INCLUDE = stdafx.h
PRECOMPILED_SOURCEFILE = stdafx.cpp

SOURCES= <br> objdir.rc <br> mainfrm.cpp <br> ntobject.cpp <br> objectdirectoryview.cpp <br> objectview.cpp <br> privobji.cpp <br> security.cpp <br> objdir.cpp <br> objdirdoc.cpp <br> objdirview.cpp

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

On Jan 6, 2006, at 9:43 AM, Mark J. Cariddi wrote:

I hope someone at MS is listening becuase I am getting really
frustrated with build. For years I have been writing Driver
community tools with MFC and have been using the DDK to build them
since a lot of the tools I build include drivers. Recently in the
process of upgrading the utilities I have moved to later versions of
MFC and visual studio (Yes, I am using 2005) and have used some of the
new classes or functions in classes. Well, now I can no longer get
my stuff to build with the DDK because all that is in there is MFC42.

I agree - it seems like the method of setting up a DDK is something
like “do the minimum it takes to get the sample code building”. I
wish Microsoft would provide better support for building user-mode
stuff through build, and I’ve given them that feedback at every
opportunity for the last couple of years.

-sd

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

5

What are the unresolved externals ? Also try introducing /VERBOSE option
in your linker command line and see if that helps narrow it down.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark J. Cariddi
Sent: Friday, January 06, 2006 7:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] DDKs and MFC applications, what is going on

I hope someone at MS is listening becuase I am getting really
frustrated with build. For years I have been writing Driver
community tools with MFC and have been using the DDK to build them
since a lot of the tools I build include drivers. Recently in the
process of upgrading the utilities I have moved to later versions of MFC
and visual studio (Yes, I am using 2005) and have used some of the
new classes or functions in classes. Well, now I can no longer get
my stuff to build with the DDK because all that is in there is MFC42.
I’ve spent countless hours trying to get MFC_INCLUDES, MFC_LIB_PATH, and
MFC_LIBS to work, but while I can get it to compile, I have linker
MFC undefines up the wazoo. Has anyone else run into this? I
have appended the sources file that I have been working with. I
should point out that I had additions lines in the TARGETLIBS section
to include MFC71UD.LIB ,etc… But I still had problems… I’d
love to go back to using only build to getting my applications built.

BTW, I created the MFC8 directory in my DDK directory becuase I know how
much build loves spaces in directory names…

TARGETNAME=ObjView
TARGETTYPE=PROGRAM
TARGETPATH=.\lib$(BUILD_ALT_DIR)
#INCLUDES=F:\MSSDK\INCLUDE;$(DDK_INC_PATH);.
INCLUDES=$(DDK_INC_PATH);F:\MSSDK\INCLUDE
TARGETLIBS= $(SDK_LIB_PATH)\comctl32.lib \
$(SDK_LIB_PATH)\Comdlg32.lib \
$(SDK_LIB_PATH)\ole32.lib \
$(SDK_LIB_PATH)\oleaut32.lib \
$(SDK_LIB_PATH)\version.lib \
$(SDK_LIB_PATH)\htmlhelp.lib \
$(SDK_LIB_PATH)\shell32.lib \
$(SDK_LIB_PATH)\comctl32.lib \
$(SDK_LIB_PATH)\SHLWAPI.lib \
$(SDK_LIB_PATH)\ntdll.lib \
$(SDK_LIB_PATH)\kernel32.lib \
$(SDK_LIB_PATH)\setupapi.lib \
$(SDK_LIB_PATH)\aclui.lib \
$(SDK_LIB_PATH)\htmlhelp.lib \
$(SDK_LIB_PATH)\uuid.lib

MFC_VER=71
#MSVCRT=1
#PLATFORM_MFC_VER=0x0600
MFC_INCLUDES=d:\WINDDK\3790.1830\inc\mfc8\include
MFC_LIB_PATH=d:\WINDDK\3790.1830\inc\mfc8\lib*\
MFC_LIBS=d:\WINDDK\3790.1830\inc\mfc8\lib*\
USE_MFCUNICODE=1
#USE_STATIC_MFC=1
#USE_LIBCMT=1
#USE_STL=1
USE_ATL=1

#MSC_WARNING_LEVEL=/W1

C_DEFINES=$(C_DEFINES) -D_UNICODE=1

#DEBUG_CRTS=1
#MSC_OPTIMIZATION=/Od

UMTYPE=windows

#BUFFER_OVERFLOW_CHECKS=NTDLL

LANGUAGE_NEUTRAL=0

LINKER_FLAGS=$(LINKER_FLAGS)

PRECOMPILED_CXX = 1
PRECOMPILED_INCLUDE = stdafx.h
PRECOMPILED_SOURCEFILE = stdafx.cpp

SOURCES= \
objdir.rc \
mainfrm.cpp \
ntobject.cpp \
objectdirectoryview.cpp \
objectview.cpp \
privobji.cpp \
security.cpp \
objdir.cpp \
objdirdoc.cpp \
objdirview.cpp

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

6

I know this is problem for some of you and we’re trying to get a better
answer. We very much want to avoid the situation where you have to
merge VS components with a DDK build environment. Getting ATL/STL/MFC
8.0 into the DDK has proven to be a bit trickier for a few reasons. Our
goal is to allow partners to build all parts of a device solution w/in
the DDK (WDK), but achieving that isn’t always going to be possible.

If requiring you to merge these components from a VS install will
disrupt your line-of-business, please send me a short email describing
the impact.

Thanks,
Richard Moore
LPM WDK Team

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
Sent: Friday, January 06, 2006 8:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DDKs and MFC applications, what is going on

On Jan 6, 2006, at 9:43 AM, Mark J. Cariddi wrote:

I hope someone at MS is listening becuase I am getting really
frustrated with build. For years I have been writing Driver
community tools with MFC and have been using the DDK to build them
since a lot of the tools I build include drivers. Recently in the
process of upgrading the utilities I have moved to later versions of
MFC and visual studio (Yes, I am using 2005) and have used some of the
new classes or functions in classes. Well, now I can no longer get
my stuff to build with the DDK because all that is in there is MFC42.

I agree - it seems like the method of setting up a DDK is something
like “do the minimum it takes to get the sample code building”. I
wish Microsoft would provide better support for building user-mode
stuff through build, and I’ve given them that feedback at every
opportunity for the last couple of years.

-sd

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

My email: xxxxx@windows.microsoft.com

and if you have general WDK feedback that you want to get to us
directly, feel free to use xxxxx@microsoft.com

Thanks,
Richard

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Richard Moore
(DDK)
Sent: Friday, January 06, 2006 12:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKs and MFC applications, what is going on

I know this is problem for some of you and we’re trying to get a better
answer. We very much want to avoid the situation where you have to
merge VS components with a DDK build environment. Getting ATL/STL/MFC
8.0 into the DDK has proven to be a bit trickier for a few reasons. Our
goal is to allow partners to build all parts of a device solution w/in
the DDK (WDK), but achieving that isn’t always going to be possible.

If requiring you to merge these components from a VS install will
disrupt your line-of-business, please send me a short email describing
the impact.

Thanks,
Richard Moore
LPM WDK Team

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
Sent: Friday, January 06, 2006 8:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DDKs and MFC applications, what is going on

On Jan 6, 2006, at 9:43 AM, Mark J. Cariddi wrote:

I hope someone at MS is listening becuase I am getting really
frustrated with build. For years I have been writing Driver
community tools with MFC and have been using the DDK to build them
since a lot of the tools I build include drivers. Recently in the
process of upgrading the utilities I have moved to later versions of
MFC and visual studio (Yes, I am using 2005) and have used some of the
new classes or functions in classes. Well, now I can no longer get
my stuff to build with the DDK because all that is in there is MFC42.

I agree - it seems like the method of setting up a DDK is something
like “do the minimum it takes to get the sample code building”. I
wish Microsoft would provide better support for building user-mode
stuff through build, and I’ve given them that feedback at every
opportunity for the last couple of years.

-sd

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

Hi Richard,

On Jan 6, 2006, at 2:02 PM, Richard Moore ((DDK)) wrote:

If requiring you to merge these components from a VS install will
disrupt your line-of-business, please send me a short email describing
the impact.

The main impact is that it makes maintainability painful going
forward. Any dev shop of sufficient size will have to hire new
developers eventually, and having a Franken-Kit is a great way to
slow them down in becoming useful. Add to that the fact that
combining dev environments in unsupported ways is much more likely to
break (witness: Mark’s original case in starting the thread).

One thing that I have seen happen is that people get their dev
environment set up perfectly, once, and then they proceed to get
locked into it forever because they can’t figure out how to upgrade
it for new kits, SDKs, etc. This is bad for ISVs, and it’s bad for
Microsoft, in the sense that new features are not taken advantage of.
Take strsafe as an example - Microsoft has a clear vested interest in
getting the development community to use the strsafe functions
(improving customer perception of Windows quality), but if upgrading
to a strsafe-supported DDK is too painful, it just won’t happen.
Franken-Kits are a great way to cause just this problem.

With that said, I really am impressed with the progress that the DDK
team has made in the past few years. In a way, it’s in a similar
position to the one articulated in the Linux thread that is also
running at the moment - lots of incremental improvements made without
a ton of fanfare, but that add up to a greatly improved kit.

-sd

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

9

Richard Moore (DDK) wrote:

I know this is problem for some of you and we’re trying to get a better
answer. We very much want to avoid the situation where you have to
merge VS components with a DDK build environment. Getting ATL/STL/MFC
8.0 into the DDK has proven to be a bit trickier for a few reasons. Our
goal is to allow partners to build all parts of a device solution w/in
the DDK (WDK), but achieving that isn’t always going to be possible.

This is a terrible problem to have to solve. I don’t know how many of
you remember the Bad Old Days, when you had to provide your own compiler
tools and SDKs, but a lot of time was wasted chasing down problems
caused by a combination of tools and SDKs that did not match the
Microsoft “preferred” solution. This was almost completely eliminated
by the inclusion of the compiler and SDK files in the DDK.

And for a long time, this has been an ideal solution for normal
development, because the compiler was stable for so long. VC++ 6.0 was
the gold standard for a long time, so the fact that the DDK included it
and its tools was perfect. Now, we have several reasonable compilers,
and lots of auxiliary tool sets.

I’m not convinced that it is reasonable to require the DDK to include
all of that. Perhaps what is needed is a well-defined way to “hook”
into MFC and ATL from whichever recent Visual Studio the user has
installed. Since those libraries would only be used for non-driver
projects, it is not unreasonable to expect the end user to provide his own.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

10

The flip side of this is to not combine VS and DDK components but to create
a development environment that supports both toolsets. This avoids the
‘franken-kit’ problem, although it does require a bit of upfront work to
make the toolsets work and play well together, and as there is no standard
way to do this, that development environment will require its own
maintenance effort.

Lots of development shops work this way - they have gui components built
within the VS world that interface with kernel or service components build
within the DDK world. Where you get into trouble is when you try to force
one or the other of these unfortunately disparate environments to build
using the other’s toolset.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
Sent: Friday, January 06, 2006 3:33 PM
To: Windows System Software Devs Interest List
Cc: Richard Moore ((DDK))
Subject: Re: [ntdev] DDKs and MFC applications, what is going on

Hi Richard,

On Jan 6, 2006, at 2:02 PM, Richard Moore ((DDK)) wrote:
> If requiring you to merge these components from a VS install will
> disrupt your line-of-business, please send me a short email
describing
> the impact.

The main impact is that it makes maintainability painful
going forward. Any dev shop of sufficient size will have to
hire new developers eventually, and having a Franken-Kit is a
great way to slow them down in becoming useful. Add to that
the fact that combining dev environments in unsupported ways
is much more likely to break (witness: Mark’s original case
in starting the thread).

One thing that I have seen happen is that people get their
dev environment set up perfectly, once, and then they proceed
to get locked into it forever because they can’t figure out
how to upgrade it for new kits, SDKs, etc. This is bad for
ISVs, and it’s bad for Microsoft, in the sense that new
features are not taken advantage of.
Take strsafe as an example - Microsoft has a clear vested
interest in getting the development community to use the
strsafe functions (improving customer perception of Windows
quality), but if upgrading to a strsafe-supported DDK is too
painful, it just won’t happen.
Franken-Kits are a great way to cause just this problem.

With that said, I really am impressed with the progress that
the DDK team has made in the past few years. In a way, it’s
in a similar position to the one articulated in the Linux
thread that is also running at the moment - lots of
incremental improvements made without a ton of fanfare, but
that add up to a greatly improved kit.

-sd

Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

11

I would concur with Mark here, for instance I still use VC6 for most of my
user space GUI stuff since that is what the customers want. I guess this
will change since VC6 does not run on Vista.

What might be desirable is a good way to invoke one from the other. We have
Mark’s DDKbuild to invoke the DDK from VS, it would be desirable to find a
good way to invoke a VS project from build.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> The flip side of this is to not combine VS and DDK components but to
> create
> a development environment that supports both toolsets. This avoids the
> ‘franken-kit’ problem, although it does require a bit of upfront work to
> make the toolsets work and play well together, and as there is no standard
> way to do this, that development environment will require its own
> maintenance effort.
>
> Lots of development shops work this way - they have gui components built
> within the VS world that interface with kernel or service components build
> within the DDK world. Where you get into trouble is when you try to force
> one or the other of these unfortunately disparate environments to build
> using the other’s toolset.
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>

12

In our shop all native lusermode development is done with visual studio
(6.0, 2003/5) environment and all kernel mode development is done with ddk
build environment. Some devs like to use visual studio as editor for kernel
mode as well as user mode and some like to use other editors (emacs, vim)
and we all use ddkbuild.bat …

… my opinion the setup sucks but it works :slight_smile:

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> The flip side of this is to not combine VS and DDK components but to
> create
> a development environment that supports both toolsets. This avoids the
> ‘franken-kit’ problem, although it does require a bit of upfront work to
> make the toolsets work and play well together, and as there is no standard
> way to do this, that development environment will require its own
> maintenance effort.
>
> Lots of development shops work this way - they have gui components built
> within the VS world that interface with kernel or service components build
> within the DDK world. Where you get into trouble is when you try to force
> one or the other of these unfortunately disparate environments to build
> using the other’s toolset.
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Steve Dispensa
>> Sent: Friday, January 06, 2006 3:33 PM
>> To: Windows System Software Devs Interest List
>> Cc: Richard Moore ((DDK))
>> Subject: Re: [ntdev] DDKs and MFC applications, what is going on
>>
>> Hi Richard,
>>
>> On Jan 6, 2006, at 2:02 PM, Richard Moore ((DDK)) wrote:
>> > If requiring you to merge these components from a VS install will
>> > disrupt your line-of-business, please send me a short email
>> describing
>> > the impact.
>>
>> The main impact is that it makes maintainability painful
>> going forward. Any dev shop of sufficient size will have to
>> hire new developers eventually, and having a Franken-Kit is a
>> great way to slow them down in becoming useful. Add to that
>> the fact that combining dev environments in unsupported ways
>> is much more likely to break (witness: Mark’s original case
>> in starting the thread).
>>
>> One thing that I have seen happen is that people get their
>> dev environment set up perfectly, once, and then they proceed
>> to get locked into it forever because they can’t figure out
>> how to upgrade it for new kits, SDKs, etc. This is bad for
>> ISVs, and it’s bad for Microsoft, in the sense that new
>> features are not taken advantage of.
>> Take strsafe as an example - Microsoft has a clear vested
>> interest in getting the development community to use the
>> strsafe functions (improving customer perception of Windows
>> quality), but if upgrading to a strsafe-supported DDK is too
>> painful, it just won’t happen.
>> Franken-Kits are a great way to cause just this problem.
>>
>> With that said, I really am impressed with the progress that
>> the DDK team has made in the past few years. In a way, it’s
>> in a similar position to the one articulated in the Linux
>> thread that is also running at the moment - lots of
>> incremental improvements made without a ton of fanfare, but
>> that add up to a greatly improved kit.
>>
>> -sd
>>
>>
>>
>> ----------------------------------
>> Steve Dispensa
>> MVP - Windows DDK
>> www.kernelmustard.com
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@hollistech.com To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
>
>

13

Actually all I do is put makefiles around the entire mess. I know -
state of the art circa 1979, but what can I say, I be dinosaur. From my
makefiles I build whatever I want, vs projects, ddk projects, who cares,
it’s a makefile.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, January 06, 2006 4:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKs and MFC applications, what is going on

I would concur with Mark here, for instance I still use VC6 for most of
my
user space GUI stuff since that is what the customers want. I guess
this
will change since VC6 does not run on Vista.

What might be desirable is a good way to invoke one from the other. We
have
Mark’s DDKbuild to invoke the DDK from VS, it would be desirable to find
a
good way to invoke a VS project from build.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> The flip side of this is to not combine VS and DDK components but to
> create
> a development environment that supports both toolsets. This avoids the
> ‘franken-kit’ problem, although it does require a bit of upfront work
to
> make the toolsets work and play well together, and as there is no
standard
> way to do this, that development environment will require its own
> maintenance effort.
>
> Lots of development shops work this way - they have gui components
built
> within the VS world that interface with kernel or service components
build
> within the DDK world. Where you get into trouble is when you try to
force
> one or the other of these unfortunately disparate environments to
build
> using the other’s toolset.
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

14

A related question to this topic
I am using make files to build the product that has a lot of user
components and a few drivers. I am using VC7’s compiler to build
everything (including drivers).

VC7’s cl.exe version # is 13.10.3077.
My ddk is 3790 and cl.exe in bin\x86 directory has version #13.10.2179.

Now having built my drivers using VC7 compiler, I do not see any obvious
problems with them. They seem to be working fine for both wnet and w2k.

Should I be concerned about the VC7 compiler being used for drivers?
Should I be using ddk’s cl.exe?

Thanks for the help
Harish

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-233128-
xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Friday, January 06, 2006 1:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKs and MFC applications, what is going on

Actually all I do is put makefiles around the entire mess. I know -
state of the art circa 1979, but what can I say, I be dinosaur. From
my
makefiles I build whatever I want, vs projects, ddk projects, who
cares,
it’s a makefile.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, January 06, 2006 4:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKs and MFC applications, what is going on

I would concur with Mark here, for instance I still use VC6 for most
of
my
user space GUI stuff since that is what the customers want. I guess
this
will change since VC6 does not run on Vista.

What might be desirable is a good way to invoke one from the other.
We
have
Mark’s DDKbuild to invoke the DDK from VS, it would be desirable to
find
a
good way to invoke a VS project from build.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Mark Roddy” wrote in message
news:xxxxx@ntdev…
> > The flip side of this is to not combine VS and DDK components but to
> > create
> > a development environment that supports both toolsets. This avoids
the
> > ‘franken-kit’ problem, although it does require a bit of upfront
work
> to
> > make the toolsets work and play well together, and as there is no
> standard
> > way to do this, that development environment will require its own
> > maintenance effort.
> >
> > Lots of development shops work this way - they have gui components
> built
> > within the VS world that interface with kernel or service components
> build
> > within the DDK world. Where you get into trouble is when you try to
> force
> > one or the other of these unfortunately disparate environments to
> build
> > using the other’s toolset.
> >
> > =====================
> > Mark Roddy DDK MVP
> > Windows 2003/XP/2000 Consulting
> > Hollis Technology Solutions 603-321-1032
> > www.hollistech.com
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com

15

Absolutely you should be concerned. The DDK specifically states that
drivers MUST be built with the DDK compiler, and there is been a veritable
plethora of rants and raves here about using anything other than the
compiler in the latest DDK. If you don’t use the DDK compiler you open
yourself up to subtle differences between the VS and DDK compilers that
MAY cause you grief and even loss of revenue, or employment, should the VS
compiler introduce one of those anomalies that causes a critical system to
fail at a critical time.

If you can guarantee this will never EVER happen … the sure … build
away with the VS compilers. But you will find that many of us here will
avoid and not recommend such a product.

Gary G. Little

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Harish Arora
Sent: Friday, January 06, 2006 5:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKs and MFC applications, what is going on

A related question to this topic
I am using make files to build the product that has a lot of user
components and a few drivers. I am using VC7’s compiler to build
everything (including drivers).

VC7’s cl.exe version # is 13.10.3077.
My ddk is 3790 and cl.exe in bin\x86 directory has version #13.10.2179.

Now having built my drivers using VC7 compiler, I do not see any obvious
problems with them. They seem to be working fine for both wnet and w2k.

Should I be concerned about the VC7 compiler being used for drivers?
Should I be using ddk’s cl.exe?

Thanks for the help
Harish

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-233128-
xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Friday, January 06, 2006 1:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DDKs and MFC applications, what is going on

Actually all I do is put makefiles around the entire mess. I know -
state of the art circa 1979, but what can I say, I be dinosaur. From
my
makefiles I build whatever I want, vs projects, ddk projects, who
cares,
it’s a makefile.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, January 06, 2006 4:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKs and MFC applications, what is going on

I would concur with Mark here, for instance I still use VC6 for most
of
my
user space GUI stuff since that is what the customers want. I guess
this
will change since VC6 does not run on Vista.

What might be desirable is a good way to invoke one from the other.
We
have
Mark’s DDKbuild to invoke the DDK from VS, it would be desirable to
find
a
good way to invoke a VS project from build.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Mark Roddy” wrote in message
news:xxxxx@ntdev…
> > The flip side of this is to not combine VS and DDK components but to
> > create
> > a development environment that supports both toolsets. This avoids
the
> > ‘franken-kit’ problem, although it does require a bit of upfront
work
> to
> > make the toolsets work and play well together, and as there is no
> standard
> > way to do this, that development environment will require its own
> > maintenance effort.
> >
> > Lots of development shops work this way - they have gui components
> built
> > within the VS world that interface with kernel or service components
> build
> > within the DDK world. Where you get into trouble is when you try to
> force
> > one or the other of these unfortunately disparate environments to
> build
> > using the other’s toolset.
> >
> > =====================
> > Mark Roddy DDK MVP
> > Windows 2003/XP/2000 Consulting
> > Hollis Technology Solutions 603-321-1032
> > www.hollistech.com
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

16

Yeah, you should build with the official DDK. You might wind up with
working code, but if you ever need support (from us or Microsoft),
that will be the first thing they/we tell you to change.

General rule: only salmons should swim upstream.

-sd

On Jan 6, 2006, at 4:59 PM, Harish Arora wrote:

A related question to this topic
I am using make files to build the product that has a lot of user
components and a few drivers. I am using VC7’s compiler to build
everything (including drivers).

VC7’s cl.exe version # is 13.10.3077.
My ddk is 3790 and cl.exe in bin\x86 directory has version
#13.10.2179.

Now having built my drivers using VC7 compiler, I do not see any
obvious
problems with them. They seem to be working fine for both wnet and
w2k.

Should I be concerned about the VC7 compiler being used for drivers?
Should I be using ddk’s cl.exe?

Thanks for the help
Harish

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-233128-
> xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
> Sent: Friday, January 06, 2006 1:48 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] DDKs and MFC applications, what is going on
>
> Actually all I do is put makefiles around the entire mess. I know -
> state of the art circa 1979, but what can I say, I be dinosaur. From
my
> makefiles I build whatever I want, vs projects, ddk projects, who
cares,
> it’s a makefile.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
> Sent: Friday, January 06, 2006 4:26 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] DDKs and MFC applications, what is going on
>
> I would concur with Mark here, for instance I still use VC6 for most
of
> my
> user space GUI stuff since that is what the customers want. I guess
> this
> will change since VC6 does not run on Vista.
>
> What might be desirable is a good way to invoke one from the other.
We
> have
> Mark’s DDKbuild to invoke the DDK from VS, it would be desirable to
find
> a
> good way to invoke a VS project from build.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Mark Roddy” wrote in message
> news:xxxxx@ntdev…
>>> The flip side of this is to not combine VS and DDK components but to
>>> create
>>> a development environment that supports both toolsets. This avoids
> the
>>> ‘franken-kit’ problem, although it does require a bit of upfront
> work
>> to
>>> make the toolsets work and play well together, and as there is no
>> standard
>>> way to do this, that development environment will require its own
>>> maintenance effort.
>>>
>>> Lots of development shops work this way - they have gui components
>> built
>>> within the VS world that interface with kernel or service components
>> build
>>> within the DDK world. Where you get into trouble is when you try to
>> force
>>> one or the other of these unfortunately disparate environments to
>> build
>>> using the other’s toolset.
>>>
>>> =====================
>>> Mark Roddy DDK MVP
>>> Windows 2003/XP/2000 Consulting
>>> Hollis Technology Solutions 603-321-1032
>>> www.hollistech.com
>>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@stratus.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://
> www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com

----------------------------------
Steve Dispensa
MVP - Windows DDK
www.kernelmustard.com

17

That is actually a very good style IMHO and not dinosaur at all!!

I dont think “build” itself is state of the art. Development tools have
moved far ahead today, check out JAM/CMake/Ant. JAM in particular allows you
parallel builds/ a cool rule based system / the ability to continue build
even if a disconnected region of your build graph fails and of course it is
cross platform. The advantage of JAM is that it clearly distinguishes
between the build process ,( read dependency graph and directory hierarchy)
from the platform dependent parts viz., compiler/linker and their flags. I m
afraid build does not do so.

IDE - Build System - Compiler/Linker are 3 different things and IMHO should
be kept separate to mix and match at ones convenience. I am not sure if it
is possible but it would be really nice if there was a way to extract the
correct compiler / linker flags for each DDK from build.exe. In a neat rule
based system like JAM, you can then pass these as arguments to a rule which
does kernel build for windows. A nice way to have your own unified
crossplatform build system for Linux/Windows kernel/user mode development.

Later you can spawn this build system from any IDE you like ( my particular
favourites are emacs/eclipse ). My only expectation from an IDE vis-a-vis
the build process is pretty much what M-x compile in emacs does, spawn the
process, spit out its text output in a separate buffer and later upon
highlighting it ,open the relevant region of the code in the main code
buffer.

banks

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
Actually all I do is put makefiles around the entire mess. I know -
state of the art circa 1979, but what can I say, I be dinosaur. From my
makefiles I build whatever I want, vs projects, ddk projects, who cares,
it’s a makefile.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, January 06, 2006 4:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] DDKs and MFC applications, what is going on

I would concur with Mark here, for instance I still use VC6 for most of
my
user space GUI stuff since that is what the customers want. I guess
this
will change since VC6 does not run on Vista.

What might be desirable is a good way to invoke one from the other. We
have
Mark’s DDKbuild to invoke the DDK from VS, it would be desirable to find
a
good way to invoke a VS project from build.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Mark Roddy” wrote in message news:xxxxx@ntdev…
> The flip side of this is to not combine VS and DDK components but to
> create
> a development environment that supports both toolsets. This avoids the
> ‘franken-kit’ problem, although it does require a bit of upfront work
to
> make the toolsets work and play well together, and as there is no
standard
> way to do this, that development environment will require its own
> maintenance effort.
>
> Lots of development shops work this way - they have gui components
built
> within the VS world that interface with kernel or service components
build
> within the DDK world. Where you get into trouble is when you try to
force
> one or the other of these unfortunately disparate environments to
build
> using the other’s toolset.
>
> =====================
> Mark Roddy DDK MVP
> Windows 2003/XP/2000 Consulting
> Hollis Technology Solutions 603-321-1032
> www.hollistech.com
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

18

> into MFC and ATL from whichever recent Visual Studio the user has

For me, ATL is fine with the DDK.

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

19

Could you expand on that? I did install VS6 on beta 1, however I can’ t
recall if I fired up VC or not (pretty sure I did; I think)… Other
portions of VS6 worked fine as long as you executed the exe directly;
the start menu and shortcuts were useless…

Don Burn wrote:

I guess this
will change since VC6 does not run on Vista.

20

I honestly don’t remember the details there was a discussion on
microsoft.beta.longhorn.developer_support. Aso since Microsoft is pulling
VS6 from MSDN due to there being some Java in there. Of course the people
who are screaming the most are the VB 6 folks, since there is a rewrite to
move to .NET

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“MM” wrote in message news:xxxxx@ntdev…
> Could you expand on that? I did install VS6 on beta 1, however I can’ t
> recall if I fired up VC or not (pretty sure I did; I think)… Other
> portions of VS6 worked fine as long as you executed the exe directly; the
> start menu and shortcuts were useless…
>
> Don Burn wrote:
>
>> I guess this will change since VC6 does not run on Vista.
>>
>
>