Women in Technology

Hear us Roar



Article:
  WinFX: An All-Managed API
Subject:   .NET, Windows API and C
Date:   2004-03-25 15:31:21
From:   anatolk
Response to: .NET, Windows API and C

"When Apple released their completely rewritten new os MacOS X, they provided new API's like Cocoa but they retained the old Carbon C flat API and not only for compatibility but it can access all the new funccionality of the OS and it is not considered an "old fashioned, outmoded, arcane" API but is considered a valuable API with a future. Now existing C programmers can apply their existing knowledge and simply expand it with the new OS features, making them even more productive. I didn't see such a choice in the future of Windows." --> You didn't commented this.


"You get improvement of productivity not because of the language you use, but because of the prewritten functionality that is already provided for you. No matter the language or the platform, when someone has written the complex funccionality for you, your life gets easy and you are happy. The same applies to the development environment. A good develompnet environment will speed up the development process in any language, any platform. Visual Studio is just not a good development environment for C WinAPI programs. It accented on C++, and now on .NET. Give me an environment aimed only to C WinAPI programming and my development cycle would speed up enormously. On the other side if you need to develop something from the scratch with .NET you write more code than i would write using the simple Win32 API, that's a fact i've already seen" --> You didn't commented this.


"Win32 is just a very low level API implemented, i can say that it is the lowest level user API compared to other commercial operating systems. That's why it is sometimes hard to use and slows the development, but that applies to all - you can build a house yourself and you can let other people build it for you and you just painting the walls. So there is nothing wrong with the flat C Windows API, like many people now are trying to make us think. And companies like Apple show just that - it can be used for building and using a very advanced funccionality and has a bright future, they don't force their developers to learn every few years the basic things in a "new way"." --> You didn't commented this.


"I don't claim that the classical Windows API is perfect, it is not fully consistent for example, some parts of it could be implemented in a simpler and more readable way, but that's not because the language or the architecture is bad, but because of bad practices in Microsoft and something called backward compatibility, which is a very serious issue for Microsoft. 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" --> You didn't commented this.


"But why many simple programs written in MFC and in .NET reserve A LOT of system resources and don't free them until the end of the program when Windows walks their heaps and frees it? " --> You didn't commented this. And that's a (strange)fact i observed for a long time.


About the .NET program -> it's certainly a shame to take 14MB of memory doing nothing more than trivial things, it would take a 1 to 2 MB of memory in Win32.


The question - why .NET programs still run too slow on my 2.4 Ghz machine and reserve too many system resources like gdi resources for just a simple operation? It's not acceptable since system resources are limited even on modern OS-es.
I just can't imagine myself doing my work if all my programs were written in .NET. It would ovewhelm any machine at this time.
M$ is promising a real improvement of .NET over Longhorn, but we didn't seen that yet. My current Longhorn version performs just really bad on my powerfull machine (given that currently it is not based entirely on .NET and not all (even user)code is managed).


Finally, there are good arguments on both sides i think, i don't want to dispute them infinitely. I think some people feel comfortable with one thing and other people - with another, that's a kind of own choice, philosophy, name it whatever you want. I think there are '+' and '-' in both worlds, i just don't accept the notion of "perfect-ness". Well, M$ is a commercial organization after all, it should advertise it's products as good products. And it should supply new products, there isn't another way to survive on the market. I don't accept the notion of "last-ness" also, that is flying on the air with every new product or platform. We've seen that most of technologies didn't last for a very long time. An example - when COM came out like a primary way of building components and ActiveX loomed into sight, it was announced by Microsoft as "that's the way to go" (did i heard it recently somewhere?), "in the future all Windows funccionality will be provided via COM" - well, they implemented a little high level funccionality of Windows via COM and it was complex and confusing, so there were smarter teams in Microsoft that continued to provide new funccionality via flat API's and they are far easier to use, look at some excellent API's in Windows like the Fax API, that's what i call a human factor, not a technology factor.
Now COM and ActiveX are evil, .NET is "the way to go", i don't want to dispute it, we'll see the future of .NET philosophy, let's hope it is the best platform to solve all programming problems.
It's a little suspicious to mention only the good sides of a thing and never mention a bad side and that's what i see in disputs on .NET, they are just not disputs after all. I know many bad nuances and there are many critiques of the classic WinAPI, but i can't find a critique on .NET, is it perfect? Perhaps as time goes by critiques on .NET will raise also. There is a cycle in life and we will be reinventing the wheel again and again.

Full Threads Oldest First

Showing messages 1 through 5 of 5.

  • Ian Griffiths photo .NET, Windows API and C
    2004-04-01 04:50:07  Ian Griffiths | O'Reilly Author [View]

    Re: Apple and Carbon.

    If Carbon's so great, why did Apple feel the need to invent Cocoa? Carbon fills more or less the same role as Win32 - it provides continuity for software houses who already have a large investment in that API, but it is no longer the preferred API. Win32 and Carbon remain fully supported of course, because of the large amount of legacy software out there. It's just not how you're encouraged to write new software.


    Re: "You get improvement of productivity not because of the language you use, ..."

    I believe I did comment on that actually. I disagree - productivity is influenced by many factors - API, language and platform all play a role. The .NET API makes most things easier than the Win32 equivalent. C# makes most things easier than the C equivalent. The CLR platform does loads of things for you which in the Win32/C combo you have to do for yourself. And the platform influences the API - you couldn't produce a C version of the .NET API because not all the necessary features are present in C.


    "Give me an environment aimed only to C WinAPI programming and my development cycle would speed up enormously."

    You already have one of those - Visual C++... If you're saying that you want the benefits of the .NET Framework brought to C, the only way you could do that would be to replace the C runtime with the CLR. Such a language already exists by the way - it's called Managed C++. As with all C++ flavours you're not obliged to use the C++ features. So if you are determined to write C, you still can, and yet you can use the .NET framework.

    So if you want to write C applications that use WinFX, that's how you'll do it. You will be obliged to use objects from time to time because that's how the WinFX API presents stuff. But you're not required to define any classes of your own for most API calls.



    Re: "Win32 is just a very low level API implemented, " --> You didn't commented this.

    Err, yes I did. But I'll comment again if you like. It's very low level. That's its problem. Higher level APIs tend to make things easier. That's why we have them.



    Re: "I don't claim that the classical Windows API is perfect, it is not fully consistent for example, some parts of it could be implemented in a simpler and more readable way, but that's not because the language or the architecture is bad, but because of bad practices in Microsoft and something called backward compatibility, which is a very serious issue for Microsoft. 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" --> You didn't commented this.

    You're mistaken about how Longhorn will work - it won't be based on the existing USER32, and GDI32 components. These are destined to be deprecated because it is no longer possible to extend them in the directions Microsoft want to take the OS - they're reaching the end of their useful life. I wrote another article in this series about Avalon's composition system which explains what the problem with these components is and what's coming next.

    As for the kernel itself (i.e. the bits that run in kernel mode), what does that have to do with application development. You don't write your applications using the DDK do you? As I already said, C is an appropriate language for writing interrupt handlers and other low-level kernel mode stuff. But this doesn't make it the right choice for building a GUI.


    Re: "But why many simple programs written in MFC and in .NET reserve A LOT of system resources and don't free them until the end of the program when Windows walks their heaps and frees it? " --> You didn't commented this. And that's a (strange)fact i observed for a long time.

    I did comment on this fact - I told you that it means you almost certainly have bugs in your code. At least I assumed that you were referring to the examples where you said you saw hundreds of megabytes being reserved.

    Were you talking about something else? What other resources?


    "About the .NET program -> it's certainly a shame to take 14MB of memory doing nothing more than trivial things, it would take a 1 to 2 MB of memory in Win32."

    Who cares? Really? Who cares? 5 years ago, lots of people would have cared. But 14MB is negligible these days. A quick look through my Task Manager reveals that at 14MB, this application is amongst the most frugal of the GUI programs I have running right now.

    What possibly benefit would it have been to me to spend 5 times as long writing the program to get it into a smaller working set? My machine has 510MB of available physical memory right now, so the 14MB that my little program is taking up really isn't hurting me.

    As I have said before, hardware moves on. Back in C's heyday - the 1980s - 14MB was a huge deal - you couldn't even get desktop machines with that much memory. Today, my mobile phone has more memory than that.

    What matters is that things run fast enough, and are cost-effective to build. Sweating over 10MB of memory on a PC application is not a cost-effective use of anyone's time these days.

    (Are there scenarios where 15MB is a big deal? Sure - it matters in embedded systems. That would be a big deal if it were non-paged memory in a device driver. But for a front end app? No - we're long since past the point where it's worth spending a significant amount of effort on trying to reduce it. And in certain cases, it's necessary to support 10 year old hardware because in some market sectors, there's a lot of old kit around. And in these cases, yes, you do have to spend more effort on being frugal. In those cases, the .NET framework is not appropriate. But the simple fact that PC hardware decays means that this becomes a smaller and smaller niche every year. Longhorn is specifically targetting what will be mainstream in 2006/2007 - by that time, circa 1995 machines will be in a tiny minority.)


    "The question - why .NET programs still run too slow on my 2.4 Ghz machine and reserve too many system resources like gdi resources for just a simple operation?"

    This seems bizarre. First of all, .NET programs don't even use GDI. They use GDI+, which is an entirely unrelated component - GDI+ brushes pens etc. are completely unrelated to GDI32 brushes, pens etc. So I really have no idea why your .NET applications are taking GDI resources.

    Secondly, my .NET apps work just fine on my 1.6GHz system, so I really can't explain why they're not working on your 2.4GHz system...

    (Although Outlook, which is *not* written in .NET is pretty slow, and it is currently using 67MB of memory. I suspect that's another example of: it's what your program does, not what language you wrote it in that will dictate its memory usage.)


    "My current Longhorn version performs just really bad on my powerfull machine"

    Of course it does - it's pre-alpha code. None of this stuff has been through any kind of performance testing. Everything in it is slow. You'd have seen the same story from any version of Windows if you looked at such an early release. (It's just that Microsoft have never previously released anything to the public this early in the development cycle.)

    At the PDC where this stuff was first released, they said time and time again that the performance was terrible because they hadn't done any work on the performance yet.

    (Despite this, parts of it are pretty snappy - some bits work better than others. For example, some of the Avalon features let you achieve smoother, faster, and yet richer visual effects than are possible on GDI32 on current verrsions of Windows.)


    "I think some people feel comfortable with one thing and other people - with another, that's a kind of own choice, philosophy, name it whatever you want."

    True. And Win32 isn't going anywhere soon. But Microsoft can't make all APIs the primary API. They have to pick one. And people who try .NET tend to prefer it to C, so it would make little sense for them to keep Win32 as the primary API.


    "I don't accept the notion of "last-ness" also, that is flying on the air with every new product or platform."

    Neither do I. I don't think we'll see the last version of anything until Moore's law ceases to apply. The capabilities of the hardware continue to improve exponentially, so there was no way that Win32 could possibly have been the definitive API, and it therefore seems extremely unlikely that .NET will be either. But Microsoft do want it to be the primary API for the next 10 years or so.


    Incidentally, on the "in the future all Windows funccionality will be provided via COM" thing, this is true for those determined to avoid .NET. The only way you'll be able to access new platform features without writing .NET code is to use interop. And guess how .NET objects are exposed in the Win32 world? COM objects! So for those who choose not to embrace .NET, that statement turns out to be true after all - COM is the only way you'll be able to use new platform functionality.
    • .NET, Windows API and C
      2004-04-02 10:05:42  anatolk [View]

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