spoiler

made you look

  • 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: July 27th, 2024

help-circle

  • I always thought it was purely a hardware limitation, but reading up on it I found it’s actually just “virtual 8086 mode” that was dropped, 16-bit protected mode is still available even when running the CPU in “long mode”.

    So it rules out DOS apps, but 16bit Win 3.x apps should still run. But it’s probably a compatibility minefield, and even MS decided it wasn’t important (iirc the only thing they kept around was support for 16-bit app installers, but by internally swapping them out with 32-bit versions when run, since it was apparently common for 32-bit 9x apps to still use 16-bit installers so they could show a proper error message when run under Win 3.x)




  • So how the OS already catches links to e.g. YouTube and offers to open it directly in the app, it could also do that for apps that weren’t installed and it’d just download and run them automatically. One of the examples was Vimeo, instead of loading the website it’d download a cut down variant of the normal app and load the video in that instead.

    The idea was to push people towards using apps instead, but now Google control the web they can just make that their app store instead, so native apps aren’t as relevant anymore.







  • It is all generic layers, the base USB stuff is called a “Human Interface Device”, controllers/keyboards/mice/etc. all show up as a HID to the OS. But you need some way to standardise the input and map the device side events to the host side, so the OS will have a mapping layer above the base USB layer that turns a generic HID into a “controller device” that an app can use.

    As you can see from the patch, that’s all they’re doing. They’re adding the USB IDs of these controllers to the mapping layer so instead of being shown as a “Generic HID”, they’re shown as “Generic Xbox Controller”. Doing so also means the controller layer can drive the devices specifically, e.g. xbox controllers need a special handshake to enable the xbox button, the base generic input layer doesn’t need to know that stuff.





  • They really want to promote their AVIF format, and supporting JXL would hinder that (Since JXL is a much nicer upgrade path from JPEG/PNG than AVIF is)

    Like you can transparently go from JPEG to JXL and back with no loss, which isn’t possible with AVIF. And PNG to JXL gives you a smaller file, while it’s usually the opposite with AVIF (Unless you get lucky, as lossless AVIF can be beaten by a BMP in a ZIP file). There’s also the issue of speed, AVIF is slow to encode compared to other formats (And while hardware decoding is possible, it’s also geared towards video, so the quality is often lacking, and can sometimes be slower than plain software encoding)



  • NTFS was designed back in the mid 90s, when the plan was to have the single NT kernel with different subsystems on top of it, some of those layers (i.e. POSIX) needed case sensitivity while others (Win32 and OS/2) didn’t.

    It only looks odd because the sole remaining subsystem in use (Win32) barely makes use of any of the kernel features, like they’re only just now enabling long file paths.