Archive for June, 2006

Interesting: wlimit.exe

Sunday, June 18th, 2006

Just ran across this:

C:\\WinDDK\\5384\\tools\\sdv\\bin\\engine>wlimit.exe
wlimit 1.42 - Windows ulimit look-a-like tool for controlling job resources

Features:
  * Provides a CLI for controlling a job's resources.
  * Can be scripted or used interactively.
  * Control memory limits.
  * Control wall clock time.
  * Control user time.
  * All resources are limited over entire job, not just the immediate process.
  * See how many resources your job actually used.
  * wlimit must be able to break away from a previous job object (if any).

Synopsis:
  wlimit [/q] [/e] [/r] [/c] [/s]
         [/w secs] [/u secs] [/m megs] cmd [arg1] ... [argn]
    /q:      quiet
    /e:      log events (advanced, undocumented)
    /r:      ignore cmd's return value
    /b:      allow process to breakaway from wlimit's control
    /c:      ignore control-c
    /s:      spare child processes' life at exit.
    /w secs: limit wall clock time to 'secs' seconds, 1<=secs<=86400.
    /u secs: limit user time to 'secs' seconds, 1<=secs<=86400.
    /m megs: limit memory usage to 'megs' Mb, 1<=megs<=65536.

Return values:
  1001, If wall clock time is elapsed.
  1003, Process failed to execute.
  1005, If user time is exceeded.
  1004, If memory resource is exceeded.
  1006, If control-c was pressed.
  1007, If wlimit cannot break away from a previous job object.
  0,    If cmd terminates OK with exit code n and the /r flags is set
  n,    If cmd terminates OK with exit code n and the /r flags is not set

Examples:
  wlimit emacs
    Starts emacs.  When you exit emacs any child processes spawned by
    emacs will also be killed.

  wlimit /w 10 cmd
    Starts a new cmd.  After 10 seconds it will be terminated.

C:\\WinDDK\\5384\\tools\\sdv\\bin\\engine>

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.

Parallels workstation goes 1.0

Friday, June 16th, 2006

If you happen to own an Intel Mac, you may be interested to know that Parallels just went gold. For those that haven’t heard, Parallels is an Intel Mac virtualiztion solution, competing with VMware and VPC (neither of which are available for Intel macs).

It’s on sale for a few weeks, for $50 or so. Worth every penny in my estimation. It has amazingly fast virtualization, perhaps in part because it uses the Intel virtualization extensions. And, even better, back-to-back kernel debugging via emulated serial ports is blazingly fast for me – the fastest that I’ve ever experienced in a VM.

Now, if only they did FireWire… although, come to think of it, they *do* do USB, so I wonder if I could route a custom USB cable from one USB port to another on my laptop. Hmmm

Anyway, I wouldn’t give up my build box at the office, but this laptop is a fantastic driver development environment if you don’t need access to your physical device.

It’s EM64T, yo…

Thursday, June 15th, 2006

I’ve heard a disappointing number of people lately refer to Intel’s version of AMD64 as EMT64. It’s not. It’s EM64T. Quite possibly the worst acronym of 2006, but hey, it’s better than AMD64, if you happen to be Intel. Oh well, it’ll always be AMD64 to me, and I have the 2003 Driver DevCon T-shirt to prove it!

Speaking of Intel, they were kind enough to ship me a 7-volume dead tree version of the processor manuals while I was at Tech*Ed. Sad to say, but for some reason, coming home to 7 free geek books feels just like Christmas…

UMDF beta is available

Thursday, June 15th, 2006

Funny how synchronicity happens. I was just having a conversation today with a guy from the Associated Press about the benefits of UMDF, and then 8 hours later, Peter Wieland announces that the UMDF 1.0 beta is now available (for XP only). I think I detected a note of sarcasm in Peter’s post regarding the size of the WDK download, though. :-)

Congrats to the Microsoft folks; this is the product of years of hard work. And, of note, a few of the key contributors to the WDF effort are also (very) regular contributors to the online community. I’m really curious to see what the driver development world looks like in five years. The WDF design goals are pretty ambitious and very well thought-out.

Tech*Ed wrap-up

Thursday, June 15th, 2006

I just got back home from Tech*Ed. What a trip. It was really good to put some faces with names, and to meet a few other MVPs from some other areas. I spent most of my time hanging out with Len Segal, who was the only other Client MVP at the show (that I know of), and Jeff Pitsch and Bernhard Tritsch, Terminal Server MVPs. Jeff and Bernhard let me be an honorary TS MVP for a day as well, an honor I won’t soon forget! I also finally got to meet Susan Bradley, the SBS Diva and proprietor of msmvps.com, and Vlad Mazek, who’s running an amazingly interesting software-as-a-service business hosting SBS and Exchange installations. I also got to hang out with Vinny Grillo, Clustering MVP, and got to pick the brain of Scott Golightly, who gave a talk on the 10 worst practices in SQL server development. All in all it was an amazing group of people.

I also had some really fascinating conversations with some Microsoft folks. I got to sit near the mobile computing crew, who had quite a few people from the product team represented (including Jill, an admin, who was working her first Tech*Ed, just because she wanted to!). I got to have an interesting, in-depth conversation with Tracy about what it’s like to be a PM at Microsoft, and another with Sri about dev and test. Totally worthwhile conversations, and very nice people. Particularly interesting was getting their feedback on what it’s like being a part of the agony and the ecstasy that is the Vista train. :-)

From a technical content perspective, the upside was that Michael Howard and Mark Russinovich were there doing their respective things. There was apparently a chalk talk on fuzz testing, which I had to miss but would have loved to see. The downside was that basically everyone else was a couple of layers too high up the stack for my taste (or expertise!). I just don’t get turned on by Active Directory, and I not a big fan of .Net development, both of which put me in a distinct minority. But it was fun getting to interact with customers and swap stories about remote access solutions.

My next Microsoft-related conference will probably be Driver DevCon, if they ever schedule it again, or maybe the 2007 MVP summit, if Microsoft is kind enough to give me an MVP award again. Failing those two, I’ll see ya at WinHec ‘07.

OK, back to real work. Nothing puts me in a blogging mood like having a feature freeze deadline in a few days, but alas, I gotta pay the bills eventually.

Microsoft’s Driver Quality rating system

Wednesday, June 14th, 2006

I just ran across this on Ars: Inside Microsoft’s new Driver Quality Rating system Microsoft will start assigning ratings – green, yellow, red – to drivers, and only green drivers will be allowed to run on logo-certified PCs. (You lose your logo if you ship a non-green driver.)

Interesting.

Things are a little backed up at the Patent Office

Wednesday, June 14th, 2006

I just ran across an article on Patently-O about a patent app that expects to get its first office action (i.e. early in the process) in, oh, about 14 years. Woah.

The trouble with twos

Tuesday, June 13th, 2006

Another marathon day at Tech*Ed. More interesting questions and answers. One thing in particular struck me during the day, though.

Another MVP was helping a customer repair a broken update server install. He read off a URL, and when he got to a / character, he said whack. I was always under the impression that whack meant \, and was created to help disambiguate the slash (/) from the backslash (\). But now it seems that people are using it to mean either character, which only creates more ambiguity.

I did the same thing last week with a new acquaintance’s name. I somehow got it into my head that his name was Jeff, when in fact it is Josh. The problem now is that I have two equally valid (to me) names for this person, so I’m doomed to tons of mental energy to prevent calling him by the wrong name.

Two alternatives is the worst case for me. I seem to be able to disambiguate 3+ similar objects easily enough, but pairs are killers for me.

This applies to programming, believe it or not. The same poorly-wired part of my brain that confuses the names of slashes and of people also confuses the names of variables in my code. The solution is easy: I have a fairly rigid naming scheme that I try to stick to when I code. That way, I can remember names. The downside is that it tends to generate fairly long variable names, but the upside is that I don’t have to constantly hit page-up to see what I called some particular mutex.

Plus, if you name your entities in a consistent manner, it makes debugging and code review a lot easier. Wrong things tend to stick out as being wrong. On the other hand, please do NOT confuse this as an argument for Hungarian notation (as commonly understood).

Anyway, if you’re at Tech*Ed, come by and say hi tomorrow afternoon – I’ll be in the Windows Client area of the TLC from 12:30 until 5:30 or so. I’m back for most of the afternoon tomorrow and again on Thursday, and am flying home Thursday night. Not a lot of driver-related questions so far…

This inconsistency is … well … inconsistent

Tuesday, June 13th, 2006

Look out for weird NDIS semantics (which I assume are for historical reasons).

From the WDK docs for NdisWaitEvent():

MsToWait: Specifies the number of milliseconds the caller will wait if the event is not set to the Signaled state within that interval. A value of zero specifies that the caller will wait for the event indefinitely.

(Emphasis mine.) And from KeWaitForSingleObject():

Timeout: Pointer to a time-out value that specifies the absolute or relative time, in 100 nanosecond units, at which the wait is to be completed.
A positive value specifies an absolute time, relative to January 1, 1601. A negative value specifies an interval relative to the current time. Absolute expiration times track any changes in the system time; relative expiration times are not affected by system time changes.

If *Timeout = 0, the routine returns without waiting. If the caller supplies a NULL pointer, the routine waits indefinitely until the dispatcher object is set to the signaled state. For more information, see the following Comments section.

That’s the kind of bug that’s very hard to detect on static analysis. Fortunately, it’s usually pretty obvious in practice.