Linux.Slashdot.org

Linux kernel developers are moving toward enabling Microsoft C Extensions (-fms-extensions) by default in Linux 6.19, with Linus Torvalds signaling no objection. While some dislike relying on Microsoft-style behavior, the patches in kbuild-next suggest the project is ready to "bite the bullet" and adopt the extensions system-wide. Phoronix reports: Rasmus Villemoes argued with Kbuild: enable -fms-extensions that would allow for "prettier code" and others have noted in the past the potential for saving stack space and all around being beneficial in being able to leverage the Microsoft C behavior: "Once in a while, it turns out that enabling -fms-extensions could allow some slightly prettier code. But every time it has come up, the code that had to be used instead has been deemed 'not too awful' and not worth introducing another compiler flag for. That's probably true for each individual case, but then it's somewhat of a chicken/egg situation. If we just 'bite the bullet' as Linus says and enable it once and for all, it is available whenever a use case turns up, and no individual case has to justify it..." The second patch is kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS to ensure -fms-extensions is passed for the CPU architectures that rely on their own CFLAGS being set rather than the main KBUILD_CFLAGS. Linus Torvalds chimed in on the prior mailing list discussion and doesn't appear to be against enabling -fms-extensions beginning with the Linux 6.19 kernel.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: For years now, Valve has been slowly improving the capabilities of the Proton compatibility layer that lets thousands of Windows games work seamlessly on the Linux-based SteamOS. But Valve's Windows-to-Linux compatibility layer generally only extends back to games written for Direct3D 8, the proprietary Windows graphics API Microsoft released in late 2000. Now, a new open source project is seeking to extend Linux interoperability further back into PC gaming history. The d7vk project describes itself as "a Vulkan-based translation layer for Direct3D 7 [D3D7], which allows running 3D applications on Linux using Wine." The new project isn't the first attempt to get Direct3D 7 games running on Linux. Wine's own built-in WineD3D compatibility layer has supported D3D7 in some form or another for at least two decades now. But the new d7vk project instead branches off the existing dxvk compatibility layer, which is already used by Valve's Proton for SteamOS and which reportedly offers better performance than WineD3D on many games. D7vk project author WinterSnowfall writes that while they don't expect this new project to be upstreamed into the main dxvk in the future, the new version should have "the same level of per application/targeted configuration profiles and fixes that you're used to seeing in dxvk proper." And though d7vk might not perform universally better than the existing alternatives, WinterSnowfall writes that "having more options on the table is a good thing in my book at least." The report notes that the PC Gaming Wiki lists more than 400 games built on the aging D3D7 APIs, spanning mostly early-2000s releases but with a trickle of new titles still appearing through 2022. Notable classics include Escape from Monkey Island and Hitman: Codename 47.

Read more of this story at Slashdot.

A maintainer of Debian's Advanced Package Tool (APT) "has announced plans to introduce hard Rust dependencies into APT starting May 2026," reports the blog It's FOSS. The integration targets critical areas like parsing .deb, .ar, and tar files plus HTTP signature verification using Sequoia. [APT maintainer Julian Andres Klode] said these components "would strongly benefit from memory safe languages and a stronger approach to unit testing." He also gave a firm message to maintainers of Debian ports: "If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port." The reasoning is straightforward. Debian wants to move forward with modern tools rather than being held back by legacy architecture... Debian ports running on CPU architectures without Rust compiler support have six months to add proper toolchains. If they can't meet this deadline, those ports will need to be discontinued. As a result, some obscure or legacy platforms may lose official support. For most users on mainstream architectures like x86_64 and ARM, nothing changes. Your APT will simply become more secure and reliable under the hood. It's FOSS argues that "If done right, this could significantly strengthen APT's security and code quality." And the blog Linuxiac also supports the move. "By embedding Rust into APT, the distro joins a growing number of major open-source projects, such as the Linux kernel, Firefox, and systemd, that are gradually adopting Rust. And if I had to guess, I'd say this is just one of the first steps toward even deeper Rust integration in this legendary distribution, which is a good thing."

Read more of this story at Slashdot.