The next-generation Microsoft Command Shell has made it to the beta stage. The Monad team has announced to testers that Beta 1 is now available from Microsoft Betaplace. For more information about MSH and how to get it, check out the Channel 9 wiki.
The next-generation Microsoft Command Shell has made it to the beta stage. The Monad team has announced to testers that Beta 1 is now available from Microsoft Betaplace. For more information about MSH and how to get it, check out the Channel 9 wiki.
Why do I have to login with Passport to download? Does MSH run on Windows 2K?
I have high hopes for this, I hope I won’t be disappointed.
I’ve been using the XP command line for everyday work with various GNU for Windows applications (wget, etc), but I’ve missed the power of Bash and its brothers and sisters.
Hopefully this will bring that kind of functionality to Windows.
I’ve been a beta tester for awhile. Here’re the requirements:
* You must use a Windows XP or Windows Server 2003 machine with all current updates.
* You must have have administrator-level permissions on the machine
* You must first install the .NET Framework 2.0 Beta2.
so, is the final release of monad will be for longhorn server edition or for blackcomb?
going to try it this weekend, just got a notification mail from redmond. hopefully it will be more like a “shell” and not just a scripting environment…
Cygwin will do the same thing, only it’s free, well tested and stable.
Um, no. Cygwin has a shell that will enable you to script Unix-style command line tools on Windows, but most Windows applications are not like that. You can’t script them with bash, and even Perl and Python have trouble with them.
On the other hand, the WSH can do a lot of what MSH can do, if more awkwardly.
Don’t get me wrong, I can’t use a Windows machine without Cygwin, but MSH is quite different. The Unix shell’s fundamental data type is a list of strings. MSH uses a type system similar to most “full” programming languages.
But don’t let the MSH guys fool you (the Channel 9 video was worthless). All they have is a Perl-like language with some additional shell-like features. Pipes aren’t magical. They’re just syntatic shorthand for a linear function call graph.
a | b | c == c(b(a()))
Add lazy lists and you’re done.
Welcome to the 80s Microsoft. Perhaps this will finally prove to the click-here dweebs that shell environments are not obsolete relics of the antiquated age that should be replaced by shiny icons, overflowing menus, overloaded toolbars and the convoluted curse we call the modern day GUI. Ha!
a | b | c == c(b(a()))
Really?
So something like this:
# updatemysqldb.pl `tar -cf – * | ssh user@host ‘cd /blah && tar -xvf-‘`
..should be just as easy in MSH.
Anyone got any examples of how this new shell works?
come on people, you don’t /need/ to test this crap, half-baked system for microsoft, they have people employed for that kind of thing, if the idea of anything beyond cmd.exe is new to you, just grab cygwin.
This becomes as easy in MSH.
find / ( -perm +4000 -fprintf /root/suid.txt ‘%#m %u %p
‘ ) ,
( -size +100M -fprintf /root/big.txt ‘%-10s %p
‘ )
((searches for files that set userid and also files over 100MB in size, and creates two files with the information – from the linux “find” man page, fyi))
Back in the days. Unix fans were criticizing MS for having their GUI as the main interface to control the OS. Everyone used to say Why would I use remote desktop if I can ssh (rlogin etc) to do the same thing.
Now you are telling them welcome to the 80’s ? It is an extra integration of the current GUI to allow Unix fans to exercise their habbits without using GUI to control the OS. Even though CMD is a good shell but of course it does not compete with csh and other known shells.
Forget about Unix fans now think of the current users who used to script batch files and vbs to do similar jobs. This is absolutly a neat integral feature in the next Windows release.
Cygwin is great if you don’t mind a little performance hit. There are native compiles of bash that do work grand. I suggest the tool set that comes with mingw, thou the last time I installed cygwin mingw was an option. It looks like these days it’s using a light weight fork of cygwin. Should be a little faster (particularly on start up).
I should probably check out this monad thou. I’m probably going to end up using it sometime in the future.
You know, this shell has been in beta for about four months plus. At least, that’s how long I’ve had access to it on betaplace. No news here.
On a brighter note, if anyone is looking for a *nis-ish shell, then just compile tcsh on windows!
oops, I meant *nix-ish, not *nis-ish, LoL.
One last thing, anyone intersted in Monad, let me just say that it sucks. It’s nowhere near as good as using a real shell. Also runs really slow because of using the .net framework runtime.
” so, is the final release of monad will be for longhorn server edition or for blackcomb?”
The final version of MSH will ship for: Exchange 12, Windows 2000, Windows XP, Windows Server 2003, Longhorn and Longhorn Server. It is on track to completely replace CMD by the time Blackcomb comes out.
Theses are from an infoworld article. I would just link to it but their having some problems ATM.
MSH> get-process
Handles NPM(K) PM(K) WS(K) VS(M) CPU(s) Id ProcessName
——- —— —– —– —– —— — ———–
105 5 1224 88 32 0.11 1956 alg
41 2 816 180 23 0.09 1340 aspnet_admin
69 3 2336 68 36 0.86 760 cmd
35 2 860 148 27 0.23 1352 Crypserv
539 6 1868 2312 27 44.89 556 csrss
100 5 960 1308 29 1.30 1252 ctfmon
…etc…
MSH> get-process | get-member -p
Class Name MemberData
—– —- ———-
Property __NounName System.String
Property BasePriority System.Int32
Property Company System.Management.Automation.MshObject
Property Container
Property CPU System.Management.Automation.MshObject
Property Description System.Management.Automation.MshObject
…etc…
Here are processes using more than 15MB of virtual memory:
MSH> get-process | where { $_.virtualmemorysize -gt 150000000}
Handles NPM(K) PM(K) WS(K) VS(M) CPU(s) Id ProcessName
——- —— —– —– —– —— — ———–
2411 89 74680 42572 211 1,176.00 396 firefox
395 11 32720 14848 272 79.89 3504 msh
484 18 30180 16012 235 337.41 2068 OUTLOOK
398 16 19172 1220 173 12.33 3636 WINWORD
Grouped by vendor:
MSH> get-process | where { $_.vs -gt 150000000} | group-object company
Count Name Group
—– —- —–
1 Mozilla {firefox}
1 – {msh}
2 Microsoft Corporation {OUTLOOK, WINWORD}
Just selected properties:
MSH> get-process | where { $_.vs -gt 150000000} | pick-object name, path, id, vs
name path id vs
—- —- — —
firefox C:firefox.09fi… 396 220983296
msh C:Program Files… 3504 285908992
OUTLOOK C:PROGRA~1MICR… 2068 245936128
WINWORD C:Program Files… 3636 181805056
Ordered by virtual memory size:
MSH> get-process | where { $_.vs -gt 150000000} | pick-object name, path, id, vs |
sort-object vs -d
name path id vs
—- —- — —
msh C:Program Files… 3504 285908992
OUTLOOK C:PROGRA~1MICR… 2068 245936128
firefox C:firefox.09fi… 396 220983296
WINWORD C:Program Files… 3636 181805056
Results assigned to a variable:
MSH> $v = get-process | where { $_.vs -gt 150000000} | pick-object name, path, id, vs |
sort-object vs -d
MSH> $v
name path id vs
—- —- — —
msh C:Program Files… 3504 285908992
OUTLOOK C:PROGRA~1MICR… 2068 245936128
firefox C:firefox.09fi… 396 220983296
WINWORD C:Program Files… 3636 181805056
MSH> $v[0].id
3504
Preview a request to kill processes using more than 20MB of virtual memory:
MSH> get-process | where { $_.vs -gt 200000000} | stop-process -whatif
# stop-process on firefox (Mozilla Firefox)
# stop-process on msh (Windows command shell preview)
# stop-process on OUTLOOK (Inbox – Microsoft Outlook)
Theres also examples where output is piped to Excel and XML! (can’t post)
” One last thing, anyone intersted in Monad, let me just say that it sucks. It’s nowhere near as good as using a real shell. Also runs really slow because of using the .net framework runtime.”
IMHO it is better than most shells on a UNIX system. I dont have a problem with speed and Microsoft even releases a 74 page indepth Getting Started RTF file with it. This drop is the June 17 2005 drop much better and complete than the September 2004 drop. They also have 64 bit editions available for people to test on a 64 bit system. Runs extremely well under a Windows Server 2003 install.
Of course the fact that it is Beta 1 (of an entirely new product) wouldn’t be an excuse that it might have some rough edges.
Obviously. But I feel that this clone of any real shell is somewhat depressing. The one thing I hope they do is drop the whole .net design in it. Something native would be a far better way to go.
Personally, if I were looking for a shell to replace the standard cmd.exe, I would most likely go with Services for Unix (SFU). It comes with ksh and tcsh by default and runs pretty well. I also like that fact that it mimics an entire *nix system within windows and gives you the ability to interact with the system as you normally would through cmd.exe.
Does any one else think that the whole Monad crap is designed to try to lure Linux users back to Windows? For that matter, SFU as well. I hope this idea goes past the cmd shell and we actually see M$ importing a more stable and robust kernel;) Can’t wait to see where this goes.
The shell in a *nix like environments works because all the little programs and stuff understand signals, backgrounding, stdout, stdin, stderr, piping, redirecting, etc. They’re “shell ready”. Microsoft bolted MSH onto its windows systems as an afterthought. Without every component and application to understand it, it’s pretty useless. Just another frontend for the (dying) WMI infrastructure.
> ((searches for files that set userid and also files over
> 100MB in size, and creates two files with the information –
> from the linux “find” man page, fyi))
Since when “find” is part of the shell? 🙂
The main thing about writing shell scripts to me is automation. Will MSH help me with automating tasks I want to do with applications that aren’t command-line utilities?
One could say the same about the GUI in unix like environments.
> One could say the same about the GUI in unix like environments.
*cough* macosx *cough* applescript *cough*
Great innovation from the proprietary Microseft labs, as usual.
“One could say the same about the GUI in unix like environments.”
Can’t say I disagree in a lot of cases. Luckily there’s always the commandline to be productive in
Besides, all a window manager is good for is to have a lot of xterms in the same screen 🙂
Fred you seems to be really uninformed (your last but one post). Who said WMI is dying? WMI is a great technology for which Linux will have to wait for ages. Similarly a simple command line is not enough. The days of only text are over. Monad gives you a text command shell with powerful .NET support built into it.
WMI gives you such an ease to query system information. Many drivers in windows implement WMI support and user mode application can easily query information. WMI gives same command interface locally and remotely. It does supports integrated windows authentication. Tell me even single equivalent of that in Linux? How do you query bios properties in Linux? In windows there are so many useful WMI classes which you can use to obtain information quickly.
Another advantage of having such a cool shell is that now i have the combined power of a shell and all the whizzy cool programming language like perl etc built into the shell. .NET integration makes sure that monad will take advantage of all the cool features of .NET as they are developed.
Now i give you a scenario and you tell me if there is anything like that in Linux: Microsoft’s Virtual Server exposes its whole functionality via DCOM objects. You can create virtual machines, control them and do all the tasks from DCOM interface which you can do from GUI. With monad, you can write small scripts to easily access that interface locally as well as remotely. You can code in any language you like and you can still access the full virtual server functionality. That is the true power. What is equivalent technology in Linux and please don’t mentioned any half baked KDE hacks.
Monad if future…gone are the days of pure text based shells…Microsoft lately is doing some really cool programmers oriented stuff and i like it.
Perez please read my last post and please don’t act like a loser by giving comments without sufficient technical information. This only makes you and the ones who brought you up, look stupid.
WMI ? What for ? We got ssh kid!
By the way, shells are not text based!!! It’s plain binary data!! A pipe is just redirecting stdoud of a program to the stdin of another. One can still serialize objects if he wants to have object oriented stuff.
Look at that example mentioned earlier :
tar -cf – * | ssh user@host ‘cd /blah && tar -xvf-‘
It not text, is it?
“Fred you seems to be really uninformed (your last but one post). Who said WMI is dying? WMI is a great technology for which Linux will have to wait for ages. Similarly a simple command line is not enough. The days of only text are over. Monad gives you a text command shell with powerful .NET support built into it.”
Hmm, I didn’t mention linux afaik. But since DTrace is available as OSS, I doubt it’ll take long. In the mean time I guess we have to make do with /proc, sysfs, acpi-tools, lspci, dmidecode, etc. You know, the usual interfaces to query every bit and byte you ever wanted to from a linux system. WMI is a bit of a late comer to this arena, yaknow. I’ll grant you that WMI provides a nice, single programming interface to access the same data which is available to everyone else who wants to. Including linux users, even though you seem to love to claim they can’t.
And for WMI dying, well, that might have been a bit of an overstatement. Maybe because it’s relatively unknown outside of the hardcore windows crowd has something to do with it. Ask a generic windows admin about WMI and all you get is a blank look.
“WMI gives you such an ease to query system information. Many drivers in windows implement WMI support and user mode application can easily query information. WMI gives same command interface locally and remotely. It does supports integrated windows authentication. Tell me even single equivalent of that in Linux? How do you query bios properties in Linux? In windows there are so many useful WMI classes which you can use to obtain information quickly.”
“Easy” is something I wouldn’t directly relate to WMI and its programming.
Again you start relating it to linux, and again I point you to the same stuff like /proc, sysfs, dmidecode, acpi-tools, lspci, etc. They might not provide one “it does it all!” interface, but then again, the *nix philosophy doesn’t really allow that anyways. Outside of linux, there’s a whole slew of other possibilities. Sun’s DTrace being one example.
Oh, and for the “Integrated Windows Authentication”, you should know as well as I do that *nix uses a different authentication model. “Proving” that linux can do the same would be senseless in this context. The point is, you can glean as much information from any random linux installation as you alledgedly can from WMI. Better, most of WMI is read-only, at least linux and most of its drivers allow you to change things too…and you don’t need a COM object to do it either. Just echo and /proc.
“Another advantage of having such a cool shell is that now i have the combined power of a shell and all the whizzy cool programming language like perl etc built into the shell. .NET integration makes sure that monad will take advantage of all the cool features of .NET as they are developed.”
Why is it that MSH fans seem to relate the concept of “shell” to “programming”. I think you people need to take a long hard look at what makes a shell a shell. Believe me, it’s not about how many languages you can make scripts in. It seems like MSH is all about giving as complex as possible access to the most obscure parts of the system. That’s stuff which is only nice for the manual to show of how “powerful” the “shell” is. Most people just want to get work done…like having the output of one program be piped into another program for further processing, and then have a mail sent to the admin when it’s done. When that isn’t possible without having to dig deep into COM objects, WMI structures, insane programming instructions, overly obfuscated programming syntax (who came up with the MSH syntax?), it’s not going to stand a chance in the real world. Admins who come from other OS’es will still complain about Window’s inability to do simple tasks elegantly and without insane amounts of programming…which most admins DON’T WANT TO DO!
“Now i give you a scenario and you tell me if there is anything like that in Linux: Microsoft’s Virtual Server exposes its whole functionality via DCOM objects. You can create virtual machines, control them and do all the tasks from DCOM interface which you can do from GUI. With monad, you can write small scripts to easily access that interface locally as well as remotely. You can code in any language you like and you can still access the full virtual server functionality. That is the true power. What is equivalent technology in Linux and please don’t mentioned any half baked KDE hacks.”
Of course it isn’t possible in linux. If I didn’t have to mow the lawn I’m sure I could come up with a couple of tasks which have no way of being able to be performed in Windows either, whether MSH exists or not. These are artificial examples, especially made up to prove a point. Well, you’ve only proven that MSH is overly complex, and will never be able to compete with a real “shell”.
“Monad if future…gone are the days of pure text based shells…Microsoft lately is doing some really cool programmers oriented stuff and i like it.”
Shells aren’t used by programmers, they’re used by real people who need to do real things in a real world. Preferably without having to be a Microsoft Certified Programmer to be able to use the fucking tool everyone is telling them they have to use. Can you say “Overengineerd”?
Back in the days. Unix fans were criticizing MS for having their GUI as the main interface to control the OS. Everyone used to say Why would I use remote desktop if I can ssh (rlogin etc) to do the same thing.
Yep, true. And MS fans were the loudest critics because of that cryptic terminal in windows, but look at them now, they are all happy:)
Personaly I welcome the shell in any system. Although I think that shell depending on .NET is a bit too much. Don’t get me wrong. I like C#, just as long as it is ment to run client applications. But for server and scripts that are being runing 24/7??? Well, I’m still wainting to look at java or .net VM that doesn’t dissapoint me after running one whole day.
Maybe a bit of topic. While I talked about .NET, I would have one question for MS.NET coders (I’m not trolling, this came out of my wish not to deploy mono but use existing .net that is mostly already present on XP machines, in that case the only thing I would need is to deploy gtk# if needed). I haven’t tested .NET on Windows a lot, just Delphi.Net, Matrox Powerdesk (god is this one slow) and Sharpdevelop. Everything is running like I would be running remote desktop over 56K modem (powerdesk is even worst, takes about 30sec to change number in monitor refresh rate). I’m not used that from mono (apps running with mono as VM are running smooth on windows). Is there something that default settings MS.NET are doing wrong, otherwise I can think of nothing but this: “this is not a bug, it’s a feature”.
I tried that on my notebook first. Then I set up a new machine with XP, updated it and installed .NET. Same result. I even tried that on second machine with completely different hardware. Again the same result. So, I can’t help my self but to wonder if there is something wrong with MS.NET by default.
You fail to understand that COM, in its current form, is a security nightmare. So virtual machines can be managed via a COM interface, great. That means that any script kiddy will be able to have your server completely pwn3d via a COM exploit, gaining control of all your virtual machines. If you want to run multiple OSs use something like Xen and run real operating systems as guests. If you have the cash, buy some LPAR enabled IBM box or a Sun server.
While, yes it is an afterthought, the reason why Muglia said Monad won’t be a full scale product for another 3 to 5 years is because of this. They expect to have at least all MS apps talk to Monad, and hopefully all new 3rd pary apps will too.
Also, as a side note, what was available on BetaPlace before was “Windows Command Shell Preview”. This is beta 1, before it was a pre-beta. If you’ll notice, there is also a new beta version of .NET 2.0 there as well.
Really, what is this so different from the interactive console of a scripting language? Apart from the bolt-on shell like syntax, in fact what it’s doing is passing objects and messages around.
The way a posix shell works is simple, and because it is simple, it allows a LCD approach to tying together different programs.
COM is no more of a security risk than any other code running locally on a machine. No matter how the interface is exposed, some authentication method needs to be used if you don’t want just anyone using your system. Most script kiddies take advantage of the user giving them local execution rights, or a known exploit in an application (COM or not) that allows them to execute their own code in a privileged context. COM’s biggest failure was users agreeing to install and run any and everything without reading the dialog telling you about the code. Users are exploited in the same way via running executables in email attachments or downloading software from malicious sources. None of this is unique to COM.
.NET improves on this situation by adding a set of policies for the code itself and not just the user. Even under this model, if a malicious developer creates a .NET application that requires full trust to execute, that app can do whatever it wants because the user gave it that level of trust. The user can be protected by a malicious app using another .NET app to gain privilege if that other .NET app runs at a lower privilege. These benefits aren’t yet available on Mono unless one of the recent builds added Code Access Security.
Technically, mono doesn’t need that feature, not on any OS with a decent security model of itself anyway. There’s no such thing as “full trust” for a user to give when said user isn’t running as root (giving a *nix example). I’m sure Code Access Security works well in a Windows environment where educated users are behind the buttons. But alas, the real world teaches us that windows users will click anything anyway as long as it makes their application to work. Malicious or not. Basically, .NET’s security model tries to solve a problem which is unsolvable due to the design decisions which make up “windows”. I don’t see the whole issue going away anytime soon either. Even Lonhorn will have a special “feature” to run IE in a sandbox. It seems even Microsoft can’t fix its products anymore to do the right thing.
BTW, according to counterpane security inc. DCOM and LSASS exploits are fighting eachother over being the most popular attack vector. (http://www.schneier.com/crypto-gram-0506.html#1). (D)COM is broken by design, yet everyone is claiming that it’s the user’s fault. I say the whole environment is broken by design.
the mingw setup…it rox!
And Monad looks pretty impressive…kind of gimmicky at the moment but cool nonetheless…appeals much to the nerdiness side of me…
So when the GNU reimplementation of Monad finally comes around, will it be called Gonad?
CAS in Mono (my linux biased view)
http://www.go-mono.com/archive/1.1.8/
http://www.mono-project.com/CAS
Not yet, but in production. But, personally I agree with Fred. The only problem posed here is only: your VM server is running as what. In windows by default .Net server is running with full privileges and there is the need for CAS. If you could say NO to this and run .Net as simple user, then your server would be locked out from doing anything on system level. And you do that on Windows, HOW???
Personally, I would never execute .NET system services on linux, and taken this point I would also suggest to restrict VM server to userland. In this case CAS is completely unusable. Just as I would never run java services. Both aren’t capable of running for 2 days without consuming all of system resources (Memory manager and garbage collector are the first that come on my mind) and 2 days is not 200 as I’m used to.
So, user software? Yes.
System services? No.
Your explanation of CAS? Correct, but only from Windows view where you’re forced to run VM server as full privileged Administrator or in case if one of your AppDomains needs full privileges, which I don’t think it will be happening a lot on linux. beagled comes to mind, but I think that even beagle can be restricted to non-privileged account without a hassle. Just use either Xen or chroot. Both should work. Maybe even sudo. All it is needed is that your system access is limited. Remember, VM server has just as much privileges as the user that owns it. It is just a simple highest or lowest starting privilege.
But, better explanation is in this blog post, and yes he praises CAS
http://zacbowling.com/blog/2005/06/12/secure-execution/
I have with .net, monad, cygwin, VC++ and why I quit using all that is the one fatal flaw: everything you write and use is only as good as the OS it’s running on, and in the case with these since they’re all running on Windows, well, we all know how good and stable that is…
Even when running under a limited account CAS provides the benefit of limiting the rights of the code beyond that of the user. Thus you can give an application just what it requires to run and no more. If another app comes along and tries to co-opt that app, it will also be restricted to only the permissions the developer of that app allowed.
When running with escalated privileges, CAS provides further benefits because even though you’re running in the context of a privileged user, you can still use CAS to deny access to functionality other than what is required by the app. If the app doesn’t require File I/O (for example), that can be specifically denied so other applications can’t use your app to gain that right even if the user is running as admin and your app is running in that context.
On Windows, you can easily run as a normal user if desired. Most managed (as in controlled by network administrators) environments do this. The only problem is that it isn’t the default on normal setups, so most regular users run w/ Admin permissions (this changes in “Longhorn”). The model isn’t broken, it just has bad defaults.
The thing about services and memory consumption is false. I’ve run .NET system serveices before with zero problems. Anyone can make a bad app that leaks memory, even in .NET.
no matter how fancy. Does it need a Radeon or better, too?
I’ve been a beta tester for awhile. Here’re the requirements:
* You must use a Windows XP or Windows Server 2003 machine with all current updates.
* You must have have administrator-level permissions on the machine
* You must first install the .NET Framework 2.0 Beta2.
>
>
Why in h*** does a *COMMAND SHELL* need garbage lke .NET Framework?
>> ((searches for files that set userid and also files over
>> 100MB in size, and creates two files with the information –
>> from the linux “find” man page, fyi))
>>
>>Since when “find” is part of the shell? 🙂
>
>
From the moment he made up this phoney example….
Perhaps because it’s written in .NET and takes advantage of some of .NET’s features, as are probably just about all other new Windows components that will be coming up, I’m sure.
And why exaclty is .NET “garbage”?
1. Agree about CAS in Windows, in fact it is what I’ve said in my comment.
2. Again agree about privileged and non-privileged IPC communication and restricted parts of the program. In fact I can welcome that solution in some cases on linux too.
3. You missed my question. While I can restrict max privilege in which mono server is running (at least on linux), how do you do that for MS.NET. As soon as any system part needs administrator privileges, .NET VM (remember that I talk about .NET VM) is activated with such privileges as default without CAS. Yes, I agree that CAS is wonderful solution, but I’m more worried how many programs will actualy implement CAS. If .NET has full privilege then it is only a simple case of breaking .NET server security, while running .NET server without privileges makes one big step to better security (even server isn’t allowed to do some things, no matter if CAS was implemented or not, server just isn’t privileged enough).
To be fair, this conclusion is my own biased and paranoid opinion (same opinion about java).
1. .NET consumes to much memory and resources to be runned on server. One solution would be simple load balancing like daily cron (kill mono, respawn services) and this is one of the reasons why .NET does not belong on server. Server should run for months or years not for days without restarting
2. I doubt that all software will use CAS, coders are lazy and often look for the quickest way to result, and not the best. Having one engine as powerful as .NET or java is quite a little paradise you can set up for potential hacker (if only he accesses your .NET server VM with admin privileges).
But, don’t get me wrong, I like (and I use) C# and .NET just as long as it is limited to client software.
.NET already runs on (and is included with) Windows Server 2003. ASP.NET requires it. Memory consumption is largely app specific as with any other runtime. If you have an app that creates a lot of objects and never destroys them, they will eat memory. If you create a bunch of long lived objects, they will eat memory because they survive multiple generations of garbage collection.
If you compare small .NET app w/ little functionality to small C++ app w/ little functionality, the C++ app will definitely use less resources because of the extra initial overhead of the .NET GC, JIT, security and other services. In a realistic comparison w/ many apps or a few large apps, the difference decreases because the initial overhead cost is only paid once, the rest of the .NET apps can share some of the same resources (unlike Java). Actual memory usage for a .NET app may also be overstated in some cases because the CLR may take more memory than is necessary for it and its apps to run. This isn’t permanent, and is freed if other apps need to use it.
There are several aspects to CAS. It is in part enforced automatically, especially depending on the scenario for app deployment. It can be strengthened beyond the defaults either by the app developer specifically denying capabilities he wouldn’t need but would otherwise have access to, and it can be strengthened by the system administrator through system/network policy. If he chooses, the administrator could (for example) decide that only whitelisted applications and/or those signed with his/the IT department’s signature can run on any machine in the organization.
Beyond the ability to strengthen defaults, I mentioned the defaults automatically applying. By default, only verifyable code (i.e., all managed such as C# with no unsafe code blocks or external unmanaged dlls) can be run from external sources such as the internet. This applies no matter if the developer specifically added extra CAS attributes or not. In .NET 2.0, ClickOnce uses the default CAS policy to allow deployment of applications from a URL. Since the code is verifyable, it is known to only used allowed functionality for the CAS context in which it runs. If it didn’t meet this policy, it would not execute. Applications can be made to run with a minimum set of features allowed under that context, and then only expose other features requiring elevated CAS, not user token, privileges if the user chooses to allow this.
I’m not 100% sure on the specifics on the execution context of the CLR, so take this w/ a grain of salt/check MSDN for more details, but in general, CLR execution context depends on how it is invoked. Application code that runs on the CLR is controlled by the app domain in which it runs, so you can launch one app that requires no special user privileges as a normal user, then an “admin-app” can be launched using runas to run it as an Administrator and the application privileges are seperated by the app domains. The user app isn’t elevated to admin privilege just because an admin app is running simultaneously. It also depends on whether the CLR is hosted inside an application. For instance, the CLR hosted in IE would run under the context in which IE was launched, thus would run in the context of a normal user if launched as such. For instance, ASP.NET provides a host for the CLR and runs in the context of a limited user. Thus, at best, assuming CAS could be circumvented, an attacker could only execute their code in the context of that limited ASP.NET account.