Das Buch Wer mitmacht, hat Recht!

The odyssey to find a message encryption for Miranda IM finally got to an end. After we had an outdated¹ GPG message plugin for years, we now got a plugin called SecureIM² which is supporting AES192, PGP and GPG message encryption.

The most other OSS IMs already have various plugins to support message encryption, but most of them are still only for Linux or itself not that handy like Miranda IM for Windows is.

[1] GnuPG Plugin
[2] SecureIM

Who thought that the days of the command line have been counted, might be wrong.

In the days of iPhones pooping popping up on every website and impressing the crowd with an unique user interface, Alex Faaborg, who recently joined Mozilla as User Experience Designer, wrote some interesting things about it on the mozilla blog.
I use the Mac application Quicksilver myself a lot – the combination of command line (or as geeks refer to as “CLI” – go and look it up yourself) and GUI is the most powerfull I’ve experienced so far for the shorter commands. For longer commands I tend to go back to the terminal (started with quicksilver of course).

more…

kudos to housetier for pointing me to bblean.

yesterday i almost killed my win2k. usually i’d say, no harm done. but it was the box i was doing all my work with right now.
so when i finally managed to get it fixed, i had spent the better part of 3 to 4 hours using linux.
you might not know, but i’m one of those “linux only” guys, i just prostituted myself for work where i develop software for windows systems.
since i’m in the US right now on an internship i was using windows for the last 6 months. no linux (i miss you, sweet, powerful linux workstation in germany).

anyways the point is: after i got back to yucky windows i got used to my “no taskbar, all task are desktop-middle-mouse-click”.
so i was very annoyed by windows.
it’s always the little things that tick me off.

so at this point housetier pointed me to above mentioned shell replacement.
i downloaded it and noticed it was only a packed directory, no installer, not nothing. holy #$%?
but worry not! a mere double click on blackbox.exe and wooosh, the shell was replaced, everything looked slick, tiny, sweet, different, better!
i then could choose to install blackbox as my default shell from within blackbox, everything on the fly.
i’m in love.

the only thing i dislike is, that some windows seem to not use the blackbox window decorations and features.
sometimes they do, sometimes they don’t.
just one little thing that’s annoying.

compared to litestep it also seems to be more stable and easier to configure.
ok, this is a little unfair, since i last used litestep like 2 or 2.5 years ago.
so i assume a lot happened to litestep over the years.

but well, it’s a lot better now compared to the windows shell from before. take a look for yourself

how everyone who did some programming on windows using MFC should know,
making dynamically re-sizable dialogs/views isn’t that easy a deal.
it’s far from the beauty of trolltech Qt or other frameworks.
basically it all comes down to catching ON_SIZE and overriding the OnSize() method.
sounds fair enough; but having to resize/move each single element of the dialog to fit the new framesize is just so much crappy, boring work.

thank god^W the coder in germany, i could use some of his older code that had a nice helper class that nicely fits in between CFormView and my own view.

all i had to do was subclass it, put two dummy elements as anchors into the view, register the elements that need resizing with the layout class, et voila it’s done.

the only thing that was done was a nasty exception, it was thrown right into my face, and it came from far, far down in the MFC abyss.
access violation when accessing memory at 0xbaadf00d.

right on!

as i know now, 0xbaadf00d stands for uninitialized heap memory.
it’s one of the usual suspects of debugging-defaults like 0xdeadbeef (deleted heap memory), 0xcd (uninitialized data byte), 0xfd (runtime heap data guard), and last but not least 0xdd (deleted data byte).

so far, so good.
i know what’s happening, i even know where it is happening (somewhere in CWin::MoveWindow(...)) but i had no clue why.

to understand the problem, one has to know the basics of the layout manager internals.
it keeps a std::list of the information of each registred element as a struct holding a pointer to the element’s CWin class, it’s initial dimensions, and a set of flags.
once OnSize() is called the layouter gets the new size of the window, calculates the delta to do the resizing of each element, checks if the element is anchored in some way, and finally does the resizing.
the resizing itself is done by dereferencing the pointer to the previously stored CWin class of the element and calling MoveWindow(...).

and there it is i’m getting the exception.

so i do what all desperate coders do, i set a breakpoint and step thru the code instruction by instruction, call by call.
i spent hours staring at parameters, variables, return values, and what not.
then i noticed that what’s getting set when registering a new element with the layouter and what’s getting returned from the std::list it’s being held in, kind of is not the same.

i replaced the container with a std::vector and used operator[](...) instead of the iterator to access it.
didn’t help.

then i noticed that instead of passing a pointer to the RECT struct (that holds the dimensions of the element) to GetWindowRect(...) the code was passing the struct member itself. duh.
fixed it, didn’t help.

then my attention was drawn to the struct member which holds the flags.
instead of a low value (something in the range of 0 to at most 32) it was set to a value of over 19000. how could that be, it’s a simple assignment.
imagine this:

void AddElement(CWin *element, int myFlags)
{ // [...]
// struct MyStruct {CWin *winp; RECT dimensions; int flags};
MyStruct foo;
foo.winp = element;
foo.flags = myFlags;
GetWindowRect(&(foo.dimensions));
mylist.push_back(foo); }

the debugger stepped right over the two assignments.
all hail to the microsofties!
i don’t know what it was, but the compiler refused to compile correct code.
even in debug mode.
the problem was solved quite fast using the lazy man’s define-and-assign:
MyStruct foo = {element, CRect(0,0,0,0), myFlags};

i’m still having the feeling that it was just the debugger trying to trick me…
fixed that problem, but i would still get the nasty exception throwing bad food in my face. yuck.

i finally noticed that once i get the elements from the list and dereference the pointer to the CWin class, i get the class with all it’s members, but a handful of them would be set to 0xbaadf00d.
i can’t remember how i got the following idea, but it got it while listening to dmnk doing his live show on jungletrain.net.
i modified the struct and the code to work on a window handle (HWND) instead of the pointer to the window class (CWin*).

believe it or not, but i’ve never really used the HWND before, so i fired up the context sensitive help and while digging around i found out that while the CWin class might cease to exist even during the lifetime of a window, the window handle would be there all the time. in short: the CWin class is just a convenience-wrapper around the handle. geez. i love MFC.

instead of just calling currentElement.winp->MoveWindow(...) i ended up with some more code:
CWin foo;
foo.Attach(currentElement.winh);
foo.MoveWindow(...)
foo.Detach()

and magically it worked!

i’ve been with the company for over two years now, and i think i’ve only found 1, at most 2 bugs in that coders code.
today i hit the nasty jackpot.
and in retrospect i have to say: stupid bug, nasty bug, and it took-me-way-too-long-to-find-it bug