|
That would make XML very interesting. 
|
|
|
|
|
That is not completely correct. Since they lumped pretty much anything that uses XML under that umbrella, that includes WSH, which is a scripting language (well, actually a set of scripting languages).
If you want to get down to it, what is the difference between an XML file and a C++ source file? They are both text files that follow a certain syntax.
"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"
|
|
|
|
|
The overall technology is pretty interesting though, even if some of the implementation borders on the silly.
|
|
|
|
|
It may be a file format alright...but hype? I think there is solid use in XML.
|
|
|
|
|
In Microsoft's opinion the future is in managed code, in whatever flavor your prefer. Here's a quote from the Longhorn FAQ at WinSuperSite[^]:
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.
|
|
|
|
|
If you look at the free text comments you will see many people have a different opinion than MS about "managed code"
|
|
|
|
|
I guess it all comes down to what platform(s) you want to write code for.
If you're part of the crowd that likes to make your money from developing for Windows, the writing certainly seems to be on the proverbial wall, and the decision seems to have been made for you already.
Time will tell of course, and if the direction were to change it wouldn't be the first backflip we've seen 
|
|
|
|
|
Furty wrote:
If you're part of the crowd that likes to make your money from developing for Windows, the writing certainly seems to be on the proverbial wall, and the decision seems to have been made for you already.
Assuming Longhorn ever ships...  
Yes, it does seem like managed code will be essential for Longhorn and future OSes... but right now, 100% of the customer base is *not* running Longhorn, since it isn't out yet.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Are you saying that only c# and c++ with "managed code" will work on Longhorn? Surely you must be joking?
|
|
|
|
|
"...c++ with "managed code" will work on Longhorn.."
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!!
I wonder how qt or cyg gonna handle this one?
|
|
|
|
|
Well, it seems like if you want access to the OS API at all, you'll need to use managed code. 
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
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?
|
|
|
|
|
Of course not! But you can put the hard earn C/C++ knowledge aside and start "manage" by .nut, native C/C++ become something "exclusive" to Microsoft...that's right, they do whatever they want, but you do EXACTLY who they ask you to! 
Who knows one day .nut application must have "MS-INTEL superior security chip" to run?
Dam! Lucky I have Linux with me...;P
|
|
|
|
|
Sorry, I didn't 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++
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
