Microsoft Next Generation Shell 832
An anonymous reader writes "I found this while searching for Perl Jobs in India:
"The Microsoft Next Generation Shell Team is designing and developing a new command line scripting environment from the ground up. The new shell and utilities, based on the .NET Frameworks, will provide a very rich object-based mechanism for managing system properties. To be delivered in the next release of Windows, it will include the attributes of competitors' shells (e.g. aliases, job control, command substitution, pipelines, regular expressions, transparent remote execution) plus rich features based on Windows and .NET (e.g. command discovery via .NET reflection API's, object-based properties/methods, 1:many server scripting, pervasive auto-complete)."
Hello, HAL do you read me? (Score:1, Insightful)
Re:Woohoo (Score:1, Insightful)
So, we're back to the 60's. (Score:5, Insightful)
MS is responsive: that's why they're #1 (Score:1, Insightful)
Good step (Score:5, Insightful)
Are they going to release command line versions of most of their administrative tools?
Any windows sysadmins out there feel free to correct me if I'm wrong, but its generally not the lack of shell features that keeps me from using cmd.exe, but rather the number of programs that you can run with it.
Re:So, we're back to the 60's. (Score:3, Insightful)
Re:Starting to sense a pattern ... (Score:2, Insightful)
they'll screw this one up as well (Score:5, Insightful)
Look, in contrast, at the "next generation UNIX shell", rc [bell-labs.com], from Bell Labs. "rc" intends to simplify, remove unnecessary functionality, and factor out features like job control and command line editing.
Re:Wasn't the CLI have disappeared? (Score:3, Insightful)
Contrary to popular belief, Windows98 is not a server operating system, it is a end user/consumer OS.
For a Server OS it makes a whole lotta sense to have a powerful CLI, for a end user OS, not as much.
I know this concept of seperating the two might seem strange and frightening, but it does reduce the number of support calls asking: "Should I type <appname> /xcc -cvx /gsg -fjhghsjh /vnbbxcxoOfjnf" or is it "<appname> /xcc -cvx /gsg -fjhgHsjh /vnBbxcXoOfjnf"?
This validates the UNIX way of doing things ... (Score:5, Insightful)
For them to turn around and now build this super-shell basically amounts to admitting that a GUI based aproach does have some serious shortcomings and that the UNIX way of allowing everything to be scripted provides serious benefits which are hard to come by if everything is accessed through a GUI. If nothing else, this validates the UNIX way of doing things and should make it easier to argue this point when competing for (a) large (number of) server installs/farms.
Re:What the... (Score:2, Insightful)
They're talking about discovering which objects are installed on the system and finding which API's those objects expose, all from the command line. Sounds very much unlike bash to me.
I currently use cygwin bash and bash on FreeBSD, and the description of this new MS shell sounds way better.
This really goes to show why Windows will "win": Everything Windows does could be done on a Unix box. Absolutely everything. But it isn't, and it won't be. Here's why: There's no agreement among the developers on the Unix platforms. Sure, I could write a command shell on FreeBSD that has some sort of similar discovery mechanism, or I could write a GUI and a few apps that allow embedding parts of spreadsheets inside of word processing documents, but what have I gained? Not a whole lot. No one else will follow my lead, so my work will die. On Windows, MS does a reasonably good job of things like this and all applications jump on the bandwagon, and the users profit from it.
Re:you are absolutely right (Score:4, Insightful)
Leaving aside the question of what a "very solid GUI" might be or whether Microsoft can even remotely be argued to have one, you are ascribing too much long-range planning to Microsoft.
Microsoft responds to the market like a leaf in the wind. All their various approaches to GUIs were driven by a panicky reaction to competition. Their first GUI was a reaction to Macintosh. MFC was driven by the success of competitive object oriented GUI libraries. The 3D look was a reaction to Motif. GUI builders were a reaction to third party tools and NeXT. RDP was an attempt to clone X11's remote access features. And their latest, C#/CLR is basically a Java clone.
Now, Microsoft feels extremely threatened by Linux, both on the client and on the server, and they are desparately trying to clone the essence of Linux so that their servers won't become completely irrelevant.
Microsoft doesn't plan or strategize anything for the long term. Microsoft is driven by paranoia, "not invented here", and the usual geek attitude of "if we implement it, it will be better". Nothing could be further from the truth, of course.
Re:Development in India (Score:3, Insightful)
Re:Good step (Score:5, Insightful)
If you want to compare this to existing non-MS projects, this sounds like a combination of bash and BeanShell [beanshell.org], rather than a simple shell replacement.
If this achieves its potential, Linux/UNIX may end up playing catch-up on the CLI front as well as on the GUI front. Good move for Microsoft, and one that would be hard to counter in the open/free software world because we have no universal object-based virtual machine/interface for use as a basis.
Or rather, I should say we have too many - Java, CORBA, the Mozila components, and even
Re:Responsive!? (Score:4, Insightful)
That's how business works. You can't make every customer happy. That's impossible. Gap can't have a rack of clothing designed to perfectly fit every single individual that comes in there. Not possible. I have a small store. I can't have *every* item that every customer has ever asked for. That's not possible, either. But, at the same time, you DO make money by making as many of your customers happy as possible. That makes 'em buy. Kinda' basic. Contrary to the popular Slashdot opinion, MS doesn't have legions and legions of pissed off customers. If they did, then Apple would be huge today. So I agree, making customers happy alone isn't a sufficient reason, but it is a major part of deciding what to implement when.
Re:Responsive!? (Score:4, Insightful)
Bill said many years ago that he doesn't assign programmers to projects unless the project will make money for Microsoft or advance its strategic goals. Making customers happy is not a sufficient reason.
Do you really think that BillG got to be worth $40 billion by making customers UNhappy? Do you really think that 93% of all end-users are masochists? Do you really think that people in a free market choose of their own free will to buy inferior products?
Or do you suppose that Apple [Macintosh] & NeXT [NeXTSTEP] & Commodore [Amiga] & Novell [DrDOS/NetWare] & Digital [RSTS/VMS/True64] & Sun [SunOS/Solaris] & IBM [OS/2] & Linux [Gnome/KDE] couldn't [and, to date, still can't] get their heads out of their asses for long enough to give the consumer he wants: An inexpensive platform that allows him to copy from a text editor, paste to a spreadsheet, and vice-versa, without having to go back to school to get a goddamned PhD in the minutae of Bourne Shell scripting [much less artificial intelligence, LISP, and emacs]?
Re:So, we're back to the 60's. (Score:4, Insightful)
-dk
Re:MS is responsive: that's why they're #1 (Score:1, Insightful)
Nope, that's not it. Can you spell m-o-n-o-p-o-l-y?
Sometimes it takes a while
Yeah, like two decades! You call that responsive?!
They've got stability
That remains to be seen. So far their track-record has been rather at the other end of the scale...
they've got security
Yeah, right. In what parallel universe? Also, if they're to add "transparent remote execution" you can bet your furry ass there's about as much security involved as the average MS VB programmer can use.
bool verify_user(char* psz)
{
char sz[12];
sprintf(sz, "%s", psz);
if (password_checksum(sz) == 'BAAD');
return true;
return false;
}
Who would'a thunk?
As I recall it MS already did - the thunk compiler to get into 16-bit code from 32-bit.
Re:So, we're back to the 60's. (Score:1, Insightful)
Can they get serious? (Score:3, Insightful)
Didn't develope its command line interfaces since the beginning of the 90's.
Didn't support implmentations of more advanced scripting tools like perl or python.
Claimed for years that shell suxxx. They marketed their system as a growing evolution from the crippled shell environment.
Granted that, in the future, all management would be through the GUI.
And now I am hearing that they are getting back to the start?
Interesting. I have seen several interesting things while I developped for Windows. and one of the things I was pretty sure, was that implementing shells or scripting tools was hard. Perl (native Win32) or bash (through cygwin) gave me always a sense of a certain handicap in relation on the *NIX world, where most of its control was based on the existence of shells. I could not get into the inner mechanics that ruled many Windows apps because their data was never supposed to be handled directly by shells. Note that many apps produce binary data, even when there is no clear need for it. So, if one needs to use perl or something similar to handle Windows data, one usually needs an interface or some tweaking on files. And, due to the fact that Windows lacks established standards for (almost) similar kinds of data, one needs to deal with different tools to deal with each piece of data.
A similar situation occurs also with file formats. Sometimes, the format of different versions of one and the same program varies so radically, that one is forced to deal with different interfaces for each version. That's also one of the reasons whyscripting tools didn't gain a wide acceptance in Windows.
Also one problem is that many programs on Windows base their interaction in a memory-to-memory basis, while *NIX still keeps a lot of its interchange in a filesystem basis.
So I am scheptic that M$ is able to do a serious move on this field. However I may understand why they are moving with a new scripting system. Frankly, with all the mess they created, perl and many other tools will never be able to have a fullscale use on Windows like in *NIX. But that depends on how far M$ will go on the development of this new system. If they will create some sort of Easy-VB-like scripting tool, it will not catch the souls of sysadmins. If they create a full-scale mutant like perl, they risk to give a new weapon for script-kiddies, but sysadmins will surely catch the wave.
Re:So, we're back to the 60's. (Score:2, Insightful)
What if you don't find your exact 'do it!' button? Settle for less?
Re:Good step (Score:4, Insightful)
Re:Learn how to use your apps (Score:4, Insightful)
Re:sorry, but this won't help Windows either (Score:2, Insightful)
Re:MS is responsive: that's why they're #1 (Score:1, Insightful)
Re:So, we're back to the 60's. (Score:5, Insightful)
Efficiency is not the only consideration. Sometimes you want to concentrate all of your thinking on your overall goal and not get bogged-down in reinventing the wheel.
Some programmers have a deeper mental stack and don't find working at multiple levels at the same time a problem. It's a great gift that they share with some movie directors and short-order cooks. It's useful but doesn't guarantee you'll write great code, win an academy award, or become a great chef.
Finally, I think some of the CLI worship is misplaced. Some people think movies are more artistic because they were filmed in black and white, but the reality is that most B&W films were done that way because color was either not available or too expensive. Similarly, many of the approaches taken by Unix and 'C' were done based on the severe limitations of the times they were invented in, not because their creators believed those approaches would be the best forever.
Re:So, we're back to the 60's. (Score:2, Insightful)
My parents just bought a digital camera. They asked me to show them how to use it. No problem.
But then they needed to know how to download the images into a coherent directory structure, create thumbnails, etc. Problem!
So I installed Cygwin on their system and wrote a script. Now there is an icon on the desktop that does it all - via script.
The fact is, giving someone directions on what to click, pull down and select, create a folder, etc, is imprecise BS. Especially when you are talking about creating files, naming directories based on the date, etc.
It doesn't matter if it is your Mom or a junior admin.
Vendors often think it is all about the GUI. But in every serious environment I have worked in, the engineers want to script everything.
Unix poorly faked (Score:2, Insightful)
There is so much missing in NT compared to Unix. No VFS-like filesystem, no symbolic links, no device nodes, no setuid/setgid, no privilege sets in the filesystem,
Even if you add a really powerful shell environment, it still can't compare itself to modern Unices.
Why don't they throw it all away and build a REAL unix instead of bending some wannabe-unix-stuff round a broken Kernel/API design?
Does a so-called professional server- and/or development-platform really need to be compatible with Windows 95/98/ME/Win32?
Remember this classic line? (Score:3, Insightful)
security. (Score:2, Insightful)
Re:wonder what this means (Score:3, Insightful)
The problem I was thinking about wasn't actually related to glibc (which actually doesn't break binary compatability at all, it uses symbol versioning) or gcc (which was only for C++, and hopefully will not break binary compatability again now it's standardised).
I'm mainly thinking of the problem that the link tree always has to be identical to the system a binary was compiled on. For instance, if you have a frozen bubble game, which was compiled against libpng3 and libSDL, then you run it on a distro where libSDL was compiled against libpng2, then two ABI incompatible versions of libpng will be linked into the same address space and you'll get an instant segfault.
Well, those sort of symbol collisions can be 95% resolved by either making everybody use symbol versioning (hard) or applying some patches to the linker and ld (easy, but libc maintainers won't do it). But you still have problems if for instance frozen-bubble passes structs between the 2 versions of the library.
I think the real solution in the long run is for people to stop using C for writing libs and apps. Higher level langauges that can do reflectivity (python/ruby/java/.net/in fact, anything other than C/C++ basically) don't tend to suffer ABI problems in quite the same way, and we'd all have higher productivity anyway.
But there are problems with trying to write everything in such langauges. I've got ideas for how to solve them too, but can only tackle one thing at a time, and pulling people away from C is going to be very hard. MS can sort of do it through sheer marketing will and forcing Windows in that direction, even for them introducing .NET will take years. We can't do that though, it's not so easy.
Re:Cygwin (Score:2, Insightful)
Every time Microsoft adds 'new powerful functionality' to its products, they're creating another exploit waiting to happen - until they fix their fundamental security model.
Let's hope to God
Re:Cygwin (Score:2, Insightful)
Way to Go, Microsoft (Score:5, Insightful)
- Having both Gnome and KDE is good because the competition will cause both to get better
- Having a Linux/UNIX desktop environment is good because the competition (with Windows) will cause both to get better
I've seen these kinds of arguments spouted repeatedly by purveyors of the Slashdot party line, and I've even made a few myself. What we have here is a confirmation of the underlying idea: that competition improves products.Plan and simple, Microsoft is competing. They've acknowledged a strength in a competitor's product and are (finally) going to tackle it head-on instead of with shady business, cash, and lawyers. They're going to try to build a better product. This is what we've wanted all along, isn't it?
I wish Microsoft's programmers the best of luck in creating these new features. They will most likely be a great improvement to the Windows platform. Likewise, I wish the Linux/UNIX communities the best of luck in creating new features to greatly improve Linux/UNIX. I believe that competition between the two groups will significantly advance the start of the art in software. Microsoft is ready to play serious but fair ball, and it's up to the rest of us to build a winning team and play the game. Humanity stands only to gain.
Promises, promises (vaporware and monopoly) (Score:3, Insightful)
Ha, ha: only serious...
Just in case you were working on something to solve a shell problem, just stop, because you can't compete. I mean, this is Microsoft, and nobody will believe that you can put out something that works better than theirs.
Even if you do actually accomplish that feat. Even still, Microsoft will trace the API calls your shell makes and pull the rug out from underneath you in the next automated .NET framework service-pack.
Then, they'll link their knowledgebase to promos of their product so when your customers search for a solution to why your shell started behaving badly (just after the ServicePack was applied), they will see "use the Microsoft shell". Next, your boss will get a letter explaining that Microsoft is attempting to purchase the rights to your project, and all your boss has to do is kill your project to collect more money than they've ever paid you (and prolly some killer seats at _insert_big_sports_event_here_).
Next, you'll probably end up contributing code to some consulting firm that agreed to make the Microsoft shell do what yours already did. It'll cost 20 times as much, and it'll be 1 year past the delivery date you would have made, and by then you'll be sick of dealing with the problems your shell intended to solve.
You'll try to move on to something else, but every where you go, no matter what you try to get into, the same old shell scripting problems will stymie you because NOBODY solved the problems that Microsoft promised their shell would solve. It will haunt you until you completely switch fields or commit suicide, or some other depressing and too-boring-to-enumerate possibility.
There is no monopoly in Unix implementation. Stick to Unix if you don't want to hire (or be) a staff of service-retarting, server-rebooting, reinstalling monkeys to do boring repetitive click-and-drool tasks at the console of a server , in what was *supposed* to be a lights-out data center, checking blanks on the left margin of of a mainframe-era "run book" as they (you) go.
Happy new year!
Re:So, we're back to the 60's. (Score:2, Insightful)
I do however disagree that it is faster using pure command line.
As a graphics person (and handy with scripts and recording commands)it is a rather simple task to simply select "Convert to Thumbnail" from my GUI's command menu (which I setup and have complete control over), 2 clicks.
I can also link my command to a keyboard shortcut, which makes it even that much faster. (unless you can do this with command line, this feature in itself makes it faster and easier than any command line control)
On top of that I can make my own GUI control elements which in can throw in dozens of simple controls to give me ultimate control and immediate access to any setting, filter or other scripted commands.
Another handy feature I have access to is recording steps and playing them back as a script and command. This is standard in Photoshop and Fireworks.
So we are both doing the same thing, running a premade script to do work for us. Only I can stay in the GUI where I did the image manipulation and not have to jump to a seperate command line window for this.
The only real difference that I see is that of typing out a command or simply clicking on one.
-v
Re:Cygwin (Score:2, Insightful)
This has got to be the blandest understatements I have ever seen on slashdot.
I use Windows for many things and think Visual Studio is an excellent development environment. It is what emacs should have been. That said, I've never really felt at home in Windows because of the awful, dane-bramaged, evil, despicable, cluster that is the Windows console command shell.
Cygwin makes it a little better, but does not interoperate with Windows in many ways that you would expect. eg: shortcuts are not symlinks, endline conventions are not handled invisbly, drag and drop not fully supported, cut and paste still limited by native console libraries, etc.
Python also goes a long way to automating tasks like dumping excel spreadsheets to csv format, find and replacing a name in a large number of documents, etc.
I hope Microsoft can deliver all this with a single set of tools. I'll certainly use it.