Nostr notes by Raymond Chen (Unofficial)

The Microsoft building that was reportedly haunted Earlier this ...

2026-10-31T10:49:03Z

The Microsoft building that was reportedly haunted

Earlier this year, Microsoft sold what was known as Building 22, an office building just up the hill from what is now the Overlake Village Station stop on the light rail 2 line.¹ The build was demolished in late June, bring an end to a creepy piece of Microsoft history.
Building 22 began its life in 1982, when construction began on what was then known as the Koll Center Overlake business park. The building was owned and operated by The Koll Company, a commercial real estate company, and was scheduled to be completed in the middle of 1983.
In February 1991, Microsoft purchased the building from Koll, and by July it was occupied by the International Product Group.
During its time as a Microsoft office, Building 22 was believed by many to be haunted. The descriptions ranged from “it was creepy to say the least” to “the ghosts were quite benign” to “those ghosts were no joke”. Evidence included a phenomenon nicknamed “sick building syndrome” that made many people ill, elevator doors opening randomly, unexplained whistling or rattling sounds from the windows, occasional ghost spottings in the hallway, and at least one time that a car’s parking brake failed, causing the empty car to roll down the hill and collide with another car. Did a ghost release the brake? Who knows?
At the time, there was a Group Health hospital complex next door.² Somehow, the story got around that Building 22 had previously served as the morgue³ for the hospital, and I suspect that the ghost stories and the morgue theory developed in tandem. However, research by Microsoft’s own archives team could not find significant evidence that the building was ever a morgue, despite people insisting with certainty that their office was exactly where the morgue used to be.
Haunted or not, the new owners of the building intend to build apartments on the property. Were the ghosts sold with the building? Will the new apartment be haunted? We’ll let the future residents decide.
Bonus chatter: An old Channel 9 video introduces us to Building 22, ghost included.
Bonus bonus chatter: Another morbid reputation that Building 22 had was that it where teams were “sent to die”, meaning that they were transferred to the building as a final stop before the team was disbanded.
Some people nicknamed Building 22 “Hotel California” or “the black hole” because once you were assigned there, it was almost impossible to get out. You might get moved to another building, but somehow you ended up back in 22. One person who managed to escape quipped, “The longest two years of my career were the six months I spent there.”
Part of what contributed to the dreary reputation of Building 22 was that due to the steep slope of the terrain, half of the bottom floor was underground. One person who had an office on the bottom floor said that it was comfortably cool in the summer, but freezing cold in the winter.
Another quirk of the building was that there was bridge from the uphill side directly into the second floor. People on the first floor whose offices were in the shadow of the bridge nicknamed themselves “trolls”.
¹ Not to be confused with “The Village at Overlake Station”, a residential complex about four blocks from Overlake Village Station.
² The property was sold in 2009 and is now the Esterra Park development.
³ An alternate rumor was that the building used to be the psychiatric ward for the hospital, and the room above the atrium was allegedly the padded room for people at risk of hurting themselves. Some people reported hearing screams from the padded room area.
The post The Microsoft building that was reportedly haunted appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261030-00/?p=112815/

#building #overlakevillage #koll #villagestation #kollcenter #haunted #kollcompany #another #productgroup #internationalproduct

#rss #feeds #linksharing #qwibbit

The support case of a customer who said that all they could see ...

2026-10-30T07:09:12Z

The support case of a customer who said that all they could see was a black screen

If you hold a PC’s power button for 12 seconds, it will turn off at the hardware level without notifying the operating system. This is a safety feature so that you can turn of the computer even if the operating system’s “Shut down” command isn’t working.
After eight seconds of the power button being held down, the Windows kernel realizes that the user is trying to do a force-power-off of the system, and it quickly takes a kernel dump that can be uploaded to the Windows Error Reporting service the next time you turn the system on. (Sometimes four seconds isn’t enough time to get enough information, and the kernel dump is incomplete. I believe that on Windows Insider builds of Windows, you get a message that says something like “Please let go of the power button so we can collect more information, and then we will turn off the computer.” This gives the kernel more time to finish capturing its kernel dump.)
These emergency kernel dumps are internally classified as “long power button hold” (LPBH) failures. One of the pieces of information recorded in these emergency kernel dumps is whether the screen consists entirely of black pixels. Those failures are sub-classified as “black screen LPBH”, and they go to a special virtual team for analysis. (I happen to be a member of this black screen LPBH team.)
Sometimes the problem is a broken video driver. Sometimes the video driver is doing just fine, but the desktop compositor is just handing black pixels to the video driver. Sometimes the desktop compositor is doing just fine, but nobody is drawing anything to the screen. And those cases are further subdivided further into cases like “there is nobody around to draw anything” or “the person who normally draws stuff is hung.”
Back in the Windows 3.1 days, there was a customer product support call that would today have been classified as a “black screen” bug: The customer reported that they turned on the computer, and Windows started up, but when the logo went away, all they saw was a blank screen.
After some questioning, the customer support engineer put the story together: It turned out that this customer really liked the color black, so they decided to set up a goth theme. They set the wallpaper color to black. They set the title bar color to black. They set the button color to black. They set the window background color to black. They set the window text color to black. Every possible color you could pick in the Colors control panel was set to black.
Once you get yourself into this situation, it’s hard to get out because you can’t see anything.
I don’t know how the customer support engineer fixed the problem, but I’m guessing that they booted into MS-DOS, ran EDIT.COM, and deleted the [colors] section from the win.ini file, thereby returning all the system colors to defaults.
The post The support case of a customer who said that all they could see was a black screen appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261029-00/?p=112808/

#black #screen #customer #lpbh #support #windowserror #errorreporting

#rss #feeds #linksharing #qwibbit

C++/WinRT overcorrection: Using make_self and immediately ...

2026-10-28T22:01:54Z

C++/WinRT overcorrection: Using make_self and immediately converting it to the projected interface

In C++/WinRT, there are two ways of creating objects that you yourself implement.
For the purpose of this discussion, let Impl be the class you wrote that implements a Windows Runtime object. If you are implementing something that was declared in an IDL file, it will be the winrt::Namespace::implementation::ClassName for the instance object or it will be the winrt::Namespace::factory_implementation::ClassName for the factory object. If it wasn’t declared in an IDL file, then it is the class that you manually derived from winrt::implements.
One way to create the object is to use make<Impl>, which creates the implementation object and then returns the Windows Runtime projection version of that object. (If Impl is manually-derived from winrt::implements, the projection is the first implemented interface.)
From that Windows Runtime projection, you can regain access to the implementation object by doing get_self<Impl>(projected), if you want to access things in the implementation object that aren’t exposed in the projection.
Alternatively, you use make_self<Impl>, which creates the object but returns a winrt::com_ptr<Impl> instead of a projection. You can then access things in the implementation object from that winrt::com_ptr, and convert it to the projected type with the * operator.
make
make_self
↓
↓
projection
get_self
→
implementation
←
operator*
Which one you choose depends on where you want to go first.
If you are first going to access non-projected public members of the implementation class, use the -> operator on the com_ptr<Impl>. For example, you might want to set up the object before returning the projection.
winrt::IVector<winrt::Widget>
MakeWidgets(int style, int count)
{
std::vector<winrt::Widget> v(count, nullptr);
std::generate(v.begin(), v.end(), [&] {
auto widget = winrt::make_self<implementation::Widget>(style);
widget->Enabled(true);
return *widget;
});
return winrt::multi_threaded_vector(std::move(v));
}
But if you are just going to use the projection, you can take the direct route instead of going the long way.
// The long way
winrt::IVector<winrt::Widget>
MakeWidgets(int style, int count)
{
std::vector<winrt::Widget> v(count, nullptr);
std::generate(v.begin(), v.end(), [&] {
auto widget = winrt::make_self<implementation::Widget>(style);
return *widget;
});
return winrt::multi_threaded_vector(std::move(v));
}
make_self
↓
projection
←
operator*
implementation
↓
returned
In this case, you don’t need to pass through the implementation type.
// The short way
winrt::IVector<winrt::Widget>
MakeWidgets(int style, int count)
{
std::vector<winrt::Widget> v(count, nullptr);
std::generate(v.begin(), v.end(), [&] {
return winrt::make_self<implementation::Widget>(style);
});
return winrt::multi_threaded_vector(std::move(v));
}
make
↓
projection
↓
return
My guess is that the people who go the long way don’t realize that there are two ways. They learned only one way and just rely on it even if there’s a shorter way.
The post C++/WinRT overcorrection: Using <CODE>make_self</CODE> and immediately converting it to the projected interface appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261028-00/?p=112803/

#winrt #windowsruntime #interface

#rss #feeds #linksharing #qwibbit

Why don’t we run the taskbar and Task Manager at high priority, ...

2026-10-28T10:03:13Z

Why don’t we run the taskbar and Task Manager at high priority, so they can remain responsive?

If a system becomes CPU-starved, all processes begin to suffer. This includes the taskbar and Task Manager, even though they are often the tools you want to use to stop whatever it is that’s making your system suffer. Why can’t we run the taskbar and Task Manager at high priority?
The catch with running anything at high priority is that unless you have been very careful to avoid it, you will eventually run into a shared resource that you will have to wait for, and you are now stuck. Your priority checkout pass gets you to the front of the line, but if the person at the register has a large shopping cart full of groceries, you just have to wait until they are done before you get your chance.
Even if the code that protects the shared resource is careful to avoid priority inversion by transferring the priority of the waiter to the thread that owns the resource, you are still stuck waiting, and that owning thread might be doing something that takes a long time, like, say, accessing a file over the network.
For UI code, this problem is particularly acute because you will eventually have to call into the UI system, and now you’re duking it out with all the other UI threads in the system.
The problem is that it’s hard to fix a runaway system from within that same system. The tools which you can use to try to fix the system may already have been compromised. And it’s definitely hard to fix a runaway system if your tools have to share critical resources with the thing that is out of control. Windows already gives preferential treatment to the program that is in focus, so if you can get focus onto the taskbar or Task Manager, you are doing about as well as you can. But that preferential treatment takes you only so far if those preferred threads find themselves blocked on things that are controlled by non-preferred threads.
The post Why don’t we run the taskbar and Task Manager at high priority, so they can remain responsive? appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261027-00/?p=112800/

#taskmanager #highpriority #even

#rss #feeds #linksharing #qwibbit

Puzzling out why a program doesn’t work when run from a batch ...

2026-10-27T00:13:40Z

Puzzling out why a program doesn’t work when run from a batch file, but works when double-clicked from Explorer

A customer asked for help writing a batch file to launch a program. For some reason, the program displayed an error message when the batch file ran it, whereas it worked fine when they double-clicked the program from Explorer.
I immediately suspected that they were not setting the current directory.
Some time ago, I noted that when you double-click a file in Explorer, Explorer sets the current directory of the program to the directory containing the thing that you double-clicked. This is done to accomodate programs that look for ancillary files in the current directory. The example I had was a hypothetical LitWare Writer program that, when given an ABC.LIT file, looks for related files like ABC.LTC (the table of contents) and ABC.LDC (the custom dictionary) in the current directory.
This also happens if you double-click the .exe file: The current directory is set to the directory that contains the executable.
My guess is that the customer’s program looks for ancillary files relative to its current directory, but the batch file ran the program by its full path without changing the current directory to match the program’s path.
The customer confirmed that explicitly changing the directory fixed the program. (More specifically, they used pushd to change the directory and then popd to restore the original directory.)
Bonus chatter: It didn’t come to it, but my second idea would have been to check whether the program had set a custom entry under App Paths to ask for additional directories to be added to the PATH environment variable when the program is run.
The post Puzzling out why a program doesn’t work when run from a batch file, but works when double-clicked from Explorer appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261026-00/?p=112797/

#batchfile #explorer #run #path #apppaths

#rss #feeds #linksharing #qwibbit

Why didn’t we use CoRegisterInitializeSpy to clean up the ...

2026-10-23T23:45:07Z

Why didn’t we use CoRegisterInitializeSpy to clean up the unmarshalable delegate?

Another suggestion from Luca Bacci on creating a fake agile wrapper that is technically agile but is not useful outside its home apartment was to use the IInitializeSpy interface.
Some of the thing that made The RoRegisterForApartmentShutdown unsuitable also apply to CoRegisterInitializeSpy. For example, you are required to revoke the spy from the same thread that registered it, which means that we have to remember the original thread so we can somehow get back to executing code on it.
Another problem is explicitly noted in the documentation for CoRevokeInitializeSpy:
It is unpredictable whether a call to CoRevokeInitializeSpy from within an IInitializeSpy method call will have an effect during the current top-level (non-nested) call to CoInitializeEx or CoUninitialize.
This is the same problem we had with RoUnregisterForApartmentShutdown function, in the case where the original object’s destruction in turn triggers an attempt to revoke an initialize spy: It revokes the spy, thinking that this will stop the callbacks, but in fact, the callback might still happen.
It also suffers from the same implementation issue regarding the number of initialize spies: Registration is O(1), but unregistration is O(n) because it does a linear search through a linked list. The assumption is that initialize spies are rarely unregistered before they are triggered.
But there’s an even bigger problem that makes this completely unsuitable for using an initialize spy to clean up an object at apartment shutdown, and maybe you noticed it in the earlier discussion.
Initialize spies are registered on a per-thread basis, not per-apartment.
If the original object is in the multi-threaded apartment, then it’s wrong to give up the object once the original thread uninitializes COM, because it might still be kept alive by another thread.
Also, a thread may change apartments over time. For example, if you are not in the neutral apartment and you call into an object that is in the neutral apartment, then there is no thread switch. COM merely removes your thread temporarily from whatever apartment it is in and puts the thread into the neutral apartment for the duration of the call.
Now, if the thread had previously belonged to a single-threaded apartment, and somebody makes a call into an object on that single-threaded apartment, COM may temporarily remove that thread from the neutral apartment and put it back into the original single-threaded apartment for the duration of that call.
A thread may move between apartments during its lifetime, but the IInitializeSpy is tied to the thread, not to the apartment.
This means that if the non-marshalable object happens to live in, say, the neutral apartment, you would be given that object in the neutral apartment, and you would register your IInitializeSpy against the thread that is currently running. When that thread uninitializes COM as a single-threaded apartment, your PreUninitialize would be running in that dying single-threaded apartment, but it can’t clean up the object because the object is in the neutral apartment, not the single-threaded apartment.
So yeah, IInitializeSpy doesn’t really help.
The post Why didn’t we use <CODE>CoRegisterInitializeSpy</CODE> to clean up the unmarshalable delegate? appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261022-00/?p=112791/

#apartment #lucabacci #initialize #clean #use #com #spy

#rss #feeds #linksharing #qwibbit

Why didn’t we use the COM static store to clean up the ...

2026-10-23T23:10:56Z

Why didn’t we use the COM static store to clean up the unmarshalable delegate?

A third suggestion from Luca Bacci on creating a fake agile wrapper that is technically agile but is not useful outside its home apartment was to use the COM static store.
The COM static store doesn’t help us, because the COM static store runs down when the last thread shuts down COM, whereas we want something that runs down when a single apartment shuts down COM.
There is a per-apartment version of the COM static store, but it is part of the CoreApplicationView, which is (1) something that only UWP programs have, and (2) exists only for apartments that have a core application view, and those are restricted to single-threaded apartments.
Even if there were a per-apartment static store, putting something into it would require generating a unique name and remembering it for later removal. You could probably use the stringified address of the object, with a fixed GUID prefix as a pseudo-namespace. Since we’re dealing with a dictionary, the insertion and removal operations are going to be O(log n) or O(1), depending on the implementation, but even the constant-time version will have a higher constant than a single index lookup in the Global Interface Table.
The post Why didn’t we use the COM static store to clean up the unmarshalable delegate? appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261023-00/?p=112793/

#comstatic #staticstore #lucabacci #interfacetable #globalinterface

#rss #feeds #linksharing #qwibbit

Microspeak: Drain the slide, back-up slides Recall that ...

2026-10-22T01:45:50Z

Microspeak: Drain the slide, back-up slides

Recall that Microspeak is not merely for jargon exclusive to Microsoft, but it’s jargon that you need to know to survive at Microsoft. Even if you don’t use it yourself, you need to know what it means when others say it.
To drain the slide is, as Mark Myers explains it, reading the contents of a slide to the audience when giving a presentation. At least at Microsoft, the term is frequently used by a speaker in the negative, such as “I don’t want to drain the slide here…”
My theory is that the phenomenon of draining the slide has multiple sources.
One is simply the result of inexperience on the part of the presenter. They don’t know what to say when giving a presentation, so they end up just reading out the text that they wrote on the slide.
A more insidious source is the result of tension between the multiple reason for creating a slide deck.
One reason to create a slide deck is to accompany a presentation. The focus of the presentation is the speaker, and the slide deck is there merely as a visual aid.
Another reason to create a slide deck is to provide a lasting record of the presentation and to serve as a reference for the future. If the topic is “How to perform process X”, then you want to make sure that all of the necessary steps are spelled out on the slides, so that you can share a link to the slide deck in the invitation for others to refer to both during the presentation but mostly for reference afterwards. People will refer back to the slides the next time they need to do process X, and they probably don’t want to have to scrub through a one-hour recording just to extract the five steps they need to follow.
Yet another reason for creating a slide deck is when presenting to a senior executive, such as for use in a placemat review. There is probably a standard template for the meeting, such as an “Accomplishments since the last meeting”, perhaps broken into “What’s going well”, “What’s not going well”, and followed by an “Items of future concern”. The meeting may run into a time crunch (because they always run over), and you may not get enough time to get through all your slides, so you want to be able to say, “You can read the rest of the slides after the meeting.” (An extreme case of this is where other teams in the placemat meeting run long and leave you with no time at all!)
A related reason for creating a slide deck is as a “proof of work”. Going into the placement review, you don’t have much to report, but you have to fill the slide. If you don’t, it looks like you haven’t done anything.
I was reminded of this last reason when I worked with a colleague to prepare our team’s weekly placemat report. My colleague would fill the slide with information, and I would recommend replacing most of the bullet points with a much more succicient summary, or just removing the items outright.
Partner Team X is considering the possibility of deploying a version that uses widgets before all of the widget features are fully implemented and rolled out to customers. They understand the consequences, such as impaired reverse widget flow. Some of these missing features will light up when the implementation is ready, but others will be stuck in a broken state unless explicit remediations are performed after the implementation rolls out, and a small number of features will be irreparably broken, with the only recourse being to destroy all the affected widgets and recreate them. Partner Team X has been advised of the various failure modes and how they can recover from the ones that are recoverable, and they are assessing whether they want to proceed with early deployment.
I simplified it to
Partner Team X understands the consequences of and limited recovery from using widgets in production before our work is fully implemented and deployed.
The people who are receiving this slide deck are not interested in the fine details. They want the 25-word summary of how things are going so that they can either decide that our feature is not a point of concern, or decide to ask follow-up questions to understand the issue better. In that case, we can present a so-called back-up slide with the details.
A back-up slide is a slide in a slide deck that you hope that you won’t need to use, but which you create just in case it is needed. You mark it as hidden or put it in an appendix so that it doesn’t show up in the normal presentation flow. But if the audience you are presenting to (usually someone higher up the executive chain) asks a follow-up question about one of your slides, you can reach into your deck and pull out your back-up slide to answer it. “I was ready for that question, so I already have a slide with the data you are asking for.”
Bonus PowerPoint jargon: PowerPoint Karaoke and the eye chart.
The post Microspeak: Drain the slide, back-up slides appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261020-00/?p=112784/

#slide #microsoft #microspeak #markmyers

#rss #feeds #linksharing #qwibbit

Why didn’t we use RoRegisterForApartmentShutdown to ...

2026-10-22T01:20:58Z

Why didn’t we use RoRegisterForApartmentShutdown to clean up the unmarshalable delegate?

In my attempt to create a fake agile wrapper that is technically agile but is not useful outside its home apartment, Luca Bacci suggested, among other things, using the RoRegisterForApartmentShutdown function.
The RoRegisterForApartmentShutdown function is nice, but it doesn’t suit our needs.
One problem is that the object registered for apartment shutdown must be agile. (If you pass a non-agile object, the call fails.) That means that our wrapper must be agile. If we put the non-marshalable non-agile object inside our wrapper, we now have an agile object (the wrapper) that holds a non-agile object (the original object) as a member, which creates the risk that the wrapper will run down in the wrong apartment. The normal way of fixing that is to use RoGetAgileReference to create an agile wrapper around the non-agile object, and store that agile wrapper in our container object.
This puts us back where we started: We are trying to implement that agile wrapper!
Even if we got past that problem, we have another problem: At apartment shutdown, COM calls the wrapper object’s UnInitialize method, and there’s a warning on the using the RoUnregisterForApartmentShutdown function:
Warning: Don’t call the RoUnregisterForApartmentShutdown function from the OnUninitialize callback.
But wait, what if the destructor of the object we are wrapping wants to call RoUnregisterForApartmentShutdown? It might happen indirectly because it has its own reference to another object, that in turn tries to call RoUnregisterForApartmentShutdown.
For example, it might hold another fake agile wrapper whose UnInitialize method has already been called! (We can work around that in our agile wrapper by nulling out the non-agile pointer so we don’t double-release, but maybe there’s some other object that uses RoUnregisterForApartmentShutdown that is less resilient to this scenario.)
Another requirement of RoUnregisterForApartmentShutdown is that it must be called from the same apartment that registered. This doesn’t quite put us back where we started, but it makes things more complicated because the whole point of the exercise is to find a way to release the object without having to try to switch to the apartment. I guess what we could do is use IContextCallback to try to switch back to the apartment to release the original object and unregister the apartment shutdown callback. If the apartment switch fails, then we assume it’s because the apartment has already run down, so we assume that the IApartmentShutdown::OnUninitialize method was called, and it released the object for us. (Of course, that still creates the problem that we are cleaning up inside the OnUninitialize callback, which meas that nobody else can unregister their apartment shutdown callback.)
The last note on this is that the implementation is written on the assumption that there are not a lot of apartment shutdown callbacks. Registration is O(1), but unregistration is O(n) because it does a linear search through all of the apartment’s registered shutdown callbacks to find the one being unregistered. By comparison, the Global Interface Table is designed on the assumption that it will have to manage a lot of objects, so it can look up its cookies in O(1) time. The proposed alternate design would register and unregister a lot of apartment shutdown callbacks, so it’s pushing the apartment shutdown callback list into a usage pattern it wasn’t optimized for.
The post Why didn’t we use <CODE>RoRegisterForApartmentShutdown</CODE> to clean up the unmarshalable delegate? appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261021-00/?p=112786/

#agile #apartment #lucabacci #use #shutdown #another

#rss #feeds #linksharing #qwibbit

Why do we need ud2 when int 6 is right there? Some time ago, I ...

2026-10-20T14:21:44Z

Why do we need ud2 when int 6 is right there?

Some time ago, I mentioned that the ud2 instruction was created to be an architecturally undefined instruction. But why not just use an int 6 instruction? It’s a two-byte instruction, just like ud2, and interrupt vector 6 is the invalid opcode vector, so a program could just invoke it manually and get whatever behavior the operating system assigns to an attempt to execute an invalid opcode.
Well, not exactly.
Architecturally, the invalid opcode is a fault, which means that the address of the faulting instruction is reported to the exception handler. On the other hand, the int 6 is a trap, which means that the address of the instruction after the int 6 is reported to the handler.
This distinction between faults and traps reflects how they are used. A fault represents an error that the kernel could attempt to repair and retry. For example, a page fault could be repaired by paging the memory in. An access violation could be repaired by changing the page protections. A trap reports an operation that has already occurred and gives you a chance to do some special work in response to it before resuming execution. In the case of a software interrupt, the handler wants to process whatever the interrupt means, and then resume execution with the next instruction.
Now, some faults are unlikely to be repaired, but reporting them as faults means that you have to take extra steps if you want to execute past them. If you just ignore the fault, the instruction restarts and faults again.
If you manually raise the int 6 interrupt to simulate a #UD undefined instruction fault, the handler will think it’s dealing with a CPU-generated undefined instruction fault, so it expects the instruction pointer in the fault frame to point to the undefined instruction. But since int puts the address of the next instruction into the fault frame, the fault handler will look at the instruction and get confused as to why the invalid instruction fault was raised. “It says here that the faulting instruction is a xor eax, eax. That’s a perfectly legitimate instruction. Why did it fault?”
One case for inspecting the faulting instruction is to emulate missing instructions on older processors.
Furthermore, in protected mode, you need to have permission to issue an int 6. The interrupt descriptor table describes what to do for each interrupt, as well as what CPU privilege level is permitted to invoke it explicitly. And to avoid exactly these types of problems where a user-mode program issues an int 6 and confuses the #UD handler, all operating systems deny int 6 privileges to user mode.
So even if you try to fake a #UD via an explicit int 6, it doesn’t work. To get the #UD undefined instruction fault, you have to issue an actual undefined instruction.
The post Why do we need <CODE>ud2</CODE> when <CODE>int 6</CODE> is right there? appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261019-00/?p=112781/

#rss #feeds #linksharing #qwibbit

C++ futures part 5: std::future and std::shared_future Wrapping ...

2026-10-16T15:12:18Z

C++ futures part 5: std::future and std::shared_future

Wrapping up our quick introduction to the C++ futures library, we come to the last two parts: std::future and std::shared_future.
The std::future is the starting point. It is a move-only class that this takes the source and forwards its wait and wait_for methods to the source, and forwards its get method to consume.
Forwarding the get to consume means that you can call get only once.
The idea is that std::future is for the case where there is exactly one consumer of the value. Since it is move-only, you can’t copy it; you can only give it away and transfer the power to retrieve the value to the recipient.
The std::future has a method called shared(). This transfers the source from the future to a shared_future object. The shared_future also forwards its wait and wait_for methods to the source, but instead of forwarding its get to the source::consume, shared_future::get() just calls source::get to get a reference to the value storage.
This is what makes the “shared future” shared: The shared_future is copyable, so you can have multiple people all with their own shared_future that share the same source, and each one can separately wait for the value and retrieve the value as many times as they want.
The downside of shared_future is that you always get a const reference, so if you want to perform non-const operations on the result, you’ll have to make a copy and operate on the copy. And that’s not possible at all if the result is itself a move-only type, since you can’t move out of a const reference.
You can see that at the end of the day, all of the pieces of the futures library are just different ways of manipulating the invisible source. Some components push values into the source, and others pull values out of the source.
It took me a while to realize that the most important part of the whole futures library is something you can’t even see.
Bonus chatter: All the names in the futures library are horrible. I mean, really, “packaged task”?
Here’s my attempt to give the pieces better names:
Old name
New name
promise
promise_source
packaged_task
function_promise_source
async(deferred)
make_lazy_promise
async(async)
make_thread_promise
future
promise
shared_future
shared_promise
I admit, these names aren’t all that good either. But I prefer to use the word “promise” to refer to the thing that “promises” to produce a value. And the pattern promise_source / promise makes the relationship between the two much clearer: A promise source is a thing that makes promises. And it avoids the hilarity of a non-async async().
The post C++ futures part 5: <CODE>std::<WBR>future</CODE> and <CODE>std::<WBR>shared_future</CODE> appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261016-00/?p=112778/

One way of thinking about access specifiers in C++/WinRT ...

2026-10-16T07:33:38Z

One way of thinking about access specifiers in C++/WinRT implementation types

In C++/WinRT, Windows Runtime classes are exposed to the outside world through the projection, but internally they are represented by their implementation type. Since the outside world sees only the projection, implementation types are visible only to the module that produced them.
This realization lets you reinterpret the C++ access specifiers for C++/WinRT implementation types.
Declared on
implementation as
C# and C++/CX
equivalent
Accessible to
implemented interface
public
Anyone
public
internal
Code in the same module
protected
protected
Code in derived classes
private
private
Code in the same class
In code:
struct Widget : winrt::implements<Widget, IStringable>
{
public:
// This is a member of IStringable,
// so it is accessible to anyone.
winrt::hstring ToString();
// This does not implement any member from IStringable,
// so it is accessible to other code in the same module.
void Recolor(winrt::Windows::UI::Color newColor);
protected:
// Accessible to implementation classes that derive from Widget.
void Reverse();
private:
// Accessible only to Widget itself.
void Reset();
};
Note that if you are implementing a runtime class, then C++/WinRT autogenerates a template for you that auto-declares all of the declared interfaces of that class.
// Widget.idl
namespace Contoso
{
runtimeclass Widget : Windows.Foundation.IStringable
{
String Name{ get; };
void Toggle();
}
}
The IDL compiler autogenerates an interface IWidget with a property Name and a method Toggle().
// implementation
namespace winrt::Contoso
{
struct Widget : WidgetT<Widget>
{
⟦ ... ⟧
};
}
The WidgetT<Widget> expands to implements<Widget, IWidget, Windows::Foundation::IStringable> because those are the interfaces declared by the IDL file.
The post One way of thinking about access specifiers in C++/WinRT implementation types appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261009-00/?p=112764/

C++ futures part 1: The mental model The C++ standard library has ...

2026-10-16T06:04:15Z

C++ futures part 1: The mental model

The C++ standard library has a group of related functions and classes: std::promise, std::packaged_task, std::async, std::future, and std::sharedfuture.
The idea is that all of these classes are built of a single unnamed class which the C++ standard library calls the “state”, but for the purpose of discussion, I’m going to call it the source, since it is the thing that produces the value, and it behaves analogously to a C# task completion source.
The source conceptually supports these operations:
Set a value.
Set an exception.
Wait for a value or exception to be set.
Retrieve the value or rethrow the exception.
Here’s a simplified version that doesn’t support references.
template<typename T>
struct source
{
private:
enum what {
nothing,
value,
exception,
consumed,
} d; // discriminant
union {
T value;
std::exception_ptr ex;
} r; // result
std::mutex m;
std::condition_variable cv;
The discriminant tells us what is in the union: Nothing (because nobody has set anything), a value, an exception, or nothing (because the value has been consumed).
The mutex ensures thread-safe access to the other members, and the condition variable lets us wait for somebody to set a value or exception.
void must_be_empty() {
if (d != what::empty) {
throw std::future_error(future_errc::promise_already_satisfied);
}
}
You can call the set methods only when the source is empty, so we’ll factor out the emptiness check.
public:
void set_value(T& v) {
std::lock_guard g(m);
must_be_empty();
new(&r.value) T(v); // "r.value = v"
d = what::value;
cv.notify_all();
}
You can set a value or exception only once, so if there is already a value or exception, we yell at you. Otherwise, we save the value and notify anybody who was waiting for a value to be set.
I won’t bother with the overload that takes T&&; it’s the same thing, but with a std::move().
There is also a set_value_at_thread_exit which will be another topic for another day.
Instead of setting a value, you can set an exception:
void set_exception(std::exception_ptr ex) {
std::lock_guard g(m);
must_be_empty();
new(&r.ex) std::exception_ptr(ex); // "r.ex = ex"
d = what::exception;
cv.notify_all();
}
It’s basically the same as set_value except that we store an exception.
That’s how values an exceptions go into the source. The next part is waiting for the source to become nonempty.
void wait() {
std::lock_guard g(m);
while (d == what::empty) {
cv.wait(g);
}
}
void wait_for(duration dur) {
std::lock_guard g(m);
cv.wait_for(g, dur, [&] { return d != what::empty; });
}
You can either wait indefinitely or wait for a particular duration. The wait_for method is why we have a condition variable at all. If it weren’t for that guy, we could have used std::atomic‘s wait and notify_all methods.
The last part is getting the values out.
void can_get() {
if (d == what::consumed) {
throw std::future_error(future_errc::future_already_retrieved);
}
if (d == what::exception) {
std::rethrow_exception(r.ex);
}
}
Regardless of how we intend to retrieve the value, it’s not legal to retrieve a value that has already been consumed. Also, if the result is an exception, we rethrow the exception.
T consume() {
wait();
std::lock_guard g(m);
can_get();
d = what::consumed;
return std::move(r.v);
}
const T& get() {
wait();
std::lock_guard g(m);
can_get();
return r.v;
}
};
You can get the value, which returns a const reference to the underlying storage. Or you can consume the value, which moves the value out of the underlying storage and marks the value as consumed so nobody can consume or get it (because it’s not there any more).
We can now build our other objects and functions out of this guy. We’ll do that next time.
Bonus chatter: Writing the destructor is left as an exercise for the reader. It’s not hard, but it’s annoying because of the union.
Bonus bonus chatter: I’m writing the series because I always forget how it works, but writing it down helps me remember.
The post C++ futures part 1: The mental model appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261012-00/?p=112767/

C++ futures part 2: The mental model for std::promise, ...

2026-10-16T05:20:56Z

C++ futures part 2: The mental model for std::promise, std::packaged_task

Last time, we looked at the “state” that powers the std::promise, std::packaged_task, std::async, std::future, and std::sharedfuture classes. Now we’ll see how that “state” (which I call the source) gets used and passed around.
The lifetime of the source is managed by a std::shared_ptr<source<T>>. Everybody who has a reference to the source uses this shared pointer.
The simplest case is std::promise. The operations on std::promise pretty much map directly to the operations on the source we laid out last time.
The next more complicated case is the std::packaged_task. This takes a callable and saves it for later. You can then call get_future to get a future and hand it to somebody as an IOU for “A value will appear here someday.”
When you want to produce a value, you invoke the packaged_task with whatever parameters you want to pass to the original callable. The result of the invocation (either a value or an exception) is then stored in the source object, which can then be retrieved by the future.
You can imagine a packaged task as just wrapping a promise:
template<typename R, typename... Args>
class packaged_task
{
std::promise<R> p;
std::function<R(Args...)> func;
public:
template<typename F>
packaged_task(F&& f) : func(std::forward<F>(f)) {}
auto get_future() { return p.get_future(); }
void operator()(Args... args) {
try {
p.set_value(func(args...));
} catch (...) {
p.set_exception(std::current_exception());
}
}
};
When you invoke it, it calls the stored callable with the arguments and puts the result in the promise.
Okay, those were the easy cases of pushing values into the source. Next time, we’ll look at the messy case: std::async.
The post C++ futures part 2: The mental model for <CODE>std::promise</CODE>, <CODE>std::packaged_task</CODE> appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261013-00/?p=112769/

C++ futures part 3: The mental model for std::async We continue ...

2026-10-16T04:37:55Z

C++ futures part 3: The mental model for std::async

We continue our study of C++ futures with std::async.
The more complex case is the std::async. You give std::async a callable and optional parameters to pass to that callable, and you also specify how and when you want the callable to be invoked. You get two axes: Do you want it to be calculated immediately or on demand? Do you want the calculation to happen on the thread that requests the value or on its own thread?
Now, you’d think you could fill out the table like this:
Immediate
On demand (“deferred”)
Same thread
Call now and save the value
Call when waited
New thread (“async”)
Start the thread now
Start the thread when waited
However, that’s not what the C++ standard says.
The C++ standard disallows asking for an immediate value on the same thread. There’s really no value to doing it that way, since there is no actual “future”; it all happens in the present! “This future could have been a function call.”
auto f = std::async({}, calculator);
auto result = f.get();
This would, in theory, mean “Immediately call the calculator and wait for it to produce a value. Store it in the source and return a future that fetches the value from that source.” But that’s the same as just
auto result = calculator();
I’m guessing that the C++ standard disallows it because there’s no point.
The C++ standard also says that if you combine both std::launch::deferred and std::launch::async, it doesn’t mean that you get a calculation that lazy-starts on its own thread. Instead, the standard says that the implementation can choose which flag to honor and which to ignore.
So really, the table is
Immediate
On demand (“deferred”)
Same thread
Illegal
Call when waited
New thread (“async”)
Start the thread now
Dealer’s choice
In all cases, the result of the callable (either a value or an exception) is stored in the source.
Now, I noted that there’s no point to asking std::async for an immediate on-thread calculation. But maybe you want to do it anyway because you are interfacing with some other component that expects to receive a future. How could you get the same result?
We’ll look at that next time.
The post C++ futures part 3: The mental model for <CODE>std::async</CODE> appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261014-00/?p=112774/

C++ futures part 4: What if I want an immediate on-thread ...

2026-10-16T03:43:26Z

C++ futures part 4: What if I want an immediate on-thread std::async?

I noted last time that you are not allowed to ask std::async for an immediate on-thread calculation. The C++ library designers probably chose not to support it because there’s no point: An immediate on-thread calculation is just a function call, so call the function already and leave me out of it.
But maybe you want to do it because you are interfacing with a component that wants a std::future. How could you do it?
One way would be to implement the immediately synchronous case manually by setting a value into a promise.
template<typename F, typename... Args>
auto
make_immediate_future(F&& f, Args&&... args)
-> std::future<
std::invoke_result_t<std::decay_t<F>,
std::decay_t<Args>...>>
{
std::promise<
std::invoke_result_t<std::decay_t<F>,
std::decay_t<Args>...>> p;
try {
p.set_value(std::invoke(auto(f), auto(args)...));
} catch (...) {
p.set_exception(std::current_exception());
}
return p.get_future();
}
Or you could make packaged_task do the work for you:
template<typename F, typename... Args>
auto
make_immediate_future(F&& f, Args&&... args)
-> std::future<
std::invoke_result_t<std::decay_t<F>,
std::decay_t<Args>...>>
{
using R = std::invoke_result_t<std::decay_t<F>,
std::decay_t<Args>...>;
std::packaged_task<R(Args...)> task(f);
task(args...);
return task.get_future();
}
Yet another way would be to ask for an on-demand in-thread execution, and then immediately demand it.
template<typename F, typename... Args>
auto
make_immediate_future(F&& f, Args&&... args)
-> std::future<
std::invoke_result_t<std::decay_t<F>,
std::decay_t<Args>...>>
{
auto f = std::async(std::launch::deferred,
std::forward<F>(f),
std::forward<Args>(args)...);
f.wait();
return f;
}
The post C++ futures part 4: What if I want an immediate on-thread <CODE>std::async</CODE>? appeared first on The Old New Thing.

https://devblogs.microsoft.com/oldnewthing/20261015-00/?p=112776/