• The Old New Thing

    How did protected-mode 16-bit Windows fix up jumps to functions that got discarded?


    Commenter Neil presumes that Windows 286 and later simply fixed up the movable entry table with jmp selector:offset instructions once and for all.

    It could have, but it went one step further.

    Recall that the point of the movable entry table is to provide a fixed location that always refers to a specific function, no matter where that function happens to be. This was necessary because real mode has no memory manager.

    But protected mode does have a memory manager. Why not let the memory manager do the work? That is, after all, its job.

    In protected-mode 16-bit Windows, the movable entry table was ignored. When one piece of code needed to reference another piece of code, it simply jumped to or called it by its selector:offset.

        push    ax
        call    0987:6543

    (Exercise: Why didn't I use call 1234:5678 as the sample address?)

    The selector was patched directly into the code as part of fixups. (We saw this several years ago in another context.)

    When a segment is relocated in memory, there is no stack walking to patch up return addresses to point to thunks, and no editing of the movable entry points to point to the new location. All that happens is that the base address in the descriptor table entry for the selector is updated to point to the new linear address of the segment. And when a segment is discarded, the descriptor table entry is marked not present, so that any future reference to it will raise a selector not present exception, which the kernel handles by reloading the selector.

    Things are a lot easier when you have a memory manager around. A lot of the head-exploding engineering in real-mode windows was in all the work of simulating a memory manager on a CPU that didn't have one!

  • The Old New Thing

    How can I query the location of the taskbar on secondary monitors?


    A customer wanted to know how to get the location of the taskbar on secondary monitors. "I know that SHApp­Bar­Message will tell me the location of the taskbar on the primary monitor, but how do I get its location on secondary monitors?"

    We asked the customer what their actual problem is, where they think that determining the taskbar location on secondary monitors is the solution. The customer was kind enough to explain.

    Our application shows a small window, and sometimes users move it behind the taskbar. They then complain that they can't find it, and they have to move their taskbar out of the way in order to find it again. We want our window to automatically avoid the taskbar.

    The solution to the customer's problem is to stop obsessing about the taskbar. Use the Get­Monitor­Info function to obtain the working area for the monitor the window is on. The window can then position itself inside the working area.

    The working area is the part of the monitor that is not being used by the taskbar or other application bars. The customer was too focused on avoiding the taskbar and missed the fact that they needed to avoid other taskbar-like windows as well.

    The customer was kind enough to write back to confirm that Get­Monitor­Info was working.

  • The Old New Thing

    It's not too late (okay maybe it's too late) to get this gift for the physicist who has everything


    A LEGO set to measure Planck's constant.

  • The Old New Thing

    It rather involved being on the other side of this airtight hatchway: Account vulnerable to Active Directory administrator


    A security vulnerability report came in that went something like this:

    Disclosure of arbitrary data from any user

    An attacker can obtain arbitrary data from any user by means of the following steps:

    1. Obtain administrative access on the domain controller.
    2. Stop the XYZZY service.
    3. Edit the XYZZY.DAT file in a hex editor and changes the bytes starting at offset 0x4242 as follows:
    4. ...

    There's no point continuing, because the first step assumes that you are on the other side of the airtight hatchway. If you have compromised the domain controller, then you control the domain. From there, all the remaining steps are just piling on style points and cranking up the degree of difficulty.

    A much less roundabout attack is as follows:

    1. Obtain administrative access on the domain controller.
    2. Deploy a logon script to all users that does whatever you want.
    3. Wait for the user to log in next, and your script will DO ANYTHING YOU WANT.

    No, wait, I can make it even easier.

    1. Obtain administrative access on the domain controller.
    2. Change the victim's password.
    3. Log on as that user and DO ANYTHING YOU WANT.

    You are the domain administrator. You already pwn the domain. That you can pwn a domain that you pwn is really not much of a surprise.

    This is why it is important to choose your domain administrators carefully.

  • The Old New Thing

    If you set up roaming profiles, you are expected to set up each machine identically, for the most part


    A customer discovered the following behavior when they set up roaming user profiles on their domain. Consider two machines, 1 and 2. An application A is installed on machine 1, but not machine 2. A user with a roaming profile logs onto machine 1 and pins application A to the taskbar. That user then logs off of machine 1 and logs onto machine 2.

    Now things get interesting: The taskbar on machine 2 initially shows a white icon on the taskbar, representing the nonexistent application A. A short time later, that icon vanishes. When the user logs off of machine 2 and back onto machine 1, the pinned icon is missing on machine 1, too.

    The white icon is deleted automatically by the system because it sees that you pinned an application which is not installed, so it unpins it too. This general rule is to handle the case where you install an application and pin it, then somebody else unninstalls it. The taskbar removes the now-broken icon to reflect the fact that the application is no longer installed. There's no point having a shortcut to a nonexisting program, and it relieves application vendors the impossible task of cleaning up pinned icons upon uninstall. (It's impossible because some users who pinned the application may not have their profile locally present because it roamed to another machine. Or worse, the uninstaller tries to edit a profile that is not active and ends up corrupting the master copy when the two versions reconcile.)

    The user profiles team explained that one of the assumptions behind classic roaming user profiles is that the machines participating in roaming be semantically identical: They must be running the same operating system on the same processor architecture. They must have the same set of applications installed into the same locations. And they must have the same drive letter layout.

    But that's just classical roaming profiles. There are other roaming profile solutions, such as User Experience Virtualization, which may meet the customer's needs better. (I'm told that there are also third-party roaming solutions, though I don't know of any offhand, this not being my area of expertise.)

  • The Old New Thing

    When corporate policies meet precision scientific equipment


    One of my colleagues used to work as an IT consultant, and one of his clients was a tobacco company. Since they were a tobacco company, the company policy on smoking was "You can smoke anywhere, any time."

    "Anywhere" includes the labs. The labs with very expensive precision scientific equipment.

    My colleague told me that this policy meant that the company regularly replaced $50,000 pieces of equipment after only a few months, thanks to smoke damage. But the company couldn't change their smoking policy. Imagine the public relations disaster if a tobacco company had a no-smoking policy!

    Starting next year, cigarette maker Reynolds American will be a smoke-free workplace.

    Bonus chatter: One of the researchers showed my colleague one of those pieces of expensive scientific equipment. The way my colleague explained it, "On the graph was a spike. The spike is what makes the cigarette taste good. It also is what kills you. The trick was to tweak the product in order to move the spike far enough to the right that people prefer the product over the competition, but not so far that you end up killing your customer base." (Note that this was my colleague's interpretation of what the researcher said, not the researcher's actual words.)

  • The Old New Thing

    Notes on calculating constants in SSE registers


    There are a few ways to load constants into SSE registers.

    • Load them from memory.
    • Load them from general purpose registers via movd.
    • Insert selected bits from general purpose registers via pinsr[b|w|d|q].
    • Try to calculate them in clever ways.

    Loading constants from memory incurs memory access penalties. Loading or inserting them from general purpose registers incurs cross-domain penalties. So let's see what we can do with clever calculations.

    The most obvious clever calculations are the ones for setting a register to all zeroes or all ones.

        pxor    xmm0, xmm0 ; set all bits to zero
        pcmpeqd xmm0, xmm0 ; set all bits to one

    These two idioms are special-cased in the processor and execute faster than normal pxor and pcmpeqd instructions because the results are not dependent on the previous value in xmm0.

    There's not much more you can do to construct other values from zero, but a register with all bits set does create additional opportunities.

    If you need a value loaded into all lanes whose bit pattern is either a bunch of 0's followed by a bunch of 1's, or a bunch of 1's followed by a bunch of 0's, then you can shift in zeroes. For example, assuming you've set all bits in xmm0 to 1, here's how you can load some other constants:

        pcmpeqd xmm0, xmm0 ; set all bits to one
        pslld  xmm0, 30    ; all 32-bit lanes contain 0xC0000000
        psrld  xmm0, 29    ; all 32-bit lanes contain 0x00000007
        psrld  xmm0, 31    ; all 32-bit lanes contain 0x00000001

    Intel suggests loading 1 into all lanes with the sequence

        pxor    xmm0, xmm0 ; xmm0 = { 0, 0, 0, 0 }
        pcmpeqd xmm1, xmm1 ; xmm1 = { -1, -1, -1, -1 }
        psubd   xmm0, xmm1 ; xmm0 = { 1, 1, 1, 1 }

    but that not only takes more instructions but also consumes two registers, and registers are at a premium since there are only eight of them. The only thing I can think of is that psubd might be faster than psrld.

    In general, to load 2ⁿ−1 into all lanes, you do

        pcmpeqd xmm0, xmm0 ; set all bits to one
        psrlw  xmm0, 16-n  ; clear top 16-n bits of all 16-bit lanes
        psrld  xmm0, 32-n  ; clear top 32-n bits of all 32-bit lanes
        psrlq  xmm0, 64-n  ; clear top 64-n bits of all 64-bit lanes

    Conversely, if you want to load ~(2ⁿ−1) = -2ⁿ into all lanes, you shift the other way.

        pcmpeqd xmm0, xmm0 ; set all bits to one
        psllw  xmm0, n     ; clear bottom n bits of all 16-bit lanes = 2¹⁶ - 2ⁿ
        pslld  xmm0, n     ; clear bottom n bits of all 32-bit lanes = 2³² - 2ⁿ
        psllq  xmm0, n     ; clear bottom n bits of all 64-bit lanes = 2⁶⁴ - 2ⁿ

    And if the value you want has all its set bits in the middle, you can combine two shifts (and stick something in between the two shifts to ameliorate the stall):

        pcmpeqd xmm0, xmm0 ; set all bits to one
        psrlw  xmm0, 13    ; all lanes = 0x0007
        psllw  xmm0, 4     ; all lanes = 0x0070
        psrld  xmm0, 31    ; all lanes = 0x00000001
        pslld  xmm0, 3     ; all lanes = 0x00000008

    If you want to set high or low lanes to zero, you can use pslldq and psrldq.

        pcmpeqd xmm0, xmm0 ; set all bits to one
        pslldq xmm0, 2     ; clear bottom word, xmm0 = { -1, -1, -1, -1, -1, -1, -1, 0 }
        pslldq xmm0, 4     ; clear bottom dword, xmm0 = { -1, -1, -1, 0 }
        pslldq xmm0, 8     ; clear bottom qword, xmm0 = { -1, 0 }
        psrldq xmm0, 2     ; clear top word, xmm0 = { 0, -1, -1, -1, -1, -1, -1, -1 }
        psrldq xmm0, 4     ; clear top dword, xmm0 = { 0, -1, -1, -1 }
        psrldq xmm0, 8     ; clear top qword, xmm0 = { 0, -1 }

    No actual program today. Just some notes from my days writing SSE assembly language.

    Bonus chatter: There is an intrinsic for pxor xmmReg, xmmReg: _mm_setzero_si128. However, there is no corresponding intrinsic for pcmpeqd xmmReg, xmmReg, which would presumably be called _mm_setones_si128 or _mm_setmone_epiNN. In order to get all-ones, you need to get a throwaway register and compare it against itself. The cheapest throwaway register is one that is set to zero, since that is special-cased inside the processor.

    __m128i zero = _mm_setzero_si128();
    __m128i ones = _mm_cmpeq_epi32(zero, zero);
  • The Old New Thing

    Detecting whether a SID is well-known SID


    You might think that the Is­Well­Known­Sid function would tell you whether a SID is well-known, but it doesn't. Rather, it tells you whether a SID exactly matches the well-known SID you specified. For example, you can ask, "Is this the Authenticated Users SID?" or "Is this the Everyone SID?" But you can't ask, "Is this any type of well-known SID?"

    I guess you could enumerate through all the well-known SIDs, and check if your SID matches any of them, but that's getting kind of ugly.

    If what you're interested in is whether this is a machine-relative SID (or a domain-relative SID, which is the special case where the machine is the domain controller), as opposed to a universal SID, you can check whether the SID format is S-1-5-21-#-#-#-#. All machine-relative SIDs have that form.

    #define SECURITY_NT_NON_UNIQUE          (0x00000015L) // decimal 21

    If you want to exclude machine\Administrator and other predefined machine-relative SIDs, you can verify that the last number (the RID) is greater than or equal to 1000.

  • The Old New Thing

    What states are possible in a DRAWITEMSTRUCT structure?


    The DRAW­ITEM­STRUCT structure has an item­State member which contains a number of bits describing the state of the item being drawn. How do those states map to the underlying control?

    Most of the states are rather obvious. For a list box item to be selected, it means that the item is part of the selection. But what does selected mean for a button?

    Since people like tables, I'll put the answer in a table:

    Menu Listbox Combobox Button
    itemID menu item ID item index or −1 item index or −1
    ODS_SELECTED Selected Selected Selected Pushed
    ODS_GRAYED Grayed
    ODS_DISABLED Disabled Disabled Disabled Disabled
    ODS_CHECKED Checked
    ODS_FOCUS Focus Focus Focus
    ODS_DEFAULT Default menu item
    ODS_INACTIVE Inactive
    ODS_NOACCEL HideAccel HideAccel HideAccel HideAccel
    ODS_NOFOCUSRECT HideFocus HideFocus HideFocus
    ODS_COMBOBOXEDIT Is edit control
    Static Header Tab Listview Status
    itemID item index item index item index part index
    ODS_SELECTED Pushed Selected Selected
    ODS_CHECKED AutoChecked
    ODS_FOCUS Focus
    ODS_NOACCEL HideAccel

    Okay, now that it's all in a table, how do I read the table?

    A box is blank if the corresponding flag is not currently used by the control type. (No guarantees about the future.) For example, as of this writing, button controls do not set an itemID, nor do they ever ask for ODS_GRAYED.

    You may have noticed that the box for CtlType is blank for status controls. That's an oops. The status bar control forgot to set the CtlType when it sends the WM_DRAW­ITEM message, so the value is uninitialized garbage. The way to detect a status bar control is to check the window handle. (This works in general. You can always detect a control by checking the window handle.)

    For list boxes and combo boxes, the itemID can have the special value -1 to mean "I am drawing a list box/combo box where no item is selected." For list boxes, this happens when the list box is empty. For combo boxes, this happens when the user types text into the edit box that does not match any of the items in the list portion of the combo box.

    Most of the other box entries are self-explanatory. For the most part, the flag name matches the conditions under which the corresponding flag is set. For example, the ODS_FOCUS flag is set when the list box item being drawn is the selected item.

    Note that the ODS_SELECTED flag is used for button and header controls to indicate that the control should be drawn in the pushed state. For example, the user may have put focus on a button control and pressed the space bar and not yet released it, or the application may have manually set the BST_PUSHED state. Header controls can get into a pushed state if you enable the HDS_BUTTONS style.

    List view controls set the ODS_CHECKED flag if a check box should be drawn over the item. This happens if the LVS_EX_AUTO­CHECK­SELECT extended style is specified and the item is selected. (Normally, the check box is drawn to the side as a state image.)

    The ODS_COMBO­BOX­EDIT flag is used only by combo box controls. It is set if the item being drawn is the edit portion of a combo box control. If not set, then the item being drawn is in the list box portion of the combo box control.

    Finally, there is a box marked Oops.

    The static control is supposed to set ODS_DISABLED if the static control is disabled. And that's what happens if you are using the classic static control. However, there is a typo in the the fancy themed static control, and it sets the ODS_DISBALED flag incorrectly. If you are owner-drawing a themed static control, and you want to draw differently depending on whether the control is disabled, then you should ignore the ODS_DISABLED flag and instead draw the disabled state based on the result of calling Is­Window­Enabled function.

    The bug in the themed static control cannot be fixed for compatibility reasons. I can pretty much guarantee that there is some application which doesn't draw correctly if the ODS_DISABLED flag is not set.

  • The Old New Thing

    If you get a procedure address by ordinal, you had better be absolutely sure it's there, because the failure mode is usually indistinguishable from success


    A customer reported that the Get­Proc­Address function was behaving strangely.

    We have this code in one of our tests:

    typedef int (CALLBACK *T_FOO)(int);
    void TestFunctionFoo(HINSTANCE hDLL)
      // Function Foo is ordinal 1 in our DLL
      T_FOO pfnFoo = (T_FOO)GetProcAddress(hDLL, (PCSTR)1);
      if (pfnFoo) {
        ... run tests on pfnFoo ...

    Recently, this test started failing in bizarre ways. When we stepped through the code, we discovered that pfnFoo ends up calling Bar instead of Foo. The first time we try to test pfnFoo, we get stack corruption because Bar has a different function prototype from Foo, and of course on top of that the test fails horribly because it's calling the wrong function!

    When trying to narrow the problem, we found that the issue began when the test was run against a version of the DLL that was missing the Foo function entirely. The line

        Foo @1

    was removed from the DEF file. Why did the call to Get­Proc­Address succeed and return the wrong function? We expected it to fail.

    Let's first consider the case where a DLL exports no functions by ordinal.


    The linker builds a list of all the exported functions (in an unspecified order) and fills in two arrays based on that list. If you look in the DLL image, you'll see something like this:

    Exported Function Table
    00049180 address of Bar
    00049184 address of Foo
    0004918C address of Plugh
    Exported Names
    00049190 address of the string "Bar"
    00049194 address of the string "Foo"
    00049198 address of the string "Plugh"

    There are two parallel arrays, one with function addresses and one with function names. The string "Bar" is the first entry in the exported names table, and the function Bar is the first entry in the exported function table. In general, the string in the Nth entry in the exported names table corresponds to the function in the Nth entry of the exported function table.

    Since it is only the relative position that matters, let's replace the addresses with indices.

    Exported Function Table
    [1] address of Bar
    [2] address of Foo
    [3] address of Plugh
    Exported Names
    [1] address of the string "Bar"
    [2] address of the string "Foo"
    [3] address of the string "Plugh"

    Okay, now let's introduce functions exported by ordinal. When you do that, you're telling the linker, "Make sure this function goes into the NNth slot in the exported function table." Suppose your DEF file went like this:

        Foo @1

    This says "First thing we do is put Foo in slot 1. Once that's done, fill in the rest arbitrarily."

    The linker says, "Okay, I have a total of three functions, so let me build two tables with three entries each."

    Exported Function Table
    [1] address of ?
    [2] address of ?
    [3] address of ?
    Exported Names
    [1] address of ?
    [2] address of ?
    [3] address of ?

    "Now I place Foo in slot 1."

    Exported Function Table
    [1] address of Foo
    [2] address of ?
    [3] address of ?
    Exported Names
    [1] address of the string "Foo"
    [2] address of ?
    [3] address of ?

    "Now I fill in the rest arbitrarily."

    Exported Function Table
    [1] address of Foo
    [2] address of Bar
    [3] address of Plugh
    Exported Names
    [1] address of the string "Foo"
    [2] address of the string "Bar"
    [3] address of the string "Plugh"

    Since you explicitly placed Foo in slot 1, when you do a Get­Proc­Address(hDLL, 1), you will get Foo. On the other hand, if you do a Get­Proc­Address(hDLL, 2), you will get Bar, or at least you will with this build. With the next build, you may get something else, because the linker just fills in the slots arbitrarily, and next time, it may choose to fill them arbitrarily in some other order. Furthermore, if you do a Get­Proc­Address(hDLL, 6), you will get NULL because the table has only three functions in it.

    I hope you see where this is going.

    If you delete Foo from the EXPORTS section, this stops exporting Foo but says nothing about what goes into slot 1. As a result, the linker is free to put anything it wants into that slot.

    Exported Function Table
    [1] address of Bar
    [2] address of Plugh
    Exported Names
    [1] address of the string "Bar"
    [2] address of the string "Plugh"

    Now, when you do a Get­Proc­Address(hDLL, 1), you get Bar, since that's the function that happened to fall into slot 1 this time.

    The moral of the story is that if you try to obtain a function by ordinal, then it had better be there, because there is no reliable way of being sure that the function you got is one that was explicitly placed there, as opposed to some other function that happened to be assigned that slot arbitrarily.

    Related reading: How are DLL functions exported in 32-bit Windows?

Page 1 of 438 (4,378 items) 12345»