4 ms·
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 dis
by snackbroken 1y ago
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.
- slashink 1y agoThat 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.
- mrits 1y agoDid it? I worked on an EDR product for a decade and the window internal gurus were always talking about undocumented API parameters
- com2kid 1y agoMicrosoft 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.
- miki123211 1y agoThe "turn off Windows Defender PLS, I am an antivirus" API being a principal (and well-justified) example.
- smileybarry 1y agoThe 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.
- anonymars 1y agoThat'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.
- snackbroken 1y agoSorry, yes. To clarify, it's about withholding features of a product in one market from your competitors in the other market.
- anonymars 1y agoYeah, 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=42163 https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42... *https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41373 https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41... *https://devblogs.microsoft.com/oldnewthing/20230113-00/?p=107706 https://devblogs.microsoft.com/oldnewthing/20230113-00/?p=10... *https://devblogs.microsoft.com/oldnewthing/20060109-27/?p=32723 https://devblogs.microsoft.com/oldnewthing/20060109-27/?p=32...
- oneplane 1y agoIt'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.
- deleted 1y ago[deleted]
- kelnos 1y agoThat seems like an unnecessary and unreasonable trade barrier. There isn't a technical or user-experience reason to exclude these sorts of apps.
- deleted 1y ago[deleted]
- oneplane 1y agoThat'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.