WinFX: An All-Managed API
Subject:   .NET, Windows API and C
Date:   2004-04-04 09:03:39
From:   igriffiths
Response to: .NET, Windows API and C

"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.