Slashdot Mirror
Microsoft Next Generation Shell
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)."
Don't fix it if it isn't broken.sh, bash et al work just fine.
Oh come on now, they ripped it all off the first time, they just did it poorly. Now they are fixing their mistake and copying the whole damn thing.
- The word is a virus.
All my friends who learned to program computers (ok, Windows) in the 90's think it strange that I keep one or more command prompts open to get work done. Besides having 'grown up' with prompts, my argument is that the core of programming is algebra+logic, and text makes a pretty good notation for both of those things... it's a much better graphical notation than anything developed in the last 40 years. So it's heartening to see even MS come back around to the way things were.
MS is #1 for a reason: they do what the users want. Sometimes it takes a while, but they have to prioritize, and usually, it gets there. If this shell is as good as they say, and it can be a part of W2K, they're going to absolutely pummel any competitors on the server end. This was one of the last holes they had to fill. They've got stability, they've got security, and now they're gonna have good scripting. Wow. Who would'a thunk?
This is a good step, but what good does it do to have a top notch shell, when the vast majority of windows programs are gui based?
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.
Neither Win2k nor NT 4.0 are microkernels. Read "Inside Windows NT" by Helen Custer. They explicitly state that NT has some MicroKernel-like features but that's it.
Look, in contrast, at the "next generation UNIX shell", rc, from Bell Labs. "rc" intends to simplify, remove unnecessary functionality, and factor out features like job control and command line editing.
For years now MSFT has said that their platform is more user friendly by providing nice GUIs for all admin modules.
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.
This and all of the similar idiotic comments just goes to show how little the /. crowd knows. Reading even the summary of the article shows how untrue this is. bash has command discovery via reflection API's? Really? It can discover commands by any other mechanism than searching the path? I think not.
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.
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.
That is what I found more interesting than the job description itself....
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
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.
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.
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]?
For YEARS they have been slowly but surely killing the shell world. They were so prone on such trend that they:
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.
Because I don't have one. I don't want to go and get one either. Really, why would I want to learn how to use a piece of new software when the CLI version does it perfectly well?
the reason most folks think XP does not crash is becasue rather than trowing up a BSOD, it just reboots the machine. I have had that happen about 3 or 4 times.
I am the Alpha and the Omega-3
So they are going to sell us an operating system, whose API was originally designed as a graphical user interface for DOS, then ported and somehow upgraded to run in hybrid real/protected mode but still on top of some DOS (called Win32), then patched to be multiuser-capable and ported onto a kernel which was originally meant to be something like VMS w/ an OS/2 API until they hacked a Windows API into it (and renamed it as Windows NT), and finally packaged with a pile of user-space programs which let this crap look like a unix shell?
...
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?
"Given enough time and resources, Microsoft will eventually invent UNIX."
Tired of FB/Google censorship? Visit UNCENSORED!
Is this going to open up a can full of worms for security on windows systems?
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.
Yeah, beautiful. And the first time some script kiddie figures out a buffer overflow in MicroSoft Outlook.NET that automatically runs the contents of an email attachment as a shell script, with said 'tremendously powerful and coherent' scripting and shell environment? Where said script kiddies don't even NEED to attach an .exe or .scr to the email, they can just embed some script as HTML comments in the message itself and pipe it to c:\winnt\system32\bash32.dll?
.NET does runlength-checks on every single buffer read, and all .NET applications process their data at the lowest security level necessary to accomplish their task.
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
-Hentai [in vita non pacem est]
They have everything to do with Cygwin. If they had provided halfway decent shell and command line tools there would have been little reason for Cygwin to be created.
--
"What do you want me to do? Whack a guy? Off a guy? Whack off a guy? Cause I'm married."
- 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.
Washington, DC: It's like Hollywood for ugly people.
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!
--- Nothing clever here: move along now...
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.
[Set Cain on fire and steal his lute.]