Microsoft Drops .NET Name For Next Windows Server
metamatic writes "C|net is reporting that Microsoft is dropping the name "Windows .NET Server" and going back to "Windows Server 200x" (where x is currently expected to be 3). Other products with .NET in the name are also being evaluated for renaming. Analysts are being quoted as saying that slapping .NET on so many Microsoft products has confused people as to what .NET actually means. Or could it be that customers know what it means, but nobody wants to buy it?"
Obiwan Kenobi points out a similar article at ENT News
Palladium is the DRM, sorry, secure platform where the idea is that a Palladium enabled OS will only run signed apps, presumably adding security by not running any viruses, worms and any haxxor tools. Of course, this means any open source will not work in a Palladium OS because of the difficulty of getting an open source app signed.
That's my understanding of the two, but I'm not 100% sure; it's been difficult trying to work out exactly what .NET really means...
Comment removed based on user account deletion
There's a blurb about it at the bottom of this Wired Article.
One quote "Microsoft also is re-evaluating the ubiquitous name's use on other software." adds another dimension to this than just taking it off of the Windows 2003 Server.
check out The Ars article on .NET
I've said it before, but I'll repeat myself, MS is run by lawyers and marketing people who don't consider any technical aspects of what they're doing. MS messed up bad with the ActiveX craze and maybe this influenced the move away from the .Net name. Very few still understand what .Net actually is, and MS isn't helping. I really wish they could have some of their techs/programmers sit down and write a coherent explanation/introduction, without lawyer/marketing influence. It took me a looong time to get a grip on it, simply because any MS material is so filled with buzzwords and marketing terms.
For those that still don't know what .Net is, it's like an MS version of J2EE, not Java, J2EE. It's a architecture with among other things a large class library and a cross platform runtime that all .Net languages can run under.
Ok, so it's not 100% accurate, but close enough.
Wax-Museum Fire Results In Hundreds Of New Danny DeVito Statues
I've seen a number of posts trying to clarify what .NET is, and they're missing the point. .NET isn't just about web services and so on, which in itself is a good reason to change the name. .NET is a major attempt to shed legacy Windows problems and modernize both Windows itself and Windows application development. If you read the .NET and C# documents, you'll see this. For example, if you want to write a GUI application for Windows today, you have to use one of (a) raw Win32 API, (b) MFC, (c) a cross-platform toolkit like WxWindows, or (d) a tool like Delphi or Visual Basic. By a large margin, the last of these is the cleanest and least stressful--if you're only concerned about Windows that is (of course you can get Delphi for Linux in the guise of Kylix). But .NET is bringing the GUI building features of Delphi and Visual Basic to the OS, so there's support for this from the ground up. Ditto for technologies like DirectX 9. No more do you have to deal with arcane C++ interfaces to COM, you can use a pretty little C# component.
.NET the preferred method for developing Windows applications. If don't like C#, that's okay. Microsoft has been getting indepdendent language developers to port their own languages to .NET, including lesser used languages like Smalltalk, APL, and Mercury.
.NET could be a huge win. No more struggling with Petzold books, just use the much simpler .NET components. No need to hang onto awful legacy frameworks like MFC, which even Microsoft employees hate. No more having to choose between C++ and much slower scripting languages like Python for application development, just use C#.
In short, Microsoft is deprecating most of the Win32 API, making
As much as I hate to say it,
I write C#.NET stuff almost every day. All .NET is is a framework. A collection of programming objects that let you build apps by fitting them together, and writing the glue, rather than re-inventing the wheel everytime. If you know what the Java classes are, or MFC, .NET is very similar. .NET objects can be accessed by writing command line apps, windows GUI apps, and ASP web-apps. It makes it very nice to be able to know the same language for all 3, at least to me. I liked Perl for CGI, but couldnt use it to make a GUI app very easily. VB was queer, but worked for GUI apps, but not very strong for complicated apps. .NET framework includes a bunch of objects for dealing with everything from I/O to Databases to XML and Webservices.
I'm Rick James with mod points biatch!
If I were in marketing, I'd say both .NET and Java are attempts to build operating systems for the Internet (as opposed to operating systems for computers.)
You are not alone. This is not normal. None of this is normal.
Which is exactly what they're doing. .NET Server was a misnomer, as it is strictly WindowsNT/2K code with the latest IIS and .NET Framework installed.
A real .NET Windows will appear when the entire OS runs as managed code along with the rest of .NET. This next server OS is exactly what they've renamed it to, Windows 2003 Server.
I'm Rick James with mod points biatch!
Passport still exists, but I think that take up has been much slower than MS wanted (ie virtually nonexistant). In fact, to order evaluation copies of Windows XP Professional and Office XP, I had to sign up for a Passport. To sign on to Hotmail (in IE 6 only?) or MSN Messenger, at least, you have to associate a Passport account with your XP user account, so no, Passport is not exactly dead.
.NET My Services, formerly Halistorm, is (currently) dead. The computing industry and target clients essentially told MS where to shove it.
It's official. Most of you are morons.
TBPH, I think Microsoft is attempting to conquor the elusive remote object invocation problem.
At first, it seemed like some version of RPC might solve this problem. And then a little bit later, developers were promised that CORBA was the future. Somewhere in there OSF/DCE made a lot of promises. And then Microsoft threw COM out there, and tried to spruce up some security issues with COM+...
Eventually EJB took hold, and now we have yet another way to remotely invoke objects via SOAP.
While things are looking up, I think most developers are fairly frustrated at this point. After grappling with IDL's and disparate RPC mechanisms, IUnknown and VisualBasic... I think unless there is a conserted effort by the industry to address remote object invocations (including a robust security model) then all of these attempts will continue to flounder.
Eric Sarjeant
eric[@]sarjeant.com
Also, the entire .NET Framework is designed with XML-based services in mind, not just ASP.NET. Most (all?) classes can be serialized and passed around to be discovered by reflection.
.NET is like Java, but it only runs de-facto on Microsoft platforms (in theory it will run on BSD too, but important parts are missing)
Schnapple
I see many "What is .NET" posts here. The best single whitepaper I've seen on .NET is by the Ars Technica folks:
.NET at Ars Technica
Microsoft
cheers.
Ultimately the meaning behind any marketing term is somewhat arbitrary. When Apple came out with the Apple name, it initially didn't mean anything. Over the years it came to mean a lot in the minds of many people. That's kind of what a brand name is all about, right? .NET is the same thing only MS has done a very bad job defining it. Re-naming the Windows .net server is (perhaps) a step in the right direction. If you look at the leaked Q&A from the announcement, it seems very clear to me what they're doing. I'll try to explain in simple terms.
.NET as a web services initiative - basically a way of writing software that uses XML, SOAP, WSDL etc. to allow apps to interoperate. A poor mans COM.
.net framework.
.net framework is - for all intensive purposes three things. First, it's a new programming model for Windows based on the common language runtime that makes it much easier to write secure, stable Windows appps. It also includes a new version of ASP that makes building web-based easier. It also includes facilities that for building XML web services and a bunch of new class libraries for Windows and web apps.
.net into the name of the framework because it confused everyone. To people who can't read the tea leaves, it suggests that any appliacation built ising the framework is a ".net app." In reality, most of the apps built using the .net framework today are just better, more secure Windows apps or ASP/web-based apps.
.net brand is about Web services interop. They obviously still want people to build Windows apps and are making it easier to do so than it has been with Win32/MFC etc. So they're building web services capability deep into their platform -into Windows, into Office I'm sure and into all of their server apps.
.net is to web services/interop. The .net framework programming model/CLR etc is, fundamentally a Windows thing. No surprise, right?
.net framework/CLR programming model and porting it to other platforms. That way they can try to lure ISV's to build "Windows apps" that run on other platforms. I know. Sounds confusing but I think this is accurate.
1. In the beginning they announced
2. The a bunch of marketing goofs started attaching the name to lots of things - most importantly the
3. The
4. The big mistake they made was putting
With the announcement they said in clear terms that the
For developers this is a beautiful thing. They can take it or leave it. They choose to build on Windows based on its merits. Market opportunity, ease of development or whatever. Some may ultimately choose to build on Windows because Windows has good XML web services support.
I think MS's strategy is to continue to make Windows as good as they can and compete with J2 by providing superior support for web services. The theory (just a theory) is that if web services mature then developers can choose whatever platform they want and rely on web services to stitch things together across platforms. This could be a good strategy because it undermines the Java-only argument. No need to build apps on a single platform (middleware platform in this case) because web services provide good cross plat interop.
So, the bottom line is that MS is narrowing what
That said, MS is taking parts of the
This is way MS, IBM and other companies are so excited about web services and why others - particularly SUN, have been a little slow on the uptake. Although this is overly simplistic, Sun/the J2 crowd basically want everything to be Java/J2. IBM will sell anything to anyone. MS wants to make Windows the most attractive platform.
Gosh, this almost sounds like good old competition to me.
Sorry for the ramble but, mark my words, this is the correct interpretation.
Fine, then I'll do it.
The biggest advantage to the platform for develpers is absolute type declarations with full knowledge at the object interface: if you write an object method in VB.NET that takes two Integers, a String, and an array of Dates and returns an Integer value, then you can directly refer to that method in your C# routine. There is no conversion needed between types, not even between languages, which has historically been a problem with Microsoft code ever since OLE.
Visual Studio .NET is a development IDE for all the Microsoft .NET languages: VB.NET, C#, and others. It's similar to Microsoft's Visual Studio 6.0, but all the separate components are better integrated. All languages compile together to produce a single "package", which you then ship to your customers. There are no "installations" as the package is self contained. And it still includes a native C++ compiler which can still emit code for any Windows platform (except for .NET...)
Microsoft says the combination of the above puts all languages on an equal footing: developers can code in whatever language suits them. (Since it's interpreted bytecodes, I think it makes all languages equally second class, but that's just me.) So with .NET language is not a barrier to function calls. You want to call method "Foo" on an object called "Bar"? You just do it in your working language, however that language invokes methods on objects. You don't know when you're writing it what language it will be called from. You don't worry when you're calling it what language it was written in.
That's the developers' carrot in a nutshell. And so here's the developers' stick: Everything is shipped as bytecodes in that package, and the supplied decompiler already spits out source code that's only missing some of the documentation. I asked the guy during the .NET product introduction "How is intellectual property protected if anyone can just decompile the code?" The answer started out evasive, but boiled down to: We [Microsoft] will be serving up our meat-and-potatoes functionality via the web, so our code is hidden behind our firewall. Come, join us. You do not know the power of the dark side. (OK, so maybe the guy didn't say that last line, or at least not out loud.)
On the whole, I was semi-impressed at the product introduction. Having strong type safety is really a good thing to me, because I do spend time fighting code that has been carelessly cast, and I also spend time converting from VARIANT arrays of UI1 to STD::strings. Automated garbage collection and automagic reference counting is also really nice. But interpreted languages haven't been exciting to me since GW-BASIC. (Sorry, you Java weenies, but I'm too old to think wasting cycles interpreting bytecodes in front of a user at run time is ever a good thing.) And C# is not C++, nor is it Java. I don't like that IL will only do its own random-time garbage collection and can not support destructors, not even virtual destructors. There are times when I want to garbage collect at a specific point in time (examples such as cleaning up scarce resources like database connections or sockets come easily to mind.)
But I really, really don't like that .NET is ultimately just a facade to hide the movement of software to the subscription model under Palladium. Want to print that Word document? Did you tithe Microsoft this month? Nope? Too bad. Are you still offline? Too bad, you can't run PowerPoint.NET until you're back online and we can check the status of your subscription (or at least check the status of your Visa card authorization.) .NET will make Palladium viable, since the CLR is a trusted software container (read: sandbox.)
So, on the whole, .NET has too many really huge negatives to get me going. It even caused me to ditch my MSDN subscription because it had become "Nothing but .NET" Literally.
John
.NET the "language" is an intermediate language bytecode called IL (Intermediate Language). (...) .NET the framework also contains the system class, which exposes all of the available platform functionality.
.NET is the platform and more like the "thinking". There's no ".NET, the language", since .NET is just a concept. There's no ".NET, the framework" either; its title is simply ".NET Framework".
.NET is:
.NET technology enables the creation and use of XML-based applications, processes, and Web sites as services that share and combine information and functionality with each other by design, on any platform or smart device, to provide tailored solutions for organizations and individual people. .NET is a comprehensive family of products, built on industry and Internet standards, that provide for each aspect of developing (tools), managing (servers), using (building block services and smart clients) and experiencing (rich user experiences) XML Web services. .NET will become part of the Microsoft applications, tools, and servers you already use today--as well as new products that extend XML Web service capabilities to all of your business needs."
.NET is Microsoft's platform that directly supports and allow creation of XML-based applications and web services. Also read this, it might clear things up.
Microsoft describes what
".NET is the Microsoft solution for XML Web services, the next generation of software that connects our world of information, devices, and people in a unified, personalized way.
There's nothing more to it than that, really --
Beware: In C++, your friends can see your privates!
C++ is not designed with these constraints in mind. Managed C++ is, basically, C++ following those constraints (and is a mess). C# is a new language designed around those constraints, using similar syntax to C++ and Java (to make it easier to learn). VB.NET is a rewrite of Visual Basic that gives it a lot of the power of C++, but retains some of VB's simpler syntax (to make it easier to learn). They're not different only in syntax, though...there are differences in rules and functions as well. Sure, you can write programs that do the same things in VB.NET as in C#, but some things are easier in one than the other...which has pretty much always been the case with different programming languages.
Standard C++ can be compiled with /clr and will be compiled to IL bytecode, therefore using CLR. You can not, however, use standard C++ to access the .NET Framework...that requires managed C++ (or another .NET safe language).
But, C# and VB.NET aren't the only languages out there. ActiveState has Python.NET and Perl.NET, there's COBOL.NET, Fortran.NET, Forth.NET, and even Pascal.NET (and many others).
But, managed code is a new addition to .NET that requires some adoptions in the programming languages. Why didn't MS port C++ or VB6 to .NET? They pretty much did...it's called Visual C++.NET and Visual Basic.NET.
Like I said, if you're not a Windows developer (which you don't seem to be), then this largely means nothing to you.