Hacker Newsnew | past | comments | ask | show | jobs | submit | contextfree's commentslogin

Most apps on Windows can already access those folders though, except for UWP/AppContainer apps (which require particular capabilities to access them). I think the same is generally still true of the equivalents on most Linux distributions despite that things like SELinux exist.

That, and how many commenters in this thread are using something like Claude Code with their src directory as context? This is no different. It’s [claude code/gemini CLI/codex] but for non-devs and with a GUI instead of a TUI.

I feel like everyone here is overly dismissive of this because it’s cool to hate Windows in these parts, but this could be genuinely useful for your average office drone. Much like we love to shit on Copilot for M365 but it’s been extremely useful to the non-tech folks at my work.


wouldnt the more apt comparison being that anthropic uses a zero day to run claude code as root on / with "dangerously ignore permissions" turned on?

claude code is quite useful, but its a tool that accepts the context i give it, and it asks for permissions before it does things


Interesting fact: Codex has access to all the files your current user has access to as well, even if you just opened it in the src directory.


Yeah, but all of that was supposed to apply to the Windows 8 start screen also


MS Office isn't single user? It supports real-time collaboration, including in the desktop apps. Though that does require you to keep the files in onedrive or sharepoint.


Yes, and this approach is an extension of the one taken with WinRT metadata which is also ".NET assembly" based.


Windows and Office never adopted .NET for client code in the first place except for the Longhorn period in the mid-00s, which burned them and put them off it. If that didn't stop .NET in the two decades between then and now, I'm not sure why it would today. Actually, Windows is just now starting to adopt C# now that AOT is supported (I think the new native Copilot app is C#).


Many Windows Server admin tools (such as Server Manager or Virtual Machine Connection) and MMC snap-ins (e.g. Event Viewer, Hyper-V Manager) are written in .NET Framework 4. PowerShell is .NET Framework 4. Everyone’s favorite bloated IDE (Visual Studio) is .NET Framework 4 as well.

In the Office land, Excel’s Power Query is .NET Framework 4.

Adopting the modern .NET is probably harder due to its lifecycle.


Calculator is C# as well (though apparently that's somewhat recent: https://github.com/microsoft/calculator/pull/1598).


Porting to C# was a community effort after it went open source, it was originally C++/CX.


Powershell is .NET Core since version 6, the .NET Framework one is Powershell 5.1.

Yeah, Microsoft themselves have issue moving away from .NET Framework.

You can add SQL Server CLR, Dynamics, Sharepoint on prem, to the list.


OMG could you imagine writing MMC snap-ins using some sort of plugin declspec import bs in C++? .Net and reflection with Assembly.Load saves so much time and effort to build modular “ship it now, deliver features later, extend it if we fall behind” apps. Not that those are good things, it just means you can defer until your MS PM gets the budget to fill those backfill positions that have been open for 12 months because the hiring bar is astrophysics


I can, because due to Windows team love for COM and C++, many extension points require doing exactly that.

Want to extend the context menu actions, or add new thumbnail capabilities for a recent file format?

It is exactly that.

Even with WinRT Runtime Components, they were doing in a way that some APIs were only surfaced when using the components from C++.

Quite a different approach from OS / language teams at Apple and Google, where productivity with better languages has a priority no matter what.


The linked document is about how IT admins can manage the filter via policy, which is exclusive to Enterprise/Education. Users can set up filters through the settings UI (on all editions).


It's off by default but still present on the system. You can remove it entirely via the "Turn Windows features on and off" dialog.


Yes, it can be removed via the "Turn Windows features on or off" dialog.


There is currently no policy setting to do this. The available policy settings are "disable Recall and do not allow users to enable it" (which is the default) and "allow users to enable Recall, but leave it disabled by default".


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: