[Mono-dev] OT: update...

BGB cr88192 at hotmail.com
Sat Oct 24 18:34:37 EDT 2009


granted, all this is OT, so if anyone wants to reply, and if this reply is 
not  necessarily relevant to the list, please consider responding privately 
(my intent here is not to troll or spam, sorry in advance if it may seem 
this way).


if anyone cares or remembers, it may be noted that some time ago, I had 
posted here, and at the time had a few disagreements with some aspects of 
the project and had partly intended to do my own (hopefully cooperative) 
implementation of .NET...

well, ok, this part didn't go anywhere... (so, no more direct competition I 
guess).


instead, I eventually settled on a different technology: virtualized 32-bit 
x86...

granted, currently I am using an interpreter, and it is terribly slow, and 
is still missing a few things (and is not well tested), ...
but, alas, it seems that x86 machine code is about the only thing which 
really seemed to meet my requirements (I may eventually use a 
trace-translator / JIT for this, but not as of yet).


granted, I looked at QEMU, but I guess had a few doubts here as well...
(didn't like the code, couldn't get to build/work in x64+MSVC, ...).

my goal is not to "own" the implementation, so others can hopefully also use 
QEMU and/or maybe even Wine as a base (assuming Wine can be made 
"acceptable" from a security POV...).


similarly, I ended up settling on PE/COFF as the cannonical binary format, 
but am still deciding between using MinGW or MSVC for the 
statically-compiled portions of the VM-based libs (testing thus far has used 
MinGW), ...

the native portion is generally being built on 64-bit Windows (as a 64-bit 
app) via MSVC (but I am trying to keep everything 'generic', and "every so 
often" go and make things work on Linux, but don't use Linux enough to 
consistently keep everything complete or up-to-date).

so, as noted, the host and client run in disjoint address spaces.


so, the basic idea is to try to make 32-bit code with is binary compatible 
with these targets:
Windows x86 and x64;
Linux x86 and x86-64;
possibly beyond (PPC?... other OS's?...).

as well as trying to be "secure" (current aim is to handle this primarily 
via sandboxing);
the goal would then be to establish a "standard" set of DLL's and API's by 
which to partly address this issue.

note: standardized on the DLL names and API's, hopefully avoiding demanding 
any particular implementation thereof. I am currently leaning against using 
OS-specific API's for this, so the goal is not to be a Windows emulator or 
anything of the sort.

probably core API's will be based on fairly standard API's (ANSI C, POSIX, 
OpenGL, ...), and currently I am leaning towards public domain for any 
components in a/the reference implementation (although, BSD or LGPL may also 
be ok, as of yet this is undecided).

beyond this, 3rd party code could be ported to this (hopefully without too 
much work), but would not likely be considered as part of the "core" (since 
doing so would burden any alternative implementations with providing the 
same libraries).

some "design" work is needed (mostly it would be for addressing less 
standardized facilities, such as OO and GUI support, ...), as well as more 
open-ended issues (specific library names / naming conventions and issues, 
...).


note that this will be in the context of a VM, and not necessarily for 
traditional applications (code may be assumed to be running within the 
context of a host-app, in much the same way as traditional apps run within 
the context of an OS).


if anyone wants to express ideas or opinions, feel free to email.




More information about the Mono-devel-list mailing list