| ▲ | snackbroken a day 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 a day ago | parent | next [-] |
| 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. |
| |
| ▲ | smileybarry 19 hours ago | parent | next [-] | | 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. | |
| ▲ | miki123211 a day ago | parent | prev | next [-] | | The "turn off Windows Defender PLS, I am an antivirus" API being a principal (and well-justified) example. | |
| ▲ | mrits a day ago | parent | prev [-] | | Did it? I worked on an EDR product for a decade and the window internal gurus were always talking about undocumented API parameters | | |
| ▲ | com2kid 2 hours ago | parent [-] | | 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. |
|
|
|
| ▲ | anonymars a day ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | snackbroken 20 hours ago | parent [-] | | Sorry, yes. To clarify, it's about withholding features of a product in one market from your competitors in the other market. |
|
|
| ▲ | oneplane a day ago | parent | prev [-] |
| 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. |
| |
| ▲ | kelnos a day ago | parent | next [-] | | That seems like an unnecessary and unreasonable trade barrier. There isn't a technical or user-experience reason to exclude these sorts of apps. | | |
| ▲ | oneplane 20 hours ago | parent | next [-] | | 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. | |
| ▲ | a day ago | parent | prev [-] | | [deleted] |
| |
| ▲ | a day ago | parent | prev [-] | | [deleted] |
|