[cap-talk] Selling capabilities programming

[James A. Donald]

James A. Donald wrote:
 > > > > I agree entirely that a language that does not
 > > > > permit code to be written which violates
 > > > > capability constraints should not be written
 > > > > using sparse capabilities.

Jonathan S. Shapiro wrote:
 > > > James: This is equivalent to stating that a
 > > > memory-safe programming language should not use
 > > > sparse capabilities.

James A. Donald:
 > > No it is not.  The most widely used counter example
 > > would be visual basic and its sharp successors.

Jonathan S. Shapiro
 > But VB# is a memory-safe language. A .Net object
 > reference is a capability.

Any VB program can modify most files, and in most cases
can modify boot.ini and config.sys.  Changing VB to
prevent this, would break almost all existing VB code.

Further, VB is a glue system, which can invoke a wide
variety of components written in a wide variety of
languages, including assembly, and use these components,
components even more powerful than VB, in ways that
their writers never intended and never tested for.
Changing VB to prevent this would break all existing
code. VB was intended to be in large part a scripting
language.  To make it truly safe, has to be no longer a
scripting language, no longer VB, making it considerably
less useful.

Further VB can call objects such as the browser through
approved official interfaces, providing or receiving
memory objects that belong to a different heap, with the
result that if the program modifies those objects, we
get heap corruption, which can result in operating
system code or device driver code executing as assembly
language data provided by the VB program. Preventing
this would break large numbers of existing programs.
Multiple heaps have been a continuing problem with VB,
and became a considerably worse problem with VB# - the
purported fixes merely move VB# back to a situation that
is not too much worse than the situation was with VB.