Become a fan of Slashdot on Facebook


Forgot your password?

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)."
This discussion has been archived. No new comments can be posted.

Microsoft Next Generation Shell

Comments Filter:
  • Cygwin (Score:5, Funny)

    by TheShadow ( 76709 ) on Sunday December 29, 2002 @09:53AM (#4976164)
    I liked this the first time... when it was called Cygwin.
    • Re:Cygwin (Score:5, Informative)

      by Anonymous Coward on Sunday December 29, 2002 @10:14AM (#4976257)
      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 (Score:5, Informative)

      by kraf ( 450958 ) on Sunday December 29, 2002 @10:27AM (#4976288)
      Or MinGW [] if you don't want to rely on cygwin.dll.
    • And microsoft had what to do with Cygwin? Seriously, if this is true then this is a good thing. Microsoft's scripting support has been lacking in a lot of ways ever since batch files.

    • Re:Cygwin (Score:5, Interesting)

      by joeykiller ( 119489 ) on Sunday December 29, 2002 @11:00AM (#4976408) Journal
      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.
  • by kfg ( 145172 ) on Sunday December 29, 2002 @09:55AM (#4976175)

  • by neildogg ( 119502 ) on Sunday December 29, 2002 @09:56AM (#4976176) Homepage
    "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.
    • by IamTheRealMike ( 537420 ) on Sunday December 29, 2002 @01:23PM (#4977085)
      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.

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

  • by pmorrison ( 513514 ) on Sunday December 29, 2002 @09:56AM (#4976177)
    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.
    • 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?
      • by Gordonjcp ( 186804 ) on Sunday December 29, 2002 @10:35AM (#4976315) Homepage
        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....
      • by dknj ( 441802 ) on Sunday December 29, 2002 @10:59AM (#4976405) Journal
        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.

        • by droid_rage ( 535157 ) on Sunday December 29, 2002 @12:37PM (#4976822) Journal
          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.AccountDisabled = False
          Set oUser = Nothing
          Set oLDAP = Nothing
          If Err.Number = 0 Then CreateUser = True Else
          CreateUser = False
          End 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.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.HomeDirectory ="\\server\share\username"
          'oUser.LoginScript = "myscript.vbs"
          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...
      • Eh, I just came home frrom visiting my parents. When there, I helped them with their WinXP computer, on which they needed ome files to be editable by just some users, and so on... It turned out you couldn't change the ACLs from explorer, as you can in w2k (right-click, select properties, etc), at least, I couldn't find it... In the end, I had to reort to the command prompt, and found out that cacls and dir /Q was quite a decentt tool for what I wanted to do... Sometimes, even MS does things right, even when it comes to good old cmd.exe...
    • by ClosedSource ( 238333 ) on Sunday December 29, 2002 @01:11PM (#4977015)
      Obviously programmers usually use text to write their code, not a graphical notation. The question is whether you want to make a user operation into a programming project (however minor).

      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.
  • Development in India (Score:5, Interesting)

    by slashuzer ( 580287 ) on Sunday December 29, 2002 @09:58AM (#4976185) Homepage
    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.
    • That is what I found more interesting than the job description itself....
  • Is this news? (Score:3, Interesting)

    by nuggz ( 69912 ) on Sunday December 29, 2002 @09:58AM (#4976187) Homepage
    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.
  • by YetAnotherName ( 168064 ) on Sunday December 29, 2002 @09:59AM (#4976189) Homepage
    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.


  • Good step (Score:5, Insightful)

    by Captain_Frisk ( 248297 ) <captain_frisk.bootless@org> on Sunday December 29, 2002 @09:59AM (#4976192) Homepage
    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.
    • wha they really need to go along with a real scripting environment is to integrate it with the gui like apple does with applescript. Then anything can be reliably scripted.

      hey wait a minute, if they do that, how are the MCSEs gonna make a living? I guess they'll just have to half-ass it like they do everything else.
    • Re:Good step (Score:2, Informative)

      by nighty5 ( 615965 )
      Not exactly so.

      Ever since NT4 became a serious peice of infrastucture, Microsoft provided Resource Kits available to manage the more advanced characteristics. You can control everything that the GUI offers. It's just that a lot of people don't bother to look past the surface of the Control Panel.

      If you want more advanced analysis of NT domain related issues, RPC problems etc, mass creation of accounts the only solution you have is to use the command line.
    • Re:Good step (Score:5, Insightful)

      by oren ( 78897 ) on Sunday December 29, 2002 @10:41AM (#4976343)
      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 (Score:5, Informative)

      by sheldon ( 2322 ) on Sunday December 29, 2002 @02:56PM (#4977522)
      "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.
  • There are also other jobs related to the same area listed for Microsoft India Development Center here [].
  • bound to reimplement it.

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

    Happy New Years to you all!!
  • by bdowne01 ( 30824 ) on Sunday December 29, 2002 @10:01AM (#4976206) Homepage Journal
    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 ;)

  • by bumblebury ( 530638 ) on Sunday December 29, 2002 @10:01AM (#4976207) Homepage
    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.
    • Actually, I think that there will be even less of a reason to switch to something else in the first place. I'm betting that this is what MS is thinking, too.
      • even less of a reason to switch to something else in the first place.

        Microsoft shops have already adapted to Microsoft's admin tools and don't see them as a disadvantage.

        What this may offer is the reverse - Microsoft wants to make it easier to switch from UNIX/Linux to Windows.

        I think that those who are switching from Windows are doing so because of license costs, the new provisions of the license program, the costs associated with making sure that you are in compliance, objectionable EULA terms, security issues, issues regarding scalability and having to run many Windows servers where fewer Linux/UNIX servers would do, rebellion at the costs associated with .Net migration, and so on.

    • 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.
  • by Chewster ( 66541 ) on Sunday December 29, 2002 @10:05AM (#4976223)
    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.

  • by handsomepete ( 561396 ) on Sunday December 29, 2002 @10:06AM (#4976226) Journal
    After the next generation shell is complete, Microsoft will be developing a new computer to computer communication protocol. It will offer the ability to operate the new exciting command line infrastructure over a local network, the internet, serial port or any other crazy method you can come up with. It will be called "tel.NET" and will feature keyboard mapping, color, and a little *ding* whenever something of interest happens., Microsoft, "operate" and "*ding*" are all registered trademarks and ©2002 Microsoft Corporation. All rights reserved.
  • by Lispy ( 136512 ) on Sunday December 29, 2002 @10:10AM (#4976239) Homepage
    While some of the unixers try to make Linux look exactly like WinXP the evil empire is trying to make winnt feel more like a real OS. When they start using a machkernel it could get kinda stupid if Apple sues them for stealing their GUI in 1990 and stealing their architecture in 200x.

    Well, who needs that anyway? Man, the screwed up on ActiveX, they couldn't fix the holes in Iexplore.exe and their latest scripttoy VB-script gave the Virus "Industry" it's biggest revival since 1985.

    I'm looking forward to .net-shell based virii...coming soon to your desktop!

  • by iomud ( 241310 )
    A whole new area of a Microsoft operating system ripe for exploitation.
  • by g4dget ( 579145 ) on Sunday December 29, 2002 @10:11AM (#4976246)
    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.

    • In theory, object file systems, an object component environment and so forth CAN be a simplification of things.

      In practice, I agree that Microsoft doesn't know how to do it right, and in practice they are not simplifications at all, but rather complications.

  • WSH (Score:5, Informative)

    by lseltzer ( 311306 ) on Sunday December 29, 2002 @10:14AM (#4976255)
    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.
  • by RNG ( 35225 ) on Sunday December 29, 2002 @10:14AM (#4976256)
    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.
    • We had some engineers working on a project that was going to involve migrating 2000 users. They were all trained MCSEs, and they going to migrate 2000 users by hand. When I showed them all the command line tools that came with the NT4 resource kit, they were floored. We put together some batch scripts and saved the clients some money.

      Point-and-click Admin GUIs are really convenient. If you are doing one user, or something similar, it is easier than remembering command line arguements. There is nothing inherently superior about a text based approach to graphical. You need to understand what you're doing, arguements vs. icons is irrelevant.

      However, when you have a LOT to do, and you want to do it based upon a list of names, CLI is the way to go.

      The group with the slickest solution is Apple w/ Applescript. Instead of separate GUI and CLI versions (NT), or CLI with GUI wrappers (Linux), it's all integrated. The applications can accept arguments while running or while not running. There is no reinvention of the wheel or duplication of effort.

  • good to see MS will be integrating a cmd-line tool into windows. i'll prolly still use cygwin. anyways, if any MSer is listening, do us all and favor and include tab support. being able to have many cmd-lines in one window is just sweet (thanks you RH 8.0).
  • ...that they would call it "Bush"?
  • The candidates are as follows:

    Command-line Remote-capable Advanced SHell (CRASH)
    Microsoft Advanced SHell (MASH)
    Synchronous Multi-user Advanced SHell(SMASH)

    What is YOUR favourite?
  • is the desire to make it square, so it won't roll away, and to later enhance it by making it triangular thereby eliminating one bump.

    M$ seems to have an absolute overarching need to make everything and anything all their own. Not better just their own. It just takes them three tries at anything before customers stop asking that it work properly.

    Just reply that their marketing division has succesfully polluted M$'s own resource pool since schools curricula now only teach operating systems as "How to sys admin with Windows NT"

  • by corvi42 ( 235814 ) on Sunday December 29, 2002 @11:00AM (#4976410) Homepage Journal
    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!
  • Damn... (Score:4, Funny)

    by torpor ( 458 ) <ibisum@gm a i l . com> on Sunday December 29, 2002 @11:16AM (#4976471) Homepage Journal
    Microsoft: We Invented the Shell in 2003.
  • This is an excellent idea, bringing this to the shell.

    If you look at the command prompt in VS.NET you'll see some of this technology today - you can type "Project." and get a list of things you can do with the current project... If you want to do a build you can type "Build.BatchBuild". If you type "b.b", down arrow, return, you've done the same thing with 5 keystrokes (the autocomplete fills in the rest). Same number of keystrokes that typing "make" and hitting return takes.

    Difference between this and typing "make" is that when I type "Build." I get a list of things I can do with the current build - it becomes an object oriented command line. It's pretty nice once you work with it a bit - You want to work with the current project (add a file to it for example) type Project. and look at the list - same for File. Debug. etc

    Interesting thing about this new shell that Microsoft is talking about is it will take capabilities ALREADY exposed by most Windows apps (through OLE automation) and make them available at the command line. If I could type this in a shell:

    Word.Fil eOpen "my.doc"

    Then I can print a Word document, using Word, from shell (and without ever seeing Word) using the same scripting interface available to VBScript (etc).

    Most Windows apps support scripting (even non-MS apps). It's getting at this functionality from the shell that's new here - something I don't think there's any Unix equivalent of yet.

    - Steve
  • by Ektanoor ( 9949 ) on Sunday December 29, 2002 @11:33AM (#4976537) Journal
    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? (Score:4, Funny)

    by Rogerborg ( 306625 ) on Sunday December 29, 2002 @12:11PM (#4976691) Homepage
    Hasn't Amazon got a bunch of patents on this?
  • by theolein ( 316044 ) on Sunday December 29, 2002 @12:23PM (#4976746) Journal
    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.
  • by furry_wookie ( 8361 ) on Sunday December 29, 2002 @12:29PM (#4976775)
    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.
  • by ninewands ( 105734 ) on Sunday December 29, 2002 @12:54PM (#4976922)
    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)>
  • by IGnatius T Foobar ( 4328 ) on Sunday December 29, 2002 @02:22PM (#4977386) Homepage Journal
    "Given enough time and resources, Microsoft will eventually invent UNIX."
  • by SecretAsianMan ( 45389 ) on Sunday December 29, 2002 @05:23PM (#4978131) Homepage
    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.

  • by aphor ( 99965 ) on Sunday December 29, 2002 @06:27PM (#4978397) Journal

    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!

An elephant is a mouse with an operating system.