D vs VM-based platforms

[Walter Bright]

Benji Smith wrote:
> Walter Bright wrote:
>> Benji Smith wrote:
>> If you designed a language around COM, you'd get all that stuff for 
>> free, too. I agree that using COM in C++ is a bit clunky, but after 
>> all, C++ was designed before there was COM.
> 
> Aha. Very interesting point. I hadn't thought of that.
> 
> Is there such a language? Or is this just hypothetical?

It turns out that Java and C# both can map directly onto COM, so if one 
were to build a native compiler for them, that can be done.

I didn't design D to map directly onto COM because COM is a dying 
technology.

>> The x86 processors have 4 rings of hardware protection built in. The 
>> idea is to do the isolation in hardware, not software, and it does 
>> work (one process crashing can't bring down another process). Where it 
>> fails is where Windows runs all processes at ring 0. This is a 
>> terrible design mistake. The CPU *is* designed to provide the 
>> sandboxing that a VM can provide. Also, as VMware has demonstrated, 
>> the virtualization of hardware can provide complete sandbox capability.
> 
> Lots of great info. Thanks. I didn't know that the x86 had support for 
> profiling, debugging, sandboxing, etc.

The problem is it's simply easier to just write a VM. But when you've 
got a billion dollars to spend, there's no need to take the easy route.

> I'd actually argue, though, that these kinds of features are actually VM 
> features, even if they have actually been implemented on silicon. Since 
> these kinds of functions provide an outside observer with a view into 
> the machine's internals, I think they're more naturally implemented in a 
> virtual machine (and VMs will, no doubt, be the environments where the 
> most interesting research is conducted into new techniques for 
> profiling, debugging, instrumentation, etc).

These features existed in the x86 since the mid 1980's, a decade before 
the Java VM and 15 years before the CLR. Mainframe hardware 
virtualization has existed for much longer.

> If you want these kinds of meta-platform features baked into silicon, or 
> solidified in your platform, you either need to wait twenty years for 
> the market to prove their viability, or you can get them in next year's 
> VM technologies.

Hardware sandboxing on the x86 has been around at least since the 
infamous 286 "penalty box". The 286 was Intel's first try at hardware 
virtualization, and a lot of mistakes were made. The 386 got it right, 
and the first fruits of that came in Windows-386, which provided 
multiple virtual DOS sessions.

The original 8086 had no virtualization capability, and as a result, it 
was a *terrible* platform for software development. Any errant program 
could pull down the whole system. With the 286 came 'protected mode', 
where errant pointers were trapped by the hardware. It was the first 
sandboxing for x86.

> PS: Keep in mind, I'm playing devil's advocate here, not because I have 
> anything against compilation for a native platform, but because I think 
> there are lots of interesting innovation in the VM universe that could 
> be useful to D.

Software VM features can certainly drive forward adoption of hardware 
features. They always have <g>.