Moving to MSVC++.Net
phil
it to the .Net environment but (and sorry if this is a naive question) can I
continue to use standard MFC C++ programming but use the Visual Studio.Net
environment.
If so are there any good pointers on potential problems.
Thanks for any help you can offer
Phil
dar...@gmail.com
.Net features for standard MFC C++ programming. It still allows a
standard interface and you can use the same unmanaged features that you
use in VC++ 6.0, so no worries.
You shouldn't run into any problems other than new options if you
choose to take them.
Darsant
phil
Phil
<dar...@gmail.com> wrote in message
news:1117390128.2...@g49g2000cwa.googlegroups.com...
Daniel James
> I have a perfectly good application in VC++ 6.0 and I dont want
> to convert it to the .Net environment but (and sorry if this is
> a naive question) can I continue to use standard MFC C++
> programming but use the Visual Studio.Net environment.
Yes, you can.
> If so are there any good pointers on potential problems.
Two issues come to mind:
1. The C++ compiler in VS2003 is much more standards-compliant and so
less forgiving of errors in C++ syntax than VC6. In fact, there are
places in which VC6 only accepts incorrect syntax and VC7.1/VS2003
only accepts correct syntax. There aren't many of these, but don't be
surprised if you have to correct a little code because VC7.1 picks up
errors that VC6 didn't.
2. The implementation of some standard classes has changed. In
particular the MFC CString class now uses the ATL CString definition.
This means that some ATL headers will be included in places that they
weren't before, and that can lead to symbol name clashes.
Also, CString implementation in VC6 used a Copy-On-Write mechanism to
avoid storing multiple copies of identical strings. COW causes
problems in multithreaded code, and so is not used in the new
CString. That can lead to an increase in memory use (on the other
hand the new CString uses the small string optimization, so may be
more efficient when storing many small strings).
Cheers,
Daniel.
Alan Klietz
<waste...@nospam.aaisp.org> wrote:
> In article news:<OcwsVRHZ...@TK2MSFTNGP09.phx.gbl>, Phil wrote:
>> I have a perfectly good application in VC++ 6.0 and I dont want
>> to convert it to the .Net environment but (and sorry if this is
>> a naive question) can I continue to use standard MFC C++
>> programming but use the Visual Studio.Net environment.
>
> Yes, you can.
>
Agreed. You can use the Visual Studio .NET IDE and VC7 compiler with the
original MFC libraries (MFC42.DLL). Just point VS.NET at the INCLUDE and
LIB folders from VC6. It requires tweaking a few VC6 MFC headers to make
them C++ standards compilant, such as adding the new keyword "typename" to
template declarations in AFXTEMPL.H and friends.
To get the benefit of /RTC1 or /GZ runtime checking, link with the VC7
version of RunTmChk.lib. Call _RTC_Initialize() and _RTC_Terminate. (Use
lib.exe to remove the duplicate symbol __except_handler3 that clashes with
msvcrt.dll.) You also need the VC7 version of delayimp.lib.
To get the benefit of VC7 stack overrun and buffer-overflow detection, add a
stub for __security_check_cookie.
With these changes you can write MFC apps using Visual Studio.NET that link
with the built-in MFC42.DLL. You do not need to ship the bulky
MFC71xx.DLLs.
Regards,
Alan Klietz
Algin Technology LLC
alank-at-algintech-NOSPAM-dot-com
phil
Phil
"Alan Klietz" <al...@newsgroup.nospam> wrote in message
news:%232bgMMS...@TK2MSFTNGP14.phx.gbl...
Alan Klietz
<ph...@oakleafsoftware.co.nospam> wrote:
An easier way to get Visual Studio 2003 and 2005 C/C++ compilers to build
legacy applications is to include the C/C++ header files from Windows Server
2003 SP1 Platdorm SDK. These were quietly rewritten by Microsoft to allow
64-bit recompilation of legacy 32-bit code. But as a side effect they
effectively extend the life of VC6 for all platforms. This is because the
PSDK bundles the VS 2005 compiler (version 14.0) to build VC6 compatible
apps for 64-bit.
You won't be able to use the 64-bit compiler bundled with the PSDK on your
32-bit apps. But you can use Visual Studio 2005's 32-bit compiler with the
new PSDK. Just point Visual Studio IDE's INCLUDE folders at the PSSDK
folders: include\mfc, include\atl, and include\crt. Point the LIB folder
to your original VC6 installation. Now you can compile with Visual Studio
2005 and link correctly with MFC42.LIB and MSVCRT.LIB while enjoying all the
new IDE goodies and security checking. (You still need the VS 2005 version
of RunTmChk.lib and sehprolg.obj, and write the __security_check_cookie
stub.)
Using the old libraries is especially handy when building lightweight ATL
ActiveX controls that download with minimal size. Visual Studio 2005
normally requires you bundle several megabytes of DLLs with your application
(MFC80.DLL, MSVCR80.dll, MSVCP80.DLL, etc). In contrast
MFC42.DLL/MSVCRT.DLL version 6 have been ubiquitious and stable since at
least Windows 2000 SP2 and Windows 98 SE.
This way you can enjoy the benefits of the newer compiler technology while
keeping your application small. I recompiled over 100000 lines of legacy
MFC code from VC6 and it worked flawlessly. In fact the new optimizer with
/W4 caught several latent bugs that were lurking in the code previously.
Regards,
Alan Klietz
Algin Technology LLC
alank-at-algintech-NOSPAM-dot-com
P.S. Note: the C++ STL headers still need manual fixes. See
http://www.dinkumware.com/vc_fixes.html. You will need to merge in the
Dinkumware fixes into new STL include files by hand. Exception: The PSSDK
include file for <DEQUE> is radically different and should be used in lieu
of the Dinkumware fix.