|
So I got saw this in the CP Daily Insider today:
http://www.redmondmag.com/features/article.asp?EditorialsID=640[^]
One of the most innovative features coming in Windows "Longhorn" Server isn't really a feature as much as a whole new version of Windows. It's called Server Core, and it will only take one-sixth of the disk space of a normal Longhorn installation. It's not expected to need anywhere near as many patches and hotfixes as Windows 2000. It's a version of Windows that does not, in fact, use windows. It's breaking Microsoft's long-standing reliance on graphical interfaces and shaking things up in several of Microsoft's product groups.
Awesome so far. A dream come true for people like me.
Server Core can only act as a file server, domain controller, DNS server or DHCP server.
Cool, file server. Wait. "File server"? Not "Web server"? And then the truth hits hard:
<big>There's also no Microsoft .NET Framework.</big>
No .NET! Can you believe it?! They couldn't make a Web server for Server Core because they couldn't get ASP.NET working! So they had to settle with a (pfft) "file server". And why? Well, here:
This means you can't run any managed code on Server Core. Mason says his development team wants to add the .NET Framework to Server Core, but they first need the Framework team to modularize the code so they can add just the essentials.
Ouch...
.NET 1.1 and 2.0 are modular and very portable for the most part -- .NET 1.1 and 2.0 work on the PocketPC/Smartphone (Compact Framework), Xbox 360 (XNA), and of course, Win32. Heck, .NET 1.1 even compiles and works on FreeBSD and OS X.
Not so anymore: remember, Server Core is Longhorn after all. But they couldn't possibly put .NET 3.0 on it. And so, Server Core's .NET implementation would be damned to either .NET 2.0 or to skip to 3.5 despite the lack of 3.0. Now what: a big huge mess. Customers have .NET 3.5 installed, but their .NET 3.5 programs won't run because they used an itty bitty class that came with .NET 3.0.
This is the exact worst case scenario that I was yelling about in the petition:
2. “Bootstraps” – .NET 3.0 does not have a “bootstrap”. It offers libraries that provide functionality as needed (just as it’s always been for .NET applications), but the “bootstrap” is in fact the .NET 2.0 CLR; “.NET 3.0 applications” merely make use of its libraries. Not only is this misleading, <big>it impairs the modular paradigm of the .NET Framework</big>. In terms of “kernels” and “bootstraps” as in the Channel9 video, the microkernel structure of the .NET Framework has been traded for a monolithic kernel.
5. Non-Win32 (Microsoft and non-Microsoft) implementations – Other implementations of the .NET Framework, such as the Compact Framework, SPOT OS, Singularity and Mono will suffer from naming confusions. The CLR team took very, very careful steps to make sure the .NET Framework works on other platforms as well. Mangling the .NET framework with Win32 specific API breaks that, <big>isolating the entire framework to Windows</big>.
Most of the other teams are a lot more careful: the BCL and CLR are carefully designed to work on other platforms with minimal modification (take a look at System.IO -- it works seamlessly on Unix). The C# team made painstaking efforts to standardize the language and submit it to ECMA and later ISO. They even put everything Windows specific (except System.Windows.Forms) in its own namespace called Microsoft.Win32. All that has gone to waste.
I mean, I'm sure that's not the only modularity issue. I imagine there's some problems with the installers and the complicated way they use MSI scripts to register assemblies in the GAC and such.
But in either case, these such problems point to a single culprit: the .NET Framework management team. This seems to be the team that makes all of the decisions on what goes in and doesn't go in the framework. Jason Zander alone, as he says in his video, is the "approver[^]" of all breaking (or what he likes to call "red bit") changes to the framework, including the one to accept Marketing's idea for the horrible misnomer. The same team also seems to be the one in charge of determining the installation and distribution process.
It looks to me as if there's a fundamental flaw in the decision making within this team.
The concern on the part of the Server Core team was obviously that they could probably do ASPX 2.0, but ASPX 3.5 (or whatever the hell they're going to call it) would be way too risky as a lot of it may rely on .NET 3.0. Therefore, any up-to-date version of the .NET Framework is too risky to support on a server OS due to its lack of modularity and consequent potential for breakage.
Well, you could say, we can still have a Web server on Server Core. Apache works with the Unix Subsystem (formerly known as Services for Unix -- now that's a nice name change eh?), and the Unix Subsystem works on Server Core. But oh man, the irony!
I hate saying this. I really do. I hate being an a***hole. But you can tell from how passionate I've been about this whole thing that this is an exceptional case, so I will say it.
Microsoft, we told you so.
|
|
|
|
|
I don't think WinFX is the problem. WinFX is just a few additional assemblies. They would just not work on Server Core, like System.Drawing (GDI+) and System.Windows.Forms probably would not work.
But the .NET framework installation requires Internet Explorer - on a plain Windows 2000 without service packs, you first need to update IE. I think there are some dependencies to {Internet/Windows} explorer parts that really shouldn't be there.
And it has been that way since .NET 1.0, completely unrelated to WinFX.
|
|
|
|
|
Actually IE is needed for the System.Windows.Forms.WebBrowser class, which is actually a wrapper for the IE COM interfaces. That's why Win2k needs the updates first. It's only so that people using Forms applications aren't baffled as to why their programs throw exceptions right as they open browser controls.
The only really Windows specific components within the .NET framework up until 2.0 are Forms, Enterprise services and arguably Interop services, though this is debatable since Server Core is still Windows and Interop uses only rudimentary Windows components.
Meaning to say, .NET up until 2.0 is indeed quite modular and portable. It certainly isn't bad to the point where they'd have to omit the whole framework from such a crucial product because it'd take too long to port.
The problem with WinFX is rather that there's now a higher risk and/or perception of risk of people, including people within Microsoft, using .NET 3.0 components for latter versions of the framework. It's part of the previous version so it's only natural to make use of it. Put bluntly, it's a landmine.
Which is fine for things like Xbox 360, since you'd seldom be using .NET binaries compiled for Windows on the 360, but as for Windows binaries on Server Core, that'd likely happen every day.
PowerShell for instance would be a good example of something that might suddenly break in latter versions. What if the PowerShell team suddenly decides to make low-level support for CardSpace in the next version? It would break on Server Core, and they'd have to stop offering it as their primary/daily use shell, forcing the whole community to resort again to VBScript and cmd.exe, thus making all of the PowerShell scripts written for version 1 on Server Core unusable.
|
|
|
|
|
.NET 1.0 requires an IE update, too. System.Windows.Forms.WebBrowser was introduced in .NET 2.0. I assume some other parts of .NET depend on the Windows explorer or some other shell libraries (which are updated together with IE).
And there's no reason the non-GUI parts of .NET 3.0 should not work on Server Core.
I agree that naming WinFX .NET 3.0 is a bad choice, but I don't think WinFx makes .NET less modular.
|
|
|
|
|
Implementation wise, yes, there are a few other things that might, like the crypto services and maybe even System.Xml. But Microsoft does have managed versions of those, used by things like Rotor and Singularity (maybe not Rotor; I can't remember). Also, I'm pretty sure the high security package and MSXML can both be installed on Server Core.
There are a lot of non-GUI stuff in .NET 3.0 as well (which is why I brought up CardSpace), but in all likelihood, they depend on higher-up Win32 functionality that probably would't be implemented on Server Core.
This being due to the simple fact that WinFX was, until just a few months ago, being developed by its programmers with the assumption that it will only be running on XPSP2, Server 2003 and Vista.
The problem is more potential risk than immediate consequences, which in terms of business, is bad enough. I'm sure with a mess like .NET 3.0 in the framework, I'd be wary of using it until I sat down with the implementors and was personally convinced that it can be implemented in time for V1.
|
|
|
|
|