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. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list