ack_complete

This case actually works because for finite numbers of a given sign, the integer bit representations are monotonic with the value due to the placement of the exponent and mantissa fields and the implicit mantissa bit. For instance, 1.0 in IEEE float is 0x3F800000, and the next immediate representable value below it 1.0-e is 0x3F7FFFFF.

Signed zero and the sign-magnitude representation is more of an issue, but can be resolved by XORing the sign bit into the mantissa and exponent fields, flipping the negative range. This places -0 adjacent to 0 which is typically enough, and can be fixed up for minimal additional cost (another subtract).

One significant difference is that Metro/UWP requires signing for pretty much everything. Without signing you can't have package identity, and without package identity, you can't even use the UI system. Furthermore, it requires a paid cert, which is expensive and requires publicly divulging your identity. I have major problems with this as it opens developers up to harassment. .NET at least allowed self-signed certs.

It's true that there is no great answer for how to add capabilities and sandboxing after the fact. But what Windows did was build an incredibly restrictive sandbox and then tell everyone who couldn't accommodate even one of the restrictions was "sucks to be you". The result was that developers, when confronted with "all or nothing" for Metro-style apps, were forced to choose nothing. It was also not a good look that Microsoft's own flagship applications like Visual Studio and Office did not show any progress toward adopting UWP, and in the latter case, was specifically exempted from the Windows RT restrictions to continue using Win32 on that platform.

If there had been a better strategy for easing in UWP technology, we might have seen better progress on adoption of Windows Runtime APIs and capabilities so new programs could gradually move toward the new technologies and away from HWNDs. Unfortunately, the technical barriers that were put in place between Win32 and UWP are so large that progress toward breaking them down in the Windows App SDK has been slow.

Eh, WinForms did a lot to make Win32 UI accessible and usable -- especially layout and easy customization -- but I have to differ on the cross-language story. It was great, IF you were making primarily a C# program that happened to use some C/C++ components.

From the native code side, it was not so great. The .NET 2.0 CLR had very poor support for hosting from the native side and really wanted you to make a program that was .NET first, it didn't work well if you wanted something like primarily a C++ program that hosted a C# UI in the same process. Reverse P/Invoke via native exports wasn't exposed, so creating DLLs for consumption by non-.NET programs was difficult. Mixed mode debugging was and still is painful, with the debugger being glacially slow at some operations like OutputDebugString() processing and blocking some native features like data breakpoints, and the CLR eating access violation exceptions from native code so they couldn't be debugged properly. Build-mode wise, we had to ban C++/CLI assemblies depending on C# assemblies because the C# project system didn't handle incremental builds properly and forced the dependent C++ assembly to rebuild all the time.

These issues still largely exist and are an issue with WPF. It's a great UI framework, but it's unusable unless your front end is primarily a C# program.

WPF originally had two major rendering issues. One was the lack of pixel snapping support, and another was gamma correction issues during text rendering, particularly for light text on a dark background (due to an alpha correction approximation, IIRC). The two combined led to blurry text in WPF applications.

These were finally improved for WPF 4, since Visual Studio 2010 switched to it and had a near riot in the betas due to the poor rendering in the text editor.

The main reason Win32 can't handle automatic background suspension or low-power push notifications is simply that those features haven't been exposed to it. There's nothing preventing a Win32 program from receiving those types of notifications and then being force-ended by the OS if it doesn't respond in time.

When I first started porting programs to Windows ARM64, I didn't have an ARM64 device and had to test in QEMU. It ran extremely slowly, probably 1/50th of real time. All UWP programs like Calculator ran like a slug. But which programs still ran reasonably? Classic WinDbg and Task Manager. Two programs that were still plain Win32.

There are significant issues with Win32, namely its lack of a permissions and isolation and lack of hardware acceleration in the old windowing UI (User/GDI). But the idea that Win32 is inherently power inefficient is, IMO, just BS. Its roots go back to CPUs that were orders of magnitude slower than modern CPUs and there is nothing difficult about making a Win32 program that idles at 0% CPU when not in use.

That might have been more significant had the Windows Runtime not been effectively locked off to Metro-style apps. You could technically use it from a desktop app, but almost all of its functionality was only allowed within a Metro-style app, often due to requiring a core window or package identity. Even today the vast majority of useful WinRT APIs, including the entire UI system, require UWP or package identity.

The most offensive part of the Sinofsky response is this part:

> WinRT (2012) - it (or the embodiment in Windows 8) failed in the market but it also showed both the problem and potential solution to building for new markets while respecting the past

I can't express how wrong this is. WinRT was the most destructive thing that the Windows team ever did to the OS. It drove a hard stake into Windows, splitting it in half and declaring that anything previous to Windows 8, oriented toward desktop, or using primary input through mouse and keyboard over touch was dead. Microsoft basically told all existing Windows developers that if they weren't building a new, touch-oriented, mobile-style app specifically for Windows 8, they didn't matter and wouldn't get any support whatsoever, which is exactly what happened every time they broke existing desktop functionality. Calling this "respecting the past" is a crass insult and taking no responsibility for damaging the Windows development experience and accelerating development away from native Windows apps.

The place I work at tried using an SO enterprise instance and it was quite ineffective. We didn't have the toxicity of the public instance, but generally having a Q&A forum double as a knowledge base is an oddball format that doesn't work out. Adding AI integration is not likely to compensate for that.

The Windows API uses WCHAR = wchar_t, so if you use char16_t, you have to convert back and forth to avoid running afoul of strict aliasing rules. This imposes conversion costs without benefits; both using wchar_t directly or converting to/from UTF-8 are better.

Doesn't need to be inline assembly, just pre-encoded lookup tables and intrinsics-based vectorized CRC alone will add quite a lot of code. Most multi-platform CRC algorithms tend to have at least a few paths for byte/word/dword at a time, hardware CRC, and hardware GF(2) multiply. It's not really extreme optimization, just better algorithms to match better hardware capabilities.

The Huffman decoding implementation is also bigger in production implementations for both speed and error checking. Two Huffman trees need to be exactly complete except in the special case of a single code, and in most cases they are flattened to two-level tables for speed (though the latest desktop CPUs have enough L1 cache to use single-level).

Finally, the LZ copy typically has special cases added for using wider than byte copies for non-overlapping, non-wrapping runs. This is a significant decoding speed optimization.

Yes, and this is also how Windows 10/11 explorer turns some parts of its UI dark like scrollbars. But notably, Microsoft refuses to officially support Explorer's dark control themes or ship a complete dark theme, and because the theming engine only loads themes signed by Microsoft, no one else can ship one either without patching the OS.

Dark mode for apps is a setting in the OS and a general expectation now, it's suboptimal to ship a new UI that doesn't support it. And, again, Win32 message boxes in your program will switch to dark mode whether you want them to or not.

Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in Windows XP. Beyond that, there were always a few hardcoded colors like disabled gray text going back to Windows 95.

Dark mode ignoring Win32 system colors is not incompetence. It was _intentional_. Dark mode was introduced by the UWP side, which intentionally did not extend it to Win32. To this day, there is not even a Win32 API for desktop apps to query whether dark mode is even enabled. The official recommendation is to compute the luminance of the UWP foreground color setting:

https://learn.microsoft.com/en-us/windows/apps/desktop/moder...

One difference is that the Mac OS itself was not initially 32-bit clean, with the top byte being used by the Memory Manager.

The main thing that's hard going down this route is dark mode support. The Win32 USER and common controls just don't not support dark mode, but are actively hostile to it due to the amount of hardcoded light colors and backgrounds in the system. All of the system colors are light regardless of the dark/light system setting, highlights are hardcoded to light blue, disabled controls use a hardcoded color, half of the window messages for changing control colors are silently ignored with theming is enabled. Menus are among the more difficult to deal with as they require extensive owner draw.

On top of this, there are a small handful of system UIs that do support dark mode and make your program look inconsistent with dark mode regardless. Message boxes will switch to dark mode, and so will file dialogs -- which is a problem if you've used the Vista-style customization, as any syslinks will appear in a color of blue that's hard to read against the dark mode background.

Or, unless they've changed it, hardware accelerated rendering. Winforms was based on System.Drawing, which used GDI+, which was largely software rendering. This was confusing because GDI+ was not really related to GDI, which had and still does retain some hardware acceleration support. Even basic color fills start becoming an issue with a big window/monitor.

Winforms is also .NET based, so it's inaccessible if you don't want to write your UI in and take a dependency on .NET.

It's hard to describe how uselessly restrictive the UWP model was when they originally introduced it as "Metro-style apps" in Windows 8. Among the things it officially did not support included:

- Multiple monitors - Non-full screen views - Sideloading outside of the Store - Offline installation - Explicit threads - thread pool only - Aligned memory allocation - malloc only - Any C++ compiler other than MSVC - Support for any version of Windows other than Windows 8 - Running apps as administrator - Running more than one instance of an app at a time - Runtime shader compilation

If any ONE of these things was a blocker, you could not write a Metro style app. And yet Microsoft pushed this extremely hard -- including almost completely ending any maintenance of Win32 APIs. And despite the many relaxations and extensions, UWP is still largely useless today, and now even itself seems to be going into maintenance mode. All of which has done a lot of damage to the state of Windows desktop platform development.

As an example of how bizarre UWP is, for some reason every time they published a list of new APIs added to it, they converted the list of API identifiers to lowercase in the documentation:

https://learn.microsoft.com/en-us/windows/uwp/whats-new/wind...

It's relatively insignificant, but... why? Just one of many things that showed how immature UWP was.

Even that is not necessarily needed, I have gotten major speedups from LUTs even as large as 1MB because the lookup distribution was not uniform. Modern CPUs have high cache associativity and faster transfers between L1 and L2.

L1D caches have also gotten bigger -- as big as 128KB. A Deflate/zlib implementation, for instance, can use a brute force full 32K entry LUT for the 15-bit Huffman decoding on some chips, no longer needing the fast small table.

There are also mode switching and calling convention issues.

The way that the vector registers were extended to 256-bit causes problems when legacy 128-bit and 256-bit ops are mixed. Doing so puts the CPU into a mode where all legacy 128-bit ops are forced to blend the high half, which can reduce throughput of existing SSE2-based library routines to as low as 1/4 throughput. For this reason, AVX code has to aggressively use the VZEROUPPER instruction to ensure that the CPU is not left in AVX 256-bit vector mode before possibly returning to any library or external code that uses SSE2. VZEROUPPER sets a flag to zero the high half of all 256-bit registers, so it's cheap on modern x86 CPUs but can be expensive to emulate without hardware support.

The other problem is that only the low 128 bits of vector registers are preserved across function calls due to the Windows x64 calling convention and the VZEROUPPER issue. This means that practically any call to external code forces the compiler to spill all AVX vectors to memory. Ideally 256-bit vector usage is concentrated in leaf routines so this isn't an issue, but where used in non-leaf routines, it can result in a lot of memory traffic.

Don't think the memory operand version would work here. If I understand the x86 architectural manual description, the 32-bit operand form interprets the bit offset as signed. A 64-bit operand could work around that but then run into issues with over-read due to fetching 64 bits of data.

The VS debugger got an order of magnitude slower in the transition from VS6 to Visual Studio .NET. It's been sped up a bit but is still nowhere near as fast as the VS6 debugger at responding to step commands, debug output, or conditional breakpoints. In VS.NET you could be waiting as long as a full second on a contemporary dev machine for the debugger to finish stepping forward one line.

Funny thing is that at the time, I was lamenting how much slower VC6 was than VC4. Macro playback, for instance, got much slower in VC6. It's all relative.

Standard LibreOffice Writer doesn't have the issue for me either, only the version shipped in Collabora Office for Desktop.

Yeah, unfortunately this seems to combine the UI and performance issues of LibreOffice with new issues from the new front end.

It also has a basic mistake in text editor UX: the caret blinks independently of caret movement. This means that the caret is invisible half of the time while trying to navigate text. Most text editors avoid this by restarting the blink cycle to force the caret visible on each movement.

A major culprit is background processes that scan the drive in the background, like CompatTelRunner.exe. Works fine if you're on an SSD, but grinds an HDD to a halt. They also forgot about their own I/O prioritization API from Vista, so it also spammed I/O at Normal instead of Background priority in the early versions. Not to mention the periodic Defender scans, the Malware Removal Tool scan that runs before each major update, etc.

Similarly, Windows Update used to consume ungodly amounts of CPU time because the update system would write a multi-hundred megabyte text log and then spend forever compressing it for upload. Then they remembered their own ETL system and switched to much more efficient binary logs.

Firefox also has problems on HDD, I remember it locking up for minutes at a time doing cache maintenance until I switched permanently to SSDs.

The timeline for fast multiplies is also a bit off, IMUL was already 4c latency / 1c throughput on the Pentium Pro (1995) and Pentium II (1997). Pretty sure IMUL was also only a few cycles on the AMD K6 (1997). Though Intel slowed it back down again in the Pentium 4, until they reverted back to the P6 architecture in the Pentium M.

Typically intersection checks outnumber updates, so it's better to optimize the former. Also, that only works if the object's pivot is at the center of the bounding box or you're accumulating movements without an explicit position.

That being said, a lot of tricks work better with center/extent instead of min/max, such as computing the AABB around an OBB or doing separating axis tests with abs() tricks. A bounding box and bounding sphere can also be stored together as center/extent/radius with only one additional value needed. Min/max works better for accumulation, though.

This shows up in a lot of other areas, like small game companies that have a devoted following. It can get pretty nasty because these types of people are able to be condescending just short of ToS, while baiting other people into crossing the line. A common thread is weak moderation or biased moderation.

As a developer, it's easy to be blind to this because they're on "your side", but it's bad for the health of your support forums.

Wine has some gaping holes in some of its API implementations. Direct2D, for instance, has existed since Windows 7 but is badly implemented in Wine -- there is no antialiasing and the ArcTo() function draws a line. The MS documentation is not that great either, so fixing Wine isn't necessarily easier than porting to native.

The keyboard I was mentioning isn't a laptop keyboard, actually, but laptop keyboards tend to be in a slightly better spot as the major vendors typically have Fn shortcuts for the missing keys, like Fn+B for Break, and they also document them in the user guides.

Detached keyboards seem to be more of a wild west, especially when they target multiplatform -- and it's always the stuff they don't document that screws you.

The antivirus / EDR / monitoring / inventory software that most corporate IT departments installs ages computers ten years. We constantly had problems with such services slamming the disk, holding files open, breaking software, running CPUs at 100%, etc.

Sets the underlying Registry keys for the Group Policy "Select the target Feature Update version". It tells the Windows Update service to select updates for a specific feature update instead of offering latest.

https://gpsearch.azurewebsites.net/Default.aspx?PolicyID=151...