Apps

Poll: Are Microsoft application APIs any good?

If you have used Microsoft's APIs for their various applications, developer Justin James wants to know what you think of them. Let us know by taking this poll.

There are a lot of aspects of the Microsoft development environment that I am really happy with; however, I've become increasingly disillusioned with many of Microsoft's "enterprise class applications" that I have to interface with in code. It seems like Microsoft writes some really lousy APIs for things, or maybe I have been spending so little time outside the Microsoft box that I don't realize that other vendors are even worse. Let us know what you think of Microsoft's APIs.

J.Ja

About

Justin James is the Lead Architect for Conigent.

40 comments
gak
gak like.author.displayName like.author.displayName 2 Like

How could the product survive that long in direct confrontation with Microsoft? It's only advantage was the ability to replace some insane MS APIs with modestly sane ones. Remember the Java fantastic start? People did not run to Java, they ran away from Win32. So, below average.

Tony Hopkinson
Tony Hopkinson like.author.displayName like.author.displayName 2 Like

Depends on what you mean by replace, hide might be a better description for many of them. Doesn't matter how attractive the wrapper is, if there's still a turd inside it... Most of their success was the IDE, which was better than anything else out on the market, wrapping MS's APIs, was a constant game of catchup, and as we all know, eventually they lost both battles badly.

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

Compared to the Win32 APIs, awt looked brilliant. Both Microsoft and the rest of the world have improved since then, but MS not as well as the rest.

apotheon
apotheon like.author.displayName like.author.displayName 2 Like

> People did not run to Java, they ran away from Win32. That's an excellent observation.

mattohare
mattohare like.author.displayName like.author.displayName 2 Like

This has been typical of Microsoft from the off. Their stuff can be excellent or it can be agonisingly awful. As any of their products mature, they generally get better (Word and Excel, for example). Infopath, on the other hand, seemed to take several steps backwards and the tutorial videos were either commercials with no substance or one guy waiting on hold with technical support to fix an issue for him (Could they not stop the camera?).

pgit
pgit

Yeah, it's hard to pick one extreme or the other when you view Microsoft as one lump sum. btw I don't know if it's because of the type of problems I run into but MS on line documentation is pretty darn good and helpful...

apotheon
apotheon like.author.displayName 1 Like

> btw I don't know if it's because of the type of problems I run into but MS on line documentation is pretty darn good and helpful... There was a time, years ago, when I thought the same thing. Since then, I've come to realize that Microsoft's online documentation for problems that should never exist, and basically don't exist outside of the land of Microsoft is good -- but it's complete crap for problems that are more universal. The solution, then, seems to be to use a different platform and software ecosystem to make those problems go away entirely rather than referring to the "excellent" documentation. As such, I've reclassified those "excellent" parts of the online documentation as bait in a trap rather than useful documentation.

Sterling chip Camden
Sterling chip Camden

Yeah, that's probably why I've only found 999 ways -- the rest are masked by the overflow.

apotheon
apotheon like.author.displayName 1 Like

Does it overflow after 999?

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

... when you're operating in a mixture of low-level Win32, ActiveX, WinForms and WPF. There are 999 wrong ways to do it, and no right way.

gak
gak like.author.displayName 1 Like

... because their designs are junk resulting in junk APIs. Example: keyboard input. Apparently, you have a message telling you which key was pressed. In fact, you do not, since there is another unrelated to messages API to get the status of register keys. Now, try to make some window believe Ctrl-F1 is pressed when F1 is pressed in any window? This gets more troublesome with time as Microsoft gets more reasons to pretend it thinks about security. Try to duplicate the Mixer in Windows 7.

Tony Hopkinson
Tony Hopkinson like.author.displayName like.author.displayName 2 Like

DON'T Integrate repoprting into your application, now that's a different animal altogether. It's that small piece of lateral thinking that is always missing from cookie cutter documentation.

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

I think you hit the point exactly -- Microsoft thinks of developers as people who are looking for cut and paste solutions, not creative recombination. This leads to a "leaves only" focus on the architectural tree, which is in such stark contrast to something like Lisp, Haskell, or Ruby where you get "here's the architectural model, now go get creative!"

Mark Miller
Mark Miller like.author.displayName like.author.displayName 2 Like

I would generally agree with that. They show you simplistic ways of accomplishing what you want to accomplish with their stuff, which work, but beyond really simple "hello world"-type examples, their recommended solutions tend to be really bad in terms of creating readable, maintainable code. Late in my "career" as a .Net developer, I discovered that there were a few people outside Microsoft who had much better ideas about how to use their stuff to solve the same problems. I really had to go searching for them, though. What they illustrated was that for what MS produced (architecturally), it wasn't half bad. They had some good ideas in there, but that MS wasn't showing people how to use their stuff to its maximum potential. What they showed were the solutions that were easy for the average developer to understand. The catch is this is generally not the best solution for the problem. To clarify, what they did was show how to accomplish quick, boilerplate solutions. They didn't document the existing architecture much, so that one could craft their own solution, which would likely be better, because it would be directed toward the specific issue the developer was dealing with. The difference was it would take some creative work to accomplish. The approach MS took was to take the creativity out of the code. "Just do this." This was the reason developers were coming out with their own decompilers, like Reflector, which allowed you to look at the source code for each method in the .Net Framework, so you could see how you could effectively leverage what was in there for your own solution. Like I was saying earlier, their stuff is good for building quick-and-dirty, throw-away apps. I wouldn't recommend most of their documented (code) solutions for commercial apps. that you think are going to have a future. Their documentation on what their mainline frameworks do, object by object, and method by method, is generally very good in terms of using the functionality (not architecture) that's available. I wouldn't recommend it to .Net newbies at all, because they're not going to know which end is up. I'd recommend a good beginner book for that. I've seen some of their documentation that was absolutely worthless. There were several occasions when a project required me to integrate Crystal Reports into a web app. That was hell. The MS documentation on CR was pointless. It didn't tell me anything of value. It made me wonder what poor shlup got the job of writing it. I looked for a book on it, but I couldn't find one. I can't remember exactly how I learned how to use the CR library in .Net, but it was by "hook or by crook"! I vaguely remember finding information on a Microsoft newsgroup for this. Without that I would've been sunk.

apotheon
apotheon like.author.displayName 1 Like

> I wish mine were half as good. Rejoice then, for they are. I kid. In my experience, you're no slouch at the pun game yourself.

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

Your subject line was a masterful pun, sir. I wish mine were half as good.

pgit
pgit like.author.displayName 1 Like

I work with a fellow who's constantly saying this kind of work is totally unsatisfying. He tells customers about it. It actually seems to help. They're usually pissed or agitated by the "damn thing" screwing up again. Telling them he'd rather be helping them on the positive side of things, rather than merely bringing them back up to zero, seems to put the folks in a much better frame of mind. He always gets huge tips, too.

apotheon
apotheon

There was a time when my primary job description could be summed up as "recovering MS Windows SNAFUs". I have since moved on, mostly because I much prefer to build good things than keep ramshackle crappy things limping along.

pgit
pgit

Geez, I thought I was cynical... but then all I know is Microsoft = lottsa work for me, some of it very easy work. For the marginally tougher bits, there's the online documentation or better yet, Mr. Fixit. pointy-clicky-workee.

apotheon
apotheon like.author.displayName like.author.displayName 2 Like

I have been known to say that if an optimist sees the glass as half full and a pessimist as half empty, the cynic sees it as half empty -- but sees that as a good thing, because the Kool Aid's probably poisonous anyway, knowing the sociopathic tendencies of the waiter. In this case, sure, the Microsoft glass is half empty, but it's better that way, because the half of the glass that is filled with Kool Aid is poison to a sane developer's state of mind. Fill it up the rest of the way, and his brain will die screaming when he drinks it.

pgit
pgit

That's a good observation. I imagine a programmer such as yourself tends to see the holistic "computer" more in the abstract. Not being a programmer, what they give me is what I got. Them bags of Sakrete have come in mighty handy not a few times. :)

Sterling chip Camden
Sterling chip Camden like.author.displayName like.author.displayName 2 Like

... is how to solve very concrete problems. They appear to have never considered anything in the abstract.

pgit
pgit like.author.displayName 1 Like

Of course that is a valid perspective. (I deploy Linux every chance I get) So Microsoft has built a Yugo... at least they documented it well. :)

Slayer_
Slayer_

Most do what you expect them to do, but their graphical and window API's are awful. Many of them memory leak and crash for no reason. My favorite is still TransparentBlt In 95, each call to it caused resources to "disappear" until you rebooted, same in 98, in 2000 and XP, task manager doesn't tell you anything, just all of a sudden your screen stops refreshing and hangs, its nasty. I tried it recently in Windows 7, I ran an endless loop of transparentblt. It crashed out after about 5 minutes and the system became unresponsive... so they still haven't fixed it. That was just my first, and most memorable broken API.

pgit
pgit like.author.displayName 1 Like

Somewhere in the middle is "I have to deal with it, nothing I can do about it, so I got over it." Every job is a daily bite outta the proverbial s#!t sandwich, no? Choice is in the condiments. =)

Mark Miller
Mark Miller like.author.displayName like.author.displayName 2 Like

"better than average," "worse than average"? The use of the word "average" doesn't seem appropriate. What are we "averaging," The quality of the APIs that most developers use, or the average of what we've used? Just some needling questions. :)

Mark Miller
Mark Miller like.author.displayName 1 Like

Sometimes their APIs were great for certain simple application cases, where the app is not going to grow much, is just for a few functions, and is otherwise a "throw-away app." Other times, while I got the sense that they covered the domain space very thoroughly, their way of approaching it felt like they hemmed me in to a particular way of doing things. I used to accept that, but it really rubs me the wrong way now. Sterling's comment brought to mind my experience with MFC. I used to appreciate that MFC simplified Windows programming from a C++ perspective, but in hindsight that was an illusion. The problem was its coverage was not complete (and in those cases I had to drop down to Win32, which was hell), and there were some cases where what they did was just funky. I got the sense that they made some good design decisions with it, and some really bad ones. MFC's container classes are a case in point. In one job I worked where all we did was MFC, we only used the STL that came with Visual Studio for all of our containers, and we created customized versions of them to suite our needs. That usually worked well. MFC's containers, as I found out later, sucked. The problem was MFC's exception framework only worked with MFC's containers. This was because MFC has its own exception classes it uses, and its own macros for trapping them. STL was just standard C++, and it used standard C++ exceptions. If an STL container threw an exception, you had to handle it separately from an MFC exception. You were basically on your own. In hindsight, I can see that MFC is a patched together mess, and that (IMO) it was really designed for C/Win32 developers, to make developing for Windows a little easier. If all you wanted to create was a quick and dirty app., MFC would fill the bill. You could do it nice and easy, and you wouldn't have to touch Win32 at all. If you wanted to build a real app. with complex functionality, you HAD to drop down to Win32. What a pain. Going from that to .Net felt like a HUGE improvement! But now I feel like Microsoft keeps missing the boat on good language and API design, because they don't feel like developers who use them can handle it. I've liked their focus on productivity for many years, trying to keep things simple so you can get things done, but on the other hand, I also see that they try to guide you to certain solutions, certain common use cases that they've anticipated, which ends up getting in the way if what you're doing doesn't fit into those cases. They do this in their IDEs, and in their APIs, and I found myself having to be wary of both. It makes doing custom, sophisticated work a real pain, and decreases productivity for those cases!

gmonylass
gmonylass

What's all this "sophisticated and complex functionality" everybody's talking about? Am I missing the boat? At one point, my company had the dubious distinction (given to us by Microsoft) as being the largest MFC application in existence! Still though, unless you're developing some ultra optimized 3D graphics engine or the next Protools, coding is coding...

Tony Hopkinson
Tony Hopkinson like.author.displayName like.author.displayName 2 Like

to have learnt a lesson of dubious value from being awarded it. Get the basics right all else follows....

Sterling chip Camden
Sterling chip Camden like.author.displayName like.author.displayName 2 Like

... then I understand how your company came by the distinction. MFC was a poor choice even when it was the only choice.

Justin James
Justin James

You are right that Microsoft's tools like to guide you in a particular direction, but what continuously baffles me is that the direction they choose is almost always a bad idea. Like how everything really encourages you to use code behinds and tightly coupled code, but they turn around and show you a zillion ways to rework things to use some MVC-like pattern. And you ask yourself, "why didn't you just make this the default if that's what you want me to do?" J.Ja

Mark Miller
Mark Miller

The little I used to hear about what was going on inside MS was that MS is really a bunch of different companies. There are certain objectives that are enforced on them from a branding and compatibility perspective, but otherwise they kind of do their own thing. I don't know the exact nature of what's been going on inside the company, but my sense of it is it's gone through some growing pains, and part of this is that some of these companies inside the MS "sphere" compete with each other. What I heard about with MS's development technologies was that each one bore the signature of individual designers. As for code-behinds vs. MVC, I'd say it was the same thing. It's like custom remoting in .Net, which got thrown out when WCF came along. A designer came up with the remoting API. Another designer, I think it was Don Box, at MS thought it was @#%^, got rid of most of it, and decided to expand on the communications concept with WCF. Code-behinds were invented to create a familiar way of doing things for VB coders. Some other designer came along and built an MVC framework for .Net. As I recall, this occurred when .Net was first introduced. Don Box told the story of how the VB team had to be cajoled into accepting .Net, because it was a more sophisticated architecture than VB. It was not as simple to deal with, nor was its complexity as easy to hide. My guess is there was a battle within MS before .Net won out over the "VB way." You can still see this going on, I think, with what's happened with ASP.Net.

Tony Hopkinson
Tony Hopkinson like.author.displayName like.author.displayName 2 Like

There are some very good ones, not too many truly awful ones, but in the main most forget lesson one of good API design. It's for them, not you.... Oh and It's not much better outside the MS box JJ.

Sterling chip Camden
Sterling chip Camden like.author.displayName 1 Like

There are some very well-written APIs in the Ruby gems collection, and in the Haskell community.

apotheon
apotheon like.author.displayName 1 Like

. . . but I believe you about Haskell, not just because I know something about your taste in code, but also because of the impression I have of the Haskell community and tool ecosystem as an outsider looking in. You're absolutely right about Ruby: the stuff with good APIs tends to end up very popular in the Ruby community, and there is definitely a culture of good APIs that makes all that enterprisey stuff in the Java and .NET worlds look almost as bad as PHP APIs by comparison.

Sterling chip Camden
Sterling chip Camden like.author.displayName like.author.displayName 2 Like

I've programmed to the Win32 API (since 1992), MFC, Office APIs, .NET (in C#, VB, C++, and Synergy/DE) and WPF -- I have yet to see a Microsoft API that wasn't filled with booby traps.

nate.irvin
nate.irvin like.author.displayName 1 Like

I voted "excellent" because I am thinking of the Office APIs. They're not brilliant, but they're easy to work with. I wish they'd play nicer with mocking, but that's a COM thing, not a design flaw - I was actually really impressed with the way they coded to interfaces. If that's not what you meant by "application APIs" though, I abstain. :)

Justin James
Justin James like.author.displayName 1 Like

I've worked with them off and on for a while now. The APIs themselves are alright, although there are a lot of inconsistencies. But they lack basic refinement. Like how the collection classes don't have a "contains" or "exists" method, so you need to iterate through the whole collection to verify if something exists in it... J.Ja