my123

The inline crypto engine is in the SoC for the phone case. Inline crypto engines for OPAL on the storage device side have a far worse security record.

Menus got moved away from Carbon on macOS 14.

You'll get this error if you try to use the Carbon menu APIs:

> References to Carbon menus are disallowed with AppKit menu system on macOS 14 and newer. Use instances of NSMenu and NSMenuItem directly instead

https://developer.apple.com/documentation/macos-release-note...

Looks like they tried some level of mapping but it didn't go too well: https://www.vttoth.com/CMS/technical-notes/?view=article&id=...

being able to transfer HANDLEs across the 16/32-bit boundary notably for COM/OLE integration becomes a lot more painful

Microsoft says at https://learn.microsoft.com/en-us/windows/win32/winprog64/ru...:

> Note that 64-bit Windows does not support running 16-bit Windows-based applications. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data. Attempts to launch 16-bit applications fail with the following error: ERROR_BAD_EXE_FORMAT.

winevdm on Windows eschews that level of integration, but perhaps MS should have shipped WoW16 with limitations instead of nothing.

An app can opt-in to it in the manifest without needing that global system override.

it's one of the ABI differences between x86 and arm. on arm, char is an unsigned char

OpenGL on Apple GPUs is implemented on top of Metal with some private extensions to be closer to OpenGL behaviour. Making things work performantly on top of regular Metal is quite a bit harder.

The CEF update was baking in the public beta channel for around the last 6 weeks.

Epic could have benchmarked their beta client against the Steam beta client which would have shown this.

It was a planned update since long before. Just a coincidence in timelines.

Things are a lot worse than Spotlight on a number of platforms...

Using American technology licensed by the Dutch, the US is able to do this because a lot of the EUV research was financed by the DoE and licensed to ASML.

> to make macOS a closed system like iOS

The reason why that won't happen (but more and more warning prompts all the time because of this modern world...) is because macOS is a self-hosted platform.

Apple _needs_ macOS as an unlocked OS at the very least as a development platform to develop their operating systems on. Not having the self-hosting requirements allows to tighten the security model a lot.

Notably, with a Unix terminal, a huge problem for sandboxing is how to determine permissions granularly, whereas a UI flow has significantly better answers to that.

Not an easily feasible option notably because the firmware ACPI tables are in part stubs - but work on hybrid ACPI/DT instead is possible.

One of the reasons is that Qualcomm uses supplemental ACPI tables (think device tree overlays) shipped inside of the driver packages. Look at the .bin in plenty of the drivers carefully and you'll see that they're supplemental ACPI tables.

Windows doesn't have such a notion and it's implemented via having an ACPI table loader statically linked in to individual drivers.

_On top_ of that, Qualcomm uses PEP to intercept plenty of ACPI functions and implement them in native code instead.

It's worth more with business practices that the current owner wouldn't be willing to do.

Monaka-X will include SME2 but it didn't make the cut for first-gen Monaka

A big problem there is ensuring performance portability between different GPUs

> I am pretty sure VkImportSemaphoreFdInfoKHR, mentioned in https://github.com/ggml-org/llama.cpp/issues/22648, works across multiple AMD devices, but somehow doesn't work across multiple nvidia devices.

p2p is disabled on nvidia customer cards, vulkan device groups are shipped for the RTX 6000s

> Added support for creating Vulkan logical devices from multiple physical devices on select cards via VK_KHR_device_group_creation. This feature can be enabled by setting the environment variable __VK_ENABLE_DEVICE_GROUPS=1.

Eight Megabytes And Constantly Swapping

For reference: https://vulkan.org/user/pages/09.events/vulkanised-2025/T47-...

coopmat2 features will eventually be rolled elsewhere. coopmat also started as an NVIDIA extension.

The client use cases that coopmat was intended for are customer machines, not multi-GPU, which is broadly seen as a datacenter feature instead. That said coopmat orthogonal to this.

coopmat2 can be implemented by anybody non-nvidia. It's not EEE when the regular coopmat extension is not good enough to get good performance

Yeah talking about the (vendor-preferred) compute part here

Vulkan's SPIR-V dialect is substantially different from the OpenCL one, notably with the former having structured control flow. They're incompatible between each other.

oneAPI is effectively an Intel-only platform not a standard.

Yes they have implementations on top of CUDA but they're maintained by... Intel. They didn't get buy-in for cross-vendor collaboration

> Intel uses SPIRV iirc

They're migrating away from SPIR-V to their own, Intel PISA: https://discourse.llvm.org/t/rfc-upstreaming-the-pisa-backen...

> TSO

yeah that one is more messy on Windows, with extensive reliance on RCpc...

> and status flags

it's part of FEAT_FlagM(2) - has been there since the Snapdragon 8cx Gen 3 on the Windows side

it's available in retail (the foldable phone variant) in mainland China since today

It's an old comment.

iirc it's a documented feature now - FEAT_E2H0, https://support.arm.com/documentation/109697/2025_12/Feature...

And it was retroactively defined to be allowed starting from Armv8.0.

Apple designs pre-date the ID register bit for it being a thing so it takes a quirk there however.

Windows has a stable syscall ABI today officially, for supporting down-level containers:

> https://learn.microsoft.com/en-us/virtualization/windowscont...

> Decoupling the User/Kernel boundary in Windows is a monumental task and highly non-trivial, however, we have been working hard to stabilize this boundary across all of Windows to provide our customers the flexibility to run down-level containers. Starting with Windows 11 and Windows Server 2022 we are enabling the ability to run process-isolated WS2022 containers on Windows 11 hosts.

One thing in the story is that the SPU - the secure enclave on Qualcomm chips that is separate from just running on TrustZone on the main processor - is only available on Snapdragon 8 and X tier products. It's market segmented away from 7 series and below.

> Finally, we will continue to progressively open-source more of the Mojo language, as well as components in MAX that we have built with it. Our commitment remains unchanged – we will open source the Mojo compiler and toolchain in 2026.