How to compare two packed bitfields without having to unpack each field
https://blogs.msdn.microsoft.com/oldnewthing/20190301-00/?p=101065 [blogs.msdn.microsoft.com]
2019-03-01 16:34
site: blogs.msdn.microsoft.com
How to compare two packed bitfields without having to unpack each field
https://blogs.msdn.microsoft.com/oldnewthing/20190301-00/?p=101065 [blogs.msdn.microsoft.com]
2019-03-01 16:34
The std::map subscript operator is a convenience, but a potentially dangerous one
https://blogs.msdn.microsoft.com/oldnewthing/20190227-00/?p=101045 [blogs.msdn.microsoft.com]
2019-02-27 21:21
The [] operator doesn’t know whether you’re going to read from or write to the result, so it has to come up with some sort of compromise. And sometimes the result of a compromise is something both sides dislike.
source: L
The Intel 80386, part 1: Introduction
https://blogs.msdn.microsoft.com/oldnewthing/20190121-00/?p=100745 [blogs.msdn.microsoft.com]
2019-01-21 23:46
As with all the processor retrospective series, I’m going to focus on how Windows NT used the Intel 80386 in user mode because the original audience for all of these discussions was user-mode developers trying to get up to speed debugging their programs. Normally, this means that I omit instructions that you are unlikely to see in compiler-generated code. However, I’ll set aside a day to cover some of the legacy instructions that are functional but not used in practice.
2: Memory addressing modes https://blogs.msdn.microsoft.com/oldnewthing/20190122-00/?p=100755
3: Flags and condition codes https://blogs.msdn.microsoft.com/oldnewthing/20190123-00/?p=100765
4: Arithmetic https://blogs.msdn.microsoft.com/oldnewthing/20190124-00/?p=100785
5: Logical operations https://blogs.msdn.microsoft.com/oldnewthing/20190125-00/?p=100795
6: Data transfer instructions https://blogs.msdn.microsoft.com/oldnewthing/20190128-00/?p=100805
7: Conditional instructions and control transfer https://blogs.msdn.microsoft.com/oldnewthing/20190129-00/?p=100815
8: Block operations https://blogs.msdn.microsoft.com/oldnewthing/20190130-00/?p=100825
9: Stack frame instructions https://blogs.msdn.microsoft.com/oldnewthing/20190131-00/?p=100835
10: Atomic operations and memory alignment https://blogs.msdn.microsoft.com/oldnewthing/20190201-00/?p=100845
11: The Thread Environment Block https://blogs.msdn.microsoft.com/oldnewthing/20190204-00/?p=100855
12: The stuff you don’t need to know https://blogs.msdn.microsoft.com/oldnewthing/20190205-00/?p=100865
13: Calling conventions https://blogs.msdn.microsoft.com/oldnewthing/20190206-00/?p=100875
14: Rescuing a stack trace after the debugger gave up when it reached an FPO function https://blogs.msdn.microsoft.com/oldnewthing/20190207-00/?p=100885
15: Common compiler-generated code sequences https://blogs.msdn.microsoft.com/oldnewthing/20190208-00/?p=100895
16: Code walkthrough https://blogs.msdn.microsoft.com/oldnewthing/20190211-00/?p=100905
17: Future developments https://blogs.msdn.microsoft.com/oldnewthing/20190212-00/?p=100915
STATUS_STACK_BUFFER_OVERRUN doesn’t mean that there was a stack buffer overrun
https://blogs.msdn.microsoft.com/oldnewthing/20190108-00/?p=100655 [blogs.msdn.microsoft.com]
2019-01-10 00:42
What this means is that nowadays when you get a STATUS_STACK_BUFFER_OVERRUN, it doesn’t actually mean that there is a stack buffer overrun. It just means that the application decided to terminate itself with great haste.
Sigh.
Choosing error codes based on a really nice #define doesn’t necessarily lead to a readable message to the user
https://blogs.msdn.microsoft.com/oldnewthing/20181203-00/?p=100375 [blogs.msdn.microsoft.com]
2018-12-17 04:07
What happened is that the program was using some internal helper object. If somebody tries to use the object before it has been properly configured, the developer needed to return an error code to indicate this. The developer went cruising through winerror.h looking for a suitable error code, and hey look, here’s one: ERROR_NOT_READY. Awesome, let’s return that error code.
But what the developer didn’t check is how that error message looks to the user. The function that displays the error code to the user will use the FormatMessage function to perform the error-code-to-message conversion. And that produces “The device is not ready”, which is nonsense.
Applies to quite a few posix errno values as well.
source: Dfly
Announcing .NET Core 3 Preview 1 and Open Sourcing Windows Desktop Frameworks
https://blogs.msdn.microsoft.com/dotnet/2018/12/04/announcing-net-core-3-preview-1-and-open-sourcing-windows-desktop-frameworks/ [blogs.msdn.microsoft.com]
2018-12-05 03:24
Today, we are excited to announce that are open sourcing WPF, Windows Forms, and WinUI, so the three major Windows UX technologies will be open sourced. For the first time ever, the community will be able to see the development of WPF, Windows Forms, and WinUI happen in the open and we will take contributions for these frameworks on .NET Core. The first wave of code will be available in GitHub today and more will appear over the next few months.
For a brief period, the kernel tried to deal with gamma rays corrupting the processor cache
https://blogs.msdn.microsoft.com/oldnewthing/20181120-00/?p=100275 [blogs.msdn.microsoft.com]
2018-11-20 18:47
Honestly. The processor manufacturer asked for this. I’m serious.
Building C# 8.0
https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/ [blogs.msdn.microsoft.com]
2018-11-14 22:47
Here’s an overview of the most significant features slated for C# 8.0. There are a number of smaller improvements in the works as well, which will trickle out over the coming months.
Windows Command-Line: Introducing the Windows Pseudo Console (ConPTY)
https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/ [blogs.msdn.microsoft.com]
2018-11-11 05:08
In this, the fourth post in the Windows Command-Line series, we’ll discuss the new Windows Pseudo Console (ConPTY) infrastructure and API - why we built it, what it’s for, how it works, how to use it, and more.
Considering the performance implications of converting recursion to an explicit stack
https://blogs.msdn.microsoft.com/oldnewthing/20180927-00/?p=99835 [blogs.msdn.microsoft.com]
2018-09-28 17:20
As with most issues of performance, the only way to know is to measure.
But a good discussion of what might affect performance.
How can I conditionally compile based on a preprocessor macro value, while ensuring that the macro is correctly spelled?
https://blogs.msdn.microsoft.com/oldnewthing/20180910-00/?p=99685 [blogs.msdn.microsoft.com]
2018-09-11 18:57
Anyway, for whatever reason, you might want to use the preprocessor’s #if directive to perform your tests. Maybe you are preprocessing something for a purpose other than compilation by a C or C++ compiler. But you’re also worried that somebody might misspell your symbol.
#define GET_NONZERO_VALUE(x) (0/(x) + (x))
The early history of Windows file attributes, and why there is a gap between System and Directory
https://blogs.msdn.microsoft.com/oldnewthing/20180830-00/?p=99615 [blogs.msdn.microsoft.com]
2018-08-31 00:03
Rewind to CP/M.
Announcing F# 4.5
https://blogs.msdn.microsoft.com/dotnet/2018/08/14/announcing-f-4-5/ [blogs.msdn.microsoft.com]
2018-08-15 03:52
The first thing you may notice about F# 4.5 is that it’s higher than F# 4.1.
The PowerPC 600 series
https://blogs.msdn.microsoft.com/oldnewthing/20180806-00/?p=99425 [blogs.msdn.microsoft.com]
2018-08-08 17:22
As with all the processor retrospective series, I’m going to focus on how Windows NT used the PowerPC in user mode because the original audience for all of these discussions was user-mode developers trying to get up to speed debugging their programs on PowerPC.
Is the TerminateThread function synchronous?
https://blogs.msdn.microsoft.com/oldnewthing/20180727-00/?p=99355 [blogs.msdn.microsoft.com]
2018-08-01 16:31
No. The TerminateThread function queues a termination to the target thread but does not wait for confirmation that the termination has occurred.
When is it appropriate to use the current processor number as an optimization hint?
https://blogs.msdn.microsoft.com/oldnewthing/20180719-00/?p=99285 [blogs.msdn.microsoft.com]
2018-07-20 15:39
If you are going to use the current processor as a hint to avoid contention, the entire scenario needs to be quick. If the processor changes while your scenario is running, then you will have contention if the new thread also tries to perform that same processor-keyed operation.
When generating a random password, the result must still be a valid string
https://blogs.msdn.microsoft.com/oldnewthing/20180713-00/?p=99235 [blogs.msdn.microsoft.com]
2018-07-13 17:10
A customer had a problem with auto-generated random passwords. Their password generator generated a string by choosing each character randomly with a code unit from U+0001 to U+FFFF. (They avoided U+0000 because that is the string terminator.) They didn’t mind that the resulting passwords were untypeable, because the passwords were going to be entered programmatically.
And then, oops.
Announcing the May 2018 Git Security Vulnerability
https://blogs.msdn.microsoft.com/devops/2018/05/29/announcing-the-may-2018-git-security-vulnerability/ [blogs.msdn.microsoft.com]
2018-05-30 01:54
Son of .. returns.
The solution to this problem is quite simple and effective: submodule’s folder names are now examined more closely by Git clients. They can no longer contain .. as a path segment, and they cannot be symbolic links, so they must be within the .git repository folder, and not in the actual repository’s working directory.
source: HN
Performance Improvements in .NET Core 2.1
https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/ [blogs.msdn.microsoft.com]
2018-05-10 16:25
Back before .NET Core 2.0 shipped, I wrote a post highlighting various performance improvements in .NET Core 2.0 when compared with .NET Core 1.1 and the .NET Framework. As .NET Core 2.1 is in its final stages of being released, I thought it would be a good time to have some fun and take a tour through some of the myriad of performance improvements that have found their way into this release.
The MIPS R4000
https://blogs.msdn.microsoft.com/oldnewthing/20180402-00/?p=98415 [blogs.msdn.microsoft.com]
2018-04-12 16:42
Continuing in the “Raymond introduces you to a CPU architecture that Windows once supported but no longer does” sort-of series, here we go with the MIPS R4000.
32-bit integer calculations: https://blogs.msdn.microsoft.com/oldnewthing/20180403-00/?p=98425
Multiplication and division: https://blogs.msdn.microsoft.com/oldnewthing/20180404-00/?p=98435
Constants: https://blogs.msdn.microsoft.com/oldnewthing/20180405-00/?p=98445
Memory access aligned: https://blogs.msdn.microsoft.com/oldnewthing/20180406-00/?p=98455
Memory access unaligned: https://blogs.msdn.microsoft.com/oldnewthing/20180409-00/?p=98465
Memory access atomic: https://blogs.msdn.microsoft.com/oldnewthing/20180410-00/?p=98475
Control transfer: https://blogs.msdn.microsoft.com/oldnewthing/20180411-00/?p=98485
Stupid branch delay slot tricks: https://blogs.msdn.microsoft.com/oldnewthing/20180412-00/?p=98495
Trampolines and stubs: https://blogs.msdn.microsoft.com/oldnewthing/20180413-00/?p=98505
More on branch delay slots: https://blogs.msdn.microsoft.com/oldnewthing/20180416-00/?p=98515
Calling convention: https://blogs.msdn.microsoft.com/oldnewthing/20180417-00/?p=98525
Function prologues and epilogues: https://blogs.msdn.microsoft.com/oldnewthing/20180418-00/?p=98545
Common patterns: https://blogs.msdn.microsoft.com/oldnewthing/20180419-00/?p=98555
Code walkthrough: https://blogs.msdn.microsoft.com/oldnewthing/20180420-00/?p=98565