WinFX: An All-Managed API
Subject:   .NET, Windows API and C
Date:   2004-04-01 04:50:07
From:   igriffiths
Response to: .NET, Windows API and C

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.

1 to 1 of 1
  1. .NET, Windows API and C
    2004-04-02 10:05:42  anatolk [View]

    • Ian Griffiths photo .NET, Windows API and C
      2004-04-03 05:30:22  Ian Griffiths | O'Reilly Author [View]

      • .NET, Windows API and C
        2004-04-03 19:09:32  anatolk [View]

1 to 1 of 1