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-03 19:09:32
From:   anatolk
Response to: .NET, Windows API and C

"Quoting from Apple's Introduction" - Yes, that's the introduction. Reading more and deeply in MacOS X documentation you'll find that Apple's firm state is that they will mantain 3 API's for their OS - Carbon, Cocoa and Java and that Carbon is the primary API for the OS containing its full funcionality. That's the difference between Longhorn and Mac OS X - in Longhorn the new funccionality will not be provided via classic Windows API's, it will only be provided through managed API's. That is certainly not the case with Carbon. Carbon is not considered a legacy API. And of course it will be a bridge between classic Mac and new Mac OS X, but will continue to provide every new OS funccionality in a consistent manner via toolkits. You can choose between plain C, Objective-C and Java languages and you are not in trouble if you want to exploit the OS funccionality through one of those languages. It is certainly different from what Microsoft will do with C programmers (it seems many people these days don't distinguish between C and C++, when i say C i mean C, not C++!). From what i see there is no way to use the Longhorn API from C (mean C!), if there is a way please tell me about it (except for the COM way which can be used from plain C, but i don't want to discuss it again).


'learning new things' with 'losing productivity'. In my experience this is often not the case. " - Well, for me it is just the case. I've spent many years on learning how to program for Windows and i don't want to relearn the same things again in a new fashion. I just don't want to learn again how to write a "Hello world" application, that's a regression, not to say humiliation. My productivity will be degraded for a long time. For me as a C programmer its worth to go down to device driver writing than to new user code.


About C - Well, there are many good books and proffesionals which state just what i said. C is a huge success and it was used for 30 years not just for writing OS-es but for any kind of application development and since you can make anything in C it is also dangerous, it is designed to give freedom and not to restrict the programmer in any way, it is considered that the programmer knows what he is doing. And since you can easily do something wrong writing in C C programmers tend to be very careful. And that produces good programmers.
(1)"C doesn't have strong typing" - of course, it shouldn't have strong typing! I would say that's a great feature of C and very useful in a miriad of situations.
(2) C does not embed type information in executables - that's entirely unrelated to the language.
"Of course it's possible to do all of these" - of course it is. So every time i discuss those problems with people we end up with this - it's all about certain degree of effort. But C# and C can't be compared that way. C is, as i would say, a mid-level language and C# is a very high level language. C is designed to be small, it could contain as many features as you want, it could be binded to some platform, but that is not the goal of the language. Denis Ritchie gives very good explanations on that subject. C was designed also with platform independence in mind. And that's not what these days many people think about platform independence. C is platform independent at source code level, not at binary level (like Java that should port all the runtime platform to be able to execute and executes bad and can't exploit the full OS funccionality, leaving the user with poor experience). There are many advantages of source code level independence over binary independence.


"Actually I think VB's ease of use is somewhat" - i agree with all you said about VB, i highly appreciate .NET programming model over VB's.


"which is a good concept but highly complex to write even a simplest thing" - yes, i was talking exactly about COM.


About kernel, user and gdi - i will make it clear:


"My own opinion is that the basic modules kernel, user and gdi are an example of a good (commercial) OS implementation - i mean that those modules are well designed (using such a simple language as C is) as building blocks of the OS.


Microsoft will build even their new Longhorn system on that kernel" - i mean that the Longhorn kernel will build right on the NT kernel code, because as i said it is excellent and very expandable (and is an example of how a good design can make a successful and long-lived software)


"Seen in that light, it seems like madness to use the same language in user mode as in kernel mode" - I can't see any madness programming through the Windows API, i'm not bored, not frustrated. Of course it is somewhat hard at the beginning but isn't it with any beginning? I see consistency in that knowing to write device drivers it is a very short learning curve to write user mode applications and viceversa which is good, i think. The classic API is a great paradigm, very logical and easy. The fact that there are bad designed API's in Windows does not make the whole paradigm bad, or the C language bad. The basic API's are well designed and easy to use. Well, many people scream about inconsistencies in programming models inside the OS or naming API elements, just to mention a few. Really, there are many inconsistencies, but there are many reasons for that, among them history, backward compatibility, unclear naming conventions, different teams working on different parts of the operating system,etc. Let's take the windowing API elements for example: looking at the windowing API we see that it is object oriented, but it looks somewhat messy. Why, for example, all functions, structures, constants aren't prefixed to indicate that they belong to certain part of the OS? Well, back in the days of the Presentation Manager we see that they've done it just that way. All windows functions are 'Win'-prefixed. But building Windows Microsoft decided that the whole OS could be viewed as an object, so there is no need to prefix core OS elements. But Windows evolved enormously over time, there are plenty of API's, and now we think it would be better if Microsoft just prefixed all different API's in a consistent manner and produce a highly good looking API.


About the new OS look and desktop features - i was speaking as a user, not as a developer. As a user i just want to write a document, not to distract myself with flying windows over the desktop. If i want to play a game i would start and play it and my action will be totally unrelated to the desktop UI.


"until a crash happens some time later like C does if you mess up your pointers?" - well, i just don't mess my pointers. If i mess pointer i would not dedicate to programming.


"It's not really a 3D UI at all, it simply exploits the 3d acceleration hardware. The UIs are still 2D" - i was abstract in saying 3D,the statement is not related to current Longhorn UI implementation, it's just a tendence and a very discussed subject.


"There is inconsistency across windows applications on things like where configuration settings go" - Well, after all it's a choice of the developers, but since the beginnings of Windows Microsoft were very consistent in making their own products. And i was speaking not about choosing where to put a menu or choosing between accelerators, but about the GUI itself - windows, buttons, menus, scrollbars. listboxes, etc. Their look is very consistent and not distracting.


About API's over time - i think the often given comparison example of Win16->Win32 and Win32->.NET is just very unsuitable. Win16 and Win32 is the same API, it is just a transition from 16 bit to 32 bit code, the API remains the same, internally of course some things change to suit the 32 bit processor architecture, but in fact you work with the same API. Now we are not moving to another processor architecture, the API changes dramatically and that transition could not be compared at all with the transition from Win16 to Win32!
The 64-bit Windows architecture is not changing the classic API much.


"Microsoft are effectively in charge of what OS gets" - Microsoft lost the war on server side systems. Now most of server side systems are UNIX-es or flavours of UNIX. Linux is moving quickly ahead as a preferred desktop operating system, especially in Europe, Apple is bringing their ever advanced solutions in reasonable prices now. Microsoft should be very careful in that situation.


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

1 to 1 of 1