The engineers who designed Windows file systems must have, at some point, discovered that their standard interface was too slow. Rather than coming up with ways to make it faster, they simply introduced a new, parallel one, called “fast I/O”, whose functionality is entirely redundant to the usual one. This is optional, but if you don’t implement it, some behaviors (like appending to a log file, one byte at a time) can become extremely inefficient. And naturally, none of their sample code shows how it’s supposed to work.

Microsoft Windows Hatred Status
Their developers are smoking advanced experimental prototype monkey crack again.

mithriltabby: Serene silver tabby (Zort)
( Sep. 15th, 2006 03:52 pm)
From the Microsoft Windows Device Driver Kit documentation:
The specific rules to follow here are unclear, but as with most things in NT, if you do it wrong the system will fall apart at some future time.
This is in a technical article written by the folks at Open Systems Resources, not the actual Microsoft writers... but it’s going out as official Microsoft material.

Microsoft Windows Hatred Status
They obviously can’t be bothered to write useful documentation.

Background: I’m writing a script to read data out of ClearCase history records. The format code %Nd is used to get the maximally specific timestamp for an operation, in yyyymmdd.hhmmss format. The lshistory command accepts a parameter -since that allows you to see all records that have been entered since a given timestamp. And -since insists that its long date format look like dd-month-[yy]yy.[h]h:[m]m:[s]s, which means that if I want to grab the most recent record and stash its timestamp to use as the -since for the next query, I have to rearrange it.

Somehow, I suspect that I will be required to redact this comment before we ship a script containing it:

# $when is in yyyymmdd.hhmmss format.  It is, of course, invalid as input
# to "-since", because that would be presenting a consistent interface,
# which would doubtless violate some engineer's Dark Pact and cause their
# soul to be claimed immediately.

I’m planning on going on vacation for the week of July 4th, so I wanted to put together a guide for people who need to solve Windows problems while I’m out. I titled it “Fenestral Haruspication”— literally “divination by inspection of the entrails of Windows”.

(Update: changed from “fenestric” to “fenestral” when a bit of searching showed that the latter is actually in the dictionary.)

A classic hacker term is phase-of-moon dependence, characterizing a bug that appears and disappears without apparent rhyme or reason. (This is distinct from the heisenbug, which disappears when you look at it too closely.) I had a bug mysteriously turn up in early January this year— and I was able to reproduce it repeatedly, on multiple machines, even using a build from early November. The exact same testing procedure on the exact same build, performed today, no longer reproduces this behavior. What’s a good name for this problem?

[Poll #670866]

Microsoft Windows Hatred Status
They obviously can’t be bothered to write useful documentation.

Today’s technical learning experience: the SuspendThread() call in Windows can return before the thread involved is actually suspended. On a fast multiprocessor machine, the “suspended” thread can actually crank out a few hundred instructions before it grinds to a halt. MSDN doesn’t tell you anything about this one way or the other.

Fortunately, I am going on vacation, and will not need to return to work until January 3, so as soon as I walk out of here tonight:

Microsoft Windows Hatred Status
I can pretend it’s not there.

cargo cult coding, n. The act of writing code to resemble provided samples when there is no information that allows actual problem solving; a last resort when documentation is hopelessly inadequate and source code to the underlying operating system is unavailable.
Documentation on Windows drivers is so bad that I had to get out the fastfat sources and do cargo cult coding until the blue screen bug went away.

— Max Kaehn, 2005

Microsoft Windows Hatred Status
They obviously can’t be bothered to write useful documentation.

mithriltabby: Serene silver tabby (Zort)
( Sep. 26th, 2005 05:12 pm)
What’s even worse than doing driver development under Windows? Dealing with problems caused by sharing a machine with Symantec’s badly written drivers.

Microsoft Windows Hatred Status
Their developers are smoking advanced experimental prototype monkey crack again.

mithriltabby: Mushroom cloud (Nuke)
( May. 16th, 2005 06:26 pm)
Windows supports a file system concept called “extended attributes”. The basic idea is quite reasonable: any application can attach data to a file without modifying the file itself (as long as it has permission to meddle with extended attributes). Each application can add its own special data without interfering with other applications. Not all file systems support this: NTFS does, FAT32 doesn’t.

At the driver level, you receive perfectly reasonable-looking requests with codes like IRP_MJ_QUERY_EA and IRP_MJ_SET_EA to manipulate them, or get them passed in at file creation time. Update: The kernel does have NtQueryEaFile() and NtSetEaFile() as undocumented APIs.

At the user level, if you want to write a reliable, runs-everywhere application, you get at them through the backup API. If you’re on a sufficiently advanced version of Windows and you know that the file system implements EAs as “streams” (a special feature of NTFS), you can use the new stream control API to manipulate EAs. But nowhere is there a straightforward way to manipulate these things the way they’re designed to be used. It’s like a filing cabinet where you have to remove the entire drawer in order to use it, even though you know perfectly well you should be able to grab the individual folders.

Microsoft Windows Hatred Status
Their developers are smoking advanced experimental prototype monkey crack again.

I now know why people write Windows viruses. I was briefly marveling at how often how-to guides by people studying ways to write viruses turn up on search results when I’m looking at driver-writing topics (e.g. Ring0 under WinNT/2k/XP and Rootkit) when I suddenly experienced a moment of clarity: these people are hurting, and they’re just responding to the horror of wrapping their brains around the internals of 32-bit Windows. Writing a fast-propagating worm that brings corporate networks to their knees is just a cry for help.
So in an effort to cut down on buggy drivers crashing Windows, Microsoft have created test suites to hammer on drivers to help shake out bugs. This is a good idea. One of the first things the DC2 utility does, though, is call ZwQueryObject() to obtain ObjectNameInformation about your driver. Where did I find documentation about this function? Not in MSDN. Not in the documentation for the Windows DDK and IFS kit. I wound up finding a web site called— I kid you not— They even have all their information in a handy CHM-formatted file. Why are Microsoft mentioning the result of this in their test code if they’re not going to document the API by which you can make your code pass the test?
This time, they’ve managed to document in their IFS kit a particular function, RtlCreateSecurityDescriptorRelative(), which has supposedly been present since Windows 2000. It exists in header files, but is not exported from any libraries. Their documented set of functions for manipulating security objects at the driver level is so incomplete as to be nearly useless; an interesting contrast to their user-level API, which is redundant and inconsistent.

[ profile] obsessivewoman, you’ll be proud of me: I did not vent virtual bile at the Microsoft recruiter who was foolish enough to send me E-mail this afternoon.

I’ve been dealing with Windows file system drivers lately, and the documentation doesn’t exactly explain the things I need to know clearly. If this were a problem on Linux, I could just open up the source code to the system libraries to figure out what’s going on underneath, and if that wasn’t enough, I could go read the source code to the kernel. But in the absence of decent documentation (which is not available to Google searches, MSDN searches, any version of the DDK or IFS Kit I can lay my hands on, or the weighty paper tomes of advice we have in house), I’m forced to experiment and see if I can compel Windows into doing my bidding.

On the plus side, it’s probably good practice for reverse engineering technology from crashed flying saucers.

Access control isn’t exactly a simple topic, but Microsoft really aren’t going out of their way to make life easy for developers who have to deal with it. Why, oh why, can’t they make a simple API with straightforward functions for manipulating things, and then provide source code for standard helper functions that use the simple API, instead of having umpty-bazillion redundant functions?
mithriltabby: Graffito depicting a penguin with logo "born to pop root" (Hack)
( Jul. 19th, 2004 05:11 pm)
Dammit Jim!  I'm a Sysadmin not a Babysitter! I’m not even a sysadmin, and I know the feeling that this shirt expresses.
So a couple of RAID controllers go out on a couple of the ClearCase servers yesterday, early in the day. About a day later, we finally get the message that servers are back online after having had the controllers replaced and the drives re-checked. I get in around 13:00 from a dental appointment, check my system, and find that the main tree in which my team is doing its work is behaving irrationally. I report the behavior to our support staff immediately, and an hour and a half later get a note that it’s being restored from backup and will be available in four hours, by which time the work day is over. That’s two days of work lost, when we could’ve restored a CVS repository from backup onto a spare machine in what, an hour? And been able to work from our checked-out files the whole time?
mithriltabby: Serene silver tabby (Zort)
( Mar. 10th, 2003 10:50 am)
There’s a system call on UNIX, clock(), that tells you how much CPU time your process has been using. This is different from total elapsed time because the computer is doing many things at once, and clock() just tells you how much time this particular process used.

Microsoft is in the habit of providing equivalents of UNIX system calls for its C developers, often with slight annoying differences in the name (like tacking on a leading underscore). This is something that I can cope with. But I really hate it when MSDN’s page on “Time Management” in the Run-Time Library Reference lists clock() under “Return elapsed CPU time for process”, then the actual page for clock() says “calculates the wall-clock time used by the calling process” and turns out to be using GetSystemTimeAsFileTime() under the covers. That’s just plain incompetent.

The classic UNIX way of keeping track of the current time is the number of seconds since midnight UTC, January 1, 1970. Win32 has a notion of “file time”, which is the number of 100-second intervals since midnight UTC, January 1, 1601. Now, a sensible thing for them to do would be to provide a constant for converting from one to the other, defined in a header file so you could just refer to it by name. (You can also do it by calling various functions, but there are times when you’d rather not pay the overhead of a function call.) Do Microsoft provide this constant? Not in a header file. It’s in the frelling MSDN documentation, but it’s not someplace that a programmer can refer to it where other programmers can recognize it as a predefined name.
Note that having an application distributed across multiple machines does not intrinsically make it fault-tolerant. We have a whole bunch of machines dealing with ClearCase here. They’re not redundant; all they do is soak up workload. If a server goes down, everyone’s still hosed.

On the plus side, I finally put together a multi-machine juggling act that will automatically generate documentation from the source code every night. I can’t force people to write documentation, but I can certainly make it so easy that people should be embarrassed when I say “so why didn’t you document it?”

I think the whole Dark Side of the Force thing is underrated. You should always try the carrot first, but if you need the stick, go get the stick. Sometimes you just gotta rule through fear to get the job done.



RSS Atom

Most Popular Tags

Powered by Dreamwidth Studios

Style Credit

Expand Cut Tags

No cut tags