I wasn’t there, but I can guess.

My guess is that the implementation always generated the two events one right after the other, so “obviously” the way you correlate them is to save the old name when you see the FILE_ACTION_RENAMED_OLD_NAME, and when the FILE_ACTION_RENAMED_NEW_NAME comes immediately after, you have your two sides.

But they never wrote down that the two events always occur in direct succession. Which meant that when new file systems came along, they might not honor the unwritten rule. If two files are being renamed at the same time, is it possible that the two sets of rename events end up interleaved? There was nothing written down to forbid it, so I guess it’s possible.

Note that I don’t know whether any file systems actually break this unwritten rule. From what I can tell, they do generate the two events in rapid succession, but rapid succession doesn’t a priori guarantee that they will come directly one after the other, particularly if there is a lot of concurrent disk activity going on.

In practice, I couldn’t find a lot of code tracking renames anyway. They generally treated the FILE_ACTION_RENAMED_OLD_NAME as a deletion and the FILE_ACTION_RENAMED_NEW_NAME as a creation. And the ones that did track renames assumed that renames did not interleave. (Not that they had much choice.)

I don’t think that providing the file IDs for the two sides of a rename operation was the purpose of Read­Directory­Changes­ExW‘s Read­Directory­Notify­Extended­Information. It was just a happy side effect that the extra information in the Read­Directory­Notify­Extended­Information also gives you the pieces needed to connect the dots reliably.

I thought you might appreciate me pointing out the trick, that’s all.

The post Why didn’t <CODE>Read­Directory­ChangesW</CODE> provide a way to correlate the two sides of a rename operation? appeared first on The Old New Thing.

The only way to get rid of the Close button is not to have a System menu at all: Remove the WS_SYS­MENU style from the window. But that also gets rid of the Minimize and Maximize buttons, so it’s kind of drastic.

If you want a System menu, or if you want Minimize and Maximize buttons, you can at least disable the Close button by disabling the SC_CLOSE menu item.

HMENU menu = GetSystemMenu(hwnd, FALSE);
EnableMenuItem(menu, SC_CLOSE, MF_DISABLED);

Of course, you could use the nuclear option and implement your own custom title bar. Then you can do whatever you want. But most people are probably not willing to take things to such an extreme.

But really, try not to hide or disable the Close the button at all. End users don’t like it. It makes them feel trapped.

The post How can I remove the Close button from my window caption? appeared first on The Old New Thing.

The ud2 instruction is an architecturally undefined instruction, guaranteed to raise an “invalid opcode” exception. Some compilers generate it to mark “unreachable” code, so that if execution somehow manages to reach it, you get a crash rather than executing random instructions. For example, if a function marked [[noreturn]] somehow returns, the compiler will put a ud2 after the call so that the program crashes instead of falling through to the next function.

Anyway, why is this instruction called ud2 instead of just ud? Was there a ud1? What was so wrong about ud1 that we had to make a ud2?

I think I can reconstruct what happened.

Originally, there was no architecturally undefined instruction on x86. So people who wanted to force an invalid opcode exception went looking for some byte sequence that reliably raised the invalid opcode exception when executed.

Somebody found that the 0F FF sequence led to an invalid opcode exception. Though, for whatever reason, the instruction internally decoded as if it took two parameters, a register destination and a register-or-memory source. The parameters aren’t actually used because the invalid opcode exception gets raised before anything else can happen.

Meanwhile, somebody else found that the 0F B9 sequence also had the same properties. So you now had two factions, the 0F FF believers and the 0F B9 adherents. There really wasn’t much of a battle between them, because both techniques seemed to work, and it’s not like one was coming at the detriment of the other.

Intel then worked on their next processor, and maybe they made some changes that resulted in 0F FF no longer raising an invalid opcode exception. Maybe they tried introducing a new instruction that uses 0F FF. Or maybe it was still undefined but just performed some random operation instead of raising the invalid opcode instruction. And when they started running software on their new processor, they found that some programs stopped working, and after laborious investigation, they discovered that the programs were relying on 0F FF being an invalid opcode.

In other words, they ran into Hyrum’s Law: With a sufficient number of users, all observable behaviors will be depended upon by somebody. Obligatory XKCD.

A similar discovery was made with 0F B9.

Now that they realized that people wanted a reliable way to trigger an invalid opcode exception, the folks at Intel decided to make it official, and they created an actual supported permanently-invalid instruction and called it ud2.

It’s called ud2 because the 0F FF variant was retroactively named ud0, and the 0F B9 variant was retroactively named ud1, leaving ud2 as the recommended undefined opcode.

One advantage of ud2 is that it is a two-byte instruction with no parameters, so you don’t have to deal with the random decoded-but-unused source and destinations.

Bonus chatter: But why do we care about the unused parameters to ud0 and ud1? Can’t we just say that ud0 and ud1 are also two-byte invalid opcodes? I mean, sure, there’s a third byte, or possibly more if the memory operand has an offset or a scaled index, but the processor doesn’t use it.

It matters, because even though the processor doesn’t use it, it still decodes it. And if the decoding of the instruction crosses into a not-present page, you don’t get an invalid opcode exception at all. You get an access violation.

Bonus bonus chatter: Except that some older processors raised the invalid opcode instruction as soon as they decoded the 0F FF without checking whether the rest of the instruction decoded properly. So if your 0F FF is at the end of a page, and the next page is not present, you sometimes got an invalid opcode exception and you sometimes got an access violation.

Better to stick with ud2. Its behavior is consistent and architecturally guaranteed.

The post Why is the x86 undefined instruction called <CODE>ud2</CODE>? Why 2? appeared first on The Old New Thing.

Has anyone attempted to figure out the RNG for how Windows XP determines what profile picture is used on first account creation?

— Xeno (@XenoPanther) December 11, 2025

The random number generator is our friend RtlRandomEx, using the current value of GetTickCount() as the initial seed.

The function uses a one-pass random selection algorithm. I can immediately think of two benefits of this decision. First, compared to the naïve two-pass algorithm of counting up all the items, then randomly picking a number from 1 to n, and then iterating a second time to find the item at that index, it’s more efficient because it reduces the amount of calls into the file system, which is where the bottleneck is. Furthermore, the one-pass algorithm avoids complications if the number of files in the directory changes while the code is running.

The one-pass algorithm is a special case of reservoir sampling, where k is 1. This special case permits a tailored algorithm that is much simpler.

selectRandomFromIterator(iterator)
{
    var count = 0;
    var winner = null;

    while (iterator.moveNext()) {
        ++count;
        if (uniform_random(min: 1, max: count) == count) {
            winner = iterator.current();
        }
    }

    return winner;
}

The way this algorithm works is by observing that in a collection of n items, the last item has a 1/n chance of being randomly selected. If it isn’t selected, then you need to select randomly from the first n − 1 items, which you can solve recursively.

Playing the recursion forward, you start with the base case which is that if you have a list of 1 item, then your only choice is to chose that item. Otherwise, if you have a list of n items, first choose an item randomly from the first n − 1, and then switch to the nth item with a 1/n probability.

As a final safety check, the code stops after sampling 100 pictures. This avoids pathological behavior if somebody puts a million files in the Default Pictures directory.

The post What algorithm did Windows XP use to choose your initial user picture? appeared first on The Old New Thing.

I found a reference to winstart.bat in the Windows 3.1 SETUP.TXT file:

Using the TIGA Display Driver
-------------------------------
If you are using the TIGA display driver, you must load the TIGACD.EXE
MS-DOS driver manually before running Setup to upgrade Windows.
Otherwise, Windows will not upgrade your system properly.

After successfully setting up Windows, you can increase the amount of
conventional memory available to non-Windows applications when Windows
is running in 386 enhanced mode by loading TIGACD.EXE from the
WINSTART.BAT file. The WINSTART.BAT file runs only in 386 enhanced
mode. If you want to run Windows in standard mode, you must load
TIGACD.EXE manually. For more information, see the README.WRI online
document.

TIGA is the Texas Instruments Graphics Architecture, a standard for high-resolution graphics modes on PCs. It held some sway for a while but ultimately fell to competing standards like VESA and SuperVGA.

The TIGACD.EXE program is the TIGA Communications Driver which seems to be the program which implements the TIGA APIs for a particular class of video cards. You need to run this TSR so that the Windows TIGA driver can use these TIGA APIs to run the video cards in resolutions higher than standard VGA, like (gasp) 800×600.

But on the other hand, it’s probably the case that only Windows needs to be able to use the video card at such high resolution. Your MS-DOS programs will just use the standard VGA resolution, if they use graphics mode at all!

In fact, MS-DOS programs cannot use the TIGA modes. The graphics card vendors wrote 16-bit Windows graphics drivers, which teach 16-bit Windows how to draw graphics with those modes. But they did not write 32-bit Windows virtual display drivers, which teach the 32-bit Windows virtual machine manager how to give each virtual machine their own virtual TIGA video card, each of which could be in a different TIGA mode. For example, this 32-bit driver has to save the video card state and memory when the user switches out of a full-screen MS-DOS program, and then restore it when the user switches back. In other words, they did not provide the necessary support for multitasking TIGA graphics among Windows and MS-DOS sessions. TIGA can be used in only one virtual machine, and the obvious choice is to let Windows use it.

This was the recommendation from Microsoft in Windows 3.1, and it appears that the recommendation was extended by Siemens to cover Windows 95 as well.

So at least one vendor continued to use it in Windows 95. I wouldn’t be surprised if there were others that also used it, but we simply don’t see them because they have such small audiences.

The post A sample use of the <CODE>winstart.bat</CODE> file in Windows 95 appeared first on The Old New Thing.

So the question is asking why the stack must be contiguous. Why not let it be sparse and fault in only the pages that are touched?

The first issue is that the stack check code would have to include an explicit check against the stack limit, instead of just walking down the stack a page at a time. This explicit check is needed to avoid security vulnerabilities if somebody manages to alloca a buffer so large that it goes past the end of the stack reservation entirely. If you go a single page at a time, you will eventually hit the no-access page that marks the end of the stack. But if you can leap over multiple pages at a time without touching them, you might leap so far past the end of the stack that you land somewhere else and start corrupting that other memory because you’re using it as a stack. In linux circles, this vulnerability is nicknamed “Stack Clash“¹ and goes more formally by “stack guard-page hopping.”²

After fixing that issue, you have another problem: How would you report a failure to commit a page in the middle of the stack?

void dosomething()
{
    void* buffer = NULL;
    __try {
        buffer = alloca(65536);
    } __except (GetExceptionCode() == STATUS_STACK_OVERFLOW) {
        if (!_resetstkoflw()) __fastfail(FAST_FAIL_FATAL_APP_EXIT);
    }

    if (buffer != NULL) {
        ⟦ use the buffer ⟧
    }
}

If you allowed sparse stacks, then the memory for the buffer would not actually be committed until the code used it. But the point the code uses the buffer is outside the exception handler for the failed alloca(). The code assumes, not unreasonably, that if alloca succeeds, then the memory is indeed allocated.

I guess you could fix this by committing the memory without making it present. That would mean making a call to Virtual­Alloc to expand the stack rather than just accessing the memory. Not only would this make the stack expansion code more complicated, particularly since you have to preserve all the registers that might possibly be used by any calling convention, but you also have to make sure that the Virtual­Alloc function itself doesn’t allocate too much stack!

Now, you can still tweak the x86-32 stack prober to avoid pete.d‘s problem, where a large stack frame is made completely present, with the resulting page-ins creating noticeable performance issues. The x86-32 prober could short-circuit the stack probe (like the MIPS and other processors listed in the table on this page) so that the page-ins occur only when the stack is actually expanding.

¹ Bonus reading about Stack Clash:

• Stack Clash Mitigation in GCC — Background
• Stack Clash mitigation in GCC: Why -fstack-check is not the answer
• Stack clash mitigation in GCC, Part 3

² Some systems mitigate stack guard-page hopping by creating a really large no-access region beyond the end of the stack. However, this isn’t a fix; just a mitigation. It just makes people have to leap further to clear the no-access region. If you already have this vulnerability, it’s probably because an attacker can control the size of the allocation, in which case you didn’t really slow them down by much; they just have to put a bigger number in their attack payload.

Other systems address this more thoroughly by (surprise) probing each page of the stack in sequence.

Stack Clash continues to be a problem even though gcc had a solution in 2020. Here’s CVE-2026-77658 from just a few days ago.

The post Why don’t we allow stacks to be sparse, instead of forcing them to be contiguous? appeared first on The Old New Thing.

It turns out that there are even more applications that expect to be able to modify GWW_CB­WND­EXTRA. So many that it wasn’t worth creating an application compatibility exception for them.

So what happens when you modify GWW_CB­WND­EXTRA, or its modern equivalent, GWL_CB­WND­EXTRA?

The change in window extra bytes takes effect, but not retroactively.

Windows that are created after you change CB­WND­EXTRA receive the updated number of extra bytes, but windows that already exist are not modified. They still have the number of extra bytes that were assigned when the window was created.

Specifically to deal with people who change the number of window extra bytes on the fly, the system keeps track of what the number of extra bytes was at the time the window was created, and those are the bytes you get to access from that window. If you try to access the nonexistent bytes, you are told ERROR_INVALID_INDEX.

This does mean that you can get into a strange situation where Get­Class­Long(hwnd, GCL_CB­WND­EXTRA) tells you that you have 8 extra bytes, say, but if you use Get­Window­Long(hWnd, 0), which asks for the LONG represented by bytes 0–3, you are told “Sorry, that’s out of range.” As far as you can tell, it is well within range. What you don’t know is that the window was created back when the GCL_CB­WND­EXTRA was less than 4.

There is no way to ask a window, “How many extra bytes do you really have?” I mean, why the system go out its your way to improve the lives of people who are abusing it?

The post What happens if you change a window class’s <CODE>GCL_<WBR>CB­WND­EXTRA</CODE>? appeared first on The Old New Thing.

// C#

async Task<bool> DownloadItemAsync(string id)
{
    var op = item.DownloadAsync(id);
    op.Progress += (s, pct) UpdateProgress(pct);
    var result = await op;
    ClearProgress();
    return result;
}

This is pretty standard stuff. Start the operation, hook up the progress, and then wait for the operation to complete. But they never got any progress.

I asked them to check if maybe the item was downloading so fast that they missed all the progress. But no, even if the download takes a long time, they never get any progress.

I suggested that they step through the Download­Async method to see where it raises progress, and then follow the execution to the point where the progress callback is supposed to be invoked, to see why it didn’t make it. (To be fair, this is a cross-language debugging problem, so it’s harder than it looks. I suggested just focusing on the C++ side: Wait for the COM-callable wrapper to be generated and set as the progress callback, and then set a breakpoint on that wrapper. If that breakpoint gets hit, but the C# code doesn’t run, then there is a problem in the projection. If the breakpoint never gets hit, then the problem is on the C++ side.)

My colleague came back with the answer. Here’s the code for Download­Async:

// C++/WinRT

winrt::IAsyncOperationWithProgress<bool, double>
    AggregateSource::DownloadAsync(winrt::hstring id)
{
    std::wstring_view idview { id };
    auto pos = idview.find(L':');
    if (pos == std::wstring_view::npos) {
        co_return false;
    }

    auto providerId = Unescape(idview.substr(0, pos - 1));

    auto provider = GetProvider(providerId);
    if (!provider) {
        co_return false;
    }

    auto providerItemId = Unescape(idview.substr(pos + 1));
    co_return co_await provider.DownloadAsync(providerItemId);
}

The Aggregate­Source gathers items from multiple providers. The format of the id is a provider, a colon, and then an ID. (The provider ID and item ID are escaped, just in case they themselves happen to contain a colon.)

We look up the provider, and then ask the provider to download the item.

Do you see the problem?

The Download­Async does not generate any progress reports!

It never calls co_await winrt::get_progress_token(), much less call the token with a progress value to generate a progress report.

It’s apparent that what the code wants to do when it attaches the progress callback is to receive callbacks from the inner operation, the one that comes from the provider. However, the only IAsync­Operation­With­Progress that it has access to is the one returned by the Aggregate­Source::Download­Async method.

The easy solution here is to get rid of the middle man and just return the provider’s IAsync­Operation­With­Progress. That way, the caller can connect to the underlying operation’s progress.

winrt::IAsyncOperationWithProgress<bool, double>
    AggregateSource::DownloadAsync(winrt::hstring id)
{
    std::wstring_view idview { id };
    auto pos = idview.find(L':');
    if (pos == std::wstring_view::npos) {
        return completed_async(false);
    }

    auto providerId = Unescape(idview.substr(0, pos - 1));

    auto provider = GetProvider(providerId);
    if (!provider) {
        return completed_async(false);
    }

    auto providerItemId = Unescape(idview.substr(pos + 1));
    return provider.DownloadAsync(providerItemId);
}

If you don’t believe in completed_async, you can just write

        return [] -> winrt::IAsyncOperationWithProgress<bool, double> {
            return false;
        }();

I said that this is the easy solution. There’s also a hard solution, which we will have to look at later because I haven’t written it up yet.

The post The case of the progress callback that never got called when progress happened appeared first on The Old New Thing.

Some time later, they came back with the solution to the mystery.

The team noticed that their data model consisted only of strings and other value types, so they decided to declare their data model as a struct rather than a full runtimeclass, thereby avoiding a lot of boilerplate typing.

If defined as a runtimeclass:

// MyComponent.idl
runtimeclass MyPageContent
{
    String Title { get; };
    String Description { get; };
    String LinkUri { get; };
    Boolean IsNew{ get; };
}

// MyPageContent.h

namespace winrt::MyComponent
{
    struct MyPageContent : implements<MyPageContent>
    {
        MyPageContent(hstring const& title,
                    hstring const& description,
                    hstring const& link,
                    bool isNew) :
            m_title(title),            
            m_description(description),
            m_link(link),              
            m_isNew(isNew) {}          

        hstring Title() const { return m_title; }
        hstring Description() const { return m_description; }
        hstring Link() const { return m_link; }
        bool IsNew() const { return m_isNew; }

    private:
        hstring m_title;
        hstring m_description;
        Windows::Foundation::Uri m_link;
        bool m_isNew;
    };
}

// Consumer.cpp

m_pages.Append(winrt::make<MyPageContent>(
                    title, description, link, isNew));

But if you define it as a struct, then most of this code isn’t necessary:

// MyComponent.idl
struct MyPageContent
{
    String Title;
    String Description;
    String Link;
    Boolean IsNew;
}

// MyPageContent.h not needed

// Consumer.cpp

m_pages.Append(MyPageContent(title, description, link, isNew));

Tastes great, less filling.

Now, the thing that makes value types value types is that they are copy-by-value, not copy-by-reference. This means that when XAML calls GetAt(n) on the m_pages to get the nth item, it gets a copy of the MyPageContent and binds to the copy.

And that’s the source of the problem.

When the code wants to navigate to a specific item at the request of the assistive technology tool, it passes the MyPageContent to navigate to, but that’s just another copy because value types are always passed by copy. XAML says, “I don’t have that guy” and fails the navigation. (XAML doesn’t realize that it has a guy who looks just like that guy. Not that it matters, because it’s not the same guy.)

The clever shortcut turned out to be the problem.

Now, while it’s true that there’s a bunch of typing needed to implement a C++/WinRT runtime class, there are helpers to reduce the amount of typing required. In the Windows Implementation Library (wil), the cppwinrt_authoring.h header contains classes to simplify the implementation of events and properties. It exploits CRTP in the same way I discussed some time ago.

// MyPageContent.h

namespace winrt::MyComponent
{
    struct MyPageContent : implements<MyPageContent>
    {
        MyPageContent(hstring const& title,
                    hstring const& description,
                    hstring const& link,
                    bool isNew) :
            Title(title),            
            Description(description),
            Link(link),              
            IsNew(isNew) {}          

        wil::single_threaded_property<hstring> Title;      
        wil::single_threaded_property<hstring> Description;
        wil::single_threaded_property<hstring> Link;       
        wil::single_threaded_property<bool> IsNew;         
    };
}

We can get away with using a single_threaded_property because the properties are written only at construction, so concurrent reads are not going to cause problems.

The post The perils of binding to value types in XAML appeared first on The Old New Thing.

In business, funding usually refers to having enough money to pay for ongoing operations.

In Microsoft engineering groups, it doesn’t mean that.

In Microspeak, funding refers to having enough people available to work on a feature. A feature that has adequate people assigned to work on it is considered to be funded, or for emphasis, fully funded, whereas a feature that does not have people working on it is unfunded.

Of course, you can have intermediate states, like partially funded, to say that some people have been assigned to it, but not enough to finish the work in time for a specific requested completion date.

Here are some citations I found.

Funding for this feature is being worked through.

This is another way of saying, “We are working on finding people to work on this feature.” This might come at the cost of defunding whatever feature those people had previously been assigned to.

The path for getting out of red involves closing on funding gaps.

In other words, there is a color-coded dashboard on which a feature is currently listed as red. There are currently some shortfalls in staffing (funding gaps), and we will have to resolve (close on) those shortfalls in order to get out of red to a more favorable color.

X said that they do not have engineering resources to fund the Y updates.

In a larger discussion about updating components throughout the system to support the Y feature, person X said that they do not have any people available who can do the Y work for their component.

Note that a feature that is unfunded is not cut. The feature is still planned. It’s just that there is nobody available to do it right now. If funding cannot be obtained soon, the feature will have to be delayed to a later release.

Bonus chatter: Software engineers are not fungible. If you take a developer who works on the taskbar and reassign them to the window manager they won’t be as effective as someone who normally works on the window manager. Furthermore, reassigning a developer across teams involves the receiving team having an open req, and reqs are generally difficult to come by since they are subject to all sorts of business constraints.

The post Microspeak: Funded / unfunded appeared first on The Old New Thing.