Edward Thomson

I got a flyer in the mail for the RSA Conference 2008. Since I enjoy cryptography - and despite the fact that I know next to nothing about it - I was interested.

But I'm not going to lie, I'm really put off by the advertising. This year's theme for the conference is Alan Turing. How this conference has been going on for 14 years and ignored him up to now is a mystery to me. (They made a carrier pigeon the theme in 1997. That's right, a carrier pigeon apparently did more for security than Turing.)

But now that RSA has finally decided to recognize the man, they're doing some stupid advertising around it: What Would Turing Do? Which, frankly, would make a cool bumper sticker, and I would have been impressed... if they had just asked the question and not tried to answer it.

Instead, they give some odd answers that show that their marketing department never bothered to talk to a developer - or even a read a Turing biography. Their answers are frequently bizarre and have nothing to do with Turing: he would "have a raging sushi addiction", "be a huge Dr. Who fan" and would "collect rare Phillip Glass vinyl". (Yes, they also didn't bother to google "Phillip Glass" to realize that they misspelled his name.)

This is the company that was founded by three math PhDs who invented the RSA public key algorithm the RC block ciphers, and the MDx hash functions. And they're suggesting that he would "recite the far reaches of imaginary numbers to pass the time"? I'd like to think that would be beneath Turing... hell, it would be beneath me. (A googleplex times i. A googleplex plus one times i. See, not very satisfying is it?)

Very disappointing.

Especially since it's obvious that really, Turing wouldn't care about sushi or Bill Gates. He'd be far too busy enjoying the liberal sexual mores of this fine time we live in.

Gluing C and Java together isn't particularly difficult - JNI is a well-designed bridge to the world of native code. Simple tasks are straightforward, and more complex ones are still possible. Surprisingly, it's quite easy to debug as well.

When working on native code, I tend to make all my code work in C first - debug it, write some native test cases, and ensure that everything works. Then I write a little JNI glue to make it accessible from Java. This has worked surprisingly well, and given few surprises. But what happens when something goes wrong?

For example: I was writing some ugly Win32 code to do some various things that can only be done in C. Despite my aversion to programming in Windows, I whipped up some native code to access what I needed. I wrote some test cases to confirm that everything worked, and I was pretty happy with myself, until I realized that all the work I had done was on ANSI C strings (ie, null-terminated char arrays.)

Regardless, I tied it up to my Java with some JNI code just to watch it fail when I passed in Unicode strings.

I'm not particularly well-versed in the intricacies of Unicode, and even less so Win32 programming with its WCHARs and PSEC_WCHARs and nasty habit of #define'ing function names to those that end in W. So I wasn't real sure of exactly what I needed to change to make my native code Unicode friendly. It sure would be nice if I could debug this in VisualStudio.

Attaching to a running process in gdb is easy - and it's easy to provide debugging symbols for that process. VisualStudio is a little less straightforward, but just as easy.

First, make sure that your DLL is emitting debugging symbols. Ensure that you're passing these flags to the compiler and linker:

CFLAGS: -Od -DDEBUG -D_DEBUG -Zi
LFLAGS: -DEBUG

Build your native DLL and ensure that a .PDB file was created - this is the debugging information for your library. Run your java application.

Open VisualStudio and setup your symbols. Go to Tools -> Options, and open the Debugging -> Symbols pane. Add a new PDB location which points to the PDB file that was created from your build.

Now you can attach to your java process by going Tools -> Attach to Process.

Finally, you can load the source (ensure that this is the source you built from, in the same directory as your PDB file) and set breakpoints, etc.