Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The key distinction is the withholding from your competitors part. WinAPI may have a ton of features labelled "pls no use thx" but MS doesn't block you from distributing a program that uses them anyway.


That used to be true but they absolutely do this today :(

Spent so much time trying to repro some functionality only to realize that Windows has an allow list for what apps it listens to for certain APIs.


Did it? I worked on an EDR product for a decade and the window internal gurus were always talking about undocumented API parameters


Microsoft considers documentation status and long term support status to be the same thing. If the behavior of a function / API is not going to remain stable, it isn't documented. If they don't want to pay maintenance/support costs for an API (more rigorous testing, sample code, etc) the API won't be documented.

Historically Microsoft had a 100% back compat guarantee for APIs, so the second an API was documented its external interface was frozen in stone forever. There are still APIs around to this day that have misspelled struct fields because someone made a typo 30+ years ago.

If an API isn't documented it is "use at your own risk", although if enough large software starts depending on it, the API may have to be frozen anyway (or compatibility shims put into place) to avoid breaking popular software programs.


The "turn off Windows Defender PLS, I am an antivirus" API being a principal (and well-justified) example.


The only APIs that are locked this way AFAIK are PPL, Defender-disabling, and AV registration, all not exclusive to Microsoft, you just have to sign up to an antimalware developer program and sign an NDA.


That's not the key distinction -- of course Windows will likely have internal-only APIs for its own internal use. The problem is when e.g. there are special internal Windows APIs that Office can use but Lotus/etc. can't, or that Edge can use but Firefox/Chrome/etc. can't.


Sorry, yes. To clarify, it's about withholding features of a product in one market from your competitors in the other market.


Yeah, I wasn't trying to be snarky, rather there often seems to be a "private code shouldn't exist, code wants to be free!" ethos that makes my eyebrows twitch in PTSD from reading all of Raymond Chen's tales of depending on undocumented code, e.g.

*https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...

*https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41...

*https://devblogs.microsoft.com/oldnewthing/20230113-00/?p=10...

*https://devblogs.microsoft.com/oldnewthing/20060109-27/?p=32...


It's not withholding, it's just not part of the AppStore if you do it. There are plenty of other ways to distribute your software, and yes, Apple will also still co-sign it or provide entitlements if you need those. Just not in the AppStore.


That seems like an unnecessary and unreasonable trade barrier. There isn't a technical or user-experience reason to exclude these sorts of apps.


That's not the argument; the argument is that this would be some form of "there is only one method and it is being withheld", which simply isn't the case.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: