Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software

Microsoft Simplifies API for Longhorn 61

Posted by timothy from the same-story-different-banner dept.
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."
This discussion has been archived. No new comments can be posted.

Microsoft Simplifies API for Longhorn More

Microsoft Simplifies API for Longhorn

Comments Filter:
  • While fewer APIs is good, I would like to know if anyone has heard if Longhorn is going to be open sourced like MS did with CE.
    • While fewer APIs is good, I would like to know if anyone has heard if Longhorn is going to be open sourced like MS did with CE

      Do you really need to ask that question?

      Windows (x86, Win32) is one of their cash cows. CE most definitely ain't - yet. You figure out the rest.

  • What happens to compatibility? (Score:3, Insightful)

    by Hanashi ( 93356 ) on Tuesday May 06, 2003 @07:55AM (#5889883) Homepage
    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.

    • I have a feeling that they'll use some of the stuff they acquired from Connectix to provide a Compatibility box to run older Win32 apps in. Let's face it, they won't shift many copies if customers can't run their existing applications on it...
      • I really doubt that. Connectix's technology would require running a virtualized machine on top of the regular PC running another version of Windows with the full API. Yes, there could be modifications, like with Classic on Mac OS X, to streamline and integrate this, but it seems a bit excessive...
        • Is it excessive? That's exactly what Microsoft did when it moved the industry from DOS to Windows 3.0: DOS became just another application running in it's own VM. Of course, in those early versions, one VM could still actually screw up another VM, but with NT, they got it right and wrapped all of 16 bit Windows in a VM. Both users and developers had the option of launching each 16-bit app in it's own VM (i.e., its own copy of Windows 3.x) or in a single system-wide VM shared with other 16-bit apps.
          • Except DOS in tiny. Win95 is not. A virtualized DOS machine takes up very few resources, disk space, RAM, and CPU. Even when running a number of them in one windows sessions. A Win95 session would double (or more) the requirement for RAM for Longhorn and have other effects.
    • While I'm all for backwards compatibility, you can only keep it up for so long. Backwards compatibility is probably one reason the current API is so freakin' huge.

      I can't run my old Sierra games, either, but thanks to efforts like DosBox [sourceforge.net] and FreeSCI [linuxgames.com], that doesn't matter.

      'Sides, I'm sure someone'll come up with a Win95 emulator somewhere along the line.
    • I don't see why Microsoft can't just run win32 and this new api together, that's part of the kernel. (Remember, Win16, Win32, OS/2 and Posix support were done this way)
    • It'll be deprecated. Consider that in the move to Win32 ( O those 11 years ago !! Has it been that long ? ) there were many API's that were lost along the way, and then there were those who were "left for compatibility" purposes.

      My guess is that the API will still be there, but that it will remain for "Unmanaged code" to utilize. After all, over 99.9% of applications today are "unmanaged", and it took a few years for all that 16-bit code to be "unthunked" ( remember that phrase ? ) into running strictly 3

    • If they are smart, they will emulate the old interface atop the new one, and release the code that does it. By putting it above the new interface they guarantee to the software developers that they are not losing any functionality or speed by switching to the new interface. And by releasing the code they provide a trusted source for instructions on how to convert their programs to the new system, and this code is enormously more useful than any documentation in showing how the new interface works.

      I expect

  • How much to learn? (Score:3, Interesting)

    by ClosedSource ( 238333 ) on Tuesday May 06, 2003 @08:12AM (#5890004)
    "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?

  • Nice Step (Score:4, Insightful)

    by 4of12 ( 97621 ) on Tuesday May 06, 2003 @08:18AM (#5890065) Homepage Journal

    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.).

    • 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.).

      Something tells me that the cost of getting access to the source code will rise in inverse proportion to its decrease in size... *grin*
  • Somewhat offtopic, but...

    Why does Microsoft feel the need to code-name everything before its official release? I mean, we know the OS will be called Windows 2003 or Windows QF or something. Why does it matter to them that we don't know exactly what it'll be called?

    Ditto with their GDI and such. I just don't get why they have to play sekrit agent.
    • Why does Microsoft feel the need to code-name everything before its official release? I mean, we know the OS will be called Windows 2003 or Windows QF or something. Why does it matter to them that we don't know exactly what it'll be called?

      Probably because Management are paranoid about Developers talking about their work to one another outside of the office, and others picking up on the conversations if the words 'Microsoft' and 'Windows' crop up.
    • Codenames make it so developers can work on (and talk about) a product without it continually changing names during it's development cycle. When they say Everett they mean "whatever the next version of Visual Studio is going to be called when it's released" (well it's released already).

      - Steve

    • Re:Codenames? (Score:1, Interesting)

      by Anonymous Coward
      This practice is not limited to Microsoft. Sun, Red Hat, Apple, IBM and many others do the exact same thing.
  • As usual they come along and pull the rug from under you.

    Give me a 30 yo Api any day

    in fact just give me "everything is a file" and mean it

    • in fact just give me "everything is a file" and mean it

      Plan 9 has I believe 17 calls in their interface. Compared to this, MicroSoft's new 8000, or Linux's several hundred, is pretty bad.

      • As Russ said : [google.com]

        "Plan 9 has 48 system calls these days,
        10 of which are deprecated. So 38. That's still a lot."

        • You are right, I think the number 17 that I quoted are the number of calls having to do with manipulating files. There are other calls are for process and memory management.
          • because once you've got your program working *any* other entity that knows about files can use your program.

            For instance, I wrote a google searching tool that presented itself as a file system. To do a google search now all any program has to do is to open a file, write to it, read it, change directory and read the files. It doesn't have to wait for someone to add support for it.

            Unix and it's POSIX progeny do the right thing but never quite cross the finish line. Corba, DCOM, XMLPRC, SOAP I mean, come on
    • Just like with NextStep! Oh, wait, that not right at all!
  • Replace 60,000+ API calls with a multi-gigabyte unintelligible MS-XML compatability transformation layer, force everyone to either code the Dot-Net way or suffer awful performance.

    Sounds more like a move dictated by MS lawyers to undo the leftover damage from the antitrust lawsuits than a decision with technical motivations.

    • Re:Microsoft formula for simplification. (Score:2, Insightful)

      by 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 transiti
    • 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....
      • I doubt the SQLServer as a Fileserver scheme will actually work out. That feature was supposed to be in Windows 2000 according to MS PR-flaks in 1998.

        Look at times in the past where vendors have decided to break compatability with "better" tecnology. Companies like Commodore, Atari, Coleco, etc who did that no longer exist.
        • I still have my doubts about this SQL-type file system... One would figure that the file system should be fast, and to me, a sql server running in the background to translate all this stuff seems slow... horrendously slow in fact. At least I hope they strip it down so it runs fast and efficient... or something.

          I dunno, I guess maybe I'm missing something
  • UpdateObject(XAML** object);

    XAML looks somthing like this

    etc.........

  • Now you can buy all new software as nothing from prior to Longhorn will run as it will be missing all it's API calls.

    Sure maybe they can fix the bloat and evil API clutter by simply stripping it all out and redoing it. Then all applications need to be re-written for no reason just so they can run on Longhorn.

    That's one way to fix the economy. Or at least force people to seriously consider an Apple Switch. Heck, as long as they have to rebuy everything anyway might as well go all the way and jump ship wh
    • Not to support MS, but from a developer's point of view, I doubt we'll have to rewrite all our apps. They're simplifying the Win32 API, not everything on top. If most of your app is MFC, you'll just need to recompile and link to a new MFC that uses the new Win32 API. Granted, there will be some manual changes, but I don't think they'll get as far as a full rewrite.
    • Now you can buy all new software as nothing from prior to Longhorn will run as it will be missing all it's API calls.

      Hmm, I don't think so, but you almost got it. I propose "nothing prior to W2K will run" instead.

      Just look in the MSDN docs, and you'll find that many API functions fall into two categories:

      * For compatibility only, use xxxEx (or xxx32, etc) in new applications, or

      * This functions supports 437 state flags, 32 of which go back to W3.1, 12 available on NT4, 42 if you have IE4, but 10 more i
    • Naw, in the future you'll 'rent' applications from over the internet for a per-use fee. If you need Norton Utilities (god knows why you'd think you would, but this is the hypethetical Joe Everyman I'm referencing here) you use MS Passport to pay for an encrypted binary, to which you don't have any of the keys, which gets downloaded into your hard drive and then runs with Palladium and the net effect is probably a lot of money will go to companies for questionable binaries. Like at the carnival, once you g

  • when I was your age... (Score:1, Funny)

    by Anonymous Coward
    When I was your age we had 0x128e0 non consistant
    API calls and we LOVED it.
  • If so it's about time the Win16 subsystem, which also includes DOS emulation, went away.. and if that's what they're doing that would account for an awful lot of APIs (especially all the DOS interrupt calls).

    - Steve
  • So we will have less things to worry, like: What is the API to close dialin RAS calls. Previously it was just undocumented...
  • 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)
  • You should read that as: M$ is going to reduce the number of documented APIs from 76k to 8k, meanwhile adding more undocumented 'features' to old routines, which are misteriously used by M$ software.

    WineLH anyone? [winehq.org]
  • Won't this new GDI make it far easier to create applications that run on Windows and on other platforms?

    At first glance, this looks like a major improvement in openness.

Slashdot Top Deals

There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann

Close