Archive for the ‘Uncategorized’ Category

Getting back online…

Wednesday, January 14th, 2009

After a ton of time essentially off the Internet radar, mostly doing PhoneFactor stuff, I’m starting to get re-engaged with the online world. It having been a couple of years since the Web 2.0 (r)evolution, and since I started blogging, I thought I’d take a fresh look at some of the sites that seem to have survived and start, you know, using them again.

Stuff I’m starting to use again, in no particular order:

  • Facebook has begun mushrooming on me, as it seems to have a habit of doing
  • Twitter is surprisingly addictive, and might actually succeed in making me use fewer words
  • del.icio.us was always interesting, to me anyway
  • Plaxo is the biggest surprise to me; its original use (keeping track of contacts?) is still surprisingly good.
  • LinkedIn is the only “social” site that strikes me as useful, as opposed to merely entertaining

And, of course, I’m still occasionally blogging here.

I have a few new projects cooking, a couple of which will be launching in the next week or two. Watch this space!

Free advice (being worth what you pay for it, of course)

Monday, September 29th, 2008

Never argue with an idiot. They drag you down to their level and then beat you with experience.

Don’t make a Rembrandt

Saturday, December 2nd, 2006

I can’t remember where I first heard the terms complexifiers and simplifiers, although it looks like they were originally coined in a blog post by Scott Berkun, but I’ve found them to be more and more useful in recent weeks.

My company is working on a Great New Service™ and we’re trying to finish up the first round of design. Virtually all of the intellectual energy I’m spending in these discussions is centered on factoring out complexity whenever possible.

Complexity is amazingly expensive:

  • It’s obviously more expensive to code.
  • It costs the business in terms of things like time-to-market.
  • It takes (much) longer to test.
  • You can wind up actually sacrificing the quality of the product you were trying to improve, by rushing the implementation process or short-changing QA (or, likely, both).
  • It presents bigger attack surface.
  • It makes security architecture harder.
  • It is more prone to bugs.
  • It makes individual bug fixes harder.
  • It requires smarter/better/more experienced developers.
  • It makes it very hard to replace those developers.
  • It’s harder to communicate your marketing message to your audience.
  • It can negatively impact scalability, performance, and responsiveness to demand changes.
  • It can kill your ability to adapt your product to changing market conditions.

I have a rule related to this: a system’s overall design is limited to what the lead technical person can fit into her head. Once your system is too complex to fit between one person’s ears (at a sufficient level of detail), you have to start dividing the architecture and scaling the team in ways that have yet more expenses built in, in terms of design, management, and programmer interactions.

Put another way: You have a limited amount of complexity that can be spread across your product. Spend it carefully.

Simplification is difficult, because complexity is the default route of most bright people that I’ve met. It’s fun (and on a deeper level, very satisfying) to build complex things. That’s why simplification has to be a going-in design goal. When you re-state simplicity as a goal, the team’s creative talents can be applied to the problem of simplification, which makes everyone happy.

There are tons of examples of people battling with this question, ranging from this week’s Vista vs. OSX shutdown wars (more here and here and here) to more abstract designs like Networking Truth #12.

This point of view may be an oversimplification :-) or you may already be years into a shipping product, with few chances to apply this principle. But if you’re in the design stage of a new product or service, like I am right now, do yourself a favor and (as my grandfather used to say) don’t make a Rembrandt!

Questions and suggestions

Saturday, December 2nd, 2006

This post is for any questions or suggestions you have. Feel free to post topic requests, feedback, etc. You can, of course, also e-mail me at dispensa - at - positivenetworks - dotcom.

Month of kernel bugs

Wednesday, November 1st, 2006

It looks like there’s a new Month of Kernel Bugs blog. From the description:

Besides hosting the Month of Kernel Bugs, this blog aims to provide information about kernel-land bugs, hacks and tricks. XNU, Linux… you name it.

You may remember a related project, the Month of Browser Bugs, in which HD Moore from Metasploit posted a new browser bug every day for a month.

Needless to say, I’m curious to see where this one goes.

New debuggers

Wednesday, July 19th, 2006

Version 6.6.7.5 of the debugging tools has been released. Get ‘em at http://www.microsoft.com/whdc/devtools/debugging/default.mspx. And, Ken has some extra upgrade advice for remote debugging.

Scratch driver

Friday, June 16th, 2006

I’ve provided a few code samples in the past, and with any luck, there will be more to come. To that end, I’m taking a page from Raymond and providing a scratch driver and test app for use in our demos. It builds cleanly with 3790.1830 and with the beta 2 WDK; it ought to build with anything else, though, given how simple it is.

The linked zip includes both the driver and the test app. First, here’s the code for the scratch driver itself. Starting with the sources file:

sources
-------

TARGETNAME=sdriver
TARGETTYPE=DRIVER
TARGETPATH=obj

MSC_WARNING_LEVEL=/W4 /WX /Wp64

PRECOMPILED_INCLUDE=pch.h
PRECOMPILED_PCH=pch.pch
PRECOMPILED_obj=pch.obj

SOURCES= sdriver.c

Note that we’re building with /WX /W4 /Wp64. This is pretty strict, but it’s what I would recommend. Next, of course, is the standard one-liner makefile:

makefile
--------

!INCLUDE $(NTMAKEENV)\makefile.def

We’re set up to use precompiled headers, in part so that we can cleanly control the warning level of the system headers without having to copy pragma statements into every file. The PCH file:

pch.h
-----

#ifndef __PCH_H_
#define __PCH_H_

#pragma warning(push,3)
#include 
#pragma warning(pop)

/* 3790.1830 warns on PAGED_CODE */
#pragma warning(disable:4127)

#endif

Finally, the scratch driver’s header and main source file:

sdriver.h
---------

#ifndef __SDRIVER_H_
#define __SDRIVER_H_

NTSTATUS
DriverEntry(
    PDRIVER_OBJECT  DriverObject,
    PUNICODE_STRING RegistryPath);

#endif

---------
sdriver.c
---------

#include "pch.h"
#include "sdriver.h"

#ifdef ALLOC_PRAGMA
#pragma alloc_text(INIT, DriverEntry)
#endif

NTSTATUS DriverEntry(
    PDRIVER_OBJECT  DriverObject,
    PUNICODE_STRING RegistryPath)
{
        UNREFERENCED_PARAMETER(DriverObject);
        UNREFERENCED_PARAMETER(RegistryPath);

        return STATUS_UNSUCCESSFUL;
}

The high warning level means that we have to use UNREFERENCED_PARAMETER macros to disable the unreferenced parameter warnings. We’re using an explicit pragma to let the OS know that DriverEntry is init-time code only, so it can be discarded. Finally, we have broken out the project’s own include file (sdriver.h) from the rest of the pch file; PCH is best used on system headers, as opposed to frequently changing headers that are a part of the project itself.

In addition, I’m including a test app in the ZIP file that we’ll use to exercise the driver. It’ll probably be added to over time, but at the moment, it is a simple shell. We’ll bring along the same build infrastructure from the driver. The makefile is identical; the sources, pch.h, and test.cpp files are listed below:

sources
-------

TARGETNAME=stest
TARGETTYPE=PROGRAM
TARGETPATH=obj

MSC_WARNING_LEVEL=/W4 /WX /Wp64

TARGETLIBS=$(SDK_LIB_PATH)\user32.lib

UMTYPE=console
UMENTRY=wmain
USE_MSVCRT=1
USE_STL=1
STL_VER=60

PRECOMPILED_INCLUDE=pch.h
PRECOMPILED_PCH=pch.pch
PRECOMPILED_obj=pch.obj

SOURCES= stest.cpp

-----
pch.h
-----
#ifndef __PCH_H_
#define __PCH_H_

#define UNICODE

#pragma warning(push,3)
#include 
#pragma warning(pop)

#endif

---------
stest.cpp
---------
#include "pch.h"

int __cdecl wmain(int argc, wchar_t **argv)
{
        UNREFERENCED_PARAMETER(argc);
        UNREFERENCED_PARAMETER(argv);

        MessageBox(0, L"Hello world", L"Hi", MB_OK);
}

Mostly the same story as above. We’re explicitly making this test app UNICODE from the start (I’m tired of win9x), so the sources, pch.h, and stest.cpp files are set up as such. wmain() is explicitly decorated as __cdecl; the DDK environment defaults to __stdcall, but main is __cdecl by definition, so this is necessary. Finally, the test app is going to be C++, so I’m going to go out on a limb and declare that STL is in use in the sources file from the get-go. We also choose to link to the dll version of the CRT.

One thing that is worth pointing out here is that you have to build the drivers for the OS you’re going to run them on. If you build targeting Vista, your test app won’t run on XP.

Please leave a comment with any suggestions or bugs; I just whipped this up this evening, and other than PREfast and (obviously) building it, I haven’t tested this much.

UPDATED: Fixed broken download link.

Day 0 wrap-up

Sunday, June 11th, 2006

I snuck out of the keynote 10 minutes early and didn’t have to wait long for the bus. What a day! I actually got some coding done, got some reading done, got set up to do the TLC thing tomorrow, and learned a lot, even though the conference is only about 2 hours old, officially.

Now, on to coding, reading, installing a Vista Beta 2 VM, and (of course) ironing my shirts and slacks for the next few days. I’ll be in the TLC in the Client area all day tomorrow. Sounds like a long day!

A minor VS 2005 nitpick

Saturday, May 27th, 2006

You should never complain about a freebie, right? I just got done converting our usermode Windows code to build with VS 2005. It turns out that Express Edition builds our product quite well, and the SDK has an x64 compiler in it, so other than resource editing, we’re not actually losing much by going with the free version. This is obviously a big step up in value from the VS2003 tools that consisted of essentially just a command line compiler and linker. Although, come to think of it, that’s the way I prefer to work anyway. But I digress…

One thing jumped out at me. Why on Earth is the build toolbar not on by default? It’s not on in the Standard Edition either. Furthermore, why isn’t there a (defualt) way to build just the project I’m on? We have dozens of projects in our usermode workspacesolution, and I rarely want to build the whole thing.

Anyway, I’m reallly impressed with MS for giving this thing away for free. The very best UNIX toolchain has been free for years; now the best Windows toolchain is free too. I wonder if it will have the desired effect.

On the topic of annoying blogs

Wednesday, May 24th, 2006

I’m all for hard-hitting commentary, and my wife routinely accuses me of being a pessimist. I love Shakespeare tragedies and I’m even enjoying Crime and Punnishment.

But even I have my limit. And so I ask you: does Mary Jo Foley of Microsoft Watch fame ever say anything nice? Good GOD, I’ve been reading her blog for months and don’t ever remember her doing anything other than looking for the most negative angle she can put on absolutely any story about Microsoft. She’s complaining about slow download speeds of the Vista beta at the moment, referring to it as a snag!

Enough with the negativity already! This is why I can’t handle election year television. I don’t need it in my newsreader. Subscription deleted!