===========================
VC7/Visual Studio.NET Notes
         12/22/02
===========================


WARNING: Use of the /alloc:L option with VC7 (any library)
currently BREAKS error decryption in general. Please don't
use /alloc:L with the VC7 compiler

-----------------------------------------------------------
Always use /WL when compiling! (STLFilt will remind you...)
-----------------------------------------------------------

STLFilt.pl provides Visual Studio.NET support, but ONLY if you
compile using VC7's /WL ("one line") compile option. This condenses
VC7's new multi-line (and massively space-wasting) new error
format into a contiguous-line format.

When the error Decryptor sees messages in the VC7 /WL format,
it processes the "with" clauses by substituting all the
place-holder names with the types they represent. The net effect
(no pun intended) is a return to VC6-style messages, with
more-or-less Dinkumware 3.08 identifier names. There are few
changes from the Dinkumware 3.08 format however; VC7 makes
use of nested typedef names such as "value_type" and "_Pairib"
in its native messages. I've taken the liberty of massaging
those types back into VC6 format as well; I think the
explicit type information makes for more useful error
messages. 

When the /width setting (either via command line or as
configured in the Proxy-CL.INI file) is non-zero, STLFilt
tries to wrap VC7/71 messages intelligently: pathnames
should always appear at the start of lines, multiple candidate
listings (new for VC71) are indented a bit extra to stand out,
and semicolons between parts of the message should always force
a line break. If you notice a case where the heuristics mess
up a message, please let me know...


--------------------------------------------
Running STLTask.EXE without MSVC 6 installed
--------------------------------------------

The Proxy CL should work fine regardless of whether MSVC6
is present on your system or not. 

To use STLTask as distributed, however, you need to have a DLL
named MSVCP60.DLL installed. This DLL presumably
is installed automatically by MSVC6, but is not
supplied with MSVC7 (or at least it wasn't present
on one Win2K system I've tried installing STLTask on).

I've made the file available here:

        http://www.bdsoft.com/dist/missingdll.zip

Download it and install it into either your C:\Windows\System
or your C:\Windows\System32 directory, depending on which
version of Windows you're running.


----------------
Allocator Issues
----------------

An issue arose while integrating .NET support, relating to
the handling of allocator clauses. Previously, I used an
automatic heuristic to detect when the allocator clause was
"significant" (i.e., provided useful information): if the
word "allocator" was preceded by the text " to ", then
presumably the compiler was referring to some kind of error
in converting from "something to" the allocator type, and
we'd probably want to see the details of that type in the
message. All other mentions of allocators were stripped.

This is *still* the way it works when you're not compiling
with VC7. With VC7, the "to...allocator" heuristic fails
miserably, because of the new error message format. So, I
added an "allocator policy" option,  /alloc:x, configurable via
Proxy-CL.INI and/or the Proxy CL and Perl command lines.
You have a choice of either 'S' (Small) or 'L' (Large) allocator
policy, referring to the length of the messages produced.
"Small" pretty much deletes all allocator mentions
indiscriminately, while "Large" leaves them intact. The
default is 'S'.

The allocator policy options are COMPLETELY IGNORED if
you're not compiling with VC7!!!! (I check for those "with"
clauses, and only apply an allocator policy if a "with"
clause was detected on a particular line).

Note that with the "Small" allocator policy, allocator
information will be omitted from messages referring to
allocator errors, so those messages may not make sense. My
suggestion: If you're using custom allocators *AT ALL*
with VC7, set the ALLOCATOR_POLICY in Proxy-CL.INI to L;
otherwise, let it default to S.

Other Function Objects
----------------------

A similar issue arises with function objects in VC7 
messages, and a similar "Functor Policy" option is 
provided: /func:x, with the same choice of Small or 
Large functor expansions. With /func:S, functors are
stripped; with /func:L, they're left intact. The
defaults is 'S'.

As with /alloc, the /func policy option is COMPLETELY 
IGNORED if you're not compiling with VC7.

vector<unsigned> Issue
----------------------

Something weird is happening with vector<unsigned> (at
least under VC7 Beta 1): VC7 seems to be confusing these
with vector<bool>. Just a head's up...the weirdness you
see when using vector<unsigned> is not the decryptor's
fault!