I've had to program in winapi recently a bit. I think a little bit of me died inside. Apparently MFC isn't much better. I've certainly coded windows.forms ala .NET and I can say its nice as long as what you need is implemented then it just ends up being P/Invoke winapi calls anyways.

So is there any reason why the most popular operating system has just an awful API. And how come.. after all this time since win95 nothing has really come along.

This is only mildly related, but I was using OSX at school today and I realized how much better windows' interface is. Yes, you heard me right. For one, it seems like the strangest thing to seperate an application's menu from it's window. What's the benifit? And where are all my active programs... in program icons with little arrows under them? WTF is that?! Why does that stupid thing at the bottom keep stretching up everytime I get close to it? Sure, it's "cool looking" but what a annoying pain in the ass.

On top of that, no scroll wheel, no right mouse button, and super slow to boot. It took that thing almost a minute and a half to log in! These are G4's! "Fastest. Mac. Ever."... yeah

The Windows API is enormously complex for a very good reason: You can do just about anything with it. It's almost like a programming language in itself, and is increasingly complex due to the ability to interface with it using almost any programming language.

I actually don't like raw Windows programming at all. Developing handlers to deal with all the messages Windows can send to programs is not my idea of fun. Don't get me wrong though, it's easier than MacOS programming. (At least, for me.)

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Indeed, but I think that's the only reason it sucks. Really, they've done the best they could without re-writing the whole thing. They can't re-write it anyway, it needs to be backwards compatible. Sad, but that's the way it goes. Luckily the documentation is good. Not great, but certainly not bad.

That would be because windows forms is just a high level wrapper around winapi calls. It's the last wrapper Microsoft will make, and it has had an incredibly short live span.

XAMAL and WPF are the new api (Formally WIN FX) that will soon be replacing future GUI projects. It doesn't make sense to make any large projects for windows forms since it will be killed so soon in its life cycle.

Old winapi calls will still be supported either through emulation or something or other, but new code wont be using it.

The WinAPI is so bad, it bullies smaller APIs and takes their lunch money.

It's a subtle philosophical difference: in MS-Windows, applications are windows. In OS X (and early Mac OSs), applications have windows, if they want them. There is not such thing as a child window in OS X, as a result many apps run without anything being obviously the "main" window. So the most logical thing is to keep the titlebar at the top of the screen, where it has been ever since the very beginning, when the Mac didn't multitask.

It's called the dock. It holds both active applications and non-active applications. The black arrow tells you which ones are currently loaded. Since programs can be running without having any windows at all, it isn't otherwise obvious.

Because every application you launch gets an icon on the dock, so when you're running quite a few the icons can get very small. Therefore you can set a "minimum" size that the icons should be for when you're trying to recognise them, and the dock will scale the ones your mouse is over if they're too small. Some people set the minimum mouse-over size to be greater than the normal icon size for a "cool" effect, other people (including me) don't.

Every currently shipping Mac that includes a separate mouse comes with two buttons and a scroll ball. Not a scroll wheel or a 2d rocker, an actual mini trackball that can scroll freely in any directly.

The laptops all have a trackpad that, if you want it, can do either:

• cursor movement, if you move one finger over them

• left click, if you tap them with one finger

• free direction scrolling, if you move two fingers over them

• right click, if you tap them with two fingers

The G4 was phased out of top end Macs in 2002. It was probably the lack of speed advancement in the G4 line and the inability to incorporate the G5 into a laptop form factor that made Apple switch to Intel 13 months ago.

MFC/win32 is the most retarded API that has ever existed.

Can you give an example?

There isn't one yet but things are getting there. With KDE4 and Gnome both using dbus things should get quite a bit simplier. E.g two things I know are in the works is common interface for controlling media players and IM clients. Adding other things should be trivial. Of cource these things will need support from those applications but at least you can use whatever libraries you want as long as you add dbus functionality to it.

Pretty sure environment variables contain what programs do what, not 100% though.

I used the winapi in a little utility I wrote last year. A lot of factors went into deciding to use it. The libs I considered were: java awt, java swing, wxwidgets, gtk, qt, fltk, and a couple of other winapi wrappers I can't remember.

In my case it all boiled down to deployment. I was making a tool to be used in my organization and we are standardized on java 1.3 so java was out. To use wx widgets, gtk, or qt would require bundling a huge set of dlls with the application (same reason .net was out). So I ended up settling for the plain winapi due to a small executable and I had to use the raw api to deal with threads and pipes anyway.

It is a shock how nasty it is. The bigger shock is how hard it is to use msdn online. But once you get used to it it's not that bad. No worse than the allegro gui imho.

The way I heard it, WPF is akin to Apples PDF rendering, a more flexible layouting based framework.

QThread, not sure if QFile can handle win32 pipes though, or if theres an api for it anywhere in Qt. QIODevice can handle them with a subclass thats for sure.