Also caused subtle bugs. I once had to debug a crash in C++ code that turned out to be due to Stackless Python corrupting stack state on Windows. OutputDebugString() would intermittently crash because Stackless had temporarily copied out part of the stack and corrupted the thread's structured exception handling chain. This wasn't obvious because this occurred in a very deep call stack with Stackless much higher up, and it only made sense if you knew that OutputDebugString() is implemented internally by throwing a continuable exception.
The more significant problem was that Stackless was a separate distribution. Every time CPython updated, there would be a delay until Stackless updated, and tooling like Python IDEs varied in whether they supported Stackless.
Unfortunately, there is a reason. During the Vista timeframe, Microsoft published guidance recommending that game developers use the Documents folder for save games, as part of the push to make games compatible with UAC and non-elevated user accounts.
It requires a code signing certificate from one of the trusted central authorities, and generally as an individual you must have your legal name on the code signing certificate. It's not pseudonymous.
The dialog editor is a good example of the damage that was done with the VS.NET transition. When they rewrote it to use the WinForms-based UI, they introduced a fundamental bug: the Z-order for picking was reversed so that clicking on a stack of controls selected the one on the bottom. Very annoying for controls like group controls intended to be stacked below other controls. Bug filed, WONTFIX'd, and it's still broken to this day.
No, overlapping sibling controls is absolutely supported in Win32. It has a defined Z-order for child controls along with functions to manage it:
> The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows.
The WS_CLIPSIBLINGS window style is also explicitly for controlling cross-clipping of child windows during painting:
> Clips child windows relative to each other; that is, when a particular child window receives a WM_PAINT message, the WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated.
Furthermore, group boxes and tab controls require overlapping child windows, because they are designed for the controls that visually appear within them to be sibling controls that are raised in Z-order. This is why the dialog editor's current behavior is broken, because the editor's picking behavior is opposite the drawing behavior and USER32's hit test order.
That might have been the transition from Visual C++/Basic 4 to 6 (I skipped 5), but the cataclysmic one was the switch from Visual Studio 6 to Visual Studio .NET, when large portions of the IDE and build system were rewritten in .NET. Visual Studio .NET (2002) was much slower and much buggier than VS6. The native debugger was glacial at conditional breakpoints and debug output, the build system took an eternity to do a dependency check, its UI visibly redrew more slowly, etc. It was so bad that Microsoft had to create a special offer for the Visual Studio .NET (2003) upgrade for only ~$30.
This transition was not great for Visual Basic developers either since their language was transitioned from generating native code (VB6) to becoming dependent upon the .NET Framework (VB.NET), supported secondarily to C#.
To this day I would consider VB 6 the epitome of COM development tooling, neither .NET, nor the UWP trainwreck were as good, and C++ tooling only MFC is worth of mention, as something putting development experience first, instead of Windows division politics.
Quite awkward for what is such a key technology on Windows.
Yeah, it seems that a lot of this is due to marginal quality resampling algorithms that allow significant amounts of aliasing. The paper does mention that even a good algorithm with proper kernel sizing can still leak remnants due to quantization, though the effect is greatly diminished.
I'm surprised that such well known libraries are still basically using mipmapping, proper quality resampling filters were doable on real-time video on CPUs more than 15 years ago. Gamma correction arguably takes more performance than a properly sized reduction kernel, and I'd argue that depending on the content you can get away without that more often than skimping on the filter.
I have a simple website consisting solely of static webpages pointing to a bunch of .zip binaries. Nothing dynamic, all highly cacheable. The bots are re-downloading the binaries over and over. I can see Bingbot downloading a .zip file in the logs, and then an hour later another Bingbot instance from a different IP in the same IP range downloading the same .zip file in full. These are files that were uploaded years ago and have never retroactively changed, and don't contain crawlable contents within them (executable code).
Web crawlers have been around for years, but many of the current ones are more indiscriminate and less well behaved.
For smaller forums, any customization to the new account process will work. When I ran a forum that was getting a frustratingly high amount of spammer signups, I modified the login flow to ask the user to add 1 to the 6-digit number in the stock CAPTCHA. Spam signups dropped like a rock.
> And on Intel C with intrinsics definitely isn't it, because their stuff was invented by Microsoft, who were famous for having absolutely no aesthetic taste in anything.
Wouldn't Intel be the one defining the intrinsics? They're referenced from the ISA manuals, and the Intel Intrinsics Guide regularly references intrinsics like _allow_cpu_features() that are only supported by the Intel compiler and aren't implemented in MSVC.
Uh, no, that's standard practice for disambiguating the intrinsic operations for different data types without overloading support. ARM does the same thing with their vector intrinsics, such as vaddq_u8(), vaddq_s16(), etc.
Not all 64-bit ARM CPUs have AES support since it's part of the optional Crypto extension. The BCM2837 in the Raspberry Pi 4 is an ARMv8 CPU that lacks it.
You are right that the cryptographic instructions are optional and they have always been so in ARM CPUs, in order to enable the making of CPUs that can be embedded in products that will be exported even to destinations where cryptography is forbidden.
However the poster above was talking about smartphone Arm-based CPUs. I doubt that there has ever existed a 64-bit ARM-based CPU for smartphones that did not implement the cryptography extension. Even the CPUs having only Cortex-A53 cores that I am aware of, made by some Chinese companies for extremely cheap mobile phones, had this extension.
The more significant problem was that Stackless was a separate distribution. Every time CPython updated, there would be a delay until Stackless updated, and tooling like Python IDEs varied in whether they supported Stackless.