VC6sp4

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-08-16 09:15:57

I just found out about this. It only includes a few fixes, but it looks like
the ones they did could make a real difference

http://msdn.microsoft.com/vstudio/sp/vs6sp4/default.asp

STL Issues
A deadlock in a critical section would lock the entire C++ library. This
occurred when the thread associated with a map object that contains
subobjects was destroyed.

Compiler/Linker/Builder Issues
The following issues have been fixed:
Q234511: Code generated by Visual C++ version 6.0 when using the /O2 option
contained extra instructions when compared to code generated by Visual C++
version 5.0, with a potential performance reduction.
Q234602: Code generated with the /Og option would be incorrect when
performing a comparison on a previously postdecremented variable.
Q262515: The /GT compiler option leaves TLSIndex as a constant.
Q167359: If a global object was declared in a file and then referenced from
within the same file using an extern declared identifier, a constructor call
was mistakenly generated for the extern identifier.
Q231872: Using #import could lead to memory leaks if the imported files
threw COM exceptions.
Visual C++ 6.0 would fail with an Internal Compiler Error when a function
had a virtual function as a parameter.

CRT Issues
Q225099: Repeatedly using realloc on small memory blocks eventually caused a
memory access violation.

Debugger Issues
The following debugger issues have been fixed:
Incorrect debug versions of Oleaut32.dll and Msvbvm60.dll included with
Service Pack 3 led to symbolic information errors when debugging.
Q243599: The debugger would occasionally fail when some undecorated names
were passed to it.
Q259726: The debugger would hit invisible breakpoints when stepping over
certain assembly instructions. This also caused a remote system to stop
responding if it was running Windows 2000.
Q259723, Q262698:The debugger would fail when used on fast dual-CPU systems.
Q262698:The debugger would fail when used on fast dual-CPU systems.
Q235434: On systems running Windows NT or Windows 2000, the Attach to
Process dialog box would occasionally be empty.
The debugger would stop functioning when a thread was suspended during a
breakpoint and then later resumed.