I know it's not completely what you asked, but I'm with the OP - the one thing I missed the most in my one year in Windows-land last year, was the command-line shell. Everything you can do on a Linux machine, you can do in the shell
Two days ago I was handed a CD with some fonts on it, and needed to get an overview of them - two lines of commands, right in the shell, took me maybe 20 minutes, to generate a HTML page with a PNG sample of each font.
Good example. I don't dispute the fact that the command line makes it easier to do some tasks. I've had cygwin installed for a while now and I use the command line a lot but its power on native linux may be much more.
As you said though, it doesn't really answer my question. I'd genuinely like to know what is poor at API level.
For example, I could easily write a small utility that would display all the fonts on the CD. It would take an hour or so but the API's should let me do that (disclaimer: haven't tried it).
I'd say, it's not so much the API itself, as much is there is just ONE API - POSIX. Files, processes and signals. This it the root of a very simple design philosophy, that much *NIX software adheres to.
Most thirdparty libraries provide a C-library that can be linked to an application - but it also provides a small tool that implements all functionality. Input values aren't "resources" or instances of this or that object. They are one of: Strings on the commandline, a piped stream or a file. And most often, all are possible. Output is a integer return value (typically just true or false), another stream or another file.
Windows does not have that single, simple API that everything adheres to, so there's no one culture of Windows development. Many of the APIs that exist in the Windows ecosystem, e.g. WMI, that I've been using to script IIS control, is perfectly well equipped to become a "POSIX-killer" - if it would just become pervasive. WMI is next to worthless when I can use it to control IIS, but not some other feature, and I can straight away forget about talking to the Win32 API altogether from Windows Script Host, and even in C#.net it's unnecessarily difficult.
I see - that is kind of neat, I suppose, because it simplifies the overall model. Windows does require you to learn and use a new set of concepts for each API.
From your answer and krshultz's below I think I see the complaint. While parts of the windows API are written well, they do not have an overreaching unifying framework. Such a framework would make it easier for developers to follow guidelines and pick up new API's.
I think that's a pretty reasonable complaint. I take it for granted that I have to read MSDN carefully for every API I use, but maybe in Linux/Mac I wouldn't have to. Interesting.
The inconsistancy in the API is one of the major complaints.
Here is a good explanation. I can't say I have dealt with most of it since I haven't done Windows development since pre-.NET, but I am significantly happier now that I don't.
Windows has always felt to me like the work of several teams, each in its own area. I never considered this a weakness because that's "just the way it is". However, this thread has helped me see that it could be.
I'll consider taking up some linux programming when I get some free time to get a feel of the difference.
>I don't dispute the fact that the command line makes it easier to do some tasks. I've had cygwin installed for a while now and I use the command line a lot but its power on native linux may be much more.
Two days ago I was handed a CD with some fonts on it, and needed to get an overview of them - two lines of commands, right in the shell, took me maybe 20 minutes, to generate a HTML page with a PNG sample of each font.