This project is read-only.

Welcome to CrossNet's forum!

Oct 1, 2007 at 4:15 AM
You can ask any question here, give some comments, share your criticisms / concerns.
Any feedback is good! Please don't hesitate!

If you have some issues, don't hesitate to use the issue tracker!

Dec 31, 2007 at 3:26 PM
I don't mean to sound stupid, can someone not just use 'ngen' to create a native image of the assembly in question?

Perhaps I'm missing something.

Additionally, wouldn't it be more appropriate (considering legalities behind reverse engineering code, since not everyone will use it on their assemblies only), to use a language file parser that understands the intent of the code and translate it into C++?

Almost sounds like this project could use 'O.I.L.' later on when both projects are further. While O.I.L. is aimed for languages built strictly on the .NET framework, a bit of fancy footwork could make it deviate from this specific goal.

I like some of the concept behind this, however. It'd be interesting, if taken far enough, to see what platforms .NET languages could fully deploy to.
Jan 5, 2008 at 6:29 AM
Thanks for the information!

Actually the goal of CrossNet is to be used where .NET platform doesn't exist and needs to be emulated.
In that regard, Ngen would not work, AFAIK it only works on a .NET platform. It pretty much pre-JIT the byte code with some fancy features / optimizations, but at the end of the day it still uses the .NET infrastructure.
The goal of CrossNet is to be used on platform where .NET is not supported by Microsoft (like PS3, Wii, or any other non-Windows platform and even X360 in some extent).
Mono and Portable.NET are more related but because they are JIT based, they are usually need Supervisor access which on some platform is impractical. Note that Mint (Mono interpeter) doesn't seem to be supported anymore and would be much slower.
Additionally generating C++ code improves the performance versus .NET due to better optimizers (you can look at the benchmarks - although it seems CodePlex doesn't display gif anymore :( ).
Finally a key idea of CrossNet is the notion of user's policy where you can tweak the language in order to change the official behavior. You could do this either at parsing time or directly with the C++ pre-processor. User's policy can be things like specific memory tracking (for platform with limited memory), improving efficiency, etc... Plain vanilla .NET would not give you as much control (in the same vein, changing Mono or Portable.NET to extend the behavior is not an obvious task).

About parsing the original language or reverse-engineer, I thought about that in the past couple of years and I found the reverse engeneering to have more advantages.
First it's language agnostic, so C#, VB.NET can be used as well as any other .NET language (think of all the .NET variant of Python, Ruby, Java, Perl etc...).
It's nice to not have to spend time on each language.
The second thing is that even if C# is much easier to parse than C++ (which I did in the past), with all the new revisions of .NET and corresponding improvements in C#, it's hard to keep up. But since .NET 2.0, the byte-code did not change, all the new features are syntactic sugar (and nice sugar indeed).
So reverse-engineering the byte-codes allow any syntactic sugar change in any .NET language for free. Priceless.

About the legal issues of reverse engineering, this is a bit outside the scope of CrossNet. There are already many ways to reverse-engineer byte-code already (with ILDasm, Lutz Roeder's Reflector - a Microsoft employee, or a bunch of free / expensive reverse-engineering tools). At the end, the real question is more "Do you have the right to reverse-engineer that assembly?". There is nothing wrong with reverse-engineering as long as the user understands that he must be careful with the license associated with the assembly. Note that this issue can be exactly the same with source code as well, it's not because you have source code that you are safe (like GPL). Everything depends of the license.

BTW CrossNet is a Reflector add-ins, Reflector creates a high-level statement / expression tree from a .NET assembly.
You might want to have a look as it might intersect with what you are doing on OIL. Also Microsoft has a tool to create domain specific languages (DSL), I may be wrong but I remember that it is able to produce .NET assembly directly. This associated with Reflector might overlap in some extent with OIL.

I hope that what I said makes sense :)