Microsoft Simplifies API for Longhorn

zzxc writes "InternetWeek.com reports that Microsoft is cleaning up its API and integrating its XML Application Markup Language for its anticipated Longhorn release. An unnamed source says that Microsoft will be slashing the number of API calls from 76k to 8k. In addition, the new graphics device interface, codename Avalon, will use XAML-based scripts instead of a complicated API. Microsoft is planning on including XAML design in the next Visual Studio.net release. CRN is also reporting on this."

Comments

What happens to compatibility?

[Hanashi]

I'm all for slimming down the Win32 API. It's monsterous, and a simplification would be of great benefit in the long run. But what will happen to application compatibility in the short term? I guess executable code that calls the "old" API won't run on Longhorn? If that's true, how will users know in advance which of their programs will run?

Comments from anyone with insight on this are very welcome.

How much to learn?

[ClosedSource]

"Win32 has like 76,000 APIs, and they're taking it down to 8,000 with Longhorn technology"

The question is will they be adding 100,000 new things to learn in AXML in order to replace the 68,000 lost APIs?

Re:How much to learn?

[superdoo]

No, they'll only be adding 65536 new things. After that they get an overflow in MSAPIOBF.DLL, the Microsoft API Obfuscator API.

Nice Step

[4of12]

OK, so are they really doing away with those old interfaces, or just pretending they're not there, not documenting them, etc?

I'd be impressed if the API was condensed into 8k well-documented routines that completely spanned win32 functionality. Like, if another company were to provide the same 8k routines they could, albeit with less performance, run any and all win32 applications (on different hardware, under different OS, etc.).

Re:Cool.

[torpor]

Sure ... lets see ... theres ummm ... LoadLibrary(), then there's LoadLibraryEx(), then there's LoadLibrary32(), then there's LoadLibrary32Ex(), then theres MS_LoadLibrary(), then theres MS_LoadLibrary32(), then theres MS_LoadLibraryEx() ...

Oh, okay, I give up. I only ever used LoadLibrary() a couple hundred times, personally, and even then, only to get incompatible API functions loaded from various copies of the same .DLL found all over C:\WINDOWS, C:\WINDOWS\SYSTEM, C:\WINDOWS\SYSTEM32, C:\WINDOWS\WINNT, etc.

Re:Microsoft formula for simplification.

[Anonymous Coward]

From a technical standpoint, slimming down the APIs makes some sense. The current APIs have so much redundancy and useless code that it makes it very difficult to learn and manage.

Yes, compatibility will take a hit, but sometimes you have cut losses and move on. Apple did the same thing when they developed Carbon. Their job was a bit easier because Apple only had to remove 2000 APIs. Apple realized that those APIs were hindering their advancement.

One smart thing that Apple did do was ease the transition by designing both Classic and Carbon to work together in the same box.

While I have no doubt that reasons other than technical helped MS make the decision, I can't say there was no technical merit.

Re:Microsoft formula for simplification.

[Tsali]

Considering the file system will render all pre-Longhorn windows applications obsolete, why not knock the tires on the API's as well?

Maybe it's to frustrate Mono some more... who knows....

the alternative already exists

[HungWeiLo]

For simple GUI apps, the WTL (a stripped-down ATL) framework provides all the GUI elements, sans the MFC nastiness and bulkiness. Of course, when I tried to use it last, it was nicely undocumented. (That could be changed by now)