Article:		WinFX: An All-Managed API
Subject:		.NET, Windows API and C
Date:		2004-03-24 00:20:30
From:		anatolk
Ok, i'm working intensively with the Windows API for 6 years and i can tell that it's a very good API (for those who strain their brains to understand it), it's simple, elegant and implemented in a simplest programming language that is C. I've never seen something that can't be done with it. I'm watching all this hysteria around new .NET technology and scratching its internals to see where this propagated "simplicity and benefits" of .NET programming sits, but all i find is an unnecessary complexity, obscurity and overhead. And over and over i see the same articles "How to make a color button...", "How to fill a list with values...", "How to get number of drives...",etc. but now with "...using .NET" appended at the end. And what is really bad is that in M$ Windows developers every time need to learn all the old things in a "new way, new paradigm". We've seen OLE, COM, ActiveX, VB way, MFC way, now we see .NET. Now the all cure word is "fully object oriented" and is very tied to things like .NET and Java. Well, OO is not a technology but a paradigm, Windows itself is a fully object oriented system from its beginning, and not to say Windows but even the Presentation Manager, its API is fully object oriented, the NT kernel is also fully object oriented and is written in plain C. The C language is NOT a procedural language, it is a general purpose language and that's why OS-es are written in it. It provides the necessary building blocks for an object oriented system. Its simplicity of programming and power shines more than 30 years. Well, i'm not going to discuss here the birth of "new" technologies(products,"paradigms",etc.) and M$ sales;). I am a hardcore Windows programmer, but what i'm really disappointed now is that i can't see my future in the Windows world az a C programmer(it's a bit paradoxical, since C programmers were most valuable in the OS world). Ok, we now stick with all managable code, but how can a C programmer fit in that world? 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.

Showing messages 1 through 10 of 10.

• .NET, Windows API and C
  2004-03-25 05:50:23  Ian Griffiths | [View]
  
  
  Having written in various different assembly languages, C, C++, and C# (and various other langauges), I cannot agree with your statement that "despite the popular belief there is no such a comparison between assembly language, C and C# for example."
  
  There is a clear progression of increasing levels of abstraction:
  
  

  
  
  • Assembly language maps directly onto machine instructions (and given the way that all modern CPUs are implemented, those are abstractions around what the CPU really does).
  
  
  • C moves away from the specifics of the instruction set, but still provides no significant extra functionality - you're still using the same abstractions of raw memory and basic data types such as int and float. (And of course any decent assembler will also let you define structs.) So the only real level of abstraction that C offers is to take you away from the specific instruction set. It doesn't add anything else. There's a reason it's frequently described as 'machine-independent assembly language' - it provides the same set of abstractions, but in a more or less machine-independent form.
  
  
  • C++ adds some higher-level features. If you want virtual functions, you are no longer obliged to implement the mechanism yourself as you would have to in C or assembly language. Also, if you want compile-time polymorphism, templates can do that rather than having to rely less powerful and more error-prone macro expansions. And because these features are integrated into the compiler, you get much better compile-time static type checking. However, you're still basically dealing with raw memory, which is, significantly, the main reason it's so easy to write code that has buffer overflows in both C and C++ (and assembler).
  
  
  • C# and Java move away from making virtual memory the basic abstraction for how information is stored, moving to a managed, intrisically typed heap. This is hugely important - think how many of the security holes out there today are caused by buffer overflows. Buffer overflow bugs are an artifact of dealing with memory as your basic abstraction. This is one of the key benefits of moving to C# or Java. Of course this means you can't use these languages to write interrupt handlers and device drivers. That's why I would still use C for that kind of code. But that's really all C is appropriate for these days.
  
  
  
  The fact that anything you can do in C# can also be done in C clearly also carries down to assembly language too, so I don't see why you think there's no comparison - it's a clear progression of abstraction: assembler abstracts away from the transistors, C abstracts away from the instruction set, C++ adds abstractions not intrinsically available in assembler, C# and Java abstract away from memory and pointers. And the benefit of this progression is evident in use: just as C usually requires much less effort to get something done than assembly language, so C++ can make things less effort than in C, and C# usually requires much less effort to get things done than C++.
  
  C was the highest level language you could reasonably run back when the Mac and Windows first came out, but this wasn't because C was an ideal language - it's clearly not! Remember that the Lisa, the Mac's predecessor, had already tried to use an object-oriented langauge. (The Lisa toolkit was written in an OO-enabled derivative of Pascal called Clascal.) The Lisa was ahead of its time in many ways, including the attempt to use an OO language before the hardware was powerful enough to support this in real apps. So it *is* about hardware limitations, or at least it was as far as the people who designed the systems you gave as examples were concerned - people recognized the productivity benefits of moving away from the low level of abstraction offered by C 20 years ago, but back then, personal computers weren't up to the job.
  
  Of course you can use an OO style of development in C. I've done this, and it's an experience I'm in no hurry to repeat. It is so much more effort than using a system which was designed to support this style of development in the first place. You can use an OO style in assembly language if you really want to, but that doesn't make it the right technology with which to write a web site. Why on earth would you expend so much effort doing it by hand when there are languages and tools available to do it for you?
  
  Apple would have used an OO language if they possibly could for the Mac. The only reason they didn't is that they already tried that on the Lisa and found it was to heavy to fly.
  
  
  If your .NET windows applications are taking 400MB of memory you are doing something wrong. In fact if they're taking 100MB of memory there's a good chance you're doing something wrong. (Unless you really are working with that volume of data in your calculations, in which case a C application would use just as much memory.)
  
  This is not evidence of a problem intrinsic to the .NET framework, because none of my .NET programs do this. This is much more likely to be indicative of implementation deficiencies in the program(s) you were looking at. It's most likely to be a case of using inappropriate techniques. A different platform requires different techniques. If you wrote code in C that assumed memory was managed in the same way as it is in C#, you'd have a leaky malfunctioning piece of code, and you would be right to accuse the author of incompetence. So why do you leap to different conclusions when you see code doing the wrong thing in C#? Just because it is possible to write code that hemorrhages memory in a particular language doesn't mean it's necessarily the language that is at fault. I can write you a C program that takes 400MB of memory too, but that wouldn't be evidence of a problem in C. It would just be a program that takes 400MB of memory for some reason...
  
  I've got a .NET windows forms application running right now that I wrote. (It's a utility that takes syntax coloured code in RTF format and converts it into HTML.) I'm running the debug build as it happens, and because it's a very simple app for my own use I've never bothered to try and optimize its memory footprint, load time, or execution speed. It is, as you put it "a program consisting of a simple form with a few controls on it and doing nothing more than sitting idle." It's taking 14MB of memory, which is normal. So no, it's not normal for such .NET programs to take 100MB. There's clearly something wrong with the program you're using as an example. And yes, 14MB is more than the equivalent in C would have taken - maybe twice as much. But I have 1GB of memory on this laptop, and it took about 5 minutes to get get the UI working. It would have taken far far longer than that to build the UI in C. (It does automatic resizing of all the content, and interacts with the system clipboard. These are certainly more than 5 minute jobs in C. They are utterly trivial in C#.) The only thing that took any amount of time to write was the RTF parsing - in other words, I was able to devote all my time to the problem at hand, rather than messing about with the vast number of little details required to write a GUI in C.
  
  So it's just untrue to say that even simple .NET applications are implicitly ludicrously memory hungry. They're a bit more hungry, but I certainly don't see hundreds of megabytes getting used by my own applications. If you're using vast wads of memory it's highly likely to be because of what the program is doing, rather than the platform it runs on.
  
  (For example, the RSS reader I use, SharpReader, is using 72MB right now! People sometimes point at SharpReader as an example of how .NET applications use unnecessarily large amounts of memory, but it's a flawed argument. As the guy who wrote SharpReader points out, its memory usage has nothing to do with .NET - it's because he wrote the application in such a way that it holds vast amounts of stuff in memory. If he had written it in C, it would use exactly as much memory, simply because of how it works. As I understand it, it actually loads all the content of all the messages into memory. That's why it takes up lots of space. If you loaded the same state into memory in a C application it would be just as bad. C# applications that don't work with such large data sets don't have such large working sets.)
  
  
  "About the faster machines - on my P4 2.4 Ghz Java runs just as slow as on my P2 300 Celeron, that's all marketing tricks but is seems you and many other people just don't get it."
  
  Marketing? All I see is that my productivity has gone through the roof, and the performance of the systems I work on is good enough. What on earth does that have to do with marketing?
  
  To give you a recent example, I worked on a rewrite of a system from VB6 to C#. It took three months to rewrite the system that had taken 3 years to write in VB, and it runs approximately 10 times faster. We know this because we measured how fast it runs, and we measured how long it took to write. It doesn't get much simpler than that - what makes you think this has anything to do with marketing? It's simple straightforward good business!
  
  
  I was initially highly sceptical when I first saw the .NET framework. Like you I didn't see any obvious benefit gained in exchange for the loss of control.
  
  But then I actually tried using it. With an open mind. After one project, I realised I had been wrong. Now, many projects down the line, I won't use C++ unless I have a particularly good reason to. (And certainly not C - why on earth would I want to invent my own idioms for object orientation that the compiler doesn't understand, and can't type check? I have better things to do with my time!)
  
  With all due respect, it sounds an awful lot like you've not tried writing a non-trivial project in C#, so your opinion is not informed by experience. (You talked about a project porting a VB application to .NET - that's always going to be a problematic thing to try and do because VB and VB.NET use a different set of abstractions. This is going to be about as easy as porting an ADA program to C - you'd have loads of problems doing that too, but would you use that as an argument against C? And you cite "finding obscure bugs" as one of the problems - I don't think you could honestly say to anyone that C programs never suffer from obscure bugs and expect them not to laugh in your face.)
  
  What's all the more remarkable is that all the arguments about not reinventing stuff and having things done for you which you put forth in favour of C are arguments that I would use in favour of C# - all the same things apply, but *much* more so because C# and .NET do so much more for you than C and Win32 ever did. I use both .NET and Win32 regularly, and believe me, when programming against Win32 you spend *far* more time doing things which in .NET are done for you. And a lot of it is down to the higher level of abstraction provided by the platform - you simply couldn't have all the things that C# automates automated in C, because it would be incompatible with C's "everything is bytes stored in memory" level of abstraction.
  
  "I've seen a very complex but briliantly written programs on plain C. One example is the Mosaic code. And i've seen a really sloppy programs written in C++, Java and C#"
  
  Sure, and I've seen lots of incompetently written C and lots of great C++, Java and C#. Such an Bad code is bad code, good code is good code. What does that have to do with choosing a language?
  
  Assume for a moment that we're going to write good code. Doesn't it then make sense to choose the platform and language that gives us the best productivity? I've tried C, C++, Java and C# - I've written substantial amounts of code in all of these languages on a variety of platforms and systems - Windows, Unix, Mac, and various embedded systems. C# and Java blow the rest away when it comes to productivity. You almost invariably end up writing far less code to get anything done. Less code means less initial work, fewer bugs, and lower maintenance costs.
• .NET, Windows API and C
  2004-04-13 15:48:48  Eric_Mutta [View]
  
  
  Your post was an interesting read. Hope you dont mind me throwing in my 1.3 cents (inflation adjusted 2 cents)
  
  (Unless you really are working with that volume of data in your calculations, in which case a C application would use just as much memory.)
  
  This is not entirely true, because C data types don't have as much overhead as some C# data types. E.g if the volumes of data were being represented by many individual objects, you pay (N * MinimumObjectSize) more in C#, ontop of the cost for the actual data itself.
  
  I've got a .NET windows forms application running right now that I wrote. (It's a utility that takes syntax coloured code in RTF format and converts it into HTML.)...It's taking 14MB of memory, which is normal.
  
  14MB for that kind of app is normal? Hmmm. I have a copy of Visual Studio.NET open on a C++ project with a hundred or so files. 20 of those files are open in the editor which does syntax colouring, code folding, smart indenting etc. All that along with the VS.NET GUI itself and its only using 16MB.
  
  I have Adobe Acrobat Reader running within Netscape 7. Its rendering a 44 page PDF file complete with coloured fonts and some graphical elements. Total memory consumption? 20MB...This tells me that "a utility that takes syntax coloured code in RTF format and converts it into HTML" and consumes 14MB is definately not normal.
  
  (It does automatic resizing of all the content, and interacts with the system clipboard. These are certainly more than 5 minute jobs in C. They are utterly trivial in C#.)
  
  No - utterly trivial in .NET. You are comparing frameworks to languages. How long would the app take to build using the C subset in Managed C++? ;)
  
  To give you a recent example, I worked on a rewrite of a system from VB6 to C#. It took three months to rewrite the system that had taken 3 years to write in VB...
  
  Well, if you are rewriting a system you cant expect it to take the same time it took to write the system initially can you? Naturally it would take shorter because the design, algorithms etc are already in place and you are not starting from scratch, so the comparison of 3yrs to 3 months doesn't mean much.
  
  You almost invariably end up writing far less code to get anything done. Less code means less initial work, fewer bugs, and lower maintenance costs.
  
  Amen to that :-)
• .NET, Windows API and C
  2004-03-25 15:31:21  anatolk [View]
  
  
  "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.
• .NET, Windows API and C
  2004-04-01 04:50:07  Ian Griffiths | [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.
• .NET, Windows API and C
  2004-04-03 05:30:22  Ian Griffiths | [View]
  
  
  Quoting from Apple's Introduction
  to Mac OS X Development Technologies here's what they say about Carbon:
  
  "The Carbon environment provides fine-grained procedural APIs in C and C++ that are intended for developers who are migrating applications from classic Mac OS to Mac OS X."
  
  They go on to identify Carbon as being primarily for use when you need to support both Mac OS 9 and Mac OS X.
  
  But they describe Cocoa first, and they describe it in much more glowing terms. Anyone new to Apple development reading that page would inevitably think that Cocoa is the best way of developing for OS X, and that Carbon is for migration of existing code, and backwards compatibility with OS 9.
  
  The message from that page - the page where Apple sets out its developer technologies for those new to Apple - is clear: Carbon is there as a link to the past. A fully-supported and powerful link, but wholly rooted in the past nonetheless. What were you reading that gave you a different impression?
  
  "They just don't force their developers to learn the same things in a new way, loosing productivity"
  
  This seems to be a theme in this thread - you always seem to equate 'learning new things' with 'losing productivity'. In my experience this is often not the case. Learning new ways of doing things often helps you do things more efficiently. The .NET Framework is a case in point.
  
  (This reminds me of a talk given a while back by David Chappell. Someone asked him if .NET was the last time Microsoft were going to ask developers to learn new stuff. He replied saying "If you can't stand change, get out of the software business.")
  
  
  
  "I think all necessary features are present in C to produce any kind of code, it's just about good and bad API design. "
  
  There are several reasons that this just isn't true. To pick a couple:
  
  (1) C doesn't have strong typing. Last time I checked, casting anything to (void*) was still legal - C's static typing is entirely optional. Strong typing is fundamentally important to .NET's security system - the ability to use the new styles of deployment in .NET (where you can get all the benefits of web-style deployment with nothing more than a URL, but also retain the benefits of a rich client-side windows program) would be worthless if the .NET framework wasn't able to verify that the code it is running sticks to the rules. (You may have heard of 'unsafe' code where you can still use pointers. This exists, but it's not allowed in this style of deployment - such code will be rejected by the .NET framework.)
  
  So standard C is not usable for the 'smart client' deployment, one of the key features of .NET.
  
  (2) C does not embed type information in executables. Many features of the .NET framework rely on the availability of type information. For example, serialization, remoting, designer integration, XML type mapping.
  
  Of course it's possible to do all of these things by hand in C. But to provide these facilities automatically an API needs access to information about the methods or data structures you are using. C's lack of support for access to type information at runtime means any API providing these facilities would require you to reenter all that information in some format it could access. This doubles the effort (e.g. you have to define methods in IDL as well as in C if you're using Windows RPC), and opens opportunities for inconsistency - if you have two representations, it's possible for them to get out of sync.
  
  There are others, but I'm not trying to provide a comprehensive list - I'm just pointing out that you are mistaken to "think all necessary features are present in C". They are not.
  
  
  "you can wrap [Win32] in any language, any platform and provide a very high level user funccionality and that's why we have VB, Delphi and current .NET. that make it really easy to write a user app"
  
  Actually I think VB's ease of use is somewhat misunderstood and in some cases overrated.
  
  VB makes some things very easy. It actually makes some other things extremely difficult. The last time I was doing any VB6 development, I ended up writing a few ActiveX controls in C++ because VB wasn't well suited to the task at hand.
  
  The fundamental problem with VB is that it presents its own set of abstractions which are quite different from how Windows really works. These abstractions make life much easier but they also restrict you.
  
  So prior to .NET you had a choice - lots of effort but plenty of power in C or C++, of massively reduced effort in VB but less power.
  
  If you've had similar experience, I could understand why you might think that easier environments are necessarily less powerful. In fact that was pretty much what I felt after using VB6 for a while - I thought that the Win32 API was the only way to get certain things done.
  
  But now that I've been using .NET for the last 3 years, I've realised I was wrong. The limitations were specific to VB6 - it simply chose to present limited abstractions. But of course you could equally choose to present limited abstractions through a C API... The power isn't a function of the language as such.
  
  The power of the facilities provided is in fact independent of the style of API used to present them - the .NET framework shows very convincingly that you can provide an API which is both easy to use and powerful. (And obviously you could provide one that is hard to use and weak...)
  
  
  "With Longhorn if i want to write plain C code with a simple C compiler i can't, i should stick with an irritating hybrid known as "Managed C++" and COM"
  
  Actually that's Managed C++ OR COM. You wouldn't use both.
  
  
  "which is a good concept but highly complex to write even a simplest thing"
  
  I think you're just talking about COM here - is that right? But as I said, use of Managed C++ lets you use the WinFX APIs directly from C++. And if you think the WinFX APIs (which are a superset of the .NET Framework) then either you were doing something wrong, or you haven't really tried.
  
  
  I said: "You're mistaken about how Longhorn will work - it won't be based on the existing USER32, and GDI32 components."
  
  You replied "Did i mentioned that Longhorn would use USER and GDI somewhere???"
  
  I certainly seemed like you did. You said this:
  
  "My own opinion is that the basic modules kernel, user and gdi are an example of a good (commercial) OS implementation. As you can see the kernel of NT systems is excellent and that's because it's written consistently and with a smallest amount of backward compatibility, that's why Microsoft will build even their new Longhorn system on that kernel"
  
  In fact you drew attention to it when I didn't reply to it first time round.
  
  I took this to mean that you thought Longhorn will build on the basic Win32 modules "kernel, user, and gdi", as you called them. (kernel32, user32, and gdi32, is what I presume you are referring to.)
  
  In fact Longhorn does not build on user32 and gdi32 - it replaces them with something else.
  
  Given the flow of the first two sentences, it looked like you were using 'kernel' to describe the core pieces of the OS rather than necessarily just the bits that run in kernel mode. But maybe I misunderstood, and you did actually mean the bits that run in kernel mode, although if that is the case, it's somewhat unclear from the way you wrote it - it makes the second sentence a big non-sequitur.
  
  But if you did simply change subject without warning, from kernel32,user32,gdi32 in the first sentence to the kernel mode parts in the second sentence, I still can't fully agree. Remember that large amounts of the UI handling in Windows are in the kernel. These parts of the kernel are being replaced in Longhorn.
  
  It's true that other things like handle management and IO will remain largely unaltered. The scheduler is being modified to support certain multimedia features not possible on today's versions of windows, but it is an incremental change on the existing scheduler. But so what? You don't program against the kernel mode APIs for anything other than device drivers.
  
  C is an appropriate language for writing an operating system in. (As is C++.) But that doesn't mean it's an appropriate language for everything - far from it. The whole point of an OS is to abstract away the raw grungy details of hardware handling, memory management, and IO. Seen in that light, it seems like madness to use the same language in user mode as in kernel mode. That's akin to using a hammer for every job!
  
  
  "I speak about very simple programs written in .NET, they could not be compared in any way with Outlook, they just show the performance overhead of .NET."
  
  But simple programs take just 10-20MB. (And that's before you do any optimization.) That's also the whole working set, and remember that some of that will be .NET Framework DLLs which get mapped between processes. And in my experience they run just fine.
  
  If you're going to get obsessed with memory, where do you stop with reducing the memory footprint? Win32 isn't all that lightweight by the standards of 10 years ago, so these arguments you raise of .NET vs Win32 all apply to Win32 vs. Win16! Back then consumer PCs had to run something lighter than Win32. Now, the fact that it takes several megabytes to run hello world in Windows is not a big deal because a PC ships with hundreds of megabytes as standard, rather than the few megabytes that were standard a decade ago.
  
  
  "Will my productivity be boosted? By the possibility of rotate windows around???"
  
  That's a pretty specious argument. Just because you can do frivolous things doesn't mean the whole system is frivolous. Picking an arbitrary feature and poking fun at it while ignoring the rest isn't a robust style of critique.
  
  After all, Windows 2000 supports transparent windows, and some would argue that those are just so much chrome, but you're happy with Windows 2000's performance.
  
  The key is whether your productivity is enhanced by the platform. Will spinning UIs help you? Probably not (unless you're building presentation applications). But will the ability to get a job done in far fewer lines of code improve your productivity? Will your productivity be improved by working on a platform which detects whole classes of errors for you and reports them, rather than just plodding on after an error has occured until a crash happens some time later like C does if you mess up your pointers?
  
  I don't know anyone who's tried a non-trivial project with .NET who didn't find it to offer substantial productivity enhancements. I know lots of people who have tried it successfully. (And none of them had much use for spinning windows around.)
  
  
  "Or i would be writing a document and making a spreadsheet in a 3D space????"
  
  This is a common misunderstanding about what's meant by the so-called '3D' nature of the Avalon UI. It's not really a 3D UI at all, it simply exploits the 3d acceleration hardware. The UIs are still 2D. Unless you use DirectX. (Just like with Win32 today in fact! But faster because the system exploits the fastest parts of the GPU for both 2D and 3D work, unlike Win32 today.) See my article on Avalon graphics in this series or on MSDN for more details. (Right now Google finds these as the first two hits searching for: Avalon Graphics.)
  
  
  "I even disagree with the concepts of the new UI design, it's irritating."
  
  Microsoft haven't actually released Aero, the new UI for Longhorn yet so I'm not quite sure what exactly it is you're disagreeing with! Any screenshots you're likely to have seen for Longhorn are all for the developer preview, which contained a slightly odd hybrid UI - mostly a modified Windows XP ui with a few experimental features added.
  
  
  "The UI of Windows (and Mac, and OS2,etc.) is a great success because 1.It is consistent."
  
  Actually I disagree with that, but that's a whole other topic. There are multiple different standards for keyboard shortcuts, and even for cut and paste! There is inconsistency across windows applications on things like where configuration settings go on menus, how to navigate around multi-window UIs and so on...
  
  The Mac seems even more inconsistent when it comes to keyboard navigation through text - every text editing widget seems to have its own minor variations on which keyboard modifiers do what.
  
  
  "Are you sure that the .NET you see today would be the primary API for the next 10 years? "
  
  Yes - it's very clear that this is the message Microsoft are sending out to everyone: .NET is where new features are going to be added. The only thing that would stop it would be pushback from the developer community. But the reaction from developers has mostly been very positive - you are very much a minority voice.
  
  
  "Another "paradigms" will raise and .NET will be another "legacy API","
  
  Sure. Eventually. Just like every other API before it. But Microsoft don't push out new APIs for fun - it's expensive and difficult.
  
  On past experience, APIs tend to last a little over 10 years before they start to look outmoded by the evolving capabilities of the hardware. Win16 was around for approximately that long. Win32 has been around for roughly that long. So yes, I'm sure .NET is likely to have been relegated to 'old stuff' by 2020. But I don't agree with your reasoning:
  
  "it's all about business, not about technology or preferences."
  
  I think it is about technology and business. Win32 was too heavyweight for 1980s PC technology. .NET was too heavyweight for the average 1990s PC. Typical PCs in 2010-2020 will likely make it possible for the OS to provide a range of facilities on our behalf that make .NET look cumbersome, and Win32 positively stone-age.
  
  Of course it's about business too - new technologies are adopted because they offer a business benefit - improved return on development spending in this case. But the business benefit is enabled by a technological advance.
  
  
  "It is really bad that all new funccionality will be provided to C programmers through COM. "
  
  Fortunately, hardly anyone is using C any more. So for most people, the move to an OO API is a big step forward. It means the API uses the same level of abstraction that they've been using in their own programs for years. This extra work is the price you will pay for using C.
  
  But then as a C developer you're already used to working far harder to get something done than a .NET developer. ;-)
  
  
  
  "the new Longhorn API would restrict freedom of programming, not utilize existing programmer's knowledge"
  
  You could apply the same logic to any change of technology. But the only reason people adopt these new technologies is because they believe they offer benefits.
  
  Microsoft really isn't in a position to force the use of a new API - if the developer community had simply rejected .NET, and carried on using Win32, Microsoft would have had no choice but to carry on making Win32 the primary API. After all, while Microsoft are effectively in charge of what OS gets installed on PCs because of their monopoly on the client OS, they are *not* in control of how people write Windows applications. They're free to introduce new APIs, but they can't make developers use them. Indeed there are plenty of APIs introduced by Microsoft over the years that didn't achieve widespread developer acceptance.
  
  Nobody forced any organization to use .NET. Companies are using .NET because they saw that it offered an advantage over using Win32.
• .NET, Windows API and C
  2004-04-03 19:09:32  anatolk [View]
  
  
  "Quoting from Apple's Introduction" - Yes, that's the introduction. Reading more and deeply in MacOS X documentation you'll find that Apple's firm state is that they will mantain 3 API's for their OS - Carbon, Cocoa and Java and that Carbon is the primary API for the OS containing its full funcionality. That's the difference between Longhorn and Mac OS X - in Longhorn the new funccionality will not be provided via classic Windows API's, it will only be provided through managed API's. That is certainly not the case with Carbon. Carbon is not considered a legacy API. And of course it will be a bridge between classic Mac and new Mac OS X, but will continue to provide every new OS funccionality in a consistent manner via toolkits. You can choose between plain C, Objective-C and Java languages and you are not in trouble if you want to exploit the OS funccionality through one of those languages. It is certainly different from what Microsoft will do with C programmers (it seems many people these days don't distinguish between C and C++, when i say C i mean C, not C++!). From what i see there is no way to use the Longhorn API from C (mean C!), if there is a way please tell me about it (except for the COM way which can be used from plain C, but i don't want to discuss it again).
  
  'learning new things' with 'losing productivity'. In my experience this is often not the case. " - Well, for me it is just the case. I've spent many years on learning how to program for Windows and i don't want to relearn the same things again in a new fashion. I just don't want to learn again how to write a "Hello world" application, that's a regression, not to say humiliation. My productivity will be degraded for a long time. For me as a C programmer its worth to go down to device driver writing than to new user code.
  
  About C - Well, there are many good books and proffesionals which state just what i said. C is a huge success and it was used for 30 years not just for writing OS-es but for any kind of application development and since you can make anything in C it is also dangerous, it is designed to give freedom and not to restrict the programmer in any way, it is considered that the programmer knows what he is doing. And since you can easily do something wrong writing in C C programmers tend to be very careful. And that produces good programmers.
  (1)"C doesn't have strong typing" - of course, it shouldn't have strong typing! I would say that's a great feature of C and very useful in a miriad of situations.
  (2) C does not embed type information in executables - that's entirely unrelated to the language.
  "Of course it's possible to do all of these" - of course it is. So every time i discuss those problems with people we end up with this - it's all about certain degree of effort. But C# and C can't be compared that way. C is, as i would say, a mid-level language and C# is a very high level language. C is designed to be small, it could contain as many features as you want, it could be binded to some platform, but that is not the goal of the language. Denis Ritchie gives very good explanations on that subject. C was designed also with platform independence in mind. And that's not what these days many people think about platform independence. C is platform independent at source code level, not at binary level (like Java that should port all the runtime platform to be able to execute and executes bad and can't exploit the full OS funccionality, leaving the user with poor experience). There are many advantages of source code level independence over binary independence.
  
  "Actually I think VB's ease of use is somewhat" - i agree with all you said about VB, i highly appreciate .NET programming model over VB's.
  
  "which is a good concept but highly complex to write even a simplest thing" - yes, i was talking exactly about COM.
  
  About kernel, user and gdi - i will make it clear:
  
  "My own opinion is that the basic modules kernel, user and gdi are an example of a good (commercial) OS implementation - i mean that those modules are well designed (using such a simple language as C is) as building blocks of the OS.
  
  Microsoft will build even their new Longhorn system on that kernel" - i mean that the Longhorn kernel will build right on the NT kernel code, because as i said it is excellent and very expandable (and is an example of how a good design can make a successful and long-lived software)
  
  "Seen in that light, it seems like madness to use the same language in user mode as in kernel mode" - I can't see any madness programming through the Windows API, i'm not bored, not frustrated. Of course it is somewhat hard at the beginning but isn't it with any beginning? I see consistency in that knowing to write device drivers it is a very short learning curve to write user mode applications and viceversa which is good, i think. The classic API is a great paradigm, very logical and easy. The fact that there are bad designed API's in Windows does not make the whole paradigm bad, or the C language bad. The basic API's are well designed and easy to use. Well, many people scream about inconsistencies in programming models inside the OS or naming API elements, just to mention a few. Really, there are many inconsistencies, but there are many reasons for that, among them history, backward compatibility, unclear naming conventions, different teams working on different parts of the operating system,etc. Let's take the windowing API elements for example: looking at the windowing API we see that it is object oriented, but it looks somewhat messy. Why, for example, all functions, structures, constants aren't prefixed to indicate that they belong to certain part of the OS? Well, back in the days of the Presentation Manager we see that they've done it just that way. All windows functions are 'Win'-prefixed. But building Windows Microsoft decided that the whole OS could be viewed as an object, so there is no need to prefix core OS elements. But Windows evolved enormously over time, there are plenty of API's, and now we think it would be better if Microsoft just prefixed all different API's in a consistent manner and produce a highly good looking API.
  
  About the new OS look and desktop features - i was speaking as a user, not as a developer. As a user i just want to write a document, not to distract myself with flying windows over the desktop. If i want to play a game i would start and play it and my action will be totally unrelated to the desktop UI.
  
  "until a crash happens some time later like C does if you mess up your pointers?" - well, i just don't mess my pointers. If i mess pointer i would not dedicate to programming.
  
  "It's not really a 3D UI at all, it simply exploits the 3d acceleration hardware. The UIs are still 2D" - i was abstract in saying 3D,the statement is not related to current Longhorn UI implementation, it's just a tendence and a very discussed subject.
  
  "There is inconsistency across windows applications on things like where configuration settings go" - Well, after all it's a choice of the developers, but since the beginnings of Windows Microsoft were very consistent in making their own products. And i was speaking not about choosing where to put a menu or choosing between accelerators, but about the GUI itself - windows, buttons, menus, scrollbars. listboxes, etc. Their look is very consistent and not distracting.
  
  About API's over time - i think the often given comparison example of Win16->Win32 and Win32->.NET is just very unsuitable. Win16 and Win32 is the same API, it is just a transition from 16 bit to 32 bit code, the API remains the same, internally of course some things change to suit the 32 bit processor architecture, but in fact you work with the same API. Now we are not moving to another processor architecture, the API changes dramatically and that transition could not be compared at all with the transition from Win16 to Win32!
  The 64-bit Windows architecture is not changing the classic API much.
  
  "Microsoft are effectively in charge of what OS gets" - Microsoft lost the war on server side systems. Now most of server side systems are UNIX-es or flavours of UNIX. Linux is moving quickly ahead as a preferred desktop operating system, especially in Europe, Apple is bringing their ever advanced solutions in reasonable prices now. Microsoft should be very careful in that situation.
• .NET, Windows API and C
  2004-04-04 09:03:39  Ian Griffiths | [View]
  
  
  "Carbon is the primary API for the OS"
  
  Can you link to a specific page that says this? Google for:
  
  Mac "OS X" "primary API"
  
  and the only thing that Google finds that says Carbon is the primary API is your message in this thread! As far as I can tell you're swimming against the tide.
  
  I've also gone further than the introductory page with apple docs - I've got a little experience of writing OS X apps, and I've not come across anything that backs up what you're saying. The main reason I pointed to the introductory page is that it's a place where Apple set out how their various APIs fit into the overall picture.
  
  The closest Apple seem to get to supporting your opinion is that in some places they describe Carbon as being of equal important to Cocoa. I've not found anywhere that says it's the main API, and as I've already shown, there are places where it's indicated as being the 'backwards compatibility' API, and where use of Cocoa is encouraged.
  
  But I'm not an Apple expert - I'm just going on what I've seen. I'm happy to accept evidence that I'm wrong if you can supply it. So can you provide a link that backs up what you're saying?
  
  
  But anyway, yes, in general in Longhorn, C is not necessarily going to supported as a means of using new functionality other than via COM. They will probably choose to provide some new C APIs, but even before .NET, many new platform features like XML support and HTML display were not directly supported C except through COM, so this is likely to continue. But then the number of people using C in Windows is so small these days that it's more or less an irrelevance. The Win32 API may be C-based but most people who use Win32 directly are accessing it through C++.
  
  However, I think you're being unnecessarily picky in rejecting managed C++. If you really want to write procedural code in managed C++ you can. This is one of C++'s explicit design goals: to support multiple programming paradigms. So if you want to write C++ that looks indistinguishable from C (indeed, which will compile as both C++ and as C) you can.
  
  So you can write procedural code that has direct access to the Longhorn APIs. And if you really want to, you can even carry on using Win32 APIs from this code, only using the new non-procedural Longhorn APIs when there is no Win32 alternative.
  
  
  
  "Well, for me it is just the case. I've spent many years on learning how to program for Windows and i don't want to relearn the same things again in a new fashion"
  
  Well you're out of luck then.
  
  Surely you don't expect the rest of the industry to stick with old-fashioned tools that the vast majority of developers find less productive just because you don't want to learn something new?
  
  If you're not prepared to learn new things then computing probably wasn't a great career choice. If you're lucky, you'll be able to carry on making a living in niches where C is still used, but even in low level stuff like device drivers and embedded systems, C++ is increasingly being used instead of C. (In fact C++ was starting to become popular for NT device drivers even back when I was last writing them in 1997.) But as far as mainstream programming is concerned, the reality is that things move on. If you aren't prepared to move with them, then that's your choice, but you can't expect the rest of the world to stay still for your benefit. By choosing not to learn you are choosing to leave the mainstream. Moreover, C++ is gradually moving into a lot of what used to be C's niches, because its multi-idiom support goes hand in hand with its 'you only pay for what you use' philosphy, which means that C rarely offers any advantages over C++. So you may find it increasingly difficult to find someone who's prepared to pay for the low productivity C offers.
  
  Good luck, though.
  
  
  
  "(1)"C doesn't have strong typing" - of course, it shouldn't have strong typing! I would say that's a great feature of C and very useful in a miriad of situations"
  
  And it's harmful in a great many more. I see you've ignored the security aspects of this that I raised. This lack of strong typing is fundamentally incompatible with the new security models offered by .NET, and as a result you are effectively ruling out certain styles of deployment by sticking with C. This is one of the main reasons .NET (much like Java) enforces type safety.
  
  Do you consider security not to be important?
  
  
  
  "(2) C does not embed type information in executables - that's entirely unrelated to the language."
  
  Are you telling me there's a version of C that does embed type information in executables? This is something that the C# compiler, VB.NET compiler, and Java compiler all do. To be sure, in .NET it's also a platform feature - this is somewhere the language and the platform meet. But it's also tightly coupled to the language - a language's type system has to support the features to enable a mapping. (And it is technically possible for a language not to use classes at all. In fact you can write a managed C++ program that doesn't define any classes at all - as always with C++ you are free to limit yourself to the C style. It's just that you won't be able to use APIs which depend on using your type information.)
  
  Moreover, long before .NET chose to make reflectable type information mandatory, there were loads of languages that supported reflection, and which ran on systems where reflection was not a fundamental platform feature.
  
  So I don't think it's remotely accurate to say it's not a language feature.
  
  
  
  Me: "Of course it's possible to do all of these"
  
  You: "- of course it is. So every time i discuss those problems with people we end up with this - it's all about certain degree of effort. But C# and C can't be compared that way."
  
  Why can't they be compared? In cases where either language can be used, then they can be compared.
  
  C# makes things much less effort than C. There are some cases in which C# cannot be used (e.g. device drivers), but in the kind of software that most people are writing for Windows today, you have a choice, and it'll take less time to write in C#. In what sense can you not compare?
  
  
  "C is platform independent at source code level"
  
  Hardly. And definitely not if you're using Win32.
  
  C is only platform independent if you don't use anything outside the standard library APIs. And even then it's not necessarily portable because not all environments are required to support the full library. (Embedded systems for example.) So you only get platform independence if you never interact with the platform.
  
  But of course, most code has to interact with the platform, so in practice about the only code that is truly portable is something which implements some algorithm, and which has to be integrated into a larger system before it can actually be used. (E.g., code that implements some image processing algorithm.)
  
  In practice most programs interact with their platform a lot. And in some applications, you do practically nothing but interact with the platform. C code which uses the Win32 is in no way platform independent - it depends on the Win32 platform. So you seem to be making a pretty irrelevant academic argument here.
  
  
  "i mean that the Longhorn kernel will build right on the NT kernel code, because as i said it is excellent and very expandable (and is an example of how a good design can make a successful and long-lived software)"
  
  OK, but of course the kernel doesn't actually present a C API to user mode. The kernel's user mode API is undocumented, and revolves around using the INT instruction. So this doesn't seem like an argument in favour of C APIs. NTDLL.DLL wraps this in a C API, but C isn't the fundamental way of talking to the kernel. That's just a wrapper to enable you to call into the kernel from C.
  
  As for the insides the kernel, it is written in a mixture of C and C++. But only because when writing in kernel mode, you have to be able to work with raw memory rather than strongly-typed data, because a large part of the OS's responsibility is dealing with raw memory. This is not a strong argument for using C in user mode. This is a good example of where C's weak typing is useful, but it is useful here specifically because
  of the kinds of things OS kernels have to do. This doesn't carry through into application development.
  
  
  "I can't see any madness programming through the Windows API"
  
  But as is now obvious, you've not given the alternatives a fair try. After any signficant .NET experience, going back to Win32 makes you realise just how much extra work a C-style API makes you do. You spend so much longer dealing with issues that have nothing to do with the problems your application is trying to solve, and are entirely down to the hoops C makes you jump through.
  
  If you could be bothered to learn the new ways, the madness of Win32 would become immediately apparent to you.
  
  
  "The classic API is a great paradigm, very logical and easy."
  
  Win32 is actually pretty inconsistent. (Mainly because it contains a mixture of stuff from different backgrounds - some from Win16, some from BSD sockets, some from the original NT team that pre-dates Win32.) So it's not as logical as it could be. .NET doesn't suffer from this mixed background - it was starting from a clean sheet. Moreover, Microsoft expend a lot of effort to try and keep things as consistent as possible in .NET - far more than they ever have with any previous API technology.
  
  And 'easy' is relative. It's certainly a lot easier to write a C Win32 application than it is to write embedded code. (I know - I've done a lot of both.) It's also a lot harder to write a C Win32 applciation than it is to write a .NET application.
  
  
  "About the new OS look and desktop features - i was speaking as a user, not as a developer. As a user i just want to write a document, not to distract myself with flying windows over the desktop."
  
  Again, you are focusing unnecessarily on graphical flashiness. That's really beside the point - it's not illustrative of the broader benefits. I think you may have been misled by the eye-catching demos.
  
  The new presentation stuff is very nice for those who have to do high-quality presentation, and irrelevant for everyone else. But the benefits of the .NET platform go far beyond the quality of presentation it will be possible to achieve. Indeed even within the presentation layer (Avalon) there are substantial productivity benefits to be had even if you use extremely dull visuals.
  
  One of the biggest practical benefits of Avalon is how easy it makes things. How many lines of code do you think it would take you to write an application which displays an RSS feed's content in C? Your target to beat is 0. That's right - you can write an RSS reader in 0 lines of code in Avalon:
  
  Codeless RSS - just markup
  
  This illustrates how easy it is to build a UI declaratively that consumes and presents an XML data source in Avalon. (Other data sources are supported too of course.) For me, this is a much better indicator of the developer productivity benefits of XAML than any number of flying windows. And it's a breeze to start adding programmatic functionality to this - everything you see described in the markup as accessible as an object, so you can just start writing stuff to manipulate the UI directly.
  
  It'd take you days to get this same work done with Win32.
  
  And this ultimately benefits the user too: improved developer productivity means more time can be spent making the application do what it's meant to do, rather than dealing with the minutiae of C and Win32.
  
  Productivity is the key. That's the main benefit of the .NET platform. Flashy UIs make for entertaining demos, but the producivity enhancements are ultimately what make it a better platform for writing software.
  
  
  "well, i just don't mess my pointers. If i mess pointer i would not dedicate to programming."
  
  And how much time and mental effort goes into that? Lots, if you're a conscientious programmer - writing high quality C code requires both skill and effort. But why waste all that energy when you can use a platform that means this work is entirely unnecessary?
  
  Consider this analogy. Insisting on carrying on managing your own memory and dealing with pointers is more or less equivalent to maintaining an evolving web site entirely by writing HTML by hand. Of course you can do that - writing HTML is dead easy and any fool can do it. But if your site changes much at all, and you want any kind of navigability, you end up doing a lot of monkey work maintaining that HTML by hand. It's much less effort to automate those things that can be automated.
  
  Of course it's possible to do all that work by hand. But it's just dull monkey work.
  
  The same is true for pointer management. The .NET Framework or the Java Virtual Machine can do that for you, so there's no need to do all the monkey work by hand.
  
  Why do you want to do monkey work? (And even if you like it, why would your employer pay for you to do work that can be wholly automated if you use the right platform?)
  
  
  
  "About API's over time - i think the often given comparison example of Win16->Win32 and Win32->.NET is just very unsuitable. Win16 and Win32 is the same API,"
  
  Not really - there were fundamental platform shifts. Several programming practices that worked fine under Win32 stopped working. There were plenty of superficial similarities, but it's really stretching things to far to say that they were the same.
  
  
  
  I wrote: "Microsoft are effectively in charge of what OS gets"
  
  You replied: " - Microsoft lost the war on server side systems."
  
  I see you've now taken to truncating my sentences to change their meaning. In the original context I was talking entirely about PCs and client OSs. You've chopped off the sentence at the point at which that became clear. And the main point that I was making was that Microsoft isn't in charge of which APIs developers use, despite their monopoly position. So you've deliberately more or less reversed the sense of what I actually said there.
  
  If you're going to resort to that kind of thing, I don't see much point in continuing this conversation. In any case, I don't think we're covering any new ground now. You clearly have no intention of learning these new technologies, and are apparently aware of the likely career-limiting consequences of this, so I think there's little more to discuss. I wish you good luck in your quest to cling to C. I fear you will need it.

• .NET, Windows API and C
  2004-03-24 02:51:31  Ian Griffiths | [View]
  
  
  Hi!
  
  I've been working with Win32 for about 10 years now, first using C and then C++. It is, as you rightly point out, a powerful API, but I think you also nailed it when you said "for those who strain their brains to understand it"
  
  Is it really the sign of a good API that you have to strain your brain to understand it? Is my time as a developer better spent dealing with complexity in the API, or improving the functionality of my applications?
  
  You say that you've "never seen something that can't be done with it" but then isn't that true of assembly language? Why are you writing in C when you could be writing assembly language - after all there's nothing that can't be done in assembler, and C adds overhead. (Overhead is one of the complaints you say you have about the .NET framework. So if overhead is that much of a problem to you, you really shouldn't be using high level languages at all, since you can only truly minimize your overheads by writing in assembly language.)
  
  Of course the reason we use higher level technologies is that we get an improvement in productivity in exchange for the increase in runtime overheads. You have clearly already bought into this to some extent because you use C. So why do you reject the exact same tradeoff when looking at .NET?
  
  You also say something which is, quite frankly, beyond belief: "all i find is an unnecessary complexity, obscurity"
  
  If you really think that using .NET is more complex and obscure than Win32 then I find it very hard to believe that you've really used both. (It doesn't sound like you've even tried to 'strain your brain to understand it' even though you were happy enough to put that effort in for Win32.)
  
  Would I be right in thinking that you've never been through a complete product development cycle in .NET? Your reaction is typical of someone who is familiar and happy with Win32 and who hasn't tried .NET in earnest yet, and has merely played with it a little and decided that it is not to their taste.
  
  I've been using .NET for years now. (I started back in the beta days.) I still do C++ development in Win32 reasonably frequently though - sometimes my customers need code to run on non-.NET systems. And every time I have to go back to Win32, I am amazed by how much more effort it is. Everything takes about three times longer than it would have done in .NET.
  
  (To give you a few specific examples I came across in a recent project: making an outbound HTTP request and parsing the text that came back; extracting a list of cookies from an incoming HTTP request; getting a piece of work called on a thread pool thread. All of these things are substantially more complex and more error prone in the Win32 world than in .NET. Of course you can do all these things in Win32 (or IIS) but it just takes a whole lot longer.)
  
  And I'm not the only one who finds this - I know lots of people who work with both technologies and they have all found the same thing. .NET is simply way more productive than Win32 was. The only people I know who prefer Win32 are people who've never written a real product in .NET.
  
  (And by the way, Win32 isn't going away. It'll be there for ever even though it will cease to be the primary API. It's just that new OS functionality will be targetted primarily at .NET applications. Win32 applications will still be able to use new features, they'll just be required to go through an interop layer to use them. But because C and Win32 have much higher development costs than .NET coding, they will become increasingly marginalized. Just like assembly language, they will still have their place, but it will be an ever smaller niche - as machines get faster, the performance benefits offered by these low-level technologies cease to justify the increased development costs.)
• .NET, Windows API and C
  2004-03-24 09:57:04  anatolk [View]
  
  
  Well, despite the popular belief there is no such a comparison between assembly language, C and C# for example. The assembly language is a mnemonic language of the machine, it provides you with the capabilities of the machine, it was never aimed to programming applications or building OS-es. C is already a high level language that gives all you need to program any type of application on it and that's why it is used for more than 30 years, and that's why it was chosen when Apple started writing their first graphical OS and later chosen also by Microsoft to build Windows. And then fully object oriented languages already existed, but it was considered not practical to use them and this was NOT a matter of slow hardware (please, first read what the people who worked on the first graphical OS-es tell us).
  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. Not to mention other problems like finding obscure bugs. My company was using VB for a long time, now it migrated to .NET, there was a strange bug in the application and it took 3 weeks to find, scratching deeply in the application code and framework internals, i would find that bug in less than a day given that the application was written using the raw API.
  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". Don't you feel the M$ outrage on their developers?
  About the faster machines - on my P4 2.4 Ghz Java runs just as slow as on my P2 300 Celeron, that's all marketing tricks but is seems you and many other people just don't get it.
  The reason because serious development was done in C for such a long time is not the slow hardware (what is now the popular belief), it's because it is simple to write and understand. You can do sloppy programming on any language, that's the human factor here, not the technology factor. I've seen a very complex but briliantly written programs on plain C. One example is the Mosaic code. And i've seen a really sloppy programs written in C++, Java and C#, when you read the code you feel the autor just doesn't get it right about programming. So technology can't prevent you from doing silly things.
  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.
  A question: Is it normal for a program consisting of a simple form with a few controls on it and doing nothing more than sitting idle to eat more than 100 MB of memory?
  My C program frees memory just when it should and doesn't consume a bunch of system resources and when there is a memory leak i always find it. 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? They both have their way of automatic "garbage collection".
  I was really amazed when a simple .NET program reserved 400 MB of my 512 MB of memory, got 4000 system brushes, Windows started to scream that it will increase the virtual memory, and all the system was so slowed down that it was impossible to work with any other program than the current "managable .NET application". That's what i call it a shame!
  And finally what is the benefit for you as a proffesional programmer in making all programming a toy - you will be underpayed in the long run as the statistics show. You and many people seem not to know the Sergei Bubka's rule.