Re: Migrating an application from ( VC6.0 to ) vs 2003 in MFC/C++
to VS2008
Ajay wrote:
On Jun 14, 2:12 pm, Scot T Brennecke <Sc...@Spamhater.MVPs.org> wrote:
Ajay wrote:
On Jun 12, 7:44 am, Scot T Brennecke <Sc...@Spamhater.MVPs.org> wrote:
Ajay wrote:
On Jun 11, 12:29 am, Scot T Brennecke <Sc...@Spamhater.MVPs.org>
wrote:
Ajay wrote:
On Jun 10, 5:55 am, Scot T Brennecke <Sc...@Spamhater.MVPs.org> wrote:
Also, to you and Ajay and others: vc7libs is a directory used by the
Microsoft (typically Windows) builds that use the VC++ libraries.
Are you saying that if I have VS2008 and never installed any previous
version, my code will be referening VC7libs directory direclty or
indirectly?
--
Ajay
Not your code, really. Microsoft's code (which may be called by you)
may have been built from source in a vc7libs directory.
I am not sure what you mean by Microsoft's code; you dont mean MFC?
IIRC, OP's assert happned in vc7 in MFC code(at least thats how I saw
it), which implies that OP somewhere (directly or indirectly(com))
still has MFC7 code.
--
Ajay
I mean code in the Windows OS that uses MFC.
I had no idea windows OS uses MFC :-)
--
Ajay
Well, obviously the "core OS" itself (kernel32, ntdll, user32, etc.)
doesn't use MFC. But there are several components/modules distributed
as part of "Windows" that do use MFC.
But you would hope none of this would be tied to a debug version of MFC
(OP's assert ).
Also, last time I checked (thru MSFT), the only time MFC was being
used was in WMI console. That was few years back though.
--
Ajay
Actually, she never did share the full location of the assertion
failure, nor the ASSERT statement that failed. I haven't seen a full
path name to the source file even.
I agree that no released MS code would have a dependency on a debug MFC,
but I still haven't seen the evidence of that. There was only a
roundabout possible implication that the path that contained vc7libs was
somehow related.
If you become really curious, you could open up the various modules in
the System32 folder with Dependency Walker just to see how many modules
are still using the MFC42 DLL. But the only reason that DLL is still in
that folder is that several MS components still use it. It is now
maintained by the Windows development team, with periodic hints from the
VC libraries team about what changes were made in the current MFC, just
in case they need to be back-ported to the OS's version. People who are
still using VC6 and depending on the MFC42 DLL in the Windows
distribution are rolling the dice.