From: William_J_G Overington (firstname.lastname@example.org)
Date: Thu Mar 26 2009 - 13:02:10 CST
> On Tuesday, 24 March 2009, Mabry, F. DR EECS <Frank.Mabry@usma.edu> wrote:
> Mr. Overington,
> I have very serious concerns for any system that would
> provide support for a portable interpretable object code as
> part of the codepoint content payload of a message or
> document. Many email clients already over interpret
> incoming MIME messages and, thereby, open gaps in the
> security model of a system.
I know very little about MIME messages and most of that is
what I have read in preparing a response to your post.
However, it seems to me that there is in MIME a fundamental
difference from my suggestion, namely that in my suggestion
the portable interpretable object code would be expressed by
using code points entirely different from those used for
text content. The portable interpretable object code code
points would all be in, say, plane 12 of the Unicode code
> In many respects your proposal is somewhat like the concept behind some aspects of the Java implementation, only you have no "sandbox" area!
Well, I thought that I had produced a sandbox by having a
virtual machine and commands that cannot access anything
outside of the programming model of the virtual machine.
I am no expert at this and maybe I have got it wrong, but
the programming model is as follows.
Registers ai, hi, p, q, x, y, j, r, g, b.
Memory array mi[1..1023].
The register q is of type Boolean.
All of the other registers are of type integer.
Each item of the memory array is of type integer.
The only output from the 7001 processor is by using the
code point U+F7F77 where U+F7F77 is defined as follows.
So could you possibly say why you say 'only you have no
"sandbox" area!' please? If I indeed do not
have a sandbox area defined, what would be needed to produce
> The nature of net based computing makes many want to be
> able to make "sharing" of new functions as easy as
> possible. Without an "information model" whose
> design addresses security concerns, you run the risk of very
> serious exploits being perpetrated against users before they can even say NO!
Well, I have no experience of addressing security concerns,
my programming has mostly been scientific programming and
advising learners on getting their programs to work.
My hope is that encoding a portable interpretable object
code into Unicode would be an interesting activity where
lots of people participate to get the best system possible.
It would be most helpful if you could please advise on what
is needed please.
> Perhaps I am misunderstanding your suggestion. Please let
> me know if I am missing the point in your view.
Well, I do not know enough about computing to form a view
as to whether I think that you are or are not missing the
Maybe you are. Then again, maybe you have found serious
problems that need addressing.
The programming model for the 7002 processor adds the
following items to those that are in the programming model
for the 7001 processor.
Memory array mf[1..1023].
The registers af and hf and the memory array are all of
type floating point.
Add the register v.
The register v is of type integer and has a default value
of 7001 at startup.
There is only one instruction involving the v register,
namely v:=ai; that allows a program to signal to a processor
as to which version of processor is needed to obey the
program. If the processor does not have that capability,
then a message saying so can be provided to the end user.
The 7001 processor has 48 code points and the 7002
processor has those same 48 code points and another 25 code
One email correspondent had got the idea that 256 code
points would be needed. The number 256 does not enter into
the design of the portable interpretable object code. A
portable interpretable object code encoded into regular
Unicode can have as many code points as desired. It may be
that less than 256 code points could be used or maybe more
than 256 code points.
From various comments by various people I am thinking that
I have devised a portable interpretable object code concept
that is very different from what people expect.
25 March 2009
This archive was generated by hypermail 2.1.5 : Thu Mar 26 2009 - 13:21:56 CST