ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Article:
  WinFX: An All-Managed API
Subject:   .NET, Windows API and C
Date:   2004-04-02 10:05:42
From:   anatolk
Response to: .NET, Windows API and C

About Apple and Carbon - It seems you didn't read well what Apple says about Carbon. They say Carbon is the low level API that is more powerfull than Cocoa, and Cocoa and Java are just high level API's that don't provide the full funccionality of the OS. They never said Carbon is a "legacy API". They never said "we encourage you to wright Cocoa code". So Carbon IS a primary API for the MacOS X. They just don't force their developers to learn the same things in a new way, loosing productivity.
"you couldn't produce a C version of the .NET API because not all the necessary features are present in C." - I think all necessary features are present in C to produce any kind of code, it's just about good and bad API design. You can produce a very high level API in plain C and it would be as easy to wright as with current OO language API's, not to say easier. It's also about concept of the API. The concept of the Windows API is that it should provide a high level system funccionality and not a very high level user funccionality. As an effect you can wrap it in any language, any platform and provide a very high level user funccionality and that's why we have VB, Delphi and current .NET. that make it really easy to write a user app. I think the WinAPI gives more freedom to write any software because it is not targeted to a specific kind of applications, if i want to write plain C code i write it, if i want to write VB,Pascal,Java,C#, etc. i write it and there are no restrictions. With Longhorn if i want to write plain C code with a simple C compiler i can't, i should stick with an irritating hybrid known as "Managed C++" and COM which is a good concept but highly complex to write even a simplest thing.
"You already have one of those - Visual C++..." - I said that Visual C++ is not a convenient C WinAPI development environment, it's aimed to C++ and MFC, it doesn't provide to C API programmers many facilities that could be provided.
"You're mistaken about how Longhorn will work - it won't be based on the existing USER32, and GDI32 components." - Did i mentioned that Longhorn would use USER and GDI somewhere??? I said that USER and GDI are examples of a good (commercial) OS implementation and actually they are really easy to use because there is a firm and simple logic behind them. I said that the Longhorn kernel will be based on the current NT kernel which is considered by most people as excellent, even UNIX gurus agree on that.
"Who cares? Really? Who cares? " - Ok, who cares of one application reserving huge amounts of memory, but what about all applications reserving huge amounts? And after all it is not that simple, but that's another story.
"Although Outlook, which is *not* written in .NET is pretty slow, and it is currently using 67MB of memory" - I speak about very simple programs written in .NET, they could not be compared in any way with Outlook, they just show the performance overhead of .NET. And since for so many years my OS-es performed relatively slow because of the hardware and now my Windows 2000 just performes like a rocket i don't plan to degrade performance again with a new heavy OS. Will my productivity be boosted? By the possibility of rotate windows around??? Or play a video on the window surface??? Or all the effects that would only tire my eyes??? Or i would be writing a document and making a spreadsheet in a 3D space???? I even disagree with the concepts of the new UI design, it's irritating. In the heart of the UI is the concept that it should be consistent, so that all programs provide a well known, consistent user interface to the user and not forcing the user to be faced with different UI for every program he is working with. And Microsoft claimed on that for years. It is the very first thing you see in any book about UI design. That's why it is sometimes hard to change the look of the existing Windows UI, it is not about resource limitation but a good user experience. If i want to see something beautiful i would go outside home and there are plenty of beautiful things you can see outside. The UI of Windows (and Mac, and OS2,etc.) is a great success because 1.It is consistent. 2. It can express very well "states", 3. It is not irritating to the eyes, 4. It helps you to do your job without paying too much attention on it, so you can focus on your work, it is really an "interface".
Since Windows XP arrived, i've seen more and more people who previously said "i'm bored by the standard grey Windows UI" discarding the new UI and back to the "standard grey UI" and saying "you just can't stick for a long time with such a gaudiness, it just tires my eyes!", not to say that flat UI can't express "states" very well ! After all there was a progress from flat UI on Windows 1.0 to 3D UI on Windows 3.0 and full support of it on Windows 95.
"But Microsoft do want it to be the primary API for the next 10 years or so." - Are you sure that the .NET you see today would be the primary API for the next 10 years? I'm not sure. Another "paradigms" will raise and .NET will be another "legacy API", it's all about business, not about technology or preferences.
And guess how .NET objects are exposed in the Win32 world? COM objects! - It is really bad that all new funccionality will be provided to C programmers through COM. Like i said early COM is a good concept but extremely complex implementation. It's what i'm talking about - the new Longhorn API would restrict freedom of programming, not utilize existing programmer's knowledge well making existing programmer's life harder forcing them to relearn the same things, they already are skilled on, in a "new" way.

1 to 1 of 1
  1. Ian Griffiths photo .NET, Windows API and C
    2004-04-03 05:30:22  Ian Griffiths | O'Reilly Author [View]

    • .NET, Windows API and C
      2004-04-03 19:09:32  anatolk [View]

1 to 1 of 1