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)."

Comments

Cygwin

[TheShadow]

I liked this the first time... when it was called Cygwin.

Re:Cygwin

[Anonymous Coward]

I liked this the first time... when it was called Cygwin.

For those whou don't know, Cygwin is a UNIX environment, developed by Red Hat, for Windows. It consists of two parts: (1) A DLL (cygwin1.dll) which acts as a UNIX emulation layer providing substantial UNIX API functionality. (2) A collection of tools, ported from UNIX, which provide UNIX/Linux look and feel. The Cygwin DLL works with all non-beta, non "release candidate", ix86 versions of Windows since Windows 95, with the exception of Windows CE.

Other thing which I'd suggest for anyone who is unfortunate enough to work under Microsoft Windows is Perl Power Tools: The Unix Reconstruction Project. The goal is quite simply to reimplement the classic Unix command set in pure Perl, and to have as much fun as we can doing so. See the command list.

(I post as AC, because I'm not a Karma whore or anything like that.)

Re:Cygwin

[kraf]

Or MinGW if you don't want to rely on cygwin.dll.

Re:Cygwin

[Anonymous Coward]

Actually, Cygwin was developed by Cygnus, which was later gobbled up by Red Hat in the bubble days like Taco 'n' Hemos gobbling up Steve Jobs' dripping dick.

Re:Cygwin

[joeykiller]

How this can be considered Insightful beats me. Cygwin is an attempt to create a Unix emulation layer on Windows, while this apparently describes a fully flegded .Net integrated shell enviroment for Windows.

If this is true, this will (in my opinion) give Windows a tremendously powerful and coherent (i.e. a single understandable object model and class library) scripting and shell environment.

Say what you will about Cygwin - I like Cygwin a lot and use it daily - but it cannot be said to be coherent and consisting of well integrated parts.

Re:Cygwin

[Doc Hopper]

I feel the need to respond to this, though the parent poster borders on flamebait.

You've provided a straw man argument in "Those unix people who use cygwin under Windows think it is so cool to list files in a 'ls' type format", and then attempt to categorize Eric S. Raymond and other UNIX or Cygwin users in this light. Cygwin is a tool, part of your arsenal of options in systems administration, and nothing more. The ability to obtain a UNIX-style directory listing is irrelevant compared to the ability to use the same script to accomplish the same thing regardless of software platform.

• "Using Cygwin under Windows is about as intelligent as using Microsoft command shell batch files on UNIX."

"Crock of Crap" is the first thing that comes to mind. Bash/tcsh/ksh/psh/etc. are so many light-years ahead of the MS-DOS command line scripting language when it comes to pure functionality and understandability that there it is difficult to know where to begin creating a valid comparison. Using a Bash shell under Cygwin to accomplish systems administration or automation duties on W32 is a sound, rational decision for reducing your time investment when supporting legacy platforms like Microsoft Windows 32-bit stuff. Using Cygwin to be able to provide environmental portability across platforms can be an intelligent, measured decision that can make sense both on a personal level as well as corporate decision-making.

• Many of the [legacy W32] command shell commands are designed to handle the way you do things in the Microsoft world ... using cygwin is a step backward, that is unless you are mind-locked into the unix paradigm.

You've made at least one incorrect assumption in this paragraph, and that is that using Cygwin makes DOS scripting unavailable. That is simply not true. Every facility of the MS-DOS command shell is available via a Bash shell in Cygwin. You can call external programs, or even use an MS-DOS batch program to launch a Bash shell. Cygwin gives you more power and flexibility to deal with all the things you wrote of, not less, and in a fully POSIX-compliant environment to boot. Using Cygwin is a giant step forward, that is, unless you are mind-locked into the legacy Microsoft Windows paradigm.

• the command shell being too incomplete... I also think this has been a good thing. [I can see] when shell scripting is at its end and jumps to coding a c binary to do something... Using shell scripting for real programming is like using Perl to write a database. It's just silly

You're entitled to your opinion. I'm a professional systems administrator, not a professional programmer, yet I've used Perl, Python, Bash, Cshell, Visual Basic, Excel scripting, MS-DOS command scripting, TCL, and other languages to automate certain tasks, make my job easier, or provide additional functionality where it was needed. Each tool has its place. I would not use Python to attempt to create a performance-critical OpenGL game, no more than I would use C to write a small daily cron job that mounts a filesystem, copies files, and unmounts the file system. Each tool has its strength. Cygwin and the programs available within that environment allow you to do more and go further with command scripting than MS-DOS command can possibly do. The "jumping off point" to an alternative language is very, very low on W32 MS-DOS scripting. Conversely, the "jumping off" point using a real, powerful command shell is quite high, and allows you to accomplish a great deal without having an enormous knowledge base of various programming languages.
The line between "scripting languages" and "programming languages" doesn't exist except at some arbitrary line which differs from programmer to programmer. Whatever language lets you get the job done in the shortest amount of time with the greatest degree of maintainability is probably what you want to pick. I can take my pick of Perl, Python, Bash/csh/ksh/whatever, Java, C, or anything in between to create what I need to get the project complete. Cygwin lets me have that additional flexibility, with the side benefit that I can use the superior command-line tools (grep/awk/sed/uniq, for instance) of a UNIX environment from Windows.

• They just learned a few words, then decided that the rest of the vocabulary wasn't needed.

The world always has a need for the simple, elegant, and practical. I would submit that your analogy is flawed. Allow me to share an analogy of my own. I recently had a choice of transportation to and from work, between daily riding the bus (an hour and fifteen-minute affair each way), or driving my car (45 minutes each way). Now, for many people, the choice is very obvious: Use the option that takes the least amount of time, driving the car. Given only the time data, many would come to the same conclusion, that driving the car takes 1.5 hours per day, while riding the bus takes 2.5 hours per day. This overly simplistic view of the question doesn't nearly cover all the facts, however. Here are some other factors that influence my decision:

• My car consumes a gallon of gas every 30 miles. Work is 40 miles away, so I will fill my 10-gallon tank roughly every 3-4 driving days, which will cost me somewhere a bit less than $20 each time
• My work provides me with a parking space ($40 value) or a bus pass ($40) every month.
• I have to pay for maintenance on my car.
• Time spent in the car is time that I cannot do something else: I must be exclusively driving

On balance, I decided to take the bus. The extra time consumed by the bus ride is time that I can sleep, work on my laptop, or read a book, whereas if I were driving that hour and a half would simply be lost to me.

How does this relate to the question? Well, I think your perspective on why people use Cygwin and other UNIX-like tools on non-UNIX operating systems is a bit skewed. The native tools may be elegant, powerful, and complete (which would be quite a debatable point on legacy W32 platforms IMHO), but the question lies in the balance. Would using native tools allow you to take that same programming effort and use the same script on another operating system? Would using native tools give those who follow you a proper perspective on how to maintain your programs once you've moved on? Would re-implementing something in a native tool, when one could otherwise just install Cygwin and run the same code that is running elsewhere in the enterprise successfully, be the best use of time and the company's dollars?
Regardless, when using Cygwin you are using the native tools available to you, but just substituting a powerful command shell and scripting language for the severely retarded one that is provided by default on W32. "When in Rome" (or some foreign operating system), they say, do as the Romans do. However, if doing so would compromise system integrity, maintainability, stability, or compatability, then I do whatever I need to to make the system work well, even if it requires using a tool that doesn't quite seem "native".

I do not use Cygwin much myself. I boot to Microsoft Windows to run legacy or gaming applications on my home system, and exclusively use GNU/Linux at work and home otherwise. I do a lot of work with legacy W32 systems at work and am a big fan of "use the right tool for the job", which, to date, has not included installing Cygwin on those machines. However, it has included installing Perl, Python, or TCL as the situation requires; if Cygwin were needed to make something work, I'd use it as just another tool in my box.

Get with the program! When running any OS, use the best tool for the job!

(As a final note, I think it's very interesting that Microsoft has finally acknowledge that their shell is horribly crippled and are working to fix that. I'm not anti-Microsoft, I am pro-GNU/Linux, and am very excited to see them finally addressing the massive wart of a lack of decent systems automation on W32 platforms.)

Re:Cygwin

[jonathanclark]

I also built a single-EXE version of cygwin that has many of the utilities that fits on a floppy. It doesn't require any installation, or rely on external DLLs, and always stays as a single EXE file (nothing extract to disk). So it's a nice little file to have sitting around.

http://thinstall.com/docs/index.php?sp=unix_tools. html

And they can call it. . .

[kfg]

bashWinXP

KFG

Re:And they can call it. . .

[robbyjo]

Fortunately, they won't backport that to WinME. Otherwise it would be called "bashme".

Re:And they can call it. . .

[mbogosian]

And they can call it...bashWinXP

No, that would never happen. It would be Microsoft bash or mash or something. After all, they invented HTML too.

wonder what this means

[neildogg]

"Candidates should have Windows NT or Windows 2000 system programming experience, development experience with object-oriented languages and design methodologies as well as with scripting and shell languages like PERL, Python and Bash. Candidates should have at least 2-5 years experience (based on level interviewing for) in high technology, preferably delivering products for both Windows and non-Windows operating systems."

I guess Microsoft has viewed users of other platforms as important before (recruiting of Palm developers) but this seems like a direct call to Unix (mostly Linux) developers to make Windows shell exactly like other existing technology. Though I can't say I'm surprised, I think this is one of the first times where Microsoft seems to have stated that they are persuing similar technologies.

Re:wonder what this means

[IamTheRealMike]

Though I can't say I'm surprised, I think this is one of the first times where Microsoft seems to have stated that they are persuing similar technologies.

Actually, the next version of IIS has dropped the binary metabase and has replaced it with XML config files, so IIS can be administered by hand, just like Apache (but with a pretty GUI if you want one). Maybe as part of this next-gen shell they'll introduce a good command line text editor.

This sounds to me very much like Microsoft is having a good hard look at what Linux/open source does well, and copying it. Fair game - we've copied them plenty, and are continuing to do so. We could well find that Windows moves on a lot thanks to the competition offered by Linux: will we be able to keep up, and keep pushing things forward to? I think so. I hope so. But the era of kicking Windows for being unstable is already over, insecure looks on its way out (I read coders can get fired now for writing insecure code at redmond), and soon traditional UNIX strongholds like good remote administration may no longer be unique either.

We have our own stupid problems to fix too of course. Lack of a decent object model? Lack of binary portability? That one is killing us at the moment, and there is no good solution (as I'm finding out as part of my project). We really really don't want to have to setup build farms (a binary for every distro version), that'd suck. But it seems the very nature of Linux itself dictates it. Now Windows is moving to .NET they are tidying up a lot of these problems, while we're still playing catchup.

It's certainly going to get interesting soon. Microsoft have sort of woken up.

Re:wonder what this means

[IamTheRealMike]

Your point about binary compatability on linux is almost painfully valid at times.[1] It'd get a LOT easier if glibc/gcc would finally decide to stop breaking backwards compatability.

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:wonder what this means

[Sentry21]

Maybe as part of this next-gen shell they'll introduce a good command line text editor.

What do you mean 'maybe'? Windows XP Pro already has edlin.exe, what more do you really need?

(Sometimes, backwards compatibility goes too far.)

--Dan

So, we're back to the 60's.

[pmorrison]

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.

Re:So, we're back to the 60's.

[Sh0t]

If you mean command prompt On Windows, there honestly no reason to keep it open unless you made a ton of batch scripts in the windows dir. The windows shell post 98 isn't comparable to the nix shells so i don't see how having it open makes things any easier. Windows was designed around the gui interface and honestly IN WINDOWS things are just easier to manipulate from the regular interface. Not to object to your l33tness or anything but I really don't see the point. "To get work done" What kind of work? Text editing with the dos editor?

Re:So, we're back to the 60's.

[Gordonjcp]

Well, I do a lot of graphics editing, including resizing and thumbnailing images from digital cameras. It's far easier for me to knock up a script to do this than to struggle with GUI programs to get the job done. Since they're going to go on a Unix webserver anyway, I can just resize then scp them across. If I'm doing a heavily graphics-orientated project, a GUI works well. If I know exactly what I want the machine to do, command line can be better - it's usually easier to ask for something by name than to point at it, in the hopes you'll be understood.
Consider - I want to resize a directory of images, and put them in a thumbnail directory. Which is easier?
Command line:

mkdir thumbnail
for i in *.jpg; do convert -resize 128x128 $i thumbnail/$i; done;

or GUI:

Click File/Open
Go to the right directory
Open the file
Click on Edit/Image Size
Set it to 128x96, or 96x128 depending on if it's portrait or landscape
Click Save As...
Go to the right directory
Click OK
Go back to the start, until all 300 or so images are done....

Re:So, we're back to the 60's.

[dknj]

How about creating users in an Active Directory automagically? I do not like the fact that we had to install Perl to get the job done (and thats the only reason why perl exists on the server) so I took it upon myself to rewrite the script in C. When I get back to work I will happily uninstall perl and not have to deal with the crappy Windows Task Scheduler anymore.

-dk

Re:So, we're back to the 60's.

[droid_rage]

You could have easily done it with ADSI in VBScript which is already natively supposrted. What were you trying to do, just write a script to add users? How about:

Function CreateUser(sOuDomainPath,sUserName)
On Error Resume Next
Set oLDAP = GetObject("LDAP://" & sOuDomainPath)
Set oUser = oLDAP.Create("user","cn=" & sUserName)
oUser.Put "sAMAccountName", sUserName
oUser.SetInfo
oUser.AccountDisabled = False
oUser.SetInfo
Set oUser = Nothing
Set oLDAP = Nothing
If Err.Number = 0 Then CreateUser = True Else
CreateUser = False
End Function
Function
CreateUser2(sOuDomainPath,sFirstName,sLastName,sDe scription,sEmail,sPassword)
On Error Resume Next
Set oLDAP = GetObject("LDAP://" & sOuDomainPath)
Set oUser = oLDAP.Create("user","cn=" & sFirstName & " " & sLastName)
oUser.Put "sAMAccountName", Left(sFirstName,1)& sLastName
oUser.SetInfo
oUser.FullName = sFirstName & " " & sLastName
oUser.GivenName = sFirstName
oUser.Sn = sLastName
oUser.AccountDisabled = False
oUser.Description = sDescription
oUser.SetPassword sPassword
oUser.Mail = sEmail
'oUser.Profile = "\\server\share\username"
'oUser.Put("HomeDrive"),"X"
'oUser.HomeDirectory ="\\server\share\username"
'oUser.LoginScript = "myscript.vbs"
oUser.SetInfo
Set oUser = Nothing
Set oLDAP = Nothing
If Err.Number = 0 Then CreateUser2 = True Else
CreateUser2 = False

End Function

That's actually some code that can be easily found in a number of locations Microsoft, for example.

Im not a huge fan of MS (Read my journal for opinions on your run-of-the-mill Windows admin), but I wish people would stop bashing Windows for a lack of understanding on their part. Most of this stuff is in the Windows 2k Server resource kit, too. I guess your company didn't shell out the $100, or you didn't read it...

Development in India

[slashuzer]

It would be interesting to know just how much of Microsoft's "future devlopment" are being made in India. My guess is that the OS, Office etc continue to be further developed by the team(s) in Redmond, but most new products/services are being developed in India.

Re:Development in India

[SerpentMage]

That is what I found more interesting than the job description itself....

Is this news?

[nuggz]

You mean the big bad MS is developing all sorts of technology. Some of it just copying features found before in other operating systems.

Does it really surprise anyone that MS knows about other operating systems, Bash, Perl and Python.

The things they list in this post are good useful tools, it should be obvious that they would look to implement them now that clustering is becomming a larger concern. Admin by GUI works for a handful of computers, but when you start dealing with many, you need something else, and MS is going to provide that.

This just shows they are acting more serious about providing Enterprise Solutions.

Starting to sense a pattern ...

[YetAnotherName]

MS-DOS was just a boot loader. Windows 95 gave us preemptive multitasking. A message-passing microkernel got stable in Windows 2000. And soon we'll have a scripting language.

Let me guess what's next down the pike: a /proc filesystem, a serial console capability, runlevels, and a package manager with dependency feature.

Hmmmm...

Re:Starting to sense a pattern ...

[goon america]

...and a package manager with dependency feature.

> winpm install Mozilla
Must satisfy dependency: Microsoft-Office-XP

> winpm install CuteFTP
Must satisfy dependency: Microsoft-Office-XP

> winpm install StarOffice
Must satisfy dependency: Microsoft-Office-XP

hmmmm

Good step

[Captain_Frisk]

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.

Re:Good step

[oren]

You are missing the point about this shell making heavy use of the .NET framework. Presumably, any .NET object would be accessible to the command line... Given that they intend for their whole OS to be based on .NET, this means the command line may offer access to more functionality than /bin/sh offers on a UNIX platform.
If you want to compare this to existing non-MS projects, this sounds like a combination of bash and BeanShell, 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 .NET (Mono). Microsoft could, if it plays nice, actually set a new portable standard for shells (based on .NET on Windows and Mono on UNIX). Of course, knowing Microsoft, they'll blow it by succumbing to the temptation of poisoning it with all sort of Windos-isms. This will be interesting to watch...

Re:Good step

[CH-BuG]

Control a running program ?

Re:Good step

[sheldon]

"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? "

Think outside the box...

In Windows we're not limited by piping text from one command to another. We have COM automation today which allows one to instantiate Microsoft Word as an object and issue commands to it. This new scripting/shell will apparently allow for similar automation using native .NET framework objects.

"Are they going to release command line versions of most of their administrative tools? "

command line version of administrative tools have been available since NT 3.x. For those that don't you can use WSH to automate the task.

"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."

Huh? Can you open up the word processor in Star Office and build a document based upon data you pulled from an Oracle query, complete with various layout features from a Unix shell script?

We've been able to do that from the Windows command line for several years now. I don't think you fully understand the scripting capabilities Windows offers.

A good thing, really.

[bdowne01]

Actually, I'm really intrigued about the possiblity of having a "strong" shell on Windows. It's one of the main reasons I can't find myself using Windows for much.

Usually, if I had to...I just installed Cygwin and used it from there. However, the interaction between the actual Windows environment and Cygwin was a little cumbersome--but usable. I've written some crazy shell scripts using Cygwin, but trying to run a Windows command using variables from the script can be tricky, for example.

However this opens up some other nice possibilities for a Windows environment. If the shell they create is complete enough, you may not even need stupid "remote control" apps, instead you could just SSH into the box and take care of things.

On the other hand, I guess it just makes Windows easier to crack too ;)

Good news... kinda ;-)

[bumblebury]

Well, perhaps if windows users get used to using a shell, then the switch to UNIX won't be too hard for them, it certainly makes it easier for the Linux movement if there are more similiarities than differences between the windows *gui* and the linux *gui*, as a large majority of Linux's advantages are more in respects to the underlying architecture, philospy[1].

--

[1] Actually, I happen to think that the linux desktop is much better than the windows desktop, if you shy away from GNOME, KDE and try some of the non-standard desktops. I've been using WindowMaker on my laptop for a year now, and I see no reason to ever switch (it just fits the way I work). Furthermore, once you go shell, you never go back.

Re:Good news... kinda ;-)

[caspper69]

a large majority of Linux's advantages are more in respects to the underlying architecture

Oh, if this were only true. As a systems developer and operating system architect (no, I do not work for MS), I can say, beyond a shadow of a doubt, that the underlying architecture of Linux (i.e. the kernel) is NOT superior to the 2k/XP kernel. Not by a longshot. OSS kernel hackers are making significant progress, but they are unfortunately stuck using an aging paradigm (UNIX) from a distant era of computing. UNIX is meant to be a data monster, nothing more, nothing less. Machines you could run for years without giving them a second thought as they churned through unfathomable amounts of information. And to be quite frank, it is still very well suited to its original purpose. On the flip-side, MS was able to start from scratch. The NT/2k/XP kernel, while similar in architecture to VMS (Dave Cutler from DEC who wrote VMS also single-handedly wrote the first NT kernel), is robust and modern. It's main issue to this point has been the inclusion of the Win32 API. But make no mistake, it is a well-designed, efficient kernel. The original NT design specification was over 1200 pages (there is quite a bit of information and excerpts available on the web). If you really want to get into architectural level discussions, or just peruse many of the thousands of threads on the "big" Win kernel vs. Linux, I suggest browsing the newsgroup alt.os.development for a while.

Needed at the Enterprise

[Chewster]

The thing is, this is sorely needed by Win32 to compete at the enterprise, so I'm not at all surprised they're doing it. Trying to stop/start Unix services remotely through ssh is a breeze. We gave up trying to use VNC (and others) remotely for Windows services since the performance was so bad.

There are 2 things I wonder about though:
1. Why is this only via .Net and not the full OS?
2. How much of the OS will be accessible via the prompt?

Kinda hard to tell by just the job posting. Neat to see though.

Re:Needed at the Enterprise

[NineNine]

Trying to stop/start Unix services remotely through ssh is a breeze. We gave up trying to use VNC (and others) remotely for Windows services since the performance was so bad.

You guys didn't research this too hard, huh?

Re:MS is responsive: that's why they're #1

[Khan]

..they've got security,

Uh, I think they still need to fill this "hole" (pun intended). Perhaps if they try removing all those integrated services and make them modular, they might be able to lock down their OS to the level that most NIX's have enjoyed for years now. Think of it in terms of inbreeding...the more times you marry your sister, the weaker the blood becomes. Same thing with Windows. My sig says it all in regards to why Windows is so popular.

they'll screw this one up as well

[g4dget]

I am sure Microsoft will do everything they promise, and as a result, their new shell will be absolutely awful. Microsoft's response to everything is "we'll implement something with more features, more technology". What they don't get is that simplicity and restraint is valuable in itself. You can see this throughout their systems. Their file systems are becoming databases. Their programming environment is fully object based and component based. Their file system protection allows you to specify arbitrary ACLs on arbitrary files. And on and on. In different words, just about every single one of Microsoft's products suffers from the "second system effect".

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.

WSH

[lseltzer]

Most of these capabilities are already in Windows Script Host, which has been standard in Windows for years. What's new, I suppose, is that this version is based on the .NET Framework.

This validates the UNIX way of doing things ...

[RNG]

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.

sorry, but this won't help Windows either

[g4dget]

they're going to absolutely pummel any competitors on the server end.

Microsoft already has their own scripting environment, and you can already get the most popular shell environments (Bash, Korn) for Windows for free. It doesn't help, because the system just isn't built for scripting.

They've got stability, they've got security, and now they're gonna have good scripting. Wow. Who would'a thunk?

Very funny. XP can be fairly stable and secure--if you dedicate machines to individual tasks and disable most multiuser features. Running Apache and ssh helps, too. But, compared to UNIX and Linux, XP's stability and security are still ridiculously poor. And that's not because lacks features, it's because it has too many features.

Re:you are absolutely right

[g4dget]

I think that they DID make that tradeoff. I'm sure that by building a very solid GUI first wasn't accidental.

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:Responsive!?

[NineNine]

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.

Re:Those dont know UNIX are

[Tet]

I don't know who said it. But it true IMHO.

"Those who don't understand UNIX are condemned to reinvent it, poorly." -- Henry Spencer

Re:Responsive!?

[Anonymous Coward]

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]?

in theory, but not in practice

[g4dget]

Yes, there are plenty of command line tools for system administration that come included with Windows. Nominally, you can do pretty much everything with them that you can from the GUI. In practice, however, you can't.

First of all, since most people use the GUI most of the time, if you want to move on to scripting, you have to learn both entirely new commands and figure out how to script them together. Not even the concepts and paradigms of how to manipulate the system are easily mapped onto one another.

Also, the command line tools don't seem to keep up with what's in the GUI, and any third party components that require administration often don't come with command line tools at all.

Finally, Windows doesn't ship with a lot of the glue necessary to make scripting work. Apart from the pathetic cmd.exe, most devices are not accessible through the file system and many important command line programs are just missing. Some come and go (NT used to come with pax.exe, but it seems to have disappeared now, leaving no archiver around).

Virus delight

[corvi42]

Wow, a hugely complex scripting environment with hooks into every aspect of the OS.
Virus writers - here is your big chance to spread like wildfire through windows machines!
.... Again!

Re:you are absolutely right

[Proc6]

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.

Yea, really. Copying sucks. Damn those dickhole car makers like Porcshe and Ferrari. They're just copying Ford. And screw that guy who came up with e-mail, what a total rip off of postal mail. And those leeches over at NASA trying to copy all the ideas of science fiction writers. God. What a bunch of losers.

Re:What about this one?

[Lumpish Scholar]

That ad is also interesting in several ways; but Windows Services for Unix is old news (warning: MSFT hype ahead):

... provides a universal environment in which to run both Windows and UNIX applications on a single system.... reduce development time while leveraging existing employee skills sets.... a UNIX environment that runs on top the Windows kernel, enabling UNIX application and scripts to run natively on the Windows platform alongside Windows applications.... you can continue to get value out of your UNIX scripts and applications -- simply reuse them on Windows.

Also old news are the Posix subsystem within Windows, and Microsoft claiming Posix compliance; the first in support of the second, and the second to get around U.S. government requirements for Posix-compliant solutions. For example (I think):

Windows NT has a minimum level POSIX compliance and has become the de facto client/server standard for small server requirements because of widespread usage.... Windows NT has been chosen as the server with the best workstation/small server capabilities. SUN Solaris' UNIX will continue as the operating system choice for enterprise or robust solutions....

Previously, most of Microsoft's Unix-like stuff has been standalone, unable to integrate with the rest of "the Win32 subsystem"; maybe that's changing.

P.S.: I accidentally discovered that the native command line interepreter in Windows XP has a decent filename completion feature. Without thinking, I hit tab to complete a file name, and it took me a minute to notice that it worked even though I wasn't using bash.

Damn...

[torpor]

Microsoft: We Invented the Shell in 2003.

Can they get serious?

[Ektanoor]

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.

Huh?

[Rogerborg]

Hasn't Amazon got a bunch of patents on this?

MacOSX, Applescript and why MS is doing this.

[theolein]

OSX has some of the functionality mentioned here in it's netinfo database, and system and programme defaults can be set through the defaults command which is based on xml. Applescript is a good glue between the CLI , System and other software.

What is interesting is MS' motivation behind this. It does seem as they are of the opinion that having an amazing shell will pull all the OSS crowd over to using Win instead of Linux/BSD/*NIX. Why I think it won't work, at least in the first few iterations, are because:
a.MS still has that licence problem which they would rather die than let go of.
b.You still have to pay extra $$$ for the whole bundle of extraneous shit that you don't need.
c.It will still be easier to script apps in VBA. 80% of the extra cludge, OO this , reflection that etc will go unused.

Re:Learn how to use your apps

[Gordonjcp]

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?

MS was at USENIX/SAGE asking what makes a good CLI

[furry_wookie]

FYI.. .I was at the USENIX/SAGE L.I.S.A Confrence 2002 in Philly a few weeks ago, and some guys from Microsoft had a late night get together to talk to us unix people. I couldn't not go, after all it was Microsoft at a 100% NIX-only event, so I figured some fun would be had at their expense.. It was called: UNIX + Windows Admin Management with Scripting & Command Line: What are your requirements?, and was on thursday night. The point of the meeting is that, they wanted to know from UNIX admins what makes a good Command Line environment and what it would take to make Windows have as powerfull a CLI as Unix. They pretty much told us that there is a LARGE high-level project at Microsoft to make Windows servers to be as easy to manage and configure as Unix servers from a serial port with no gui required. What is their REAL goal: From what I could tell its simple... they want to eliminate the competitive advantage that UNIX has with the CLI. That this away from NIX as a "advantage", then thats one less think people can point to as something that Windows lacks. They want to be able to honsetly say... "Unix isnt any easier/more-powerful on the CLI than Windows." After all, that is one of the SINGLE LARGEST differences there are today between their product and NIX. Take that argument away, and you have a huge marketing/argument weapon against us NIX people.

Wouldn't it be interesting ...

[ninewands]

I defy Microsoft to be able to prove that a developer with " ... Windows NT or Windows 2000 system programming experience, ... as well as with scripting and shell languages like PERL, Python and Bash." and "2-5 years experience in high technology, preferably delivering products for both Windows and non-Windows operating systems." to be able to PROVE that any similarity to bash arose in a "cleanroom reverse engineering environment."

Imagine Stahlman winning a copyright infringement lawsuit against Microsoft and Windows getting "infected" by the GPL ... it's be Microsoft's worst dream come true ... <VERY Evil Grin(TM)>

Re:What the...

[CoolVibe]

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.

tcsh can. Guess the problem is still solved. tcsh can expand command from other 'completors' other than just the $PATH. Like, type mount somehost: and it will try to expand from the output from 'showmount -e' for example. Granted, they aren't reflection API's but that's just another buzzword to me :)

The job is indeed in India

[Doug Merritt]

the job listing was most likely a job in redmond washington, but posted in an indian job listing to specifically recruit indian guys.

It's not necessary to carefully avoid reading the very short page that this story is about. It's not necessary to make a (completely wrong) wild speculation that is trivial to double-check just by glancing at the final line of the job posting. It's not necessary to embarass yourself in public. The final sentence of the job posting says:

This position is in Hyderabad, India.

Of course, this is the first time anyone on Slashdot ever posted something incorrect without reading the story in question, and doubtless no one will ever do something that silly ever again.

Remember this classic line?

[IGnatius T Foobar]

"Given enough time and resources, Microsoft will eventually invent UNIX."

Re:What about this one?

[self assembled struc]

I too discovered this, and then learned from one of the Win32 programmers at work that this has been available in the NT command line since 3.51, it's just turned off by default. You have to turn it on via the registry.

Re:Well that's nice

[orangesquid]

No, see, that's the point. Microsoft doesn't support Linux, but Linux people want some of the things Microsoft provides for Windows, so we have created our own. It's not innovation. I have never seen any open source programmer consider cloning proprietary software innovation. Major innovation (totally new ways of doing things) is usually somewhat rare in software created by hobbyists because companies generally spend thousands on research-and-development costs to majorly innovate. Open source is full of minor innovations, though (clever hacks, minor improvements, small enhancements), that can make the difference between software being a pain to use and a joy to use.

Microsoft is infamous for speaking so highly of their innovation while usually only performing minor innovation (many of their products are simple improvements on another company's software, or were straight-out bought from other companies which does not constitute innovation in any form). If you are going to talk of how innovative you are, come up with some really-damn-new, really-damn-good ideas on your own!

Way to Go, Microsoft

[SecretAsianMan]

This is the moment of truth for all you people out there who have made arguments like the following:

• 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)

[aphor]

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!

Unix aren't living in the same world as Windows

[Jugalator]

Another proof comes from that site:

You can download the huge current tree in standard gzipped tar format, but be warned: it's about a megabyte right now.

IIRC, Microsoft didn't warn us explicitly before downloading the 100 Mb Service Pack for Windows XP. :-)