ACK! :eek: I was afraid this would happen now that I'm learning the Win32 API. (Move this thread if you need to.)

Microsoft plans a major cleanup of the Win32 API set and XML application markup language (XAML) to make its next version of Windows, code-named Longhorn, as friendly for developers as it is for users.

"Win32 has like 76,000 APIs, and they're taking it down to 8,000 with Longhorn technology," said one source familiar with the plans.

http://www.internetweek.com/breakingNews/showArticle.jhtml?articleID=9400498
Posted on 2003-05-06 13:03:49 by Masmer
Sorry to hear that...

The "stability" of Windows depends on the number of different APIs, etc... The more, the greater chance that one or two required to keep the system running will be working.

Imagine if shlwapi.dll was integrated into kernel32.dll!!! Not only IE, Outlook, etc would be a security risk, just booting up would be a security risk (and it already is...)
Posted on 2003-05-06 13:31:25 by V Coder
I don't like this paragraph ...

"Also in Longhorn, Microsoft plans to integrate a replacement for the Windows graphics device interface (GDI), code-named Avalon, that replaces the need to do manual coding with prebuilt, extensible XAML scripts. That means developers wouldn't have to access many APIs directly and instead can modify XAML scripts, sources said."
Posted on 2003-05-06 13:33:14 by Masmer
Well my OS has about 10-15 API functions with only 1-2 documented on site curently ... and growing :P
So i will catch them up soon ... :)
Besides i will always have API and not scripts ...
Posted on 2003-05-06 13:36:27 by BogdanOntanu

The "stability" of Windows depends on the number of different APIs, etc... The more, the greater chance that one or two required to keep the system running will be working.

That's somewhat lame. The more functions, the more chance to have a fuckup somewhere.

A good thing that they're finally cleaning up - the win32 API is rather awful. I just fear they'll be too focuse on XML etc, and we'll end up with something crappy. Dunno what to think about the "Avalon" stuff - XAML scripting doesn't sound like a _replacement_, and I know nothing about it... but GDI _does_ need a cleanup, and if they do stuff right... well, would be nice scripting parts of the GUI instead of hardcoding it.

I hope the cleanup doesn't mean we will have a few calls that take a zillion parameters, though...

oh, and this I do not like:

the 3-D-capable Aero interface in Longhorn is slated to be fine-tuned to better exploit the unused processing power available on Intel Pentium 4-based PC desktops.

3D GUI? No thanks. "unused processing power available"? XP with themes enabled is already bad enough.
Posted on 2003-05-06 13:46:57 by f0dder
I'm not sure how that is going to work though. A script by definition just calls an engine and that engine interfaces with the API. Is MS planning on replacing the primary API with a scripting engine ? That would be terrible news, but in line with their disillusionment with anything even remotely low level. They are moving away from C++, VB and all of the other mainstays of the MS programming enviroment and concentrating on scripting languages. This will add alot of power to the shell via no-compile executable scripts but at the expense of the low-level guys like us. Accessing a scripting engine is tough work from what I have gathered in reading Ernie's paper on the subject.

"Generating script to draw sad face please wait...."
Posted on 2003-05-06 13:47:41 by donkey
Don't worry... it will take many years before assembly is eradicated totally :). Perhaps it will be hard writing full-assembly apps for the new windows versions, but it should still be possible to use it "where it matters".
Posted on 2003-05-06 13:51:16 by f0dder
Oops.

I had read "developers wouldn't have to access many APIs directly" as "developers wouldn't have access to many APIs directly" :rolleyes: (Must get sleep.)
Posted on 2003-05-06 14:10:28 by Masmer
Actually when you think about it, what are they going to do - throw out the whole software catalog? Those apps that are written now will still have to work so they have to keep the exact same API calls. Granted the 16 bit leftovers are gone, they were always clear on the fact that they would be replaced so if your still using AppendMenu or OpenFile too bad. But they would break too much code if they scrapped them or didn't supply direct replacement wrappers for the functions, all 76,000 of them.
Posted on 2003-05-06 14:21:20 by donkey
donkey, my guess: wrapper layer for legacy software.
Posted on 2003-05-06 14:22:15 by f0dder
From that movie, where the kid sez 'I see dead people'...

*I see huge exes...
*I see poor optimizations...
*I see less control over my own stuff...
*I see web-tv...
*I see monopolies
*I see a no xbox emulators...
*I see a need to switch to linux...

Am I paranoid?
Posted on 2003-05-06 14:47:20 by drarem
drarem, if they do the cleanup properly, this doesn't have to be the result. In fact, stuff might shrink a bit.

As for scripting the UI... dunno how it'll be performance wise, but it might make EXEs even smaller, since there's less stuff you have to handle yourself. Unless they majorly screw it up, it could even be quite nice - GUI coding is so trivial, and there's so much boring stuff you have to handle.

And if we start talking p-code... well, don't mention performance until really good JIT appears, but EXEs can be quite smaller (at the price of a many many many megabyte runtime... but as long as that's distributed with the OS, "who cares" :rolleyes: )
Posted on 2003-05-06 14:52:49 by f0dder
One question, does anybody know the word compability? What will happen to it? :confused:
A wrapper, wouldn't that mean that the "old" API still would exists (virutally)? Why give up old windows programming habits for new problems? (<- every new inovation opens a new world of possible problems, and if history repeats itself, then many of the possible errors will occur)
A wrapper wouldn't that risk causing new problems, like functions not doing what it was supposed to do (but something similar), and therefore causing errors?

Perhaps it would be better to let the windows api use interrupts, like linux's int 80h, that would set some limit to the number of API functions. 76,000 APIs, I wonder how many of them that will be forgotten (thus no wrapper function made for it)...
Posted on 2003-05-06 14:54:32 by scientica

wrapper, wouldn't that mean that the "old" API still would exists (virutally)?

Sure, just like there's win16 and (limited) DOS support in NT. Subsystems.


Why give up old windows programming habits for new problems?

Because it can be done better? Because it might be possible to create a new API set that's more coherent and reasonable, making apps easier to write, causing less bugs? Yeah, it's a dream, but it could be done. There's been _many_ years of experience with the win32 api now, should be possible to have learnt something from that.



The wrappers would conform to microsofts specifications. If you have taken advantage of undocumented behaviour, too bad. Your fault.


Perhaps it would be better to let the windows api use interrupts, like linux's int 80h, that would set some limit to the number of API functions. 76,000 APIs, I wonder how many of them that will be forgotten (thus no wrapper function made for it)...

:eek:
That's rather crappy. Descriptive names are nicer, and it's easier to remap than numbers for an INT call. Too bad linux doesn't really have an API. And INT calls for everything... correct me if I'm wrong, but doesn't that force a ring transition?
Posted on 2003-05-06 15:01:25 by f0dder

Because it can be done better? Because it might be possible to create a new API set that's more coherent and reasonable, making apps easier to write, causing less bugs? Yeah, it's a dream, but it could be done. There's been _many_ years of experience with the win32 api now, should be possible to have learnt something from that.



The wrappers would conform to microsofts specifications. If you have taken advantage of undocumented behaviour, too bad. Your fault.

Well it's a nice dream that things will be better in the next version, since WinXP I find it a bit harder to belive (since IMO WinXP is terrible, win2k was the last useable OS they made; I've lost a bit of faith in Wndows you see).
Reminds me of an countys dream, it's just a dream. Too bad "some" of them hasn't woken up

The part about using undocumented stuff I can agree that it's a bit risky, and something that should only be done if there's a good reason and that the software((/programmer)) should check for the right system verison/build before utilizing code that uses undoc stuff.

Descriptive names vs. descriptive equates, what's the difference in niceness? As for interrupt requiring ring transition I don't know at the moment, perhaps our dear pinguin programmer bazik knows?
Posted on 2003-05-06 15:41:42 by scientica
Nah, not necessarily. If the higher of the RPL of the selector in an interrupt or trap gate and the DPL of the segment it refers to is equal to the CPL of the calling program, then there's no ring transition.
Posted on 2003-05-06 16:03:31 by Sephiroth3
I'll take your word for it - it has been some time since I messed at this level.

However, INT transition should still be slower then CALL if I am not mistaken, plus you need supervisor code to set up the interrupt.

Make's more sense to have the api in shared libraries, most of it will be ring3 code anyway.

I like the nt/win32 model... I mean, the win32 API is totally polluted, but the idea of "any subsystem" using NT native API, and NT native api finally does the r3->r0 transitions.
Posted on 2003-05-06 16:09:21 by f0dder
My bet, if this does happen, is that MS will update the "compatibility wizard" to support "old" apps, and encourage new development in "API II", by supporting it in the then current version of Visual Studio, or whatever it'll be called...

And I wouldn't worry about "wasting your time" learning the current API structure. I'ld imagine the same model would be used, just less functions to worry about.

Sort of like when we went form Function to FunctionEx, that would be my guess.

After all, we are talking Windows here, aren't we... :grin: :grin: :grin:
Posted on 2003-05-06 20:04:07 by S/390
M$ has to make more money,so they will have new plans. :)
Posted on 2003-05-07 03:06:43 by Vortex
looks like what is comming down the pike will be buggie untill the 3rd version

there is one big point that is being over looked M$ will have a copyright on the new API and you guys will not be allowed to have acess to info on the new API
Posted on 2003-05-07 11:31:42 by rob.rice