Sign in to follow this  
valla2

NO C in Longhorn!

Recommended Posts

valla2    100
HI. Can anyone help me with this question? WInFX is going to be the new API in Longhorn. It's going to be object oriented, but it won't wrap the current win32 API. I don't know if it's going to be compiled at runtime like .Net ( can anyone answer me this? ). Ok so what's the problem now? THe problem is that programmers won't be able to use C on windows anymore! NO C?!?! An OO API that can't be supported by C. Why nobody cares? Don't you think it's tragic? ps i could be wrong lol thx! edit: you can use C with other APIs but not with the official API of windows.. i mean

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
well, you may be wrong. otherwise I think Microsoft is building a system that will not work at all, will be made by idiots and will be used only by idiots!!!
How could exist a OS that does not support C programming? (Well I mean C/C++). How do they write the OS? How do companies make programs that work in ugly languages? Even worse code that may be interpreted!!! Videogames wouldn't go much far...
My last opinion: I don't know anything about this OS but if you're right I think Microsoft will make Linux beat it with its own hands! (Remember that I'm not a Linux fan at all! I hate it!)

Share this post


Link to post
Share on other sites
Fruny    1658
Quote:
Why nobody cares?


Because a) it's not out yet and b) there are other languages.

Quote:
Don't you think it's tragic?


No.

Share this post


Link to post
Share on other sites
cozman    583
I don't think this is too suprising, it is still going to be possible to use C, but C is not the best language for the development of most GUI apps. There are already a few MS APIs that exclude C, from MFC to .NET. 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.

Honestly if you've written a Windows app in C and in most other languages (Java/C++/Python/C#) it's pretty easy to see that a language which has at least some OO constructs fits GUI programming much better than C.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Well I am angry if there is no C++ support. I can live very well without C. About C# and .NET language I think they are so similar to C++ that it is not a problem to learn them if you already know C++ (about GUI I totally agree, OOP is a must! However I wouldn't like a system without some great features of C++ like pointers, (Java has not them))

Share this post


Link to post
Share on other sites
Helter Skelter    332
I'm surprised that it took them this long to do it. There was a lot of snickering when we went from punch cards to terminals. Who in their right mind would choose line editors over punch cards? It's silly. After a while we got to scream about the transition from assembly language to C and PASCAL. It was just absurd to think you could accomplish anything in C. Then we had got to laugh at all the morons who switched to C++, Objective-C and Java. You just can't do any serious programming in type restritive languages. God forbid people have to adapt to a new way of thinking or be forced to write safe code.


All sarcasm aside I welcome our new object oriented overlords.

Share this post


Link to post
Share on other sites
valla2    100
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

Share this post


Link to post
Share on other sites
Saruman    4339
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.

Share this post


Link to post
Share on other sites
jperalta    356
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.

Share this post


Link to post
Share on other sites
Kwizatz    1392
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.

Share this post


Link to post
Share on other sites
valla2    100
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 :)

Share this post


Link to post
Share on other sites
Saruman    4339
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.

Share this post


Link to post
Share on other sites
jperalta    356
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.

Share this post


Link to post
Share on other sites
markr    1692
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

Share this post


Link to post
Share on other sites
swiftcoder    18437
Quote:
Original post by Kwizatz
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.


This is not 'entirely' true, you don't actually have to use the same compiler, but you do have to use a compiler that uses the sam ABI ("Application Binary Interface").
I am not sure, but I think I heard somewhere that the ISO C++ Standards Committee has decided on an ABI for the C++ Standard, and if this is true, it means that all standard conforming compilers in the future will be able to link with libraries compiled by other standard conforming compilers.
However, please correct me if I am wrong on these points.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Well, I like the idea of a new API set entirely using OOP and it is OK for me if it is C#. But I also want to code my _own_ applications in C++; I'm pretty sure compilers will support that. I don't know C# and I don't know which aspects present in C++ are missing in C#

Share this post


Link to post
Share on other sites
swiftcoder    18437
Quote:
Original post by Anonymous Poster
Well, I like the idea of a new API set entirely using OOP and it is OK for me if it is C#. But I also want to code my _own_ applications in C++; I'm pretty sure compilers will support that. I don't know C# and I don't know which aspects present in C++ are missing in C#


As the core of the OS is most likely written in C, and many programmers use C, I would be very surprised if the compilers did not support C.
And as far as the Platform API not being in C, it probably doesn't matter very much for games programmers, since libraries like GLUT and SDL will still support C anyway (SDL already bridges from a Platform API in another language, Objective-C, on Mac OS X, so they could always do this on Longhorn as well).

vgmtech: Well, there are always the GNU related compilers, if you can bring yourself to use such a rallying point of Open Source on a Microsoft OS ;)

Share this post


Link to post
Share on other sites
Kwizatz    1392
Quote:
Original post by swiftcoder
This is not 'entirely' true, you don't actually have to use the same compiler, but you do have to use a compiler that uses the sam ABI ("Application Binary Interface").
I am not sure, but I think I heard somewhere that the ISO C++ Standards Committee has decided on an ABI for the C++ Standard, and if this is true, it means that all standard conforming compilers in the future will be able to link with libraries compiled by other standard conforming compilers.
However, please correct me if I am wrong on these points.


I had to look up ABI on wikipedia just to make sure it is what I thought it was [smile], indeed if there is a standard C++ ABI, and Microsoft decides to follow it, then all compilers following the standard (in theory) should be able to generate binaries for Windows, however, it is still all speculation, as of this moment, there is no ABI standard, neither is Longhorn out, so we'll have to wait and see.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this