Just a quick heads up on a products a lot of my work friends on that has been announced publically. It’s Windows Network Access Protection. The basic idea is that a client connecting to a network is put on a restircted network till it has proven that it’s a safe machine (up to date with patches, running anti-virus, AV signatures are up to date, etc). This restricted network has enough access to do things like update the AV signatures and so forth. It’s a pretty nice idea for all thoose corperate laptops that slip around the firewall and screw your internal network.

Don Box points out that you can now download the Comega compiler that contains Xen (X#) and Concurrency extensions. Xen is what happens when you take databases and xml and make it fundimental to a OOP language.

The problem facing the programming language designer is not only identifying the “heavily used APIs” and “common programming patterns” mentioned earlier but also tastefully realizing them as first-class language features or constructs. Bolting on random features leads to language bloat, potentially destroying any coherence the language may have had. In addition one hopes that by promoting a feature from an API it will be better supported given its existence in the language.

…

In our opinion three areas that are ripe for liberation from their lowly API status are (a) data-access, (b) concurrency and (c) security. [Programming with Circles, Triangles and Rectangles]

This week I’m taking some training by OSR on advanced driver development. I’ve been testing drivers since I started at Microsoft, but rarely from the kernel directy. As a result I have a fisheye’s view of the kernel that I hope to correct.

In the process of explaining how PnP works they showed off thier tool Device Tree, which is also distributed as part of the DDK. I couldn’t find a copy of the DDK for immediate download (although MSDN has a online copy of the docs), one could order it for just the shipping and handling. One of the cooler things about the recent DDK is that is comes with prefast, a nice tool finding some types of bugs in both drivers and normal code.

It was suprising to hear that people have trouble setting up a kernel debugger for windows kernel development. After noticing a prety good description of how to do it by Jolyon Wright, I feel I can only add two points and quick and dirty step-by-step guide. You can find the debugger on microsoft.com and the builtin “bootcfg” command line tool is a nice way to avoid the whole attrib thing when editing the boot.ini.

Here is the minimum setup:

1. Connect the two machines via a NULL modem cable. Notice which serial ports you plugged the cable into.
2. Choose a machine to be the debugger. Install the debuggers on this machine. Run windbg. Hit ctrl-k and put in the serial port you are using on that machine with a speed of 115200.
3. On the other machine the debugee, run bootcfg. Run something like this: BOOTCFG /Debug ON /PORT COM1 /BAUD 115200 /ID 2
4. Reboot the debugee and wait for debug spew to show up in windbg.
5. hit the break button in the debugger (ctrl-break). Type .symfix and hit enter. Wait for the symbols to load from the internet’s symbol server and hit g to allow the debugee to continue running.

BTW: This item is a test post, which might get picked up by the Microsoft Community page.