|
Sorry, I should have read the post by TW before I posted:
"Native C/C++ application of course will still execute on Longhorn, BUT there will be no more improvement on native C/C++ (MFC/ATL/WTL/SDK) a foreseen fact. Future VC++ become a 100% .net dependent language..., shame on MS!!"
...of course there has been no real improvement of MFC since VC 4.0, so that doesn't make any difference. Also, most companies have to support all versions of Windows, not just the latest, therefore they won't be able to take advantage of the latest SDK features anyway. What will happen is if a company wants some of the latest features in Longhorn they will just find a way of implementing them in c++
|
|
|
|
|
If they want to take advantage of new features in Longhorn, then yes. Although it is possible to mix managed and unmanaged code, so I bet that in most cases, code will be mostly C++, with some hooks into managed C++ whenever necessary.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Anonymous wrote:
so a company with a 1 million line application has to rewrite it in a new language just so it can run on the next version of windows?
No, Win32 will still run:
That is, Win32 will be in maintenance mode
But I don't think anyone has a re-coding task as big as MS:
Today, there are over 76,000 Win32 APIs, and countless wrappers. With Longhorn, Microsoft hopes to reduce the API set to 8,000 to 10,000. 
|
|
|
|
|
Re-code? Not really. .nut is a layer above WIN32 API for now, what's really extra is the language abstraction and memory layer. Internally, .nut is all about C/C++ and ASM.
|
|
|
|
|
And what do you say about layer of MFC above Win32 API?
Well, I remember your article about MFC 
I am sure that managed code has perfect future.
Don't worry - a year ago I thinked as well as you about .NET.
|
|
|
|
|
What's wrong as MFC is layer above Win32 API  ? API is no more than exported "C" function, you can view MFC as object-oriented organised of these APIs.
With native C/C++, we emphasize design and optimum. With .nut? You learn nothing more than using the framework + tons of associate MS products! Note that .nut framework application must comply to .nut way of doing things. C/C++ itself is written by itself (cool!), you are free to do anything with it, there is no "frame" in your design. Further more, C/C++ has the best open source support because of this. People around the world learn so much from C/C++!
"Microsoft Managed Code" will not have a future. While you see it the other way round because you undermind MS intension on .nut framework.
I would not let MS managed my C/C++, because I am smart enough not to use .nut framework to complete my work. Until MS does its dirty work again, implicitly force people to comply. 
|
|
|
|
|
TW wrote:
Re-code? Not really. .nut is a layer above WIN32 API for now,
We're not talking about Now, we're talking about the Future.
More from the Longhorn FAQ:
Q: So what's changing from a developer's standpoint?
A: In the technology generations leading up to Longhorn, Microsoft has been moving to a .NET-based managed code environment, and the Longhorn generation will finally mark a clean split with the Win32 APIs of the past. That is, Win32 will be in maintenance mode, and all new development will occur with managed .NET APIs. One such API, Avalon, forms the basis for the new Desktop Compositing Engine (DCE) in Longhorn that replaces GDI and GDI+. Another, called Aero, provides APIs for the new user interface. All of the new Longhorn APIs will utilize the XML Application markup language (XAML) to make Longhorn more accessible to developers than ever before. The idea is to significantly reduce the number of APIs and make the APIs more standardized. Today, there are over 76,000 Win32 APIs, and countless wrappers. With Longhorn, Microsoft hopes to reduce the API set to 8,000 to 10,000.
|
|
|
|
|
When Sun shipped Solaris 9 that ran almost entirely on top of a Java base (which is 'managed code' in a way), only academic institutions bought it, and the users hated it.
It will be interesting to see what happens with Longhorn, since managed code usually equates to slower programs (free garbage collection is hardly ever 'free').
"If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week"
|
|
|
|
|
But see, this is Microsoft, will anyone really have a choice? Once their vendors start shipping PCs with Longhorn pre-installed, programmers will have to support it somehow.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Has your company started supported XP-specific APIs in its latest revisions? I know that mine hasn't (and won't for quite some time). Just because Microsoft puts something out there does not mean it will take over the market. Case in point: Microsoft ships Windows with Media Player already installed; however, 90% of everyone I know that listens to music on their computers still download WinAmp. They can influence the market, but that does not make them the market.
"If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week"
|
|
|
|
|
...voted CListCtrl, but I decided to answer sensibly instead. 
Anyway, I find that C# and XML are the most important, and both are equally important to my work. I use them in almost every project, web or desktop. 
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Good work - I think the joke is somewhat worn out now !!
*¨¨`)
¸¸.·´ ¸.·*¨¨`)
(¸¸.·* ¸ .·*
¸¸.·*
(¸¸.~~> Joel Holdsworth.
|
|
|
|
|
I've tried C#, and while it is great for ASP.NET and small ad-hoc tools, for big projects C++ is still a must.
|
|
|
|
|
|
You said it!
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
