Very Computer

Ever since installing Visual C++ 6.0, programs compiled with Visual C++ 5.0
crash with access violations. I've found it necessary to find a copy of the
old MFC DLLs and copy them into the same directory as the executable so the
older programs will start up without crashing. I suspect this is the reason
Personal Web Server keeps crashing on me with similar errors.

If even Microsoft's development tools are broken, no wonder they even have
to recall service packs to be patched now.

Microsoft: Quality is job 3.1.

No, MFC 6.0 (internal version number) is not truly backward compatible with
MFC 4.21.

In our app, we have trouble with ActiveX objects (we are a container) and
tool tips (we have some extended functionality to allow user customization)
when the version built with VC++ 5.0 (and installed on thousands of machines
around the world) is run with the new DLLs.

I was a beta tester, so to some degree it is my own fault for not testing
more extensively, but I am also an hourly consultant and it isn't fair to my
client to bill for testing MS products (past a point; some is justified as a
trade off for getting to see the product early). I just made sure it built
and then did some baseline usability testing.

I hate to guess what the total cost of testing will be. Every product built
and shipped with 4.2 through 5.0 SP3 is at risk. It isn't just MFC, BTW. PWS
was broken by MSVCRT.

I hope they fire the moron that made the decision to keep the same DLL
names.

-Andy

I have the same problem, anyone know if the service pack works? I've tried
it and no joy....some applications won't even start...this is a real pain!

Anyone managed to fix it without having to install windows again?

Steve.

I just dl'd the Service Pack and installed it. Despite the notes for it that
suggest that it will resolve the issues with VC++ 5 programs that use the
old dll's, I am still getting the same errors that I had before.

The only way I have been able to resolve them is by renaming the new dll's
and putting the old ones back in my WINDOWS/SYSTEM directory.

I think there is still a lot more to be done to have VC++ 5 programs work or
vendors will have to put out updates using VC++ 6.

Why couldn't MS have just named the new ones differently if there were known
compatibility problems?

John G.

Quote:>I have the same problem, anyone know if the service pack works? I've tried
>it and no joy....some applications won't even start...this is a real pain!

>Anyone managed to fix it without having to install windows again?

>Steve.

Weve only seen the problem with the MFC debug dlls. The release dlls are
backwards compatible.

Any debug versions of our software we have to ensure dont run with the
new mfc debug dlls in the system32 or path.

-Adam

This means that in your application, either you have no problems or have
detected no problems. It doesn't mean the DLLs are backward compatible. I
suspect that less than 20% of developers will have a problem, but that
number is way too high. In our case, new CDs will have to be created, run
through the normal QA cycle, mass copied and shipped to thousands of users,
all highly paid professionals who will spend time installing it. All we will
do is relink the existing VC5 version statically, because it doesn't work
right with the new MFC42.DLL. I would guess that the total cost to the
organization will be somewhere between $50K. Multiply that times how many
other developers will hit this, and this is an expensive debacle.

-Andy

That would be far to good for that particular idiot. I just can't wait
until commerical apps start shipping with these broken VC6 DLL's and
existing VC5-built apps suddenly start crashing.

Of course, there's also still the problem with debug dll's. I still
can't run any apps built with debug info under VC5 with the VC6 dll's on
the system.

I was truely disappointed that MS did this in the original release. I'm
stunned that they didn't resolve it in the patch. Gross negligence in my
book.

Greg

You're right. As time as gone by, I have found more problems and have
stronger feelings about what they should do. I finally sent a rant to

out that the title is sexist; I'll admit it. Only one of us guys would do
something so stupid. ;^>

-Andy

Well, serving up his head on a pike sounds reasonable to me; but, I'm
sure that's not what you meant. ;>

Please let us know if you get any response. We all make mistakes and
sometimes really bad things get by us; but, I just can't believe they
didn't fix this in the patch. I'm curious if they will give you a
meaningful response.

Greg

Greg,

Quote:> I was truely disappointed that MS did this in the original release. I'm
> stunned that they didn't resolve it in the patch. Gross negligence in my
> book.

AGREED! Totally! I couldn't have said it better myself.

I am just in complete shock. I REALLY, truly thought it was just my
machine -- you know something I did wrong, *ed up or whatever.

But, then I went to somebody else's machine... and read this thread...

This is totally unacceptable.

Has Microsoft even ADDRESSED this issue? I just assumed this was fixed
with the Service Pack. Wow.

I'm speechless. I am without speech. :-)

  Alan

I understand it was this way in the final beta(s) too, so I must
conclude they decided it wasn't that important or there's a technical
reason that it isn't desireable to resolve - like the cure is worse than
the disease.

Supposedly, it only effects the debug dll's. There's a number of posts
indicating problems with shipping libs; but, there's a doc on the
support board indicating such problems are because the new libs are less
tolerant of memory overwrites and multiple calls to free on the same
address. Well, I guess that's at least sort'a, kind'a believable.

Greg

Greg,

alias without getting a single reply. That is somewhat unusual. In the past,
I typically got at least one or two follow ups when I reported a problem,
and my first couple of messages about this problem(s), were explicit
descriptions without any venom. After failing to get any response, I got mad
and sent mail that is a bit antagonistic. I am not surprised too much that
they ignored that.

At this point, a head on a pike is beginning to sound reasonable. But all I
really want is for them to fix this mess.

The very nature of C++ makes it impossible to do anything but make fixes to
a class library and still retain complete compatibility. You can add classes
and still retain binary compatibility (name collisions happen at compile
time, not run time), but you can't add virtual functions or change behavior
without putting existing code at risk.

-Andy

It almost seems that this belongs in alt.*!

I had some thoughts along the same line, though not as deep and gloomy as
yours. It occurred to me that nearly all developers who have applications in
the field that use MFC42.DLL must now buy VC++ 6.0 to see if there are
problems with the new DLLs and debug them if there are. There are a lot of
people using 4.2 and 5.0 that have not had a compelling reason to update.
They have one now...

[...]

Please cite a specific example of MS purposely changing something in
MFC42.DLL or MSVCRT.DLL that would break binary compatibility with
apps that were not depending on undocumented features or classes and
weren't just plain buggy. (NOTE: I'm *not* talking about the
deliberate incompatibilities in the debug DLLs, which aren't
redistributable and which do not pose a problem for end users.)

I'm interested in hearing about incompatibilities concerning
documented features that weren't addressed by SP1. This is of interest
to everyone using VC6, but all I seem to hear are generic flames and
* theories, which are absolutely useless, and I'd hate to
base a decision concerning replacement of the system DLLs on such.
Talk about FUD!

BTW, MS left the DLL names alone (MS *did* increment the version
numbers) in order to avoid an explosion of different DLLs taking up
space on disk and in memory and slowing down application load times.
This is a good goal, but perhaps overly optimistic.

Quote:>I can recall two quotes that help back up this claim... the first is from a
>manager of desktop applications at MS.  When asked how far MS would go in
>pursuing the desktop applications market, he said:
>    "We only want a fair percentage of the desktop applications market,
>     and for us, a fair percentage is 100%."

>And of course, the obligatory Bill quote, which came up when he was asked why
>Microsoft was growing so much more quickly than its competitors:
>    "They are hampered by the concept of finite greed."

>The quotes may not be verbatim, but the sentiment is right, trust me.

These "non-verbatim quotes" don't help back up your claim at all. In
fact, above, you passed up a chance to give one of your accusations
some substance.

--
Doug Harrison