> Better yet, way back when they first started catering to games with Windows 95, they could have introduce a call like BeginFullScreenGame(), and that could ha

> Better yet, way back when they first started catering to games with Windows 95, they could have introduce a call like BeginFullScreenGame(), and that could have done literally everything for you: In general, APIs like this are pretty undesirable. They're rigid and not really orthogonal to any other API, so they're difficult to combine with existing or new APIs. They can't ever really change behavior either, because people are going to rely on specific implementation details. If you're a game, you might be able to use them (assuming you don't want to do anything out of the norm), and you can't if you aren't. Problem is, the platform isn't just a gaming platform, it's a platform for pretty much everything, and the platform developer probably isn't a game developer either. This means he or she probably doesn't have the expertise to write the exact APIs game developers want, that will be flexible in just the right ways, etc, and whatever API they did write would only be for a subset of the platforms "customers". The real problem here is that the APIs that do exist sound like they are poorly documented and not necessarily thought-out with respect to the rest of the system. Ideally, all of the options needed for a full screen game should be well-documented and orthogonal, so they can be combined to achieve what each of the various apps wants without having to write a "BeginFullScreen$APPTYPE" function. Then, if there truly is a common setup games want, it can be built as a separate library on top of these APIs, either by the platform maker or by a 3rd party. > They might try to hire and cultivate good API designers, and have real, talented developers who do nothing but work on the APIs to the internal systems. There are teams at these companies that do this. This is exactly what the Android Frameworks team does at Google, which includes people like Dianne Hackborn and Romain Guy (until a few months ago), to name a couple of the better known members. They're in charge of designing and implementing a lot of APIs exposed to third party developers, but also spend time each release reviewing all of the APIs that are being made public.