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)."
Cygwin (Score:5, Funny)
Re:Cygwin (Score:5, Informative)
For those whou don't know, Cygwin [cygwin.com] 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 [perl.com]: 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 [perl.com].
(I post as AC, because I'm not a Karma whore or anything like that.)
Re:Cygwin (Score:3, Informative)
Unix aren't living in the same world as Windows (Score:4, Funny)
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.
Re:Cygwin (Score:5, Informative)
Re:Cygwin (Score:4, Informative)
http://thinstall.com/docs/index.php?sp=unix_tools
Re:Cygwin (Score:2)
-dk
Re:Cygwin (Score:5, Interesting)
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 (Score:5, Informative)
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.
"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.
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.)
And they can call it. . . (Score:5, Funny)
KFG
Re:And they can call it. . . (Score:2)
How about C:<enter>### ;-)
Re:And they can call it. . . (Score:4, Funny)
Fortunately, they won't backport that to WinME. Otherwise it would be called "bashme".
Re:And they can call it. . . (Score:2)
And it's so damn appropriate, too.
Re:And they can call it. . . (Score:3, Funny)
No, that would never happen. It would be Microsoft bash or mash or something. After all, they invented HTML too.
wonder what this means (Score:5, Interesting)
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 (Score:5, Interesting)
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 (Score:3, Funny)
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
Re:wonder what this means (Score:3, Insightful)
The problem I was thinking about wasn't actually related to glibc (which actually doesn't break binary compatability at all, it uses symbol versioning) or gcc (which was only for C++, and hopefully will not break binary compatability again now it's standardised).
I'm mainly thinking of the problem that the link tree always has to be identical to the system a binary was compiled on. For instance, if you have a frozen bubble game, which was compiled against libpng3 and libSDL, then you run it on a distro where libSDL was compiled against libpng2, then two ABI incompatible versions of libpng will be linked into the same address space and you'll get an instant segfault.
Well, those sort of symbol collisions can be 95% resolved by either making everybody use symbol versioning (hard) or applying some patches to the linker and ld (easy, but libc maintainers won't do it). But you still have problems if for instance frozen-bubble passes structs between the 2 versions of the library.
I think the real solution in the long run is for people to stop using C for writing libs and apps. Higher level langauges that can do reflectivity (python/ruby/java/.net/in fact, anything other than C/C++ basically) don't tend to suffer ABI problems in quite the same way, and we'd all have higher productivity anyway.
But there are problems with trying to write everything in such langauges. I've got ideas for how to solve them too, but can only tackle one thing at a time, and pulling people away from C is going to be very hard. MS can sort of do it through sheer marketing will and forcing Windows in that direction, even for them introducing .NET will take years. We can't do that though, it's not so easy.
So, we're back to the 60's. (Score:5, Insightful)
Re:So, we're back to the 60's. (Score:3, Insightful)
Re:So, we're back to the 60's. (Score:5, Informative)
Consider - I want to resize a directory of images, and put them in a thumbnail directory. Which is easier?
Command line:
or GUI:
Re:So, we're back to the 60's. (Score:2)
for i in *.jpg; do convert -resize 128x128 $i thumbnail/$i; done;
Looks like somebody is inthe same business I'm in (see below)
Re:Learn how to use your apps (Score:4, Insightful)
Re:So, we're back to the 60's. (Score:4, Insightful)
-dk
Re:So, we're back to the 60's. (Score:5, Informative)
Function CreateUser(sOuDomainPath,sUserName)e scription,sEmail,sPassword)
End FunctionOn 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,sD
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
That's actually some code that can be easily found in a number of locations Microsoft, for example [microsoft.com].
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...
Re:So, we're back to the 60's. (Score:2)
Re:So, we're back to the 60's. (Score:5, Insightful)
Efficiency is not the only consideration. Sometimes you want to concentrate all of your thinking on your overall goal and not get bogged-down in reinventing the wheel.
Some programmers have a deeper mental stack and don't find working at multiple levels at the same time a problem. It's a great gift that they share with some movie directors and short-order cooks. It's useful but doesn't guarantee you'll write great code, win an academy award, or become a great chef.
Finally, I think some of the CLI worship is misplaced. Some people think movies are more artistic because they were filmed in black and white, but the reality is that most B&W films were done that way because color was either not available or too expensive. Similarly, many of the approaches taken by Unix and 'C' were done based on the severe limitations of the times they were invented in, not because their creators believed those approaches would be the best forever.
Development in India (Score:5, Interesting)
Re:Development in India (Score:3, Insightful)
The job is indeed in India (Score:5, Funny)
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:
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.
Is this news? (Score:3, Interesting)
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 ... (Score:4, Funny)
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 ... (Score:2, Insightful)
Re:Starting to sense a pattern ... (Score:4, Funny)
> 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 (Score:5, Insightful)
Are they going to release command line versions of most of their administrative tools?
Any windows sysadmins out there feel free to correct me if I'm wrong, but its generally not the lack of shell features that keeps me from using cmd.exe, but rather the number of programs that you can run with it.
Re:Good step (Score:2)
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)
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)
If you want to compare this to existing non-MS projects, this sounds like a combination of bash and BeanShell [beanshell.org], rather than a simple shell replacement.
If this achieves its potential, Linux/UNIX may end up playing catch-up on the CLI front as well as on the GUI front. Good move for Microsoft, and one that would be hard to counter in the open/free software world because we have no universal object-based virtual machine/interface for use as a basis.
Or rather, I should say we have too many - Java, CORBA, the Mozila components, and even
Re:Good step (Score:4, Insightful)
Re:Good step (Score:5, Informative)
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
"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.
in theory, but not in practice (Score:3, Interesting)
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).
additional information (Score:2, Interesting)
Those dont know UNIX are (Score:2, Funny)
I don't know who said it. But it true IMHO.
Happy New Years to you all!!
Re:Those dont know UNIX are (Score:4, Informative)
"Those who don't understand UNIX are condemned to reinvent it, poorly." -- Henry Spencer
Re:Those dont know UNIX are (Score:2)
Henry Spencer - who originally said: those who do not understand Unix are condemned to reinvent it, poorly.
Even more appropriate...
A good thing, really. (Score:5, Interesting)
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 ;-) (Score:3, Interesting)
--
[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 ;-) (Score:2)
Re:Good news... kinda ;-) (Score:2)
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
Re:Good news... kinda ;-) (Score:3, Informative)
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 (Score:3, Interesting)
There are 2 things I wonder about though: .Net and not the full OS?
1. Why is this only via
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 (Score:4, Informative)
You guys didn't research this too hard, huh? [jsifaq.com]
Re:Needed at the Enterprise (Score:2)
What's next on Microsoft's to do list? (Score:5, Funny)
Tel.net, Microsoft, "operate" and "*ding*" are all registered trademarks and ©2002 Microsoft Corporation. All rights reserved.
Yeah! More Backdoors!!! (Score:3, Interesting)
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
cu,
Lispy
Great (Score:2)
they'll screw this one up as well (Score:5, Insightful)
Look, in contrast, at the "next generation UNIX shell", rc [bell-labs.com], from Bell Labs. "rc" intends to simplify, remove unnecessary functionality, and factor out features like job control and command line editing.
Re:they'll screw this one up as well (Score:2)
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)
Re:WSH (Score:2)
This validates the UNIX way of doing things ... (Score:5, Insightful)
For them to turn around and now build this super-shell basically amounts to admitting that a GUI based aproach does have some serious shortcomings and that the UNIX way of allowing everything to be scripted provides serious benefits which are hard to come by if everything is accessed through a GUI. If nothing else, this validates the UNIX way of doing things and should make it easier to argue this point when competing for (a) large (number of) server installs/farms.
I worked at a large (1000+) NT consulting shop (Score:2)
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.
Alex
tabs billy, tabs! (aka request for tabs) (Score:2)
I would imagine.... (Score:2)
Possibe names for the shell (Score:2, Funny)
Command-line Remote-capable Advanced SHell (CRASH)
Microsoft Advanced SHell (MASH)
Synchronous Multi-user Advanced SHell(SMASH)
What is YOUR favourite?
Re:Possibe names for the shell (Score:2, Funny)
Windows Extensible Argument Related Event Activator Made On Needlessly Over Programmed Object Languages Yesterday
Yes, I know. I am a huge loser.
The problem with re-inventing the wheel... (Score:2)
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"
Virus delight (Score:5, Funny)
Virus writers - here is your big chance to spread like wildfire through windows machines!
Damn... (Score:4, Funny)
Pervasive Autocomplete (Score:2)
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=CreateObject("Word.Application")
Word.Fi
Word.Print
Word.Quit
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
Can they get serious? (Score:3, Insightful)
Didn't develope its command line interfaces since the beginning of the 90's.
Didn't support implmentations of more advanced scripting tools like perl or python.
Claimed for years that shell suxxx. They marketed their system as a growing evolution from the crippled shell environment.
Granted that, in the future, all management would be through the GUI.
And now I am hearing that they are getting back to the start?
Interesting. I have seen several interesting things while I developped for Windows. and one of the things I was pretty sure, was that implementing shells or scripting tools was hard. Perl (native Win32) or bash (through cygwin) gave me always a sense of a certain handicap in relation on the *NIX world, where most of its control was based on the existence of shells. I could not get into the inner mechanics that ruled many Windows apps because their data was never supposed to be handled directly by shells. Note that many apps produce binary data, even when there is no clear need for it. So, if one needs to use perl or something similar to handle Windows data, one usually needs an interface or some tweaking on files. And, due to the fact that Windows lacks established standards for (almost) similar kinds of data, one needs to deal with different tools to deal with each piece of data.
A similar situation occurs also with file formats. Sometimes, the format of different versions of one and the same program varies so radically, that one is forced to deal with different interfaces for each version. That's also one of the reasons whyscripting tools didn't gain a wide acceptance in Windows.
Also one problem is that many programs on Windows base their interaction in a memory-to-memory basis, while *NIX still keeps a lot of its interchange in a filesystem basis.
So I am scheptic that M$ is able to do a serious move on this field. However I may understand why they are moving with a new scripting system. Frankly, with all the mess they created, perl and many other tools will never be able to have a fullscale use on Windows like in *NIX. But that depends on how far M$ will go on the development of this new system. If they will create some sort of Easy-VB-like scripting tool, it will not catch the souls of sysadmins. If they create a full-scale mutant like perl, they risk to give a new weapon for script-kiddies, but sysadmins will surely catch the wave.
Huh? (Score:4, Funny)
MacOSX, Applescript and why MS is doing this. (Score:3, Interesting)
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.
MS was at USENIX/SAGE asking what makes a good CLI (Score:5, Interesting)
Wouldn't it be interesting ... (Score:3, Interesting)
Imagine Stahlman winning a copyright infringement lawsuit against Microsoft and Windows getting "infected" by the GPL
Remember this classic line? (Score:3, Insightful)
Way to Go, Microsoft (Score:5, Insightful)
- Having both Gnome and KDE is good because the competition will cause both to get better
- Having a Linux/UNIX desktop environment is good because the competition (with Windows) will cause both to get better
I've seen these kinds of arguments spouted repeatedly by purveyors of the Slashdot party line, and I've even made a few myself. What we have here is a confirmation of the underlying idea: that competition improves products.Plan and simple, Microsoft is competing. They've acknowledged a strength in a competitor's product and are (finally) going to tackle it head-on instead of with shady business, cash, and lawyers. They're going to try to build a better product. This is what we've wanted all along, isn't it?
I wish Microsoft's programmers the best of luck in creating these new features. They will most likely be a great improvement to the Windows platform. Likewise, I wish the Linux/UNIX communities the best of luck in creating new features to greatly improve Linux/UNIX. I believe that competition between the two groups will significantly advance the start of the art in software. Microsoft is ready to play serious but fair ball, and it's up to the rest of us to build a winning team and play the game. Humanity stands only to gain.
Promises, promises (vaporware and monopoly) (Score:3, Insightful)
Ha, ha: only serious...
Just in case you were working on something to solve a shell problem, just stop, because you can't compete. I mean, this is Microsoft, and nobody will believe that you can put out something that works better than theirs.
Even if you do actually accomplish that feat. Even still, Microsoft will trace the API calls your shell makes and pull the rug out from underneath you in the next automated .NET framework service-pack.
Then, they'll link their knowledgebase to promos of their product so when your customers search for a solution to why your shell started behaving badly (just after the ServicePack was applied), they will see "use the Microsoft shell". Next, your boss will get a letter explaining that Microsoft is attempting to purchase the rights to your project, and all your boss has to do is kill your project to collect more money than they've ever paid you (and prolly some killer seats at _insert_big_sports_event_here_).
Next, you'll probably end up contributing code to some consulting firm that agreed to make the Microsoft shell do what yours already did. It'll cost 20 times as much, and it'll be 1 year past the delivery date you would have made, and by then you'll be sick of dealing with the problems your shell intended to solve.
You'll try to move on to something else, but every where you go, no matter what you try to get into, the same old shell scripting problems will stymie you because NOBODY solved the problems that Microsoft promised their shell would solve. It will haunt you until you completely switch fields or commit suicide, or some other depressing and too-boring-to-enumerate possibility.
There is no monopoly in Unix implementation. Stick to Unix if you don't want to hire (or be) a staff of service-retarting, server-rebooting, reinstalling monkeys to do boring repetitive click-and-drool tasks at the console of a server , in what was *supposed* to be a lights-out data center, checking blanks on the left margin of of a mainframe-era "run book" as they (you) go.
Happy new year!
Re:MS is responsive: that's why they're #1 (Score:2)
Will it be free?
Re:MS is responsive: that's why they're #1 (Score:2, Interesting)
Re:MS is responsive: that's why they're #1 (Score:3, Funny)
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.
Re: (Score:2)
you are absolutely right (Score:2)
Yeah: they collect every possible feature under the sun into a gigantic feature list. Then they hire away a number of experts from other companies that feel constrained not to be able to do what they wanted to do at their previous jobs and give them lots of money and programmers. And instead of having to compete for market share with their ideas, they just get to dump whatever they come up with into the Windows distribution. The result spells out "second system effect" in big letters.
Good design requires restraint and tradeoffs. It requires figuring out how to pick a small set of features that get most of the work done. It requires actually competing in the market place, where not only dysfunctional systems fail to find acceptance, but also systems that are too complex and big for mere humans to figure out. Microsoft completely lacks the taste, corporate culture, or ability to make those tradeoffs.
But you are right: this approach is indeed why they are number one. There are many morons out there who do indeed think that the longest feature list is what makes a system good.
Re:you are absolutely right (Score:4, Insightful)
Leaving aside the question of what a "very solid GUI" might be or whether Microsoft can even remotely be argued to have one, you are ascribing too much long-range planning to Microsoft.
Microsoft responds to the market like a leaf in the wind. All their various approaches to GUIs were driven by a panicky reaction to competition. Their first GUI was a reaction to Macintosh. MFC was driven by the success of competitive object oriented GUI libraries. The 3D look was a reaction to Motif. GUI builders were a reaction to third party tools and NeXT. RDP was an attempt to clone X11's remote access features. And their latest, C#/CLR is basically a Java clone.
Now, Microsoft feels extremely threatened by Linux, both on the client and on the server, and they are desparately trying to clone the essence of Linux so that their servers won't become completely irrelevant.
Microsoft doesn't plan or strategize anything for the long term. Microsoft is driven by paranoia, "not invented here", and the usual geek attitude of "if we implement it, it will be better". Nothing could be further from the truth, of course.
Re:you are absolutely right (Score:2)
Well, I can't get inside of Gates' head, so I can't say for sure, but I'd find it a tremendous stroke of luck if a company could go from nothing to the largest on the planet in 20 years by doing nothing but kneejerk reactions to competitors.
Re:you are absolutely right (Score:2)
It has nothing to do with luck. Embrace-and-extend works if, like Microsoft, you have a monopoly. And Microsoft didn't even earn that monopoly themselves, they got it handed for free by IBM.
Re:you are absolutely right (Score:3, Funny)
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:you are absolutely right (Score:2)
sorry, but this won't help Windows either (Score:3, Interesting)
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.
Responsive!? (Score:2)
Re:Responsive!? (Score:4, Insightful)
That's how business works. You can't make every customer happy. That's impossible. Gap can't have a rack of clothing designed to perfectly fit every single individual that comes in there. Not possible. I have a small store. I can't have *every* item that every customer has ever asked for. That's not possible, either. But, at the same time, you DO make money by making as many of your customers happy as possible. That makes 'em buy. Kinda' basic. Contrary to the popular Slashdot opinion, MS doesn't have legions and legions of pissed off customers. If they did, then Apple would be huge today. So I agree, making customers happy alone isn't a sufficient reason, but it is a major part of deciding what to implement when.
Re:Responsive!? (Score:4, Insightful)
Bill said many years ago that he doesn't assign programmers to projects unless the project will make money for Microsoft or advance its strategic goals. Making customers happy is not a sufficient reason.
Do you really think that BillG got to be worth $40 billion by making customers UNhappy? Do you really think that 93% of all end-users are masochists? Do you really think that people in a free market choose of their own free will to buy inferior products?
Or do you suppose that Apple [Macintosh] & NeXT [NeXTSTEP] & Commodore [Amiga] & Novell [DrDOS/NetWare] & Digital [RSTS/VMS/True64] & Sun [SunOS/Solaris] & IBM [OS/2] & Linux [Gnome/KDE] couldn't [and, to date, still can't] get their heads out of their asses for long enough to give the consumer he wants: An inexpensive platform that allows him to copy from a text editor, paste to a spreadsheet, and vice-versa, without having to go back to school to get a goddamned PhD in the minutae of Bourne Shell scripting [much less artificial intelligence, LISP, and emacs]?
Re:MS is responsive: that's why they're #1 (Score:2)
Do you really think that BillG got to be worth $40 billion by making customers UNhappy? Do you really think that 93% of all end-users are masochists? Do you really think that people in a free market choose of their own free will to buy inferior products?
Or do you suppose that Apple [Macintosh] & NeXT [NeXTSTEP] & Commodore [Amiga] & Novell [DrDOS/NetWare] & Digital [RSTS/VMS/True64] & Sun [SunOS/Solaris] & IBM [OS/2] & Linux [Gnome/KDE] couldn't [and, to date, still can't] get their heads out of their asses for long enough to give the consumer he wants: An inexpensive platform that allows him to copy from a text editor, paste to a spreadsheet, and vice-versa, without having to go back to school to get a goddamned PhD in the minutae of Bourne Shell scripting [much less artificial intelligence, LISP, and emacs]?
Re:Wasn't the CLI have disappeared? (Score:3, Insightful)
Contrary to popular belief, Windows98 is not a server operating system, it is a end user/consumer OS.
For a Server OS it makes a whole lotta sense to have a powerful CLI, for a end user OS, not as much.
I know this concept of seperating the two might seem strange and frightening, but it does reduce the number of support calls asking: "Should I type <appname> /xcc -cvx /gsg -fjhghsjh /vnbbxcxoOfjnf" or is it "<appname> /xcc -cvx /gsg -fjhgHsjh /vnBbxcXoOfjnf"?
Re:Wasn't the CLI have disappeared? (Score:2)
Indeed. Instead, they have calls like : "Where can I change this ? Edit menu, right. Preferences
I'm not sure it's easier to talk about a 2D graphical environment than a 1D command line one. Really.
Userfriendliness is another thing, but having had some phone calls from my grand father, believe me, it's horribly hard to describe graphical interfaces (not to mention they change in every version).
Re:What the... (Score:2, Insightful)
They're talking about discovering which objects are installed on the system and finding which API's those objects expose, all from the command line. Sounds very much unlike bash to me.
I currently use cygwin bash and bash on FreeBSD, and the description of this new MS shell sounds way better.
This really goes to show why Windows will "win": Everything Windows does could be done on a Unix box. Absolutely everything. But it isn't, and it won't be. Here's why: There's no agreement among the developers on the Unix platforms. Sure, I could write a command shell on FreeBSD that has some sort of similar discovery mechanism, or I could write a GUI and a few apps that allow embedding parts of spreadsheets inside of word processing documents, but what have I gained? Not a whole lot. No one else will follow my lead, so my work will die. On Windows, MS does a reasonably good job of things like this and all applications jump on the bandwagon, and the users profit from it.
Re:What the... (Score:5, Informative)
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 :)
Re:What about this one? (Score:3, Informative)
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.
Re:What about this one? (Score:3, Informative)
Re:Well that's nice (Score:3, Interesting)
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!