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.
Microsoft Plans Windows API Cleanup
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Microsoft has realized its defects in the computing world. It has learned how Linux got so popular… adapted… they have become better… they have learned…the day of Linux and UNIX is not yet over, but Windows users need not seek an alternative now as much as they have in the past… fear the future… make Linux stronger, this is where the line is drawn between Microsoft and Linux… I’m not trying to cause OS wars, I’m simply stating the status of alternatives to Microsoft in the days where Linux is imperative… good luck to developers… try not to respond to this post aggressively, take it as an opinion, think about it, and move on. Thank you for listenining.
I remember many API “cleanups” coming from MS. The problem is that the new APIs are just added, instead of displacing the old. This means that the 76,000 APIs taken down to 8,000 actually ends up being more like 80,000 when the old APIs are included in the operating system as well.
This is not to say that I don’t think the new APIs are a good idea. Given my experience having to clean up code written to the old APIs, I’d go so far as to say that the development tools should give a warning if any of the old APIs are used in any code, or should even delete the old headers. I like that Windows Server 2003 dropped support for some APIs that were properly deprecated years ago. Good riddance.
The problem is that these APIs generally aren’t always backported to Win2k or 98se where they could do the most good for those who need lower resource usage or the ability to change computers without rebuying their OS. Sorry, pet peeves
.
Are they ending compatibility with Wine, or am I a conspiracy theorist?
So, they took the best of KDE/Mozilla (XML GUI descriptions) and the best of POSIX (orthogonal, minimal API) and are now hyping it up? This should have been done a decade ago. Still, this is great news for Windows developers. Just getting rid of all of those STRUCTURESWITHLONGALLCAPITALIZEDNAMES will help a great deal, as will getting rid of all those functions with more than half a dozen parameters. The current Windows API is a mess. Let me just give you a small taste. To open a file, you have to call the following function in windows:
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);
To do the same in UNIX, you call:
int open(
const char * fileName,
int flags
);
Let’s just put it this way: mmap(), which is a POSIX call with 6 parameters, is unusually complex. CreateFileMapping(), which is a Windows call that also takes 6 parameters, is fairly normal.
Sounds a lot like… MacOS X
Sherlock 3 certainly does a great deal to demonstrate the power of the new XML-ized NeXT Interface Builder format… Sherlock’s channels are implemented entirely in XML, with the GUI design in NIBs and the scripting done in XQuery.
It seems Microsoft will be shipping an XAML interface builder as well. Perhaps Microsoft is taking a lesson from the world of Cocoa development…
XAML sounds like it could be an interesting way to specify application user interfaces. Kind of reminds me of the REBOL/View layout dialect and others like it; I don’t expect XAML to be that powerful, but maybe it could be comparable to something like Delphi. It would be nice to have something that one can put on a resume for people who don’t understand programming to appreciate, but still be a useful tool.
One can hope, but this quote worries me:
So now a Windows application can inherit the behavior of the operating system with zero lines of code.
This attitude clearly comes from someone who hasn’t done any declarative visual specification or worked with markup languages like XML. Just because it’s not procedural doesn’t mean it’s not code.
Bascule:
It seems Microsoft will be shipping an XAML interface builder as well. Perhaps Microsoft is taking a lesson from the world of Cocoa development…
I hope so. Of course it could be that error-free code in XML-based languages is easier to generate than it is to write by hand (awkward syntax). That and keeping up the pretense that this isn’t programming.
I think the real advantage to languages like this is that the XAML processor only has to be written once, while traditional display code procedures have to be duplicated in every app. That duplication leads to bloat and security issues. An description processor only has to be written once (per OS) and doesn’t necessarily need to be written in a language with inherent security flaws, like C.
Dan:
Are they ending compatibility with Wine, or am I a conspiracy theorist?
They ended that compatibility long ago, and do it again with every service pack (Wine keeps catching up). I can’t answer that second part
Seriously, this development sounds like a good thing. Assuming they don’t patent the hell out of this (which I’m not), simpler APIs are simpler to replicate. XML description processors are even simpler still. Keep in mind that most of this will be written in managed code – Mono is doing a pretty good job of replicating that. XAML sounds like it will be easier to copy than WinForms. In the long run, moves like this may be better for Wine.
I just don’t know. Does it the same concept?
Windows’s XAMPL and Mozilla XUL.
I remember many API “cleanups” coming from MS. The problem is that the new APIs are just added, instead of displacing the old.
No, the problem is that, over time, they have accumulated ~250 system calls and ~400 runtime library functions that totally put to shame both Unix and Win32, but are for internal use only, thus undocumented
The Win32 API is a thick, crusty layer on top of these, so designing a new API requires no modification to the current one – they’ll just be both there, side-by-side, and the old one will slowly fade away – nor is a huge effort – just make the new API an easier way to handle the rather low-level NT system calls, and you get a wonderful environment (trust me – writing low level code for ReactOS just made me fall in love with the NT API) and no loss of functionality
To get a taste of what the new API will likely be (or at least how I hope it will turn out), look at the current registry functions: they are just simplified wrappers above the system calls, and they retain their great design – objects are manipulated through their handles (never through their names, like some file manipulation APIs force you to), named objects are opened relatively to other objects, all objects are securable, error codes are returned instead of being stored in a global variable, etc. Oh, sure, you can’t write neatly “compressed” (and unreadable) code because the function names are long and complex, so what? the system is complex, it needs complex APIs
Let’s just put it this way: mmap(), which is a POSIX call with 6 parameters, is unusually complex. CreateFileMapping(), which is a Windows call that also takes 6 parameters, is fairly normal.
I feel your pain, brother. But it’s even worse. To map a file in Windows you need no less than 3 function calls and must specify the desired access in each one: CreateFile(GENERIC_READ), CreateFileMapping(PAGE_READONLY), and MapViewOfFile(FILE_MAP_READ). Yeesh. I wonder if it’s clear that I’m only interested in reading the file.
Office, IE, IIS and SQL Server will probably use the new API in Longhorn. Since most vendors can’t afford hordes of extra development staff, non-MS apps will mostly continue to use the “legacy” API, and eventually will not be able to take advantage of the latest features of the shell. So Microsoft will tell everyone, with a certain sense of righteousness, to port their stuff to the either the new C API or the (slow) .NET framework. About a year later, Microsoft’s tools group will release the 1.0 version of a C++ class framework built on the new API. Meanwhile, the cycle of API creep will begin anew. Advantage: Microsoft’s applications group.
Good guess, but…
I haven’t heard anything that implies that the new API is a C one – most of the new APIs they’ve made recently are more C++ friendly from the beginning. For that matter, the .NET framework isn’t necessarily slow. Code doesn’t have to be interpreted to be managed (ever hear of Managed C++), and even the CIL code can be ahead-of-time compiled. The managed code just adds more bounds-checking, better central memory management, code signing, versioning support and simple installation. Oh, and the libraries.
I wonder if it’s clear that I’m only interested in reading the file.
Well, the Win32 API does an awful job at being a simpler layer over NT – it isn’t simpler at all. It should expose calls to simplify such common sequences of actions, or to minimize the amount of necessary parameters by using sensible defaults – e.g. inheriting the access to the Section object from the file handle, and the access to the mapped page from the Section object – instead it just hides useful features, often also perverting the very design Windows is founded on in the process (e.g. accessing processes by their ID instead of the handle – pseudo-Unix semantics that are unacceptable in Windows)
so this is what happens when there is competition…
I highly doubt the new APIs will be .NET based. What would be the point? .NET already has it’s own APIs. Nope, these APIs are going to be for the coders still using plain old C, which is most of them.
…and they are really going to clean the API (meaning it will cease being as pathetically convoluted and stupid as it is today) then that is great news. However, I’m not going to hold my breath.
the world is full of whingers and whiners who complain that their 15 year old DOS or win16 application won’t work. It is time Microsoft said, “tough luck, get with the programme and upgrade”.
Again I’ll say it again, it is up to the application developers NOT the operating system manufacturer to maintain compatibility.
We hear complaining by the Johny cheap skates of the world that their application won’t work with 2003. Need I remind that person that companies have well and truely bloody known that there was going to be major changes and that it is THEIR (software producers) NOT Microsoft’s responsibility for issuing patches to make the software compatible with the latest release.
As for Longhorn, I say rip and burn. Anything can be even show the slightest hint of insecurity, rip the bloody thing out. Fix up current API calls, and if it means that a few applications are broken along the way, so be it. One only needs to look at NTPL. Linux threads NEEDED to be replaced. Sure, a few applications are broken, however, it will be only a matter of months when we start seeing a NPTL compliant Java etc. Same goes for Microsoft, a bit of short term pain for long term gain is needed.
Rayiner Hashem:
I highly doubt the new APIs will be .NET based. What would be the point?
Some of these new APIs were created to implement .NET, such as GDI+ (a simpler C++/.NET graphics API, faster than C-based GDI). For others, it would be to make use of new system services that are implemented in managed code, such as the Longhorn interface and XAML.
Most of the new programming at Microsoft is being done in C++ and managed code, not C. Trusted computing, security focus and all that. New APIs would reflect that.
“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.
I just finished doing some spring cleaning in the house and it sometimes means – if I’m being lazy – sweeping some dust into some crevices no one will find it in. Taking 76,000 APIs and cutting it down to 8,000 seems more like intensive surgery in comparison. Whew!
Hopefully, this will lead to cleaner, faster and more secure applications for everyone.
Well, we can only live in hope. Hopefully Microsoft will remove the APIs fully so that they are not supported at all. As for GDI+ (gdiplus) and other parts, I hope that they fully remove the old crap from the operating system along with DOS and Win16 support. If you’re still running those applications today, you deserve a public flogging.
It depends. From what I have heard, from those who delve into the depths of Windows, there are 1000s of duplicate API calls that do the same bloody thing but have never been removed. For example, Windows 2000 may consilidate a number of calls however, they keep the old ones for “compatibility”, however, now Microsoft, through some miracle, have realised that this costs money, makes maintainace more complex and opens themselves up to security issues. What they’re going to be doing is removing API’s that should have been removed a while back. For example, before COM+, there were a number of precursors, all have been left in for backwards compatibility. You’d be surprised how the lines of code just keep adding up.
The Windows NT/XP/2000/2003 is mainly written in C++ and a few of the lower parts of the operating system written in assembly from the early days to give a speed boost. Assembly was used in the lower regions to give a speed in the early days because of a combinations of factors, firstly the computers were not as powerful and secondly the C++ compilers were not as mature as they are today.
IIRC, BeOS was pretty much the same thing, C++ for the majority of the operating system and assembly for the low nether regions for speed.
One major problem with simply removing the old stuff is that in many cases, “deprecated” or “obsolete” APIs do give the best performance. For example, on my current system, I quickly gave up using GDI+ (although they finally seem to have designed a reasonable OO API there) because the performance was abysmal.
I have the strong opinion that the APIs for Windows are just as confusing, complex, incoherent, and ad-hoc as the user interface, if not more so.
I don’t think you can pin the inspiration for this on anything in particular, ALL development environments except win32 have had this for ages. Mozilla went the furthest, taking advantage of the gecko engine to do so. Less dramatic would be Delphi, Qt, NeXTStep which use file based UI descriptions but not XML, and Glade, which is actually XML, but it takes advantage of the consistancy of the GTK API and a bit of reflection, so it looks like:
<widget class=”GtkButton”></widget>
for instance.
It’s about time Win32 caught up really.
The thing about performance is interesting – it’s not really to do with the interfaces, it’s just that they have new implementations mostly to go with the new APIs, and those implementations aren’t optimized. Win32 is heavily optimized, working with Wine has rammed this home in a powerful way. That’s not to say Wine is slow, it isn’t, but if you do something like add 20,000 items to a listview in Wine it takes 10 seconds, in Win32 it’s instant.
Windows NT etc. are mainly written in C, not C++, although in later versions, several parts of the system (e.g. the shell) use C++ where it makes sense.
A very small part of the kernel is written in assembly, not for speed, but because you can’t do everything in C. The vast majority of the NT kernel is C, for portability (remember the same kernel has been ported to several different processors and architectures).
There was an interview with an MS programmer a while back and one of the questions was what language do they use for the nether regions of the kernel. As for C and Assembly, IIRC, isn’t UNIX written in 100% C?
Nope, UNIX was never written in 100% C. There are bits you can’t write in C. For example, how would you save all registers during a context switch, within C? Also, NT *is* written mainly in C, and most relevantly, all the APIs are in C. Most major application developers (think Adobe, etc) are using C, or at best limited forms of C++ (I think Adobe uses Qt with one of its products, which is pre-STL C++). Leaving those developers out in the cold would be foolhardy.
About NT and C++ in the kernel: http://www.cmkrnl.com/faqcpp.html
If this is for 64bit computing, why the hell are they using ANY old API’s? As I recall the jump from 16bit to 32bit removed a lot of API’s.
IF I was microsoft, I’d make the API simpler and secure. “insecure by design” implies that security was originally an after thought. Now is the time for them to fix their retarded and REDUNDANT API scheme.
NeXTStep which use file based UI descriptions but not XML
The NeXT Interface Builder format has been reworked into XML for OS X.
Mozilla went the furthest, taking advantage of the gecko engine to do so.
I would argue that OS X has gone the furthest. The interface of any Cocoa application in OS X is described in XML (check the Resources bundle of any Cocoa application and you’ll find the interface descriptions of every window in the application in XML) Furthemore, as I mentioned before, it is possible to code entire OS X applications in XML, using the OS X .NIB format for interface descriptions and XQuery for a scripting language.