Think of it as XS for .NET--while you can do anything you want and interface to some external library or other, there's nothing to stop the code from stomping on the world. It also means you'll need the perl component on any machine executing your perl code in the .NET environment, though I think .NET's packaging scheme takes care of fetching that as need be. (I'm not 100% sure of that, thoug)

My understanding (based on the little technical info provided during the .NET Launch party in Las Vegas last month) is that unmanaged code allows you direct contact with the hardware as opposed to the CLR handling that low level happiness. The implication being that you are responsible for your own memory mangagment, garbage collection, etc. (primarily an issue for C and C++ folks!)

Does this sound like it lines up with your understanding, or am I totally off-base ;).

-Brett

Yup, that's it. Use a single piece of unmanaged code and all security and stability guarantees are shot to hell. OTOH, it lets you do things that .NET either can't, or can't do efficiently.