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.

Showing messages 1 through 3 of 3.

• .NET, Windows API and C
  2004-04-03 05:30:22  Ian Griffiths | [View]
  
  
  Quoting from Apple's Introduction
  to Mac OS X Development Technologies here's what they say about Carbon:
  
  "The Carbon environment provides fine-grained procedural APIs in C and C++ that are intended for developers who are migrating applications from classic Mac OS to Mac OS X."
  
  They go on to identify Carbon as being primarily for use when you need to support both Mac OS 9 and Mac OS X.
  
  But they describe Cocoa first, and they describe it in much more glowing terms. Anyone new to Apple development reading that page would inevitably think that Cocoa is the best way of developing for OS X, and that Carbon is for migration of existing code, and backwards compatibility with OS 9.
  
  The message from that page - the page where Apple sets out its developer technologies for those new to Apple - is clear: Carbon is there as a link to the past. A fully-supported and powerful link, but wholly rooted in the past nonetheless. What were you reading that gave you a different impression?
  
  "They just don't force their developers to learn the same things in a new way, loosing productivity"
  
  This seems to be a theme in this thread - you always seem to equate 'learning new things' with 'losing productivity'. In my experience this is often not the case. Learning new ways of doing things often helps you do things more efficiently. The .NET Framework is a case in point.
  
  (This reminds me of a talk given a while back by David Chappell. Someone asked him if .NET was the last time Microsoft were going to ask developers to learn new stuff. He replied saying "If you can't stand change, get out of the software business.")
  
  
  
  "I think all necessary features are present in C to produce any kind of code, it's just about good and bad API design. "
  
  There are several reasons that this just isn't true. To pick a couple:
  
  (1) C doesn't have strong typing. Last time I checked, casting anything to (void*) was still legal - C's static typing is entirely optional. Strong typing is fundamentally important to .NET's security system - the ability to use the new styles of deployment in .NET (where you can get all the benefits of web-style deployment with nothing more than a URL, but also retain the benefits of a rich client-side windows program) would be worthless if the .NET framework wasn't able to verify that the code it is running sticks to the rules. (You may have heard of 'unsafe' code where you can still use pointers. This exists, but it's not allowed in this style of deployment - such code will be rejected by the .NET framework.)
  
  So standard C is not usable for the 'smart client' deployment, one of the key features of .NET.
  
  (2) C does not embed type information in executables. Many features of the .NET framework rely on the availability of type information. For example, serialization, remoting, designer integration, XML type mapping.
  
  Of course it's possible to do all of these things by hand in C. But to provide these facilities automatically an API needs access to information about the methods or data structures you are using. C's lack of support for access to type information at runtime means any API providing these facilities would require you to reenter all that information in some format it could access. This doubles the effort (e.g. you have to define methods in IDL as well as in C if you're using Windows RPC), and opens opportunities for inconsistency - if you have two representations, it's possible for them to get out of sync.
  
  There are others, but I'm not trying to provide a comprehensive list - I'm just pointing out that you are mistaken to "think all necessary features are present in C". They are not.
  
  
  "you can wrap [Win32] 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"
  
  Actually I think VB's ease of use is somewhat misunderstood and in some cases overrated.
  
  VB makes some things very easy. It actually makes some other things extremely difficult. The last time I was doing any VB6 development, I ended up writing a few ActiveX controls in C++ because VB wasn't well suited to the task at hand.
  
  The fundamental problem with VB is that it presents its own set of abstractions which are quite different from how Windows really works. These abstractions make life much easier but they also restrict you.
  
  So prior to .NET you had a choice - lots of effort but plenty of power in C or C++, of massively reduced effort in VB but less power.
  
  If you've had similar experience, I could understand why you might think that easier environments are necessarily less powerful. In fact that was pretty much what I felt after using VB6 for a while - I thought that the Win32 API was the only way to get certain things done.
  
  But now that I've been using .NET for the last 3 years, I've realised I was wrong. The limitations were specific to VB6 - it simply chose to present limited abstractions. But of course you could equally choose to present limited abstractions through a C API... The power isn't a function of the language as such.
  
  The power of the facilities provided is in fact independent of the style of API used to present them - the .NET framework shows very convincingly that you can provide an API which is both easy to use and powerful. (And obviously you could provide one that is hard to use and weak...)
  
  
  "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"
  
  Actually that's Managed C++ OR COM. You wouldn't use both.
  
  
  "which is a good concept but highly complex to write even a simplest thing"
  
  I think you're just talking about COM here - is that right? But as I said, use of Managed C++ lets you use the WinFX APIs directly from C++. And if you think the WinFX APIs (which are a superset of the .NET Framework) then either you were doing something wrong, or you haven't really tried.
  
  
  I said: "You're mistaken about how Longhorn will work - it won't be based on the existing USER32, and GDI32 components."
  
  You replied "Did i mentioned that Longhorn would use USER and GDI somewhere???"
  
  I certainly seemed like you did. You said this:
  
  "My own opinion is that the basic modules kernel, user and gdi are an example of a good (commercial) OS implementation. As you can see the kernel of NT systems is excellent and that's because it's written consistently and with a smallest amount of backward compatibility, that's why Microsoft will build even their new Longhorn system on that kernel"
  
  In fact you drew attention to it when I didn't reply to it first time round.
  
  I took this to mean that you thought Longhorn will build on the basic Win32 modules "kernel, user, and gdi", as you called them. (kernel32, user32, and gdi32, is what I presume you are referring to.)
  
  In fact Longhorn does not build on user32 and gdi32 - it replaces them with something else.
  
  Given the flow of the first two sentences, it looked like you were using 'kernel' to describe the core pieces of the OS rather than necessarily just the bits that run in kernel mode. But maybe I misunderstood, and you did actually mean the bits that run in kernel mode, although if that is the case, it's somewhat unclear from the way you wrote it - it makes the second sentence a big non-sequitur.
  
  But if you did simply change subject without warning, from kernel32,user32,gdi32 in the first sentence to the kernel mode parts in the second sentence, I still can't fully agree. Remember that large amounts of the UI handling in Windows are in the kernel. These parts of the kernel are being replaced in Longhorn.
  
  It's true that other things like handle management and IO will remain largely unaltered. The scheduler is being modified to support certain multimedia features not possible on today's versions of windows, but it is an incremental change on the existing scheduler. But so what? You don't program against the kernel mode APIs for anything other than device drivers.
  
  C is an appropriate language for writing an operating system in. (As is C++.) But that doesn't mean it's an appropriate language for everything - far from it. The whole point of an OS is to abstract away the raw grungy details of hardware handling, memory management, and IO. Seen in that light, it seems like madness to use the same language in user mode as in kernel mode. That's akin to using a hammer for every job!
  
  
  "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."
  
  But simple programs take just 10-20MB. (And that's before you do any optimization.) That's also the whole working set, and remember that some of that will be .NET Framework DLLs which get mapped between processes. And in my experience they run just fine.
  
  If you're going to get obsessed with memory, where do you stop with reducing the memory footprint? Win32 isn't all that lightweight by the standards of 10 years ago, so these arguments you raise of .NET vs Win32 all apply to Win32 vs. Win16! Back then consumer PCs had to run something lighter than Win32. Now, the fact that it takes several megabytes to run hello world in Windows is not a big deal because a PC ships with hundreds of megabytes as standard, rather than the few megabytes that were standard a decade ago.
  
  
  "Will my productivity be boosted? By the possibility of rotate windows around???"
  
  That's a pretty specious argument. Just because you can do frivolous things doesn't mean the whole system is frivolous. Picking an arbitrary feature and poking fun at it while ignoring the rest isn't a robust style of critique.
  
  After all, Windows 2000 supports transparent windows, and some would argue that those are just so much chrome, but you're happy with Windows 2000's performance.
  
  The key is whether your productivity is enhanced by the platform. Will spinning UIs help you? Probably not (unless you're building presentation applications). But will the ability to get a job done in far fewer lines of code improve your productivity? Will your productivity be improved by working on a platform which detects whole classes of errors for you and reports them, rather than just plodding on after an error has occured until a crash happens some time later like C does if you mess up your pointers?
  
  I don't know anyone who's tried a non-trivial project with .NET who didn't find it to offer substantial productivity enhancements. I know lots of people who have tried it successfully. (And none of them had much use for spinning windows around.)
  
  
  "Or i would be writing a document and making a spreadsheet in a 3D space????"
  
  This is a common misunderstanding about what's meant by the so-called '3D' nature of the Avalon UI. It's not really a 3D UI at all, it simply exploits the 3d acceleration hardware. The UIs are still 2D. Unless you use DirectX. (Just like with Win32 today in fact! But faster because the system exploits the fastest parts of the GPU for both 2D and 3D work, unlike Win32 today.) See my article on Avalon graphics in this series or on MSDN for more details. (Right now Google finds these as the first two hits searching for: Avalon Graphics.)
  
  
  "I even disagree with the concepts of the new UI design, it's irritating."
  
  Microsoft haven't actually released Aero, the new UI for Longhorn yet so I'm not quite sure what exactly it is you're disagreeing with! Any screenshots you're likely to have seen for Longhorn are all for the developer preview, which contained a slightly odd hybrid UI - mostly a modified Windows XP ui with a few experimental features added.
  
  
  "The UI of Windows (and Mac, and OS2,etc.) is a great success because 1.It is consistent."
  
  Actually I disagree with that, but that's a whole other topic. There are multiple different standards for keyboard shortcuts, and even for cut and paste! There is inconsistency across windows applications on things like where configuration settings go on menus, how to navigate around multi-window UIs and so on...
  
  The Mac seems even more inconsistent when it comes to keyboard navigation through text - every text editing widget seems to have its own minor variations on which keyboard modifiers do what.
  
  
  "Are you sure that the .NET you see today would be the primary API for the next 10 years? "
  
  Yes - it's very clear that this is the message Microsoft are sending out to everyone: .NET is where new features are going to be added. The only thing that would stop it would be pushback from the developer community. But the reaction from developers has mostly been very positive - you are very much a minority voice.
  
  
  "Another "paradigms" will raise and .NET will be another "legacy API","
  
  Sure. Eventually. Just like every other API before it. But Microsoft don't push out new APIs for fun - it's expensive and difficult.
  
  On past experience, APIs tend to last a little over 10 years before they start to look outmoded by the evolving capabilities of the hardware. Win16 was around for approximately that long. Win32 has been around for roughly that long. So yes, I'm sure .NET is likely to have been relegated to 'old stuff' by 2020. But I don't agree with your reasoning:
  
  "it's all about business, not about technology or preferences."
  
  I think it is about technology and business. Win32 was too heavyweight for 1980s PC technology. .NET was too heavyweight for the average 1990s PC. Typical PCs in 2010-2020 will likely make it possible for the OS to provide a range of facilities on our behalf that make .NET look cumbersome, and Win32 positively stone-age.
  
  Of course it's about business too - new technologies are adopted because they offer a business benefit - improved return on development spending in this case. But the business benefit is enabled by a technological advance.
  
  
  "It is really bad that all new funccionality will be provided to C programmers through COM. "
  
  Fortunately, hardly anyone is using C any more. So for most people, the move to an OO API is a big step forward. It means the API uses the same level of abstraction that they've been using in their own programs for years. This extra work is the price you will pay for using C.
  
  But then as a C developer you're already used to working far harder to get something done than a .NET developer. ;-)
  
  
  
  "the new Longhorn API would restrict freedom of programming, not utilize existing programmer's knowledge"
  
  You could apply the same logic to any change of technology. But the only reason people adopt these new technologies is because they believe they offer benefits.
  
  Microsoft really isn't in a position to force the use of a new API - if the developer community had simply rejected .NET, and carried on using Win32, Microsoft would have had no choice but to carry on making Win32 the primary API. After all, while Microsoft are effectively in charge of what OS gets installed on PCs because of their monopoly on the client OS, they are *not* in control of how people write Windows applications. They're free to introduce new APIs, but they can't make developers use them. Indeed there are plenty of APIs introduced by Microsoft over the years that didn't achieve widespread developer acceptance.
  
  Nobody forced any organization to use .NET. Companies are using .NET because they saw that it offered an advantage over using Win32.
• .NET, Windows API and C
  2004-04-03 19:09:32  anatolk [View]
  
  
  "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.
• .NET, Windows API and C
  2004-04-04 09:03:39  Ian Griffiths | [View]
  
  
  "Carbon is the primary API for the OS"
  
  Can you link to a specific page that says this? Google for:
  
  Mac "OS X" "primary API"
  
  and the only thing that Google finds that says Carbon is the primary API is your message in this thread! As far as I can tell you're swimming against the tide.
  
  I've also gone further than the introductory page with apple docs - I've got a little experience of writing OS X apps, and I've not come across anything that backs up what you're saying. The main reason I pointed to the introductory page is that it's a place where Apple set out how their various APIs fit into the overall picture.
  
  The closest Apple seem to get to supporting your opinion is that in some places they describe Carbon as being of equal important to Cocoa. I've not found anywhere that says it's the main API, and as I've already shown, there are places where it's indicated as being the 'backwards compatibility' API, and where use of Cocoa is encouraged.
  
  But I'm not an Apple expert - I'm just going on what I've seen. I'm happy to accept evidence that I'm wrong if you can supply it. So can you provide a link that backs up what you're saying?
  
  
  But anyway, yes, in general in Longhorn, C is not necessarily going to supported as a means of using new functionality other than via COM. They will probably choose to provide some new C APIs, but even before .NET, many new platform features like XML support and HTML display were not directly supported C except through COM, so this is likely to continue. But then the number of people using C in Windows is so small these days that it's more or less an irrelevance. The Win32 API may be C-based but most people who use Win32 directly are accessing it through C++.
  
  However, I think you're being unnecessarily picky in rejecting managed C++. If you really want to write procedural code in managed C++ you can. This is one of C++'s explicit design goals: to support multiple programming paradigms. So if you want to write C++ that looks indistinguishable from C (indeed, which will compile as both C++ and as C) you can.
  
  So you can write procedural code that has direct access to the Longhorn APIs. And if you really want to, you can even carry on using Win32 APIs from this code, only using the new non-procedural Longhorn APIs when there is no Win32 alternative.
  
  
  
  "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"
  
  Well you're out of luck then.
  
  Surely you don't expect the rest of the industry to stick with old-fashioned tools that the vast majority of developers find less productive just because you don't want to learn something new?
  
  If you're not prepared to learn new things then computing probably wasn't a great career choice. If you're lucky, you'll be able to carry on making a living in niches where C is still used, but even in low level stuff like device drivers and embedded systems, C++ is increasingly being used instead of C. (In fact C++ was starting to become popular for NT device drivers even back when I was last writing them in 1997.) But as far as mainstream programming is concerned, the reality is that things move on. If you aren't prepared to move with them, then that's your choice, but you can't expect the rest of the world to stay still for your benefit. By choosing not to learn you are choosing to leave the mainstream. Moreover, C++ is gradually moving into a lot of what used to be C's niches, because its multi-idiom support goes hand in hand with its 'you only pay for what you use' philosphy, which means that C rarely offers any advantages over C++. So you may find it increasingly difficult to find someone who's prepared to pay for the low productivity C offers.
  
  Good luck, though.
  
  
  
  "(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"
  
  And it's harmful in a great many more. I see you've ignored the security aspects of this that I raised. This lack of strong typing is fundamentally incompatible with the new security models offered by .NET, and as a result you are effectively ruling out certain styles of deployment by sticking with C. This is one of the main reasons .NET (much like Java) enforces type safety.
  
  Do you consider security not to be important?
  
  
  
  "(2) C does not embed type information in executables - that's entirely unrelated to the language."
  
  Are you telling me there's a version of C that does embed type information in executables? This is something that the C# compiler, VB.NET compiler, and Java compiler all do. To be sure, in .NET it's also a platform feature - this is somewhere the language and the platform meet. But it's also tightly coupled to the language - a language's type system has to support the features to enable a mapping. (And it is technically possible for a language not to use classes at all. In fact you can write a managed C++ program that doesn't define any classes at all - as always with C++ you are free to limit yourself to the C style. It's just that you won't be able to use APIs which depend on using your type information.)
  
  Moreover, long before .NET chose to make reflectable type information mandatory, there were loads of languages that supported reflection, and which ran on systems where reflection was not a fundamental platform feature.
  
  So I don't think it's remotely accurate to say it's not a language feature.
  
  
  
  Me: "Of course it's possible to do all of these"
  
  You: "- 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."
  
  Why can't they be compared? In cases where either language can be used, then they can be compared.
  
  C# makes things much less effort than C. There are some cases in which C# cannot be used (e.g. device drivers), but in the kind of software that most people are writing for Windows today, you have a choice, and it'll take less time to write in C#. In what sense can you not compare?
  
  
  "C is platform independent at source code level"
  
  Hardly. And definitely not if you're using Win32.
  
  C is only platform independent if you don't use anything outside the standard library APIs. And even then it's not necessarily portable because not all environments are required to support the full library. (Embedded systems for example.) So you only get platform independence if you never interact with the platform.
  
  But of course, most code has to interact with the platform, so in practice about the only code that is truly portable is something which implements some algorithm, and which has to be integrated into a larger system before it can actually be used. (E.g., code that implements some image processing algorithm.)
  
  In practice most programs interact with their platform a lot. And in some applications, you do practically nothing but interact with the platform. C code which uses the Win32 is in no way platform independent - it depends on the Win32 platform. So you seem to be making a pretty irrelevant academic argument here.
  
  
  "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)"
  
  OK, but of course the kernel doesn't actually present a C API to user mode. The kernel's user mode API is undocumented, and revolves around using the INT instruction. So this doesn't seem like an argument in favour of C APIs. NTDLL.DLL wraps this in a C API, but C isn't the fundamental way of talking to the kernel. That's just a wrapper to enable you to call into the kernel from C.
  
  As for the insides the kernel, it is written in a mixture of C and C++. But only because when writing in kernel mode, you have to be able to work with raw memory rather than strongly-typed data, because a large part of the OS's responsibility is dealing with raw memory. This is not a strong argument for using C in user mode. This is a good example of where C's weak typing is useful, but it is useful here specifically because
  of the kinds of things OS kernels have to do. This doesn't carry through into application development.
  
  
  "I can't see any madness programming through the Windows API"
  
  But as is now obvious, you've not given the alternatives a fair try. After any signficant .NET experience, going back to Win32 makes you realise just how much extra work a C-style API makes you do. You spend so much longer dealing with issues that have nothing to do with the problems your application is trying to solve, and are entirely down to the hoops C makes you jump through.
  
  If you could be bothered to learn the new ways, the madness of Win32 would become immediately apparent to you.
  
  
  "The classic API is a great paradigm, very logical and easy."
  
  Win32 is actually pretty inconsistent. (Mainly because it contains a mixture of stuff from different backgrounds - some from Win16, some from BSD sockets, some from the original NT team that pre-dates Win32.) So it's not as logical as it could be. .NET doesn't suffer from this mixed background - it was starting from a clean sheet. Moreover, Microsoft expend a lot of effort to try and keep things as consistent as possible in .NET - far more than they ever have with any previous API technology.
  
  And 'easy' is relative. It's certainly a lot easier to write a C Win32 application than it is to write embedded code. (I know - I've done a lot of both.) It's also a lot harder to write a C Win32 applciation than it is to write a .NET application.
  
  
  "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."
  
  Again, you are focusing unnecessarily on graphical flashiness. That's really beside the point - it's not illustrative of the broader benefits. I think you may have been misled by the eye-catching demos.
  
  The new presentation stuff is very nice for those who have to do high-quality presentation, and irrelevant for everyone else. But the benefits of the .NET platform go far beyond the quality of presentation it will be possible to achieve. Indeed even within the presentation layer (Avalon) there are substantial productivity benefits to be had even if you use extremely dull visuals.
  
  One of the biggest practical benefits of Avalon is how easy it makes things. How many lines of code do you think it would take you to write an application which displays an RSS feed's content in C? Your target to beat is 0. That's right - you can write an RSS reader in 0 lines of code in Avalon:
  
  Codeless RSS - just markup
  
  This illustrates how easy it is to build a UI declaratively that consumes and presents an XML data source in Avalon. (Other data sources are supported too of course.) For me, this is a much better indicator of the developer productivity benefits of XAML than any number of flying windows. And it's a breeze to start adding programmatic functionality to this - everything you see described in the markup as accessible as an object, so you can just start writing stuff to manipulate the UI directly.
  
  It'd take you days to get this same work done with Win32.
  
  And this ultimately benefits the user too: improved developer productivity means more time can be spent making the application do what it's meant to do, rather than dealing with the minutiae of C and Win32.
  
  Productivity is the key. That's the main benefit of the .NET platform. Flashy UIs make for entertaining demos, but the producivity enhancements are ultimately what make it a better platform for writing software.
  
  
  "well, i just don't mess my pointers. If i mess pointer i would not dedicate to programming."
  
  And how much time and mental effort goes into that? Lots, if you're a conscientious programmer - writing high quality C code requires both skill and effort. But why waste all that energy when you can use a platform that means this work is entirely unnecessary?
  
  Consider this analogy. Insisting on carrying on managing your own memory and dealing with pointers is more or less equivalent to maintaining an evolving web site entirely by writing HTML by hand. Of course you can do that - writing HTML is dead easy and any fool can do it. But if your site changes much at all, and you want any kind of navigability, you end up doing a lot of monkey work maintaining that HTML by hand. It's much less effort to automate those things that can be automated.
  
  Of course it's possible to do all that work by hand. But it's just dull monkey work.
  
  The same is true for pointer management. The .NET Framework or the Java Virtual Machine can do that for you, so there's no need to do all the monkey work by hand.
  
  Why do you want to do monkey work? (And even if you like it, why would your employer pay for you to do work that can be wholly automated if you use the right platform?)
  
  
  
  "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,"
  
  Not really - there were fundamental platform shifts. Several programming practices that worked fine under Win32 stopped working. There were plenty of superficial similarities, but it's really stretching things to far to say that they were the same.
  
  
  
  I wrote: "Microsoft are effectively in charge of what OS gets"
  
  You replied: " - Microsoft lost the war on server side systems."
  
  I see you've now taken to truncating my sentences to change their meaning. In the original context I was talking entirely about PCs and client OSs. You've chopped off the sentence at the point at which that became clear. And the main point that I was making was that Microsoft isn't in charge of which APIs developers use, despite their monopoly position. So you've deliberately more or less reversed the sense of what I actually said there.
  
  If you're going to resort to that kind of thing, I don't see much point in continuing this conversation. In any case, I don't think we're covering any new ground now. You clearly have no intention of learning these new technologies, and are apparently aware of the likely career-limiting consequences of this, so I think there's little more to discuss. I wish you good luck in your quest to cling to C. I fear you will need it.