Weblog Without Honor or Humanity

In a shocking proof that someone actually reads this blog, Microsoft’s Gangadhar sent me the following explanation of linking problems I’ve seen:

This is regarding the problem you posted on your blog here: http://blog.kowalczyk.info/archives/2006/01/13/debugging-adventure/

The problem was realized a bit late during end game of Whidbey, and we could not accommodate a fix for this in whidbey RTM, This is been tracked as a bug in our database and will be fixed in the next release cycle. You can see the issue being blogged on VSD team blog site here: http://blogs.msdn.com/vsdteam/archive/2005/11/16/linker_error_lnk2019_lnk2001.aspx

So there’s hope for the future.

Too bad their weblog isn’t updated more often - it has really good information.

Of all the pseudo-science junk in movies this quote claims the first prize for stupidity: “We found frequencies we didn’t even know existed”.

Curtesy of the “Pulse” - an upcoming horror movie about dead people who want to live.

I thought I knew about them all, but no, I just found another one: Pawn.

Pawn is C-like language intended as an embeddable scripting language for writing extensions for your C code. Not that we need yet another one.

I’ve only skimmed the website, but it looks fairly interesting. It’s being maintained, it comes with zlib license (i.e. open-source and can be used in commercial apps), compiles to p-code (i.e. virtual machine), has interpreter for p-code, optimized interpreter written in assembly as well as JIT interpreter. It works under Windows and Unix. I would check it out (as an alternative to lua or python) if I was writing an app that needs an embeddable scripting language.

This is a debugging story and the lessons learned.

I was writing an application using a MailSwitchToAccount API new in WIndows Mobile 5.0. According to docs it’s defined in cemapi.h and an app needs to link with cemapi.lib.

That’s how I called it:

hr = MailSwitchToAccount(_T(”SMS”));

Visual Studio 2005 refused to link the app, claiming that:

TestDevice.obj : error LNK2019: unresolved external symbol “long __cdecl MailSwitchToAccount(wchar_t const *,unsigned long)” (?MailSwitchToAccount@@YAJPB_WK@Z) referenced in function “void __cdecl OnMailSwitchToAccount(void)” (?OnMailSwitchToAccount@@YAXXZ)

My first thought was that this symbol is simply missing from cemapi.lib. So I used dumpbin.exe (part of Visual Studio tools) to dump all symbols exported from cemapi.lib:

dumpbin -exports cemapi.lib

I found that it does have MailSwitchToAccount:

?MailSwitchToAccount@@YAJPBGK@Z (long __cdecl MailSwitchToAccount(unsigned short const *,unsigned long))

Howerver, if you look closely, you’ll see that signatures don’t match: expected type for the first parameter is “unsigned short *” while I’m calling it as “wchar_t const *”. Now, “unsigned short” is the WCHAR Windows UNICODE type. C++ also defines wchar_t which is also UNICODE char.

I vaguely remembered that some C++ compilers have an option to treat wchar_t as a native language type (as opposed to just a typedef for existing type, “unsigned short” in Windows’ case). At indeed, there it was, in project properties, C/C++/Language there’s an option “Treat wchar_t as Built-in Type”, set by default to Yes. You can set it to “No”, which corresponds to passing “/Zc:wchar_t-” to cl.exe.

It seems wrong that you have to do that. It seems like cemapi.dll/cemapi.lib were compiled with “/Zc:wchar_t-” which forces everyone who links to them also be compiled like that.

Lessons learned:

• C++ is evil
• dumpbin.exe is your friend
• Visual Studio’s code browsing is your friend (it’s easy to find out what a given typedef or #define really is)
• be aware of “wchar_t as built-in type or not” issue

Update: turns out it’s a known problem and has been blogged about on official Visual Studio blog: http://blogs.msdn.com/vsdteam/archive/2005/11/16/linker_error_lnk2019_lnk2001.aspx. Good news is that it will probably be fixed in future versions of Visual Studio.

There’s a new section on my website: knowledge base .

The idea is to collect small snippets of technical information that I might need in the future.

I’m doing this because I’ve been re-doing the same thing or trying to find the same information way too many times (e.g. every time I do a fresh install of Emacs I have to re-do some basic customization). This is a central place for me to look for stuff that I have figured out in the past. And if someone else finds them useful - all the better.

Each snippet is written to be concise, give information without rambling (so often seen on weblogs).

The html pages are generated from a single text file by a 500-line python script, articles are tagged. Entries are written in markdown markup (although the code also support textile - I haven’t yet decided which one would be better for that sort of writing).

I could have used a blog or a wiki for that so why didn’t I?

There are few reasons:

• I don’t think those belong to a blog. This is a very specific kind of information, a mini-article, a receipt of sorts. Blogs are for commentary.
  
• my experiences with posting code snippets to wordpress are not good
• my experiences with posting anything through a web interface are not good

I now that last two points could probably be solved by installing more/better software, but I probably won’t, so they are real for me now.

I just started and I’m already curious how it will look a year from now. If things go well, this knowledge base will grow to be a really useful resource. On the other hand maintaining it will require some effort so it might just as well die. I’ve seen dead wikis and dead knowledge bases before. Only time will tell.

If I manage to keep my knowledge base update, I should add RSS feed and add syntax coloring to code snippets.