I too have been very pleased with powershell, although do on occasion find it’s syntax a bit less than intuitive.
I’ve written multi-threaded (you can call the .Net thread/synchronization objects) and asynchronous event processing test scripts (a code lambda makes a great value to go with an event key in a dictionary object) in powershell, which is generally beyond the capability of most scripting languages. If powershell can’t do what you want, it’s not hard to embed C# in your script, and that C# can even make unsafe (native) calls to DLLs and OS APIs if you really need to. I call WMI methods in drivers a lot, and almost never call native code APIs, although perhaps making ioctl calls would be higher performance than WMI method calls. The flexibility is really impressive and working with structured objects is way better than working with streams of text that have to be parsed.
I also use powershell interactively a lot, like I was debugging a bunch of changes to the interrupt handler last month and made a little WMI method to poke the DPCs that service request rings. If the driver seemed to be stuck (see below how I could tell), answering the question “Is it stuck because it missed an interrupt” was as simple as $d = gwmi –Namespace root/wmi myDebugClass and then $p.poll_interrupts(0). I expect to leave much of this this code in the driver through development and early/middle QA, and unless it’s decided to be somehow dangerous (like security risk) expect to leave it in the production driver for field support. One of the development goals is to have robust support tools.
The most recent serious chunk of powershell I made creates a .Net forms GUI with a tree control on the left and a html rendered control (most of the window) on the right. Each tree node is hooked up to a lambda of code that passes some device instance specific parameters to a powershell function that spits our some dynamically rendered hml interspersed with WMI data queried from my driver, which is squirted into the html render control for display. It refreshes every second (or not if you so choose) and you can check tree nodes to select what details of the driver instance you want to monitor.
The end result is basically a GUI operational dashboard of my driver operation updating in near real time, showing the subset of data you currently care about. It’s been exceptionally useful to watch as I feed test scripts to the driver. It shows things like operational characteristics of each interrupt vector, each tx and rx queue info, things like bytes/packets/descriptors processing rates/sec, percentages of descriptors processed in dpcs vs polling threads (NIC driver have to avoid DPC watchdog timeouts under heavy load, so you end up dynamically shifting from interrupts/dpcs to polling threads dynamically). Adding new data I think is useful for debugging/monitoring and just takes collecting the data in the driver, adding a new WMI method, and writing a small powershell function to query the WMI method and render it into html, complete with things like commas on big numbers so you don’t have to look hard to decide if it says 7 billion or 70 billion bytes. I’ve made one of these dashboard gadgets for a number of driver projects, originally as a VBScript html app, but the last two have been powershell. A graphics UI designer would probably frown, but it’s way better than some text pouring out to a console window.
Jan
From: > on behalf of “Maxim S. Shatskih” >
Organization: StorageCraft
Reply-To: Windows List >
Date: Wednesday, February 10, 2016 at 9:59 PM
To: Windows List >
Subject: Re:[ntdev] Driver development: Windows 7 or Windows 10
Good tool. But PowerShell is better, covering both bash and Python abilities.