Joel Spolsky's post How Microsoft Lost the API War has had a fair amount of press, and has got a number of developers running scared - some even talking about switching to Linux development. A common theme is that Microsoft won't be advancing the state of the existing API: all new features are going into Avalon/WinFX. People seem to have implied from this that they'll have to rewrite all their apps from scratch, which should not be the case at all.
I wrote a message on the CodeProject forums yesterday which I'll include here:
Don [Box]'s blog post Teaching COM made it pretty clear that Microsoft are extending COM for the Longhorn generation.
They've previously said that the Win32 stack will continue to be present in Longhorn and demonstrated old DOS apps running on Longhorn builds. I don't have a Longhorn SDK handy, so I can't tell you how much Win32 is being enhanced. The new window management and drawing APIs will be exposed through managed interfaces only, I believe, but your UI and data are abstracted, aren't they?Joe Beda, an Avalon architect, talks about this in a Channel 9 video.
Managed C++ or the new C++/CLI syntax should allow you to build a new front end to your existing C++ code.
I seem to recall that Avalon architect Chris Anderson has talked about being able to host Win32 GDI+USER content in an Avalon application, and being able to host Avalon controls in a Win32 application. Windows Forms is just a special case: a Win32 application written in managed code.
Visual Studio 2005 comes with new versions of MFC and ATL, version 8.0. See Visual C++ 2005 Libraries Features for a list of the changes: note that MFC can now host Windows Forms controls, for example.
Remember that Microsoft's platforms and developer tools division's first customer is their applications division. These guys aren't going to want to rewrite Word: there's twenty years of code in there. Rick Schaut, a Mac Word developer, talks about analysing a bug which caused Mac Word to complain "Disk is Full" when trying to save.
They're not going to throw that fix away. They're going to write a new rendering layer, to render to Avalon, new frame UI code targetting Aero, then compile the rest of the monster using CL.EXE's /clr switch. I seem to recall that one of the targets for /clr was that the compiler had to be able to compile Word. I'd expect Microsoft to compile the whole of Word to IL, rather than native code, for future generations so that the same binary runs on both 32-bit and 64-bit machines. Of course, there's always P/Invoke if a component truly can't be compiled to IL.
Anyway, I've now downloaded the Platform SDK for XP SP2 and the Longhorn SDK, and I'm running a diff between the Include directory of the LHSDK and the version that ships with VS2003. Bizarrely, Microsoft have built the XP SP2 SDK from the XP SDK, which means it's impossible to build programs which use features new to Windows Server 2003 using this SDK - those features are missing. Thanks a bunch.
I plan to add new posts covering various areas of the SDK that have been updated. I'll add links to this post as I post them.
No comments:
Post a Comment