initial commit, including theme

1 files changed, 87 insertions, 0 deletions

diff --git a/content/posts/2004-04-07-party-like-it-s-1992.html b/content/posts/2004-04-07-party-like-it-s-1992.html
new file mode 100644
index 0000000..427202b
--- /dev/null
+++ b/content/posts/2004-04-07-party-like-it-s-1992.html
@@ -0,0 +1,87 @@
+---
+date: "2004-04-07T21:41:10Z"
+title: Party Like It's 1992
+---
+
+<p>
+I've been using <a
+href='http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/cryptography_objects.asp'><acronym
+title='Cryptographic API Component Object Model'>CAPICOM</acronym></a>
+at work.  Since most <acronym
+title='Component Object Model'>COM</acronym> objects are supposed to
+work with <a href='http://msdn.microsoft.com/vbasic/'><acronym
+title='Visual Basic'>VB</acronym></a>, the string values returned by
+<acronym title='Component Object Model'>COM</acronym> functions (in my
+case <a
+href='http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/certificate_export.asp'>CAPICOM::Certificate.Export()</a>)
+have some bizarre and baroque semantics when called from C++.  One quirk
+I found particularly amusing was the memory allocation behind <a
+href='http://msdn.microsoft.com/library/default.asp?url=/library/en-us/automat/htm/chap6_7isy.asp'><acronym
+title='Binary STRing'>BSTR</acronym></a>s; here's what <a
+href='http://blogs.gotdotnet.com/ericli/permalink.aspx/853ae05f-7610-4531-ab1b-070695e61168'>"Eric's
+Complete Guide to BSTR Semantics"</a> has to say about what's 
+happening under the hood for <a
+href='http://msdn.microsoft.com/library/default.asp?url=/library/en-us/automat/htm/chap6_7isy.asp'><acronym
+title='Binary STRing'>BSTR</acronym></a>s:
+</p>
+
+<blockquote cite='http://blogs.gotdotnet.com/ericli/permalink.aspx/853ae05f-7610-4531-ab1b-070695e61168'>
+<p>
+COM code uses the BSTR to store a Unicode string, short for "Basic
+String". (So called because this method of storing strings was developed
+for OLE Automation, which was at the time motivated by the development
+  of the Visual Basic language engine.)
+</p>
+
+<p>...</p>
+
+<p>
+<ol>
+<li>If you write a function which takes an argument of type BSTR then
+you are required to accept NULL as a valid BSTR and treat it the same as
+a pointer to a zero-length BSTR.  COM uses this convention, as does
+Visual Basic and VBScript, so if you want to play well with others you
+have to obey this convention.  If a string variable in VB happens to be
+an empty string then VB might pass it as NULL or as a zero-length buffer
+-- it is entirely dependent on the internal workings of the VB
+program.</li>
+<li>BSTRs are always allocated and freed with SysAllocString, SysAllocStringLen, SysFreeString and so on.  The underlying memory is cached by the operating system and it is a serious, heap-corrupting error to call "free" or "delete" on a BSTR.  Similarly it is also an error to allocate a buffer with "malloc" or "new" and cast it to a BSTR.  <u>Internal operating system code makes assumptions about the layout in memory of a BSTR</u> which you should not attempt to simulate.</li>
+<li>The number of characters in a BSTR is fixed.  A ten-byte BSTR contains five Unicode characters, end of story.</li>
+<li>
+<p>A BSTR always points to the first valid character in the buffer.
+This is not legal:</p>
+
+<pre>
+<code>
+BSTR bstrName = SysAllocString(L"John Doe");
+BSTR bstrLast = &amp;bstrName[5]; // ERROR
+</code>
+</pre>
+
+<p>
+bstrLast is not a legal BSTR
+</p>
+</li>
+</ol>
+</p>
+
+<p>....</p>
+
+<p>
+When you call SysAllocString(L"ABCDE") the operating system actually allocates sixteen bytes.  <u>The first four bytes are a 32 bit integer representing the number of valid bytes in the string</u> -- initialized to ten in this case.  The next ten bytes belong to the caller and are filled in with the data passed in to the allocator.  <u>The final two bytes are filled in with zeros</u>. You are then given a pointer to the data, not to the header.
+</p>
+</blockquote>
+
+<p>(Emphasis is mine)</p>
+
+<p>
+Strings with a length prefix <em>and</em> a double-NULL suffix.  Now
+that's what I call <em>efficient</em> use of memory!  Seriously though,
+this is like some sort of programming time warp; it reminds me of both
+the Pascal-induced single-byte length prefix strings the 
+<a href='http://developer.apple.com/macos/'>Mac Toolbox</a>
+calls used and the associated (and equally wacky) string-conversion
+functions.
+ Ah, history.
+</p>
+