Thank you Mr @MBond2 …
The secondary purpose is to pass otherwise unfindable / inaccessible synchronization or file mapping objects
Yeah… that’s pretty outdated, as you say. We don’t share object instances, we share object names, and communicate them among processes via secure channels.
they should all be legacy and obsolete
Agreed. Thank you again.
You know, I once suggested (long ago) in a meeting that the code to duplicate processes be removed from the OS. This happened just after support for the Posix Subsystem was removed from Windows, which would have been a great excuse. Not one person on the core team agreed that this was a good idea. Most everyone was silent, except the guy who owned the Memory Manager who dismissed it with “We can’t do that” for reasons of compatibility.
Compat has been a great thing for Windows, but it has often been taken too far and been an excuse for not innovating. The entire I/O Subsystem has lacked innovation for years in the name of carefully maintained compatibility. The truth is, it’s super hard and risky work to champion changes, communicate these to the installed base, and get buy-in to make breaking innovations (because, unlike Linux, that would be what’s required in the Windows world). So, why do it? Fucking up a bunch of ancient drivers in the field will get you sent to Siberia. But ensuring nothing changes — including nothing improving — and that everything stays running will get you promoted to Partner Architect.
Sad but true. Sorry… on one of my many hot-button tangents…
Peter