(( meatspace ))

1) Get New Mail

2) Read it with OWA

3) Notice that the envelope icon in the taskbar doesn’t go away, even if you double click it and see there are no new messages.

You can right click on the envelope and click “hide envelope” to make it go away, but it’s still an interesting UI bug…

(Outlook 2003 11.5608.5606, Exchange 2003)

this is so broken.

I installed the Bitstream Vera fonts (download from here) on Windows XP. I rebooted, changed font display options from 120 dpi to 96 dpi (which is more appropriate anyway since I’m only running at 1280×1024, to avoid 60 f—ing hz refresh rates at 1600×1200), whatever, I checked everything. No matter what, the fonts folder view (open %windir%\fonts in explorer in winXP) shows all 10 combinations of Bitstream Vera, while Developer Studio only shows three (Options – Environment – Fonts and colors) — Vera Sans, Vera Sans Mono Bold, and Vera Serif.

Lame workaround: Pick Vera Sans Mono Bold, close devstudio, edit the registry key:
HKCU\Software\Microsoft\VisualStudio\7.1\FontAndColors\{guid…}.

(I’m not typing that whole thing, just go to the FontAndColors key and search for Vera, then whack the bold off the end.) Lame-ass. Why aren’t all the fonts shown?

Update: I’m actually using Verdana now, because fixed-point fonts aren’t that necessary when you’re working on team that couldn’t care less about 80 column text anyway, but it’s still annoying.

If, for some reason, I append “.exe” to devenv, when running a command line build in a batch file, the build runs but is completely silent.

If I copy and paste that same command into a regular command prompt window, it returns immediately and the build happens silently in the background.

If I don’t put .exe on the end of the command line, in both cases it runs in the foreground with full build output to the console.

Who writes crap software like this?

"C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv"  C:\work\everything\everything.sln /build

vs

"C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe"  C:\work\everything\everything.sln /build

Apparently (and I say only “apparently” because I’m not too big on testing this) — if I leave a process in the debug state using the MSVC.NET debugger and the screen saver kicks in, after I unlock the screen the UI fails to return — instead I just get my desktop background wallpaper and a mouse cursor and nothing else.

The kicker? apparently enough of the windowing system still works that, after 10 minutes, the screen saver kicks in again.

Now, I’m sure everybody’s going to tell me that it’s my fault because I use the Novell GINA. I’m sure it is. I’m sure it’s all 100% novell’s fault.

However, I would argue, perhaps with merit, that replacing the authentication system should not result in these kinds of deadlocks in the windowing system.

Ugh, pimpl makes things WORSE, not better. I can’t complete on the pimpl struct at all when implementing class methods that use it — and often not anywhere after that either.

Man, what a terrible IDE.

Ok, the title might be a slightly rhetorical question:

I’m writing an application in C++ using VStudio.NET and Windows XP. The application asserts an error, I choose to examine it under a debugger, I fix the error, stop the application, and restart it. Upon restarting the application, it throws a different assertion — the socket cannot be bound, because it is already in use.

Kill the new incarnation, check the process table. No sign of the previous app. netstat.exe -a shows the port still bound.

Kill the debugger/dev environment, in case it has some of the resources still locked in limbo. netstat.exe -a shows the port still bound.

Log out and log back in. netstat.exe -a shows the port no longer bound.

What the fuck? All resources in use by a program should be released by the kernel when the process ends, even if it was under debugging when it ends. And where are these traces of the application hanging around that a session restart fixes it?