Re: presentation softo [was: MSword reader]

[Jake Morrison <jacob.morrison@example.com>]

shimpei@example.com wrote:
> 
> Stephen Turnbull wrote:
> >     Shimpei> [1] On an even more tangential note, strings(1) is also
> >     Shimpei> eminently useless for plucking strings out of compiled
> >     Shimpei> Visual Basic executables--I guess it must be converting
> >     Shimpei> everything to UTF-16 internally or something. This ruined
> >     Shimpei> my plans to use RCS ident to keep tabs on a project last
> >     Shimpei> year.
> >
> > Hmm.  Now this sounds interesting.  Exactly what do we need here?
> 
> I think all that is needed is a doctored version of RCS for win32 that
> can search an executable file for the UTF-16 representation of "$Id:".
> I think. I tried hacking something up in perl along these lines, but that
> didn't work. strings(1) does uncover quite a bit of the internal symbols
> used by VB--object names, file paths, and other garbage that should have
> been stripped off at compile time but weren't--so I think what's happening
> is that VB is converting any constant string occuring in the code section
> (which is where I have to put the RCS strings) and clobbering them into
> 16-bit-ness at compile time.
> 
> In any case, I've given up on this in disgust long ago. Life is too short to
> be wasted on Visual Basic internals hacking. [1]

Amen! 

Some of our guys wasted incredible amounts of time getting
some UTF-8 data read from the network into VB. It seems that all strings
in VB are UTF-16, but VB "helpfully" converts all data (in both directions)
between UTF-16 and the local character set for the machine (e.g. SJIS). 
I think they ended up making the socket connection "binary", reading the 
data into a buffer, then calling a custom-written COM object to convert 
things into VB strings.

-Jake