[Mono-dev] OT: update...
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
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
instead, I eventually settled on a different technology: virtualized 32-bit
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
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
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
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