Slashdot Mirror
A Guided Tour of the Microsoft Command Shell
jpkunst writes "Ryan Paul at Ars Technica provides an in-depth, 13 page review of the new Microsoft Command Shell (Monad). (The beta release can be downloaded for free from Microsoft.) From the conclusion: 'Despite my initial skepticism, I am deeply impressed with MSH technology, and I am legitimately excited about the future of the Windows command line.'"
Has any project been started to provide an open source clone, similar to what the Mono Project has done with .NET?
Cyric Zndovzny at your service.
A witty saying proves nothing.
- Voltaire
It's worth mentioning here that the real strength of the pipe is not "what you can pipe", but "what you can pipe things from, and to", and the fact that you can daisy-chain them together as far as you like. There are literally thousands, maybe tens of thousands of little tools and widgets that you can pipe information into and out of to achieve various effects. Regardless of what new things the MSH pipe can do, the unix world has a significantly larger toolbox.
Mike Hoye
Are you talking about the new Vista UI?
:-)
In that case, that's a visual style that's changing only the aspects of the UI Windows XP changed. Windows border styles and new flashy button hover effects, etc. Think of it as a different theme/skin, not a way for them to change the UI design guidelines. "OK" will still always be followed by "Cancel", group boxes will still group UI elements with a relation, menus will still be part of the applications and not the dsektop, combo boxes will still be recommended only in "little space" situations, and so on.
Actually, Microsoft has released preliminary design guidelines for Vista, and I was surprised to see how much can be directly applied, and is even recommended to be applied like that, to Windows XP.
Also, even in Windows Vista, just like in XP, can you still apply the Windows 2000 look & feel via a flip of a switch. That if anything should show that all they're really doing are mostly just applying new skins to sell their product, and not coming up with new guidelines that indeed would alienate their broad customer base. If I'm at some user that have applied some simple settings, I often lose myself in thinking I'm working on a Windows 2000 workstation when I'm in reality on XP.
Beware: In C++, your friends can see your privates!
For a long time, it has been proud of his UI technologies, and thought the UNIX shells are too complicated to most people. As for the genernal people, it's right indeed; but it's not true for those developers that want to perform some customized tasks through some kind of relatively easy method.
The real problem is, Linux has been attracted more and more developers, it's absolutely dangerours to the Windows future. it must do something to change this situation, as a part of a series of actions according its plan.
-- forgive me my poor Engl...
I kill me.
Seriously though, the design of MSH is odd. Their hybrid of paradigms from functional programming and OOP is just weird and inconsistent. Having completely different syntaxes for invoking "Commands" and "Methods" is obviously a byproduct of trying to have both a traditional shell syntax and OOPy goodness, without thinking much about internal consistency.
Typical Microsoft: very use-case focused, at the expense of helping their users build a consistent mental model of how their system works. I bet it's pretty hard to do anything in MSH that its designers didn't specifically anticipate.
It looks just like eval.rb the interactive ruby shell:
http://www.rubyist.net/~slagell/ruby/strings.html
ATH0 Bitcoin: 1DnwFLXczVZV8kLJbMYoheUrpqHesjxrSi
Followed closely by: It's a security nightmare waiting to happen. If people think BASH viruses are a potential problem then imagine the full horrors of ActiveX with access to a system shell. At least Mozilla exploits don't lead to "rm -rf
fast as fast can be. you'll never catch me.
I've studied the new UI quite a bit, and you, sir, are clueless.
.NET object, everything inherits from another object. The entire thing is texture based, like OS X.
.NET, is to have a framework to build off for the future. Like .NET, too, the new UI is well-written. I've been programming for it for half a year now and it blows Windows XP out of the water. It even tops OS X in a few areas.
Are they keeping things like "OK" and "Cancel? Yes. Are you able to change the look back to Windows 2000 (well, sort of). Yes. They do things like this so people don't need to totally retrain.
Is the user interface anything like Windows XP, under the hood? No. God no.
The entire thing has been rewritten from the ground up. Everything is a
What this means is they CAN make drastic changes down the road by simply changing a few objects. Everything will inherit down. Ever notice that buttons can be totally dissimilar from one app to the next, and all MS has been able to do is (for example) but a blue highlight around them? That's because the UI has been so cripped.
The new UI is simple, beautiful and brilliant. Is it completely different than Windows XP? No. It's not intended to be. The goal, like
Hypothetically: What if MS pulls it off and puts out the best OS that the Linux guys have ever seen. Let's say it's the Longhorn Server, WinFS, Monad, and everything MS has been touting works... Will the Linux guys at that point stop bashing MS? Will you consider using the MS OS?
You're attempting to formulate a "what if" scenario, but as often happens you've oversimplified things on such a scale that it is meaningless. Linux admins do consider using MS products now, and deploy them occasionally where appropriate. As for "what if MS put out a better OS" well, I guess that depends upon what you mean by a better OS. The case for Linux vs. MS is both technological and business. Suppose the next version of Windows is technologically on par with, or better than, Linux as a server. It will still suffer from not being free of cost, not being customizable by the end user, locking the user into a single supplier for a critical component of a system, and putting customers in the position of having to deal with a company renowned for putting it's customers out of business using unfair tactics. No smart businessman wants any of those things. Even so, in some cases it makes sense to put up with those problems, and that is what smart administrators do.
For example, If I run a smaller business and need specialty software only available commercially on Windows and I don't have the resources and contacts necessary to build a open solution on an open platform, then it makes a whole lot of business sense to buy a Windows machine, at least for that one component. If, on the other hand, I'm working for IBM or a company with similar resources, there is rarely any compelling reason to go with MS for anything, since the resources are available to get a better long-term ROI and TOC by using open source solutions. Why lock oneself into paying a competitor every year, with no competitive bidding, when for a slightly higher initial investment a free alternative, with free development, and some free support can be created, that also places IBM in the position of being a market leader in that particular niche and ties into the bread and butter services business.
A good analogy might be, you invent a new desert pastry and it needs a fruit filling. You can use oranges, which you can get from any number of vendors, or grow yourself or you can use MSFruit which is patented and you can only buy from one supplier. Even supposing MS gains the edge in harvesting and processing technologies, does it make sense to sign a contract to use them as your sole supplier and agree to never alter your recipe or does it make sense to invest in better harvesting and processing technologies and keep using oranges so that you can take competitive bids and experiment with new recipes?
Of course, as you said, this is all theoretical. MS is so far behind other solutions in so many areas that they have not even tried to address that it is unlikely MS will catch up any time soon. The fact that they keep introducing anti-features designed to benefit MS as a company and cost customers extra money somewhat counters other advances they make. They pay a lot of attention to bullet points and making things "good enough" while not really achieving that for a good portion of users. They have a few nice features that I'd say are better and more usable than anyone else, but at the same time they are really really behind in other areas and falling further behind all the time. Don't call me when they have pipes and scripting that work without writing any code and from the GUI. Don't call me when they allow programs to offer services to other programs. Don't call me when they fix the disaster they call managing programs. Don't call me when they no longer expose network services by default. Don't call me when they move to open APIs. Don't call me when they open and document their formats and support other open formats. Don't call me when they have workable non-admin accounts. Don't call me when they make the UI responsive during heavy multit
A shell is nice but, can you change all the settings from the command line? The fact that most of your settings are stored in the registry, makes things a lot harder to do from the command line.
.ini files ten years ago what happened to the KISS principle? They did a good thing when they invented the "Program Files" folder and instructed developers to install their program folders there. Why didn't they just make another directory called "System Settings" and specify a standard .ini file format at that point?
/etc directory then you'd be right--it's worked for aeons so why complicate things by re-inventing the wheel? The concept was sound it just needed fine tuning. Then MS wouldn't have had to make a special utility to manage system settings at all if it didn't want to.
.config XML files stored in the same folder as the application's executable. MS is deprecating any tools they had to deal with the registry in favour of this method of managing system settings.
.NET libraries that make it much easier to do GUIless application developent and allow you to do it in many different languages (although if you look at VB.NET it is more of a CLR dialect than a distinct language anymore--esentially C# without semicolons and a handful of BASIC
Very valid concern regarding the Windows platform. You can indeed do most of what you need to do in Windows through a command line if you are a guru, however without Monad Windows command-line capabilities are extremely weak. Regedit can be used at the command line, however it is quite cumbersome--especially if you must browse the registry. The whole concept of the registry puzzles me actually--here is this obsfucated, hidden, monolithic configuration file that holds all this important system information and if it were to be corrupted it could potentially make the machine unusable. In order to manage it, MS spent the time to greate this regedit program to decode the registry and present it as...a filesystem-like tree structure. Good Lord, what the hell for? When MS was addressing the problem of
If that sounds almost like a UN*X
Fortunately MS has seen the light and it appears that they are trying to quietly re-invent Windows in the image of UN*X. Of course, they won't admit their mistakes and copy UN*X/Linux design outright--they are re-architecting Windows using the same concepts but their own dialects (and in some cases they are making improvements to those concepts). This means that Microsoft can claim to be "innovating" instead of fixing bad design decisions. Some examples of the direction MS is going:
* Monad--an "object oriented shell" that brings a modern image to a very old idea. MS is acknoledging that the command line really IS a good adia and not obsolete, and that it was a mistake to neglect its command line shell. The object oriented approach and consistent interface is a modern solution to a problem originally solved in part with pipes in UN*X. Python provides an object-oriented shell on that platform now--but MS just polished the idea a bit and made the whole shell solution more unified.
* XML-based config files. You won't ever hear Microsoft admit it, but the system registry is a flawed concept and the implementation in Windows was so bad it was a significant source of relaibility and security problems. If you look hard enough in MSDN literature and in blogs, you will find that MS is quietly pushing developers to eliminate their dependency on the registry in favour of
* Microsoft has been slowly expanding developer options for creating GUI-less applications (services and console apps). Prior to VS.NET (right up to version 6) to do so required using C or employing awful, unsupported hacks (anyone who has tried writing a VB6 console app or service knows what I'm talking about--the required hooks into low-level Windows APIs make the result so ugly you are best advised to give up and use C anyways). Now MS has the CLR and