Slashdot Mirror
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
check out The Ars article on .NET
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.
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
.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
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