Emails from the Edge; The Hodgepodge Version

More emails from the Peninsula Pal:

Mo,

It takes a number of references and correlating what's said to assemble a picture between what MSTF is doing behind the scenes and what they are presenting to the public. MSFT has broken the discussion up by keeping "designers" (folks who work with format and content) in one part of the software construction task and developers (folks who build functionalities) in another.

Powershell is MSFT's attempt to fit their system with a text command and parameterization system so machines may simply exchange strings of text to run the system rather than being piped up by developers to appropriate graphic modules.

http://www.betanews.com/article/Why_Cant_PowerShell_Be_the_Windows_Command_Prompt/1179385810

Last year, when Microsoft revealed the development of Server Core - an optional Windows Server setup that omits the graphical environment in favor of a command prompt, for use in limited server roles - admins wondered whether the command prompt in question would be based on old-world DOS or new-world PowerShell.

The answer was disappointing, but the reasons were sound: PowerShell is a managed application, based on the .NET Framework which, for now, requires the graphical environment. So Server Core's command line would be CMD.EXE.

But is that the way things will stay? At WinHEC, BetaNews asked Windows Server 2008 product director Iain McDonald (one of its developers, as opposed to a product manager who works in marketing) about his goals for PowerShell in Server Core.

Admitting that this was his personal preference and not that of his division, McDonald responded to a question from BetaNews, "Personally -- this is biased -- if I could set the direction of it, I would like to make PowerShell the default shell for Windows. That's my personal bias." He added he doesn't expect his preference alone to set the direction of the product for the next couple of years, although he would like to see it replace the basic CMD.EXE command shell.

For now, Server Core has its own command set, including .EXE functions that operate from the command line. Would McDonald plan to alias those functions when PowerShell does become available for Server Core, so that admins won't find themselves making yet another lexicon shift? "I would like to do that," he responded.

http://it.slashdot.org/it/07/05/02/1336216.shtml

Above is an important thread to unravel what MSFT has been doing to keep their developers ignorant all the while they were hiding .Net xml cross-platform capabilities.

Sorry to keep bombarding you but I think if you simply post this (from the URL I just sent you) the evidence will make itself known: "abuse of it's developers by pretending .NET was a true cross-platform framework they're doing everything in their power to stop it from being just that"... "Even more interesting is one of the comments on that article linking to legal documents in which Microsoft employees discuss the (im)possibility of creating a cross-platform code and UI framework, years before the .NET project even started!"

Enjoy!

http://it.slashdot.org/it/07/05/02/1336216.shtml

Posted by CmdrTaco on Wednesday May 02, @10:08AM
from the write-once-run-everywhere-that-is-windows dept.

Michelle Meyers writes "Just days before Microsoft claimed to be making parts of the .NET CLR "available" to other platforms, NeoSmart Technologies had published an article bemoaning and blasting Microsoft's abuse of it's developers by pretending .NET was a true cross-platform framework when they're doing everything in their power to stop it from being just that. Of interest is NeoSmart's analysis of how Microsoft has no problem making certain portions of .NET available to Mac users — just so long as its distributed under an "open source" license that forbids any and all use of the code except for educational purposes — yet are terrified of the very thought of .NET being available to *nix users, even if that's to the benefit of .NET developers everywhere. Even more interesting is one of the comments on that article linking to legal documents in which Microsoft employees discuss the (im)possibility of creating a cross-platform code and UI framework, years before the .NET project even started!"

Just a few randomly picked Comments:

Re:Does it matter?

(Score:5, Insightful)

by Ucklak (755284) on Wednesday May 02, @11:12AM (#18957199)

Cross platform for Microsoft means it will work on Windows, Xbox, and mobile devices that run Windows.

It's just another word to ignore when Microsoft says it versus say Samsung when their printers are cross platform which means Linux/Mac/Windows.

Re:Does it matter?

(Score:4, Interesting)

by Rob Y. (110975) on Wednesday May 02, @02:30PM (#18960383)

...was just a ploy to take some of the wind out of Java's sails.

Absolutely right. Microsoft was originally pushing .NET as a 'better Java', and in some ways, it actually was better. But in the way that really mattered to most Java developers, it was much worse. Its cross-platform nature was the main appeal of Java. Yes, the language may have been viewed as an improvement, and the 'managed code' approach to security is nice. But 'write once, run anywhere' was the main selling point of Java.

So how did Microsoft 'compete'? First, by deliberately sabotaging the cross-platform nature of Java, and Second by implying that their Java clone was cross-platform as well.

And the saddest part is that if Microsoft had been broken up by the Justice Dept when it should have been, .NET probably would have been made truly cross-platform. Then it could have competed honestly with Java.

Re:So C# is .Net?

(Score:5, Informative)

by digitig (1056110) on Wednesday May 02, @11:13AM (#18957213)

No. As I see it (and there's more than one way to see it) .NET is essentially an API and virtual machine offering that API. C# happens to be a high level language that maps very closely onto the virtual machine language, but in theory any language can compile to that machine language (and many do -- C++, Java, VB, Python, Ada, Eiffel, and so on). I like it as an API (at least at version 2.x), the VM makes multi-language programming a cinch, its memory manager really does seem to eliminate a lot of classic memory bugs, and its deployment model moves away from huge, centralised registries. But it comes at the expense of bloat and the speed penalty of an extra layer between the code and the metal. IMHO that's a reasonable design choice to have to make. If you're developing for MS Windows I reckon .NET is a decent design choice as long as you're not particularly size or speed constrained. If you're developing for anything else -- well, try starting here: http://it.slashdot.org/article.pl?sid=07/05/02/133 6216&from=rss [slashdot.org].

Re:So C# is .Net?

by mabhatter654 (561290) on Wednesday May 02, @10:50AM (#18956843)

I view .Net as Microsoft's version of RPG. IBM still doesn't sanction moving RPG anywhere except AS400/iSeries/i5 and I wouldn't expect them to ever. I see .Net as Microsoft putting themselves in a smaller box so they can move from low cost commodities to high(er) profit support contracts and perhaps non-configurable hardware. They seem to want to be like "so-and-so" but not actually do business like that.

I think the biggest problem is that too many people outside want to make the Microsoft stuff work for them and it's just not practical.. look at Mono. First, it's a waste of resources that could be used on ruby, python or smalltalk based solutions. Second, it's just stepping into Microsoft's arena of IP and marketing "bait-n-switch". Novell will never win trying to "bargain" with the devil.