Uncomfortable Admission:
I wrote Windows specific code today...

I also do sometimes, and guess what, there are occasions where the Win API is actually better than Posix threads - conditions with timeout is an example.

@Fast-Nop It was trash code. Literally, send files to trash code. We use Qt here and the version we are using doesn't have a cross platform way to send things to trash instead of delete. Apparently version 5.15 has this feature. We are standardized on an older version. What I don't understand is why the trash feature isn't a directory that is local to the user. It is some special system directory that is not accessible to any user programs. So you have to use an api rather than just copy the files somewhere.

@Demolishun If it were just a directory, I see a gaping security hole because one process' trash-moved data could become accessible to another process. IMO, having a system API for that makes sense.

@Fast-Nop Isn't the Windows recycle bin accessible to all applications?
The "boundary" usually is per user and not per programme which is perfectly fine to setup with fs permissions. Processes running as the same user have no security between each other anyway.

@sbiewald The recycle bin is not a folder on windows. Its something else owned by the system. I think its a one way trip for the data. Unless the user clicks in the bin and says "restore".

@sbiewald A program can easily lock a file (e.g. with runtime data) by opening it exclusively. Or you could use group policies for a specific application and revoke read rights for all others.

Also, of course there's process isolation between processes of the same user by letting them live each in its own address space. Win 98 with 16 bit processes is long gone.

@Demolishun It actually is a folder, C:\$Recycle.Bin\{your sid}\ under modern Windows; mount the Windows disk under it under Linux to see it, or enable the view of hidden system files.
Files in the recycle bin are renamed and an information file (containing original filename and so on) is added.

@Fast-Nop That is true.
The intention behind it is "if process A dies, it will not take all other with it".
The security aspect was added later.
While it is not allowed to directly write to other processes memory (besides using debugging calls, which usually require, well, debugging privileges), they can interact with each other (e.g. with signals), thus a process can kill the other one and access files. It is also possible to create a process dump or similar for other processes of the same user.
Do you mind dropping me a link to the specific GPO?

The isolation is stronger, if apps run under different users (e.g. process A as X, B as Y).

Its ok. We have code that still uses windows interop/com components, lmao