No offense, but I don't think you looked too hard. There are lots of calls that could be used to do things in a more performant way, or to make things possible that were not possible using documented APIs. [0]
Generally speaking though, what you say is true. There are certainly no "magically faster" API calls.
There are thousands of undocumented calls that, if you were aligned with the internal team at Microsoft that wrote them, allowed you to write better performing code than if you were a third party. And as a major developer inside Microsoft, you had the power to get API calls created for your needs, while third parties didn't. That is the crux of the matter.
Here's one straight from the site we're discussing today, the IOwnerDataCallback interface [0] makes it possible to do grouping on a virtual ListView. Windows Explorer uses it to great effect, everyone else can't use it. [2]
Of course there are internal APIs, every OS has those. I don't know of any that would make the difference between an app being competitive and not, certainly not in that timeframe.
Grouping on a virtual list view was added in Vista which is after I stopped working on Wine, but again, that is hardly the sort of thing that makes or breaks apps. Most competing office suites and browsers don't even use comctl32 at all, preferring to roll their own widgets for portability reasons.
The reasons IE and Office were so fast to start was due entirely to heavy optimization. In particular Microsoft were very good at doing profile guided re-ordering of code pages to minimize HDD head movements, which was critical in an era when hard disks were the only storage medium and also much slower. The Linux toolchains didn't have anything like that and the technique wasn't even well known outside of Microsoft back then, so to GNU hackers the results appeared to be almost magic. OpenOffice or Mozilla would take like 30 seconds to start and Word/IE could start in 3.
So what thousands of calls are you thinking of? To give MS such a huge competitive advantage that other companies get wiped out they'd need to have done stuff like kept a new DirectX back only for themselves. Back then they didn't even have the technology to do that. Even your link where you say people "can't do that" is about how to use that private API you named. Blocking that sort of thing requires pervasive code signing, package identity and for that to be propagated robustly through IPC. Even today Windows is kinda ropey in that regard (vs macOS/iOS where robustly enforced Apple only APIs are widespread and critical, e.g. mmap +x is an Apple-private API on macOS).
> No offense, but I don't think you looked too hard. There are lots of calls that could be used to do things in a more performant way,
Undocumented API calls were rumored to be a big deal even back in the Windows 3.x days. I remember reading through this at the time looking for the 'smoking gun'.
There were some cute and offensive names, and a few interesting details about the internal implementation of Windows, but nothing that would've been hugely beneficial.
Things might well have changed since then. (Both at Microsoft and at Apple, where their software is definitely allowed to do things that third party software is not.)
Generally speaking though, what you say is true. There are certainly no "magically faster" API calls.
There are thousands of undocumented calls that, if you were aligned with the internal team at Microsoft that wrote them, allowed you to write better performing code than if you were a third party. And as a major developer inside Microsoft, you had the power to get API calls created for your needs, while third parties didn't. That is the crux of the matter.
Here's one straight from the site we're discussing today, the IOwnerDataCallback interface [0] makes it possible to do grouping on a virtual ListView. Windows Explorer uses it to great effect, everyone else can't use it. [2]
[0] http://undocumented.ntinternals.net/
[1] https://www.geoffchappell.com/studies/windows/shell/comctl32...
[2] https://www.codeproject.com/Articles/35197/Undocumented-List...