u/kobyk

According to the third paragraph of https://github.com/microsoft/STL/issues/1800, 2022 (aka Dev17) isn't "vNext" and won't be an ABI break.

The installer for the Preview version of the Build Tools (no IDE) is available at https://aka.ms/vs/16/pre/vs_buildtools.exe

Here's a bug I filed that makes even elementary testing with modules unfeasible: https://developercommunity.visualstudio.com/content/problem/1218898/c20-modules-intellisense-does-not-work-with-pch.html
The result? The bug being marked as non-prioritized due to lack of broad customer impact.
If you encourage people to take the time and file modules bugs with minimal repros, it's reasonable to expect at least some minimal feedback. Even a reply that says EDG won't be able to handle this in the 16.10 timeframe is better than nothing.

You can use __debugbreak instead (see https://docs.microsoft.com/en-us/cpp/intrinsics/debugbreak).

The current <filesystem> implementation does not support paths longer than MAX_PATH even when LongPathsEnabled is set in group policy and the process manifest specifies longPathAware (introduced in Windows 10 Anniversary Update) because parts of the implementation use statically sized MAX_PATH arrays internally. Will this be addressed by the eventual implementation of Standard <filesystem>?

Additionally, is_symlink etc. does not appear to be actually implemented, in the sense it does not recognize NTFS symbolic links. Is this expected to change?

https://www.dropbox.com/referrals/NTE1NjU3NTI5

AppInit_DLLs or user space in general is really not the appropriate way to do this. Note that in Windows Server 2008 R2, AppInit DLLs that are not digitally signed will not be loaded, and this facility is generally on the way out.

I strongly suggest you take justanotheratom's advice and implement registry filtering with a kernel driver, using the CmRegisterCallback DDI (the newer CmRegisterCallbackEx is for Vista and you mentioned you were targeting XP).

You can pick up the free Windows Driver Kit (WDK) from Microsoft Connect to get a Windows driver build environment and documentation.

The driver you need to write is not a file system filter. It is simply a driver whose DriverEntry function invokes CmRegisterCallback with your registry callback function. The callback implementation will filter registry access as it sees fit.

Looks like it's been pulled, there's even a Special Announcement on the CTP's page about a temporary pull, presumably as the result of my post or someone else noticing the issue.