April, 2012

  • The Old New Thing

    Microspeak: scoped to


    The Merriam-Webster dictionary gives as the meaning of scope as a verb to look at for evaluation, as in "to scope out the competition." But that's not how we use it at Microsoft.

    Here are some fake citations:

    The Widgets pop-up shows the available widgets scoped to the current selection.
    The results of the search are scoped to the current folder.
    Workflows can be scoped to containers, content types (scopeable to containers, sites, collections, servers, or enterprises), or combinations of these.

    Okay, that last one wasn't fake. You can tell it's not fake because it is extra confusing.

    To be scoped to something is to be limited to or filtered to that thing, or things which apply to that thing. In other words limited in scope to. Here's an attempt to translate those citations into English:

    The Widgets pop-up shows the available widgets which apply to the current selection.
    The results of the search are filtered to those in the current folder.

    I'm not going to try to translate that last one on there. It has this sort of Escherian feeling to it. "Workflows can be scoped to A, or to B (which can be scoped to A), or combinations of A and B (which means combinations of A, and B, and A's within B's?)"

    Another sense of the verb phase scoped to is altered in scope. Usually, the change is to reduce the scope to meet external constraints:

    The proposal has been scoped to meet our December release.

    To emphasize that the scope has been narrowed, you add the adverb down: "scoped down to."

    Translation: "The original proposal was too broad and could not be accomplished within the required time allotted, so we reduced its scope to the point where the parts that remain can be accomplished in time."

    On the other hand, sometimes scope expands.

    Based on customer feedback, the search results have been scoped to include archived data as well.

    And finally, a citation from an official Microsoft job description:

    Oversees the structuring of consulting engagements to ensure they are properly scoped to meet the customer's requirements profitably.
  • The Old New Thing

    What were the tests that WinG did to evaluate video cards?


    Georg Rottensteiner was curious about the weird things that WinG performed on installation to evaluate video cards. "What did it do actually and what for?"

    I don't actually know, since I was not involved in the WinG project, but I remember chatting with one of the developers who was working on video card benchmarks.

    He says that video card benchmarks are really hard to develop, not just because video cards are complicated, but also because video drivers cheat like a Mississippi riverboat card sharp on a boat full of blind tourists.

    He discovered all sorts of crazy shenanigans. Like a video driver which compares the string you ask it to display with the text "The quick brown fox jumps over the lazy dog." If the string matches exactly, then it returns without drawing anything three quarters of the time. The reason: Benchmarks often use that sample string to evaluate text rendering performance. The driver vendors realized that the fastest code is code that doesn't run, so by ignoring three quarters of the "draw this string" requests, they could improve their text rendering performance numbers fourfold.

    That was the only one of the sneaky tricks I remember from that conversation. (I didn't realize there was going to be a quiz 17 years later or I'd have taken notes.) Another example of benchmark cheating was a driver which checked if the program name was TUNNEL.EXE and if so, enabled a collection of benchmark-specific optimizations.

    Anyway, I suspect that the weird things that the WinG installer did were specifically chosen to be things that no video card driver had figured out a way to cheat, at least at the time he wrote the test. I wouldn't be surprised if fifteen seconds after WinG was released, video driver vendors started studying it to see how they could cheat the WinG benchmark...

  • The Old New Thing

    What is the real maximum length of a DNS name?


    The maximum length of a DNS name is 255 octets. This is spelled out in RFC 1035 section 2.3.4. A customer didn't understand why the DnsValidateName was rejecting the following string:

    (63 letters).(63 letters).(63 letters).(62 letters)

    The documentation says

    Returns ERROR_INVALID_NAME if the DNS name

    • Is longer than 255 octets.
    • Contains a label longer than 63 octets.
    • ... other criteria not relevant here...

    The length of the domain name passed in is 63+1+63+1+63+1+62=254 characters, just under the length limit of 255. Why is it rejecting this name that is under the limit?

    Because the limit isn't the number of characters; it's the number of octets.

    Section 3.3 says that a domain-name is represented as a series of labels, and is terminated by a label of length zero. (The label of length zero represents the root label.) A label consists of a length octet followed by that number of octets representing the name itself. Therefore, the domain name www.microsoft.com is encoded as follows:

    3 'w' 'w' 'w' 9 'm' 'i' 'c' 'r' 'o' 's' 'o' 'f' 't' 3 'c' 'o' 'm' 0

    Technically, www.microsoft.com is shorthand for www.microsoft.com. with a trailing period, and the trailing zero byte encodes that implied period.

    If you sit down and do the math, you'll see that the the readable maximum length of an ASCII DNS name is 253 characters: You don't encode the dots, but you do encode the length bytes, so they cancel out, except for the length byte of the first label and the length byte of the root label, for an additional cost of two bytes. (On the off chance that you explicitly specified the root label, don't count it towards the 253-character limit.)

    If you use UTF-8 encoding, then the maximum length is harder to describe since UTF-8 is a variable-length encoding.

  • The Old New Thing

    You can use an OVERLAPPED structure with synchronous I/O, too


    Even if you didn't open a file with FILE_FLAG_OVERLAPPED, you can still use the OVERLAPPED structure when you issue reads and writes. Mind you, the I/O will still complete synchronously, but you can take advantage of the other stuff that OVERLAPPED has to offer.

    Specifically, you can take advantage of the Offset and OffsetHigh members to issue the I/O against a file location different from the current file pointer. (This is a file pointer in the sense of Set­File­Pointer and not in the sense of the C runtime FILE*.) If your program does a lot of reads and writes to random locations in a file, using the synchronous OVERLAPPED structure saves you a call to Set­File­Pointer at each I/O.

    Let's illustrate this by writing some code to walk through a file format that contains a lot of offsets to other parts of the file: The ICO file format. First, the old-fashioned way:

    #define UNICODE
    #define _UNICODE
    #include <windows.h>
    #include <pshpack1.h>
    struct ICONDIRHEADER {
        WORD idReserved;
        WORD idType;
        WORD idCount;
    struct ICONDIRENTRY {
        BYTE bWidth;
        BYTE bHeight;
        BYTE bColorCount;
        BYTE  bReserved;
        WORD  wPlanes;
        WORD  wBitCount;
        DWORD dwBytesInRes;
        DWORD dwImageOffset;
    #include <poppack.h>
    BOOL ReadBufferAt(__in HANDLE hFile,
        __out_bcount(cbBuffer) void *pvBuffer,
        DWORD cbBuffer,
        DWORD64 offset)
     DWORD cbRead;
     li.QuadPart = offset;
     return SetFilePointerEx(hFile, li, nullptr, FILE_BEGIN) &&
            ReadFile(hFile, pvBuffer, cbBuffer, &cbRead, nullptr) &&
            cbBuffer == cbRead;
    int __cdecl wmain(int argc, wchar_t **argv)
     HANDLE hFile = CreateFile(argv[1], GENERIC_READ,
      nullptr, OPEN_EXISTING, 0, nullptr);
     if (hFile != INVALID_HANDLE_VALUE) {
      if (ReadBufferAt(hFile, &hdr, sizeof(hdr), 0) &&
          hdr.idReserved == 0 && hdr.idType == 1) {
       for (UINT uiIcon = 0; uiIcon < hdr.idCount; uiIcon++) {
        ICONDIRENTRY entry;
        if (ReadBufferAt(hFile, &entry, sizeof(entry),
                         sizeof(hdr) + uiIcon * sizeof(entry))) {
         void *pvData = LocalAlloc(LMEM_FIXED, entry.dwBytesInRes);
         if (pvData) {
          if (ReadBufferAt(hFile, pvData,
                           entry.dwBytesInRes, entry.dwImageOffset)) {
           // process one image in the icon
     return 0;

    Run this program with the name of an icon file on the command line, and nothing interesting happens because the program doesn't generate any output. But if you step through it, you can see that we start by reading the ICON­DIR­HEADER to verify that it's an icon and determine the number of images. We then loop through the images: For each one, we read the ICON­DIR­ENTRY (specifying the explicit file offset), then read the image data (again, specifying the explicit file offset).

    We use the Read­Buffer­At function to read data from the file. For each read, we first call Set­File­Pointer to position the file pointer at the byte we want to read, then call Read­File to read it.

    Let's change this program to take advantage of our newfound knowledge:

    BOOL ReadBufferAt(__in HANDLE hFile,
        __out_bcount(cbBuffer) void *pvBuffer,
        DWORD cbBuffer,
        DWORD64 offset)
     OVERLAPPED o = { 0 };
     o.Offset = static_cast<DWORD>(offset);
     o.OffsetHigh = static_cast<DWORD>(offset >> 32);
     DWORD cbRead;
     return ReadFile(hFile, pvBuffer, cbBuffer, &cbRead, &o) &&
            cbBuffer == cbRead;

    We merge the Set­File­Pointer call into the Read­File by specifying the desired byte offset in the optional OVERLAPPED structure. The I/O will still complete synchronously (since we opened the handle synchronously), but we saved ourselves the hassle of having to call two functions when it could be done with just one.

  • The Old New Thing

    Introducing the unrolled-switch anti-pattern


    Over the years, I've seen a bunch of coding anti-patterns. I figured maybe I'll share a few.

    Today, I'll introduce what I'm calling the unrolled-switch anti-pattern, also known as "Specialization is always faster, right?"

    enum Axis
    // code earlier in the function ensure that
    // "axis" is always a valid axis
    int newPosition;
    switch (axis)
    case XAxis:
        newPosition = m_position[XAxis] + amount;
        if (newPosition < m_minPosition[XAxis])
            newPosition = m_minPosition[XAxis];
        if (newPosition > m_maxPosition[XAxis])
            newPosition = m_maxPosition[XAxis];
        m_position[XAxis] = amount;
    case YAxis:
        newPosition = m_position[YAxis] + amount;
        if (newPosition < m_minPosition[YAxis])
            newPosition = m_minPosition[YAxis];
        if (newPosition > m_maxPosition[YAxis])
            newPosition = m_maxPosition[YAxis];
        m_position[YAxis] = amount;
    case ZAxis:
        newPosition = m_position[ZAxis] + amount;
        if (newPosition < m_minPosition[ZAxis])
            newPosition = m_minPosition[ZAxis];
        if (newPosition > m_maxPosition[XAxis])
            newPosition = m_maxPosition[XAxis];
        m_position[ZAxis] = amount;
    As we all know, special-case code is faster than general-purpose code. Instead of writing slow general-purpose code:

        newPosition = m_position[axis] + amount;
        if (newPosition < m_minPosition[axis])
            newPosition = m_minPosition[axis];
        if (newPosition > m_maxPosition[axis])
            newPosition = m_maxPosition[axis];
        m_position[axis] = amount;

    we unroll it into a switch statement, thereby generating highly-optimized special-purpose code, one for each axis.

    What makes this anti-pattern particularly frustrating is that you cannot tell at a glance whether all the cases really are the same (just with different axes).

    In fact, they aren't.

    If you look closely, you'll see that we check the new Z-position against the X-axis maximum rather than the Z-axis maximum. If you're reading this code, you now start to wonder, "Is this a copy/paste bug, or is there some reason that we really do want to check the Z-position against the X-axis minimum?"

    A variation on the unrolled-switch is the unrolled-if, used if the item you want to unroll cannot be used in a switch statement:

    FruitBasket *BananaBasket;
    FruitBasket *AppleBasket;
    FruitBasket *PearBasket;
    FruitBasket *MangoBasket;
    if (basket == BananaBasket) {
      if (!BananaBasket->IsEmpty()) {
        fruit = BananaBasket->TakeFruit();
        if (HaveKnife()) {
        } else {
    } else if (basket == AppleBasket) {
      if (!AppleBasket->IsEmpty()) {
        fruit = AppleBasket->TakeFruit();
        if (HaveKnife()) {
        } else {
    } else if (basket == PearBasket) {
      if (!PearBasket->IsEmpty()) {
        fruit = PearBasket->TakeFruit();
        if (HaveKnife()) {
        } else {
    } else if (basket == MangoBasket) {
      if (!MangoBasket->IsEmpty()) {
        fruit = MangoBasket->TakeFruit();
        if (HaveKnife()) {
        } else {

    When I pointed out in an aside to the customer that this could be simplified (after fixing the copy/paste errors) to

    if (!basket->IsEmpty()) {
      fruit = basket->TakeFruit();
      if (HaveKnife()) {
      } else {

    the response was, "Hey, that's a neat trick. I didn't realize you could do that."

    I wonder if this person also programs loops like this:

    switch (limit)
    case 0:
    case 1:
    case 2:
      for (int i = 0; i < 2; i++) do_something(array[i]);
    case 3:
      for (int i = 0; i < 3; i++) do_something(array[i]);
    case 4:
      for (int i = 0; i < 4; i++) do_something(array[i]);
    case 5:
      for (int i = 0; i < 5; i++) do_something(array[i]);
    case 6:
      for (int i = 0; i < 6; i++) do_something(array[i]);
    case 999:
      for (int i = 0; i < 999; i++) do_something(array[i]);
      FatalError("Need more cases to handle larger array");
  • The Old New Thing

    Shortcut properties are in the shortcut, so if they can read the shortcut, they can read the properties


    A customer wanted to know if "there was a way to hide the properties of a shortcut."

    We asked for an explanation of the problem they were trying to solve, so we could understand what their question meant. The customer liaison explained:

    The customer is insisting on this, even though I think it's really the wrong approach. They want to put a password into the parameters of a shortcut, but they don't want their employees to see the password when they right-click the shortcut and select Properties. We're trying to convince them of better ways of doing this, but right now they want to see if they can solve it by marking the field as "hidden" somehow.

    If the password is anywhere in the shortcut file, the employees can dig it out. After all, the shell needs to dig it out, and since the shell runs with the user's privileges, in order for the shell to see it, the user must be able to see it. In other words, you can't hide anything in a shortcut because the user can just open the shortcut in Notepad and see all your "hidden" data. Or they can go to Task Manager and ask to see the command line. Or they can connect a debugger to Explorer and set a breakpoint on the Create­Process function.

    It's like saying, "I want my employees to be able to bake cakes, but I don't want them to have access to an oven. To block access to the oven, I put a combination lock on the oven controls. On the other hand, I want to write a cake recipe that lets the employees bake cakes in the oven. Therefore, the recipe says Step 5: Go to the oven and press 1234. But now the employee can just read the recipe and find out the combination to the oven! Is there a way I can write a cake recipe that lets them bake a cake without revealing the oven combination?"

    The recipe executes with the privileges of the employee. If you want the employee to be able to bake a cake by following the recipe, then they need to be able to perform the steps in the recipe, and that means being able to go to the oven and press 1234.

    The oven analogy does provide some ideas on how you can solve the problem. For example, if you simply don't want employees to be able to email the oven combination to their friends with the subject line Here's the combination to the oven!, then change the way access to the oven is managed. Instead of putting a combination lock on the oven, put an employee ID card scanner on the oven that enables the oven controls if the employee has oven privileges.

    For the original problem, this means changing your database so that instead of using a single password to control access and trusting each client to use it wisely, it uses the security identity of the client to control access. (I'm assuming that the password on the command line is a database password.)

    On the other hand, if your goal is to prevent employees from using the oven to do anything other than bake at 350°F for one hour, you can change the employee ID card scanner so that it checks the employee for cake-baking privileges, and if so, sets the oven to bake for 350°F for one hour and locks the controls (except perhaps for a cancel button). If you have multiple recipes—say, cakes and cookies—the ID card scanner checks which recipes the employees are allowed to use and lets them choose which preset they want to activate.

    For the original problem, this means changing your database so that the user identity selects which operations are permitted on the database. Some users have permission to see only records for active clients, whereas others have permission to see all records, and still others have modify permission.

    If your goal is to prevent employees from doing anything other than baking cakes according to this specific recipe, then you need to move even more actions "behind the counter", because you have no way of knowing that "that pan full of batter" was created according to your walnut cake recipe, or whether it's some unauthorized recipe with extra cinnamon. If you don't trust your employees to follow recipes, then you need to take the recipe out of their hands. The instructions are now Step 1: Order a walnut cake from the cafeteria.

    For the original problem, this means changing your database so that instead of letting the employee access records directly, the employee submits the action to the database ("change client 23 address to 123 Main Street"), and the database verifies that the employee has "change a client address" permission, and if so, performs the record update.

    Of course, if you want to ignore all the security guidance and "just hide the password in the shortcut file, why won't you answer my question?", you can just put the password somewhere other than the shortcut file. You could, say, have the shortcut run a batch file, and the batch file has the password.

  • The Old New Thing

    Registration-free COM the old-fashioned way: The car mp3 player


    Windows XP introduced Registration-Free COM, permitting you to place your COM object registrations in a manifest rather than in the registry. Very handy when you want to support xcopy deployment or running directly off a thumb drive. And very much in keeping with the principle of not using a global solution for a local problem. (If you need your COM object to be used from other programs, then global registration is not unreasonable, but if the only client is another part of your program, then you have a local problem that should employ a local solution.)

    Here are some articles on the subject:

    Before manifest-based COM object registration was possible, you had to do things the old-school way. Mind you, old-school registration-free COM is not a very useful skill any more, falling into the same category as knowing how to churn butter or use a typewriter eraser, but since when did that ever stop me from writing about something?

    One old-school way is to call Dll­Get­Class­Object directly. This works only if you control both sides of the equation (the client and the server) because it's now your responsibility to ensure that both sides agree on the threading model. You won't have the actual COM libraries sitting in between watching out for scenarios that require marshalling, for example.

    For a toy project of mine, I used a different approach. My little project was an mp3 player for my laptop. Now, sure, we already have tons of mp3-playing apps out there, but mine was different: Mine was designed to be used on long driving trips. (This was back in the days when long driving trips were part of my life. I don't drive that much any more.)

    Here was the plan: I connected the line-out from the laptop into my car sound system, so that the music came out my car speakers. Meanwhile, all input to the program came from the mouse. Specifically, it came from the mouse buttons and the wheel. The mouse itself never moved. The idea was that I could hook up a mouse to the laptop, put the laptop on the passenger seat, and leave the mouse on the center console. I would then use the mouse buttons and wheel to navigate my music collection. I forget exactly what I ended up doing, but it was something like

    • Left button click = select current item
    • Right button click = go up one level
    • Rotate wheel = scroll through current directory

    Now remember, this program was designed to be used while driving, which means both eyes on the road. (This was long before hands-free driving laws came on the scene.) Therefore, the program provided feedback not by displaying items on the screen but by using speech synthesis to read the names of the files and directories out loud. Finding a song to play, therefore, consisted of turning the wheel and listening as the laptop read out the name of the album, then when I found the one I wanted, I would click the left mouse button, and then I would use the wheel to scroll through the songs, and when I heard the title of the one I wanted, I clicked the left mouse button again, and boom, the song started playing.

    I added some heuristics to the code so if consecutive tracks began with the same words (which happens often with classical music, think Symphony #5 in c minor, first movement followed by Symphony #5 in c minor, second movement) it spoke only the changes.

    While the song was playing, the mouse buttons served as playback controls. I think it went something like this:

    • Left button click = pause / play
    • Right button click = exit and choose another song
    • Rotate wheel = rewind / fast-forward ten seconds
    • Press middle mouse button and rotate wheel = previous/next track

    (Exercise: Why didn't I need a volume control?)

    The easiest programming language for this was a Web page. I created a host program that simply created a Web browser control. The host program told the Web browser control to navigate to my carplay.html file, and boom, I now had an in-car playback system. I could use things like File­System­Object to navigate the file system and the Windows Media Player control to do the playback. Now, this story takes place so many years ago that Internet Explorer didn't support the mouse wheel yet, so the host program also converted wheel messages into fake keyboard activity (wheel motion was converted into the up and down arrows) so that the Web page could respond to them.

    Once nice thing about this whole set-up is that I had the HTML DOM at my disposal. My program spewed diagnostic output to the screen like crazy, but who cares? The end user isn't looking at the screen. Therefore, the entire Web page is free real estate for debugging.

    The only thing missing was the speech synthesizer.

    There was no ActiveX control for speech synthesis, so I wrote one of my own. I let SAPI do the heavy lifting; my ActiveX control was simply some glue that let a Web page pass a string to be spoken. (Or pass a null string to shut up.) I wanted my program to be xcopy-deployable (USB thumb drives didn't exist back then) so I looked for a registration-free technique. The Dll­Get­Class­Object technique wouldn't work since I didn't control how Internet Explorer created COM objects; it always called Co­Create­Instance.

    The technique I used was Co­Register­Class­Object. I created a class factory for my object and explicitly registered it before creating the Web browser control. That way, when the Web page asked for my object, lo and behold, there it was: In memory, not in the registry.

    That was a really long-winded story with a punch line that tells you how to do something you don't need to do any more because there are easier ways of doing it nowadays. I wouldn't be surprised if you wanted a refund.

    The real punch line: I spent far more time writing the program than I ever did using it.

  • The Old New Thing

    I thought I was so clever, salvaging an old floppy drive from a dead computer, but I didn't think *two* steps ahead...


    When one of the oldest computers at Microsoft still doing useful work finally died, I had the presence of mind to salvage the 5¼″ floppy drive from the machine, so that I could (someday) extract the data off all the old 5¼″ floppy discs I have packed away in boxes meaning to convert someday. (Mind you, the data capacity of a giant box of 5¼″ floppy disks is approximately equal to half of a CD.)

    Oh, and by the way, if you know what a floppy drive is, then this question on superuser.com will make you feel old.

    I thought I was so clever, salvaging an old floppy drive from a dead computer so I could use it to rescue data from obsolescence, but that was only thinking one step ahead. I failed to think two steps ahead: Nobody makes motherboards with 5¼″ floppy drive connectors!

    Bonus coincidental posting date: The Geeks Who Saved Prince of Persia's Source Code From Digital Death.

  • The Old New Thing

    Why don't I get a Caps Lock warning balloon any more?


    A customer asked for help diagnosing a problem they were experiencing on Windows XP:

    My customer reports that on their machines, they do not get the warning balloon that appears when Caps Lock is set while you are typing into a password field. I searched for relevant KB articles but couldn't find anything related to that. Can you help?

    Time for the psychic powers.

    My psychic powers tell me that the customer disabled all balloon tips.

    The customer liaison replied

    You are right. Thanks for the help.

    This is a not uncommon situation with some customers. They change a setting, and then later report that they're having some problem caused by that setting. They don't bother going to a freshly-installed machine to see whether the problem occurs there as well, in order to isolate whether the problem is related to their customizations or not. They just assume that their customizations couldn't possibly be the cause of the problem, and they are so convinced of this that they don't even mention "Oh, we customized this setting" when they ask for help.

    By the way, the setting to disable all balloon tips in the entire system is a rogue feature. At the time that balloons were originally being developed (and the rules surrounding them being refined based on research and feedback), one developer was impatient with the progress toward making the balloons less annoying, and he just went in and added a rogue feature to disable them with a sledgehammer. And now that people know about it, the rogue feature has become a support burden.

  • The Old New Thing

    I know that an overlapped file handle requires an lpOverlapped, but why does it (sometimes) work if I omit it?


    A customer observed that the formal requirements for the Read­File function specify that if the handle was opened with FILE_FLAG_OVERLAPPED, then the lpOverlapped parameter is mandatory. But the customer observed that in practice, passing NULL results in strange behavior. Sometimes the call succeeds, and sometimes it even returns (horrors!) valid data. (Actually the more horrifying case is where the call succeeds and returns bogus data!)

    Now sure, you violated one of the requirements for the function, so the behavior is undefined. But why doesn't Read­File just flat-out fail if you call it incorrectly?

    The answer is that the Read­File function doesn't know whether you're calling it correctly.

    The Read­File function doesn't know whether the handle you passed was opened for overlapped or synchronous access. It just trusts that you're calling it correctly and builds an asynchronous call to pass into the kernel. If you passed a synchronous handle, well, it just issues the I/O request into the kernel anyway, and you get what you get.

    This quirk traces its history all the way back to the Microsoft Windows NT OS/2 Design Workbook. As originally designed, Windows NT had a fully asynchronous kernel. There was no such thing as a blocking read. If you wanted a blocking read, you had to issue an asynchronous read (the only kind available), and then block on it.

    As it turns out, developers vastly prefer synchronous reads. Writing asynchronous code is hard. So the kernel folks relented and said, "Okay, we'll have a way for you to specify at creation time whether you want a handle to be synchronous or asynchronous. And since lazy people prefer synchronous I/O, we'll make synchronous I/O the default, so that lazy people can keep being lazy."

    The Read­File function is a wrapper around the underlying Nt­Read­File function. If you pass an lpOverlapped, then it takes the OVERLAPPED structure apart so it can pass the pieces as an Io­Status­Block and a Byte­Offset. (And if you don't pass an lpOverlapped, then it needs to create temporary buffers on the stack.) All this translation takes place without the Read­File function actually knowing whether the handle you passed is asynchronous or synchronous; that information isn't available to the Read­File function. It's relying on you, the caller, to pass the parameters correctly.

    As it happens, the Nt­Read­File function does detect that you are trying to perform synchronous I/O on an asynchronous handle and fails with STATUS_INVALID_PARAMETER (which the Read­File function turns into ERROR_INVALID_PARAMETER), so you know that something went wrong.

    Unless you are a pipe or mailslot.

    For some reason, if you attempt to issue synchronous I/O on an asynchronous handle to a pipe or mailslot, the I/O subsystem says, "Sure, whatever." I suspect this is somehow related to the confusing no-wait model for pipes.

    Long before this point, the basic ground rules for programming kicked in. "Pointers are not NULL unless explicitly permitted otherwise," and the documentation clearly forbids passing NULL for asynchronous handles. The behavior that results from passing invalid parameters is undefined, so you shouldn't be surprised that the results are erratic.

Page 1 of 3 (22 items) 123