The "other" Steve T. and the API war

Interesting blog entry from my old friend and colleague Steve Trefethen on Microsoft APIs.  Steve brings up a lot of good points, and I particularly agree that the API landscape is way more fragmented and confusing than it should be, and we at Microsoft need to fix that.  However, I also come in on the opposite side of several issues Steve raises, so I thought it would be worthwhile to call out a few specific points.

It seems Redmond has one-upped Google by putting out alpha software and beta software with "Go Live" licenses. How long will it be before we see alpha software with a "Go Live" license? Are we to believe businesses today are betting their future on all of this pre-release code?

While I agree the proliferations of alphas, betas, CTPs, etc. can be confusing, I actually don't feel this is a bad thing.  Years ago, Microsoft (and the industry as a whole, for that matter) was much more secretive about project under development. These days, customers overwhelmingly prefer transparency, even knowing that transparency means working with software that has a few warts and is subject to change in shape and behavior.  The comparison with Google is also interesting because Google customers have clearly been very happy to use services that Google has deemed beta quality (Gmail, Maps, Toolbar, etc.).   Given the way folks are voting with their feet in favor of these things, a reasonable person could conclude that customers often find value in software even if it's not considered "RTM quality."

Is [an MSDN statement comparing WPF to GDI] implying that the new Office 11 Ribbon UI is "constrained? Ah, but it's  not .NET so it must be constrained. And what about Vista's fancy new albeit unmanaged UI surely that must be constrained right?

Nobody ever said that all things .NET were constrained.  The referenced quote was making a point that it's a great deal of work to build WPF-quality user interfaces with straight Win32 because Win32's GDI is old and crufty.  Of course you can build the Office ribbon and cool looking Vista apps in straight Win32, but the point is that it requires more effort than some of the alternatives.

Btw, where is Microsoft's developer support for the new Vista UI? That's not due to arrive until Orcas ships. Didn't the MFC guys know when Vista was going to ship? Or was it that it just didn't matter until recently?

Our bad.  While Developer Division was successful in launching .NET 3.0 technologies (e.g., WPF and WCP) with Vista, we did not deliver comprehensive tooling that enables developers to easily take advantage of the breadth of the platform.  Yes, the MFC guys (i.e., my team) knew Vista was coming.  We were just not agile enough to release such a product before Orcas.  However, making mistakes is also a great way to learn, and you can bet that future tools releases will have better schedule alignment with major platform releases.

It's almost as though the Microsoft factory is stuck on hyperdrive. They're competing with Linux, Apache, PHP, Flash, Eclipse, Java, Oracle/MySQL/DB2/etc, Google, Mozilla, Open Office, MySpace, Yahoo and over the past 12 months have released betas in nearly all of these areas.

I wouldn't say that we're in "hyperdrive." This is who we are.  We're the world's largest software company, we have broad product and business portfolios, and we're going to be very competitive in all of the markets we serve.  However, I do think it's fair to say that because of this broad scope, Microsoft is less technologically homogenized than in past years, which can mean a lot of different platforms with a lot of different APIs which can result in a lot of confusion.

Staying with Microsoft tools will undoubtedly mean moving to .NET...

No way, Jose! In fact, the Visual C++ team's primary focus is on the native Windows platform.  We have some very aggressive post-Orcas plans for advancing the state of the art of native development.  Our secondary focus, btw, is on native-managed interop, with the goal of enabling ISV-style applications to have their cake and eat it too by getting full value from their native code while still incorporating and benefiting from .NET technologies (or bringing together the Raymond Chen camp and the MSDN Magazine camp, to use Joel Spolsky's taxonomy).

I might also add that Olivier Giroux over at NVidia (who takes a wait-and-see approach to all of this new technology) intimates why native C++ code will always be important:

...I have to write cross-platform software by day...

In fact, many of our best C++ customers use C++ because it enables them to target almost any platform, whether it's consumer software on the Mac or server software on Linux or avionics software running in a jet fighter.  These customers require the portability and/or the runtime control offered by C/C++, but we do need to make sure they also have a development-time experience comparable to that of the managed code developer.

Does anyone know what will really happen to WinForms with WPF being touted as the new UI for Windows? Will there be an Interop WPF toolkit available to move your WinForms apps one form at a time to XAML/WPF?

I have a couple of thoughts on this: first, WPF does not currently have the features and capabilities necessary to supplant WinForms as the framework of choice for line of business style applications.  I know we've tried to message this appropriately, but I agree that it sometimes gets lost in the WPF enthusiasm.  Projecting down the road, I would ask: what are your expectations? If, some day in the future, WPF does overtake WinForms in terms of LOB capabilities, my expectation would be that we would continue to support WinForms for existing customers but recommend WPF for new code.  Or am I talking crazy talk here? Meanwhile, we do intend to support mixed WPF-WinForms apps in the Orcas release.  A WinForms to XAML converter is something I know people have talked about internally, but I expect customer demand would dictate what we do here.

The sad thing is that I'm actually interested in several of these technologies but the field is increasingly looking like the slide from Stephen Colbert's The New AT&T (see about 50 seconds into the video). I've been trying to keep up though it seems a lost cause with each passing day I'm falling further behind.

First, props for the pointer to Colbert's hilarious AT&T video! More seriously, my view on this is that the day has long passed where it is practical to keep up with every developer technology coming out of Microsoft.  Ten years ago, it was totally doable and expected that any "real" developer was totally on top of all of the new stuff coming out of Microsoft.  Today, software developers are more specialized.  A developer may focus on web applications or ISV-style native apps or LOB apps or mobile or SOAs or some industry vertical or some other spoonful of alphabet soup.  Or maybe even one or two of these.  After all, most of us have day jobs and the world of Microsoft platforms is so big that simply understanding it all to any reasonable level of depth would be a full time job in itself.

That said, I'm not going to hand-wave away the fact that there are areas where would do have overlap or should better aligned or must be better at messaging when and where to use what technology.  And we also need to better align platform and tools releases.  All of these things are true. But I don't believe it should be a fundamental goal to homogenize our platforms and APIs before letting anything out the door.

Comments (9)

  1. nfurtwangler says:

    Nice post!  Its definitely good to hear that you guys plan on supporting native more in the future.

    And thanks for the link to Joel’s article about Microsoft losing it’s API.  I don’t quite agree with everything he wrote about it but it is definitely well written and makes a lot of great points.

    As Joel pointed out, an entire generation skipped out on Win32/COM in favor of .NET, Java, and web-based programming, mainly scripting languages (PHP, Python, Javascript, Ruby etc).  I definitely fall into this category, that is until last summer when a project I was on required me to use Win32/COM.  It was REALLY HARD to grok at first, my mind was solidly planted in class-based OO and pointer management wasn’t something I normally dealt with (outside of small school projects).   However, I am also REALLY glad I learned!  So much in the .NET world makes more sense now that I know how things work at the Win32/COM level.  I recommend people read Don Box’s Essential COM and try to get a grasp of how native Win32 apps work!

  2. Hey Steve!

    Thanks for the reply. I’ve posted a few follow up comments <a href="">here.</a&gt;

  3. OlivierGiroux says:

    Are there any new APIs coming to help on thread-level parallelism?

    OpenMP is a nice first step.  What’s the next step?

    Herb’s ‘futures’ library looks great, can we get it? :^)

    I attended yet another luminary talk on TLP today (this time by RISC’s inventor, David Patterson) and got a bit more of the same sour taste as before…  it often feels as though they’re not thinking about programmers…

  4. OlivierGiroux says:

    Any new APIs coming to help on thread-level parallelism?  OpenMP is a nice first step.  What’s the next step?

    Herb’s ‘futures’ library looks great, when can we get it? :^)

    I attended yet another luminary talk on TLP today (this time by RISC’s inventor, David Patterson) and got a bit of the usual sour taste: they’re often not thinking about programmers…

  5. RPW says:

    .NET is a very nice framework, but how did MS totally overlook the ability to easily create proper database applications (UI separate from the Business logic)?

    The Typed Dataset with all of it’s bloat is a joke!

    Take a good look at Borland/CodeGear and how a real database framework is suppose to work.

    There is an entire market that has form to fill this gap.

    I shouldn’t have to purchase someone else’s database solution, it should come with the IDE, it’s 2007 for crying out loud!

    Like I said, I love .NET, but I can’t use it for any serious database applications that I want to complete this year, for that, I go back to Borland/CodeGear C++.

  6. > We have some very aggressive post-Orcas plans for advancing the state of the art of native development

    Oh man we are waiting for over 10 years for post-Orcas "advancing", when is it going to arrive? 2012? This statement keeps repeating with every VC++ release.

    The native tooling (please leave the C++/CLI time-wasting exercise) is pathetic.

    > WPF does not currently have the features and capabilities necessary to supplant WinForms as the framework of choice for line of

    > business style applications

    Both are pathetic. I have read Chris’s first 100 pages and have to say it is awful, awful approach with WPF. It shows in 100MBs taken on a simple textbox and button, that is rather silly.

    WinForms is as hungry with its software GDI+ rendering and it is no good for high-performance apps in all areas you mention.

    Why was that Italian bloke on WPF team pushing propaganda that GDI cannot be accelerated on new hardware platforms.

    Can you please talk to NVidia people you  mention and ask that same question? I guess not, it is propaganda after all.

    GDI is orders of magnitude faster than GDI+ and X times light-speed faster than WPF. Why is the support for GDI accelearation on Vista dropped?

    There is no technical reason, I will prove it any day if required. Why on earth would graphic cards manufactures drop support or not provide a translation layer in DirectX either. It is NOT good to gang-up on this, and people read it very early with all the WPF leakage.

    It is absolutelly the same story for database work in VC++, you guys have lost it BIG with .NET bloatware focus.

    Keep it up and you know Linux and GCC will get more and more native developers on their side.

    It puzzles me how you all miss the point that Java approach simply does not scale. It puzzles me even more why MS is killing their own OS performance with synchronous code, free-from-acceleration, free-from-native-code, and ‘oh-so-wow’ bloatware.

  7. Parker McCauley says:


    I have been sort of loosely following this blog and I am not, in general a big MS basher so I have often just shaken my heads at the rants over MS tools.

    However, in reading this response, I got angry.

    No personal offense steve, but apparently the boys (and girls) at MS are totatlly clueless about how people develope rich client applications.

    I had a MSDN Universal subscription for years and years. I remember the good old days when we actually got Visual Studio Update quarterly, but here is the deal

    I am using VS 6 and C++ and MFC

    Why you ask? well here are some reasons

    1. Many of the applications I develop and support are still alive today and started out on VS 5 and MFC. Imagine that.

    2. I have believed and bought into MS hype

    3. I really hate myself for doing this with COM. What a nasty nasty nasty API and  system to maintain, talk about writing plumbing to just do the simplest things, ugh.

    4. I have a suite of mission critical applications that combined has over 500 KLOCS (not including comments).

    5. This I stupidly split into locical execution unints all tied together via COM. This decision has plagued me for 10 years.

    6. I can not afford the time, or risk of breaking existing code to port my code to your new frameworks, and from what I can see, there is no compelling reason.

    7. I bought VS 2003. Never switched because the interface and code produced was always more buggy than VS 6. Can you believe THAT?

    8. I played with VS2005. It wouldn’t build my code. Nice. I really want to spend a man month to fix all the "MS Made issues (yeah I know, the comipiler is now standards complient BFD)" to get what, an new IDE that doesn’t work any better, or even as well as the VS 6 IDE? There are no compelling additions for MFC apps from VS 6 to VS 2005. The DHTMLView was nice, but I had already rolled my own by that point. In fact

    9.If you buy a couple add ons to VS6 like whole tomoto’s visual assist and codjocks exteme tool kit you can pretty much forget MS Tools after VS6 and if they don’t give me a compelling reason to stick with them, I will be looking at cross platform solutions when I do upgrade.

    10. If you need compelling support, check out I get way more cutting edge tools/code example from there than anything MS has offered in a decade.

    And no, I am not receiving any comensation form mentioning the above products/web sites.

    I left borland tools when they basically abandoned their developer with version 4 of their c++ compiler and went to MS

    VS 6 is a great product for what it does. With add on tools it does pretty much what you need.

    MS has however lost my confidence and loyalty. I am looking to the future, but the playing field is level, and the next generation will be on the best technical platform

    MS has us all locked in with their frameworks. Then they threw them away, instead of enhancing them… How stupid is that?

    Really, Were is Mike Blaz when we need him

    Again, no offense to you steve, but when you say you have some great plans for C++ development in the future, come on, I have been waiting for that for 8 years now.

    Too little, way too late.

    Don’t bother.



    Parker McCauley

    Staff Engineer, R&D

    Advanced Control Systems

    cell  : (906) 440-6100

    fax   : (678) 348-7275

    email :

  8. OlivierGiroux says:

    (Nvidia guy here, Story-telling conjured me to come.)

    That’s a lot of pent-up anger you guys spilled here.

    Having moved linearly through VC++ releases over the last decade, I can’t imagine any comparison where VC 2005 doesn’t come out on top.  It’s just plain better at everything, and the work required to port (I consider any move between compiler versions to be a port) is well worth it.  The longer you wait, the worse it is to port.

    Granted though, maybe the MFC dialog editor in VC6 was still the best.

    Beyond this, VC 2005 compares _very_ favorably to Linux & GCC.  Once you make this switch, you’ll discover GCC has its own idiosyncracies and the OSS libraries are all so inconsistent as to prevent many combinations you might want to make.  Linux typically offers 15 ways of doing anything, and none of them work as well as you hoped for.  There are other platform limitations you’ll learn to deal with, e.g. under X11 only one thread per process can talk to the window and display system (forget worker threads updating some piece of UI).

    As for hardware-accelerating GDI… (puts Nvidia hat on)

    Microsoft cashed in on a large number of favors with Vista.  They asked us to rewrite our entire driver stack (new OS, new driver model, new API) while at the same time as we were designing a brand new hardware architecture for DX10.  In the end, not everything got done, and some things got pushed into the future — I couldn’t say if faster-GDI fell in that bin (litterally, I don’t know).  My hunch though, is that the issues here are all in software, not hardware, and are likely due to the new window manager model.  In 2007 the little transactions of GDI are puny for multi-100-million-transistor graphics chips.

    – My own feedback for Steve –

    I’m really looking forward to what native code innovations you have in store for parallel programming.  This is a problem that has virtually all industry leaders worried/excited… I’d like to see some incremental attempts come on the native-code side.  Don’t promise me anything groundbreaking, just focus on making things better one step at a time.



  9. b says:

    Conjured to a better point, comparison is mute unless you have monetary or resource-relative justification.

    Still don’t buy any of it.

Skip to main content