Women in Technology

Hear us Roar



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.

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Ian Griffiths photo .NET, Windows API and C
    2004-04-04 09:03:39  Ian Griffiths | O'Reilly Author [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.