you can use c++ with .net too, but do you do so?

Quote:Original post by cozman
With (from what I understand) the move being to more technologies that are similar to .NET, the phasing out of C (and even C++ somewhat) in favor of C# isn't a big suprise.

While I agree with you that the C language is being phased out on the Microsoft platform, you are completely wrong about C++. Especially considering that CLI/C++ is the top performing .NET language with the most features.

Quote:Original post by valla2
Well... one can make nice GUIs with win32 API and C...

And when i say tragic i mean that you can't program a GUI for this OS, in the language that this OS was programmed with.. :/

Anyway... i have a more ..serious question... ( i'll try not to hijack my own thread heh )

Why would you want to use WinFX ( Avalon ), when you have .Net and WinForms there? Especially for the guys who already feel comfortable with .Net? Let me put it this way: What's the need for this WinFX API? Do we really need it ( when we have .Net? )
thx

1. Sure you can make nice GUIs with win32 API and C, and you can write very nice videogames entirely in x86 machine language. The more important points becomes: why the hell would you ever want to? There's better technology out there that makes your life so much easier that there's no reason not to use it.

2. I'm 99% sure that Longhorn is being written primarily in C# and C++ and that there will be little, if any, C code used for Longhorn.

3. WinFX is necessary because it will provide much cleaner looking interfaces, more customization and will be hardware accelerated.

I think some of you are misunderstanding, like Malal said C!=C++, I am sure you will be able to use C for your programs as in the end it all translates to machine code, however, think of the implications of completelly removing the C WinAPI in favor of a WinFX that uses a C++ API exclusivelly.

Enter the Silent killer: Name Mangling, if you ever tried to link a C++ dll compiled with a particular compiler against an application compiled with a whole different compiler, you would know that the issue is not a trivial one, MS has 2 options here, do nothing and lock everyone into compiling C++ Windows Applications with MSVC++ exclusivelly, or build the API around COM objects, personally, I think going from C WinAPI to a COM API is not really an improvement.

Anyway, like Fruny said, it's not out yet, once it comes out we will know for sure what's the approach they're taking, in the mean time, I recomend lerning some Linux, you know, just in case it flunks.

Quote:2. I'm 99% sure that Longhorn is being written primarily in C# and C++ and that there will be little, if any, C code used for Longhorn.

I really doubt about that. How do you know? How can we know?

Quote:3. WinFX is necessary because it will provide much cleaner looking interfaces, more customization and will be hardware accelerated.

i don't know about the last one, but all those describe .Net too, so..?

Now let's place the facts on the table:

- There is so, SO much code written in win32 api and MFC.
- There are so, SO many people learning win32 api/MFC *now*.
- When Longhorn will be published, it's going to be expensive as hell and it will take too much time for the average user to migrate to it.
- Many people are comfortable with their own API, and many bosses probabbly don't see any reason to start implementing their software with another API their programmers aren't comfortable with. (-) Not to mention that many of them don't like the idea of the on-the-fly compilation or that their source code will be decompiled so easily.
- The factor of money ( for the developers this time ) is there too
- There is always Linux :P

It seems too me that it will take too much time for the industry to migrate to the new technologies of MS, but as always i am a moron and i could be wrong :)

Quote:Original post by valla2
It seems too me that it will take too much time for the industry to migrate to the new technologies of MS, but as always i am a moron and i could be wrong :)

Yeah I heard this back in the days of DOS too :) The way the industry works is and has always been, learn the new stuff or go find another job really. There are lots and lots of replacements waiting to take the job if you don't want to migrate to it.

Quote:Original post by valla2

Quote:3. WinFX is necessary because it will provide much cleaner looking interfaces, more customization and will be hardware accelerated.

i don't know about the last one, but all those describe .Net too, so..?

I think you don't understand. WinFX isn't just an API update like winforms or MFC it's a replacement for GDI+, it's not just a new set of wrappers around the same old crap, it's an entirely new drawing system. Well, actually it's an extension of the old system, WinFX includes all the capabilities of winforms/GDI+ but includes many new features as well. Longhorn will be able to run applications written using Win32 and MFC, it would be suicide for it not to be able to.

As to what Language Longhorn is being written in: Avalon/WinFX is being written in C#, there are many sources on the internet to confirm this (try using Google to find them). The only things being written in C for Longhorn are the low-level kernel things.

Quote:I really doubt about that. How do you know? How can we know?

Read the blogs of the Longhorn developers.

I think it's extremely unlikely that you won't be able to code in C.

As far as I am aware, they will have to retain the existing kernel32, gdi32 and user32 APIs (all of which are C APIs). They will have to retain a large number of other libraries for legacy applications.

Plus also, regarding C++ linkage, they will want to retain C linkage because of .NET P/Invoke - i.e. it is almost impossible to P/Invoke C++ linkage code from .NET, but very easy to call C linkage code (even if it's written in C++).

C linkage is the only kind which is actually properly portable between compilers / technology, and given that MS have such a lot of stuff to support, they *have* to retain the C linkage.

Add that to the fact that low-level code will almost certainly still be written in C (In Windows, all kernel-mode code is written in C as far as I'm aware). This includes all device drivers (all kernel-mode ones anyway - which is any storage, network hardware, display drivers and many others).

Then there's NT native mode code - which AFAIK is more or less entirely written in C - it all uses C linkages anyway (even if you can write it in C++). It's unlikely that these apps can be written in C#, or even C++, as there is no library support for these applications.

Applications of NT native code include stuff like startup disk defragmenters and other early boot-process stuff.

So all in all, I think this is basically nonsense.

---
Will Longhorn be able to run C code? Yes
Will Longhorn potentially include some optional "trusted computing" profile setting which allows you to restrict users from running arbitrary native-code applications? Possibly, but if it does, it will apply equally to C++, Delphi etc.

Mark