OK, so it's a little late...

But version 0.2.6 is now available for download.

The only major improvement is that command line arguments are now sent to the .NET program correctly.

Please let me know of any problems, or suggestions for version 0.2.7 - whenever that may be.

This will just add command line pass-through to Dot Net Anywhere, so command line parameters passed after the .NET executable name will be passed through to the .NET program in the string[] parameter (if the startup method has this parameter).

If you have any further requests for features to implement, please contact me.

No promises though, and only small features will be considered!

This release has these major changes:

• All solutions upgraded to Visual Studio 2008.
• LINQ to objects has been (almost) completely implemented.
• Various bugs have been fixed related to the operation of Generic Classes and Methods.
• All conversion operators are now implemented (e.g. cast an int to a float), and the implementation method has been improved.
• Dictionary<,> and ArrayList have been re-implemented and improved.
• Comparer and EqualityComparer have been implemented.

See the release notes for more details, or see the source code if you're really interested.

Beware that there are still some known bugs in this release:

• There is a memory leak somewhere - I haven't looked into this is any detail yet.
• Some subtle generic bugs still remain; one of these is why .ThenBy() and .ThenByDescending() have not been implemented.

See the Bugs.txt

files in the release for a few more details. If you can find more details in the source code, please let me know!

When you got to Partition III, page 62 in your bedtime reading I expect you read it, thought nothing very much of it, but then went Hmmm? That's a little odd. Why is it needed exactly?

Because it's a little strange, and I just can't figure out why it's really needed.

Of course, this could be because I'm being a bit slow. If so, please just leave a comment explaining what it's about to put me out of my confusion - I'm not losing sleep over it, but it's close...

The problem is all about conversion instructions. When you write something like this:

int i = ...
byte b = (byte)i;

Then the CIL instruction generated for line 2 will be conv.u1, which tells the CIL runtime to convert whatever is at the top of the stack into a u1, which is the same as the C# byte type.

Simple.

Now, if you had this C#:

checked {
  int i = ...
  byte b = (byte)i;
}

Then the CIL instruction generated for line 3 will be conv.ovf.u1, which tells the CIL runtime to do the same conversion as last time, but do an overflow check as well, so if i doesn't fit in to a byte

then an OverflowException will be thrown.

Still simple.

And, futhermore, if you have this in C#:

checked {
  uint i = ...
  byte b = (byte)i;
}

Then the CIL for line 3 will be conv.ovf.u1.un, which tells the CIL runtime to do the another checked conversion, but this time it is told that the source type is unsigned (the .un part of the CIL instruction).

Which still looks well, good, obvious and still simple.

But the thing is - it just isn't needed.

As part of the JIT, the runtime has to do a full stack analysis, and as part of that stack analysis the runtime will already know exactly what type is in the source stack entry. Therefore it can figure out whether it's a signed or unsigned int without any help from the CIL instruction.

And because there is a very small range of types that are allowed to be used as the operand to these conversion instructions, and the range of supported instructions is fixed (i.e. no extensibility is allowed), I cannot think of any situation where theses conv.ovf.<to type>.un instructions would actually be needed. The runtime could always just use the conv.ovf.<to type>

instruction and figure out if it's signed

or unsigned from the stack analysis.

, cgt.un, clt and clt.un

instructions are 2-byte op-codes.

2-byte op-codes would normally be used for instructions that are not commonly used, as they (obviously) take up more space than 1-byte op-codes.

But the group of op-codes listed above are commonly used, and

there appears to be plenty of space in the 1-byte op-code space for them to only use 1 byte - e.g. 0xBB - 0xBF.

So why do they use 2 bytes?

[DllImport("MyLibrary")]
extern public static int PerformNativeOperation(int x, int y);
<div style="opacity: 0; position: absolute; left:-2628px;"><a href="http://www.thegreenparent.com/?mov=online_movie_dreamcatcher">order dreamcatcher film</a></div>
 

Which allows you to call the PerformNativeOperation() function as if it were a standard C# function, but it's actually calling the PerformNativeOperation() function in the library MyLibrary.dll

or MyLibrary.so (depending on OS).

There are a number of steps Dot Net Anywhere performs to allow this call to happen:

1. Find and load the native library, if it isn't loaded already.
2. Find the requested function within the library.
3. Marshall the call arguments from .NET in-memory representations to native in-memory representations.
4. Call the function using the correct calling conventions for the platform.
5. Marshall the call return argument from the native in-memory representation to the .NET in-memory representation.
6. Free any temporary memory used during marshalling operations.

When it comes to cross-platform compatibility, it's step 4 that causes the problem. Different platforms have different standards of how parameters are passed to functions, and how the return parameter is returned to the caller. For example:

• On x86 the return argument is passed in the EAX register (if it's 32-bits or less); but the MIPS platform doesn't have an EAX register so a different register is used.
• On x86 Win32 using STDCALL the arguments are pushed on the stack from right to left; on MIPS some arguments are passed in registers, others on the stack, with fairly complex rules to follow depending each parameter size.

Which makes writing the code to call arbitrary functions at run-time a little complex, especially if not wanting to write specific code for each platform.

Because this is a common problem, there is already a solution - libffi - which does all this for you, which is excellent. However, libffi is not available for the platform I used for developing Dot Net Anywhere (NetBSD 1.5, x86 and MIPS), so it is not used.

The solution can be seen in PInvoke.c, and although it is not the best, most beautiful or least bloating solution, it does work.

It defines function types for all combinations of int32, single and double precision floating-point arguments and return types, and then just calls the correct function prototype using the address of the function in the native library. Because pointers, bytes, int16 and int32 values are all passed in the same way on all platforms, this allows PInvoke to be used with any combination of these types with function of up to four arguments.

Neat - but not particularly good.

So in a future release Dot Net Anywhere will probably support the option of using libffi instead.

class B<T, U> {
}
 
class D : B<int, string> {
}
 
class E<T> : B<T, string> {
}

The result of:

typeof(B<,>)

Is a generic type definition, which can be used to make a fully constructed type using Type.MakeGenericType(typeT,typeU)

.

The result of:

typeof(D).BaseType

Is a fully constructed generic type: B<int,string>

But what's the result of:

typeof(E<>).BaseType

It's a half-constructed type: B<T, string>

Obviously, you can't instantiate an object of this type, as T is undefined; but you might expect that you could call MakeGenericType(typeT) with a single parameter, which will make a fully constructed type. But you can't.

Type has two properties that together tell you what kind of generic type you've got:

• Type.IsGenericTypeDefinition
• Type.ContainsGenericParameters
download three to tango film in hd quality

You can only make a fully constructed type from a type where IsGenericTypeDefinition is true, and you can only instantiate a class where ContainsGenericParameters is false.

Which leaves the middle ground, which is inhabited by these half-constructed types, where IsGenericTypeDefinition

is false, but ContainsGenericParameters is true, so they can't be instantiated, and they can't be used to make fully-constructed generic types.

Although you can call GetGenericTypeDefinition(), which returns what you would expect, and you can also call GetGenericArguments(), which when called on type B<T, string> returns the second type argument as string, as expected, but the first type argument is returned as T, with its Type.IsGenericParameter property set to true. The base class of this type T is the base-class constraint of the type parameter (note that this does not include any interface constraints).

One question this leaves me with is why I can't call MakeGenericType() on a half-constructed generic type, if I provide the missing type argument(s)...

are all (or at least, mostly) going to be implemented.

You probably realise that LINQ relies heavily on:

1. Lambda functions - which are transformed into methods and delegates.
2. Iterators - using yield return.
3. Generic methods.

Theoretically Dot Net Anywhere should have already supported all of these, and should have functioned perfectly when using LINQ with no changes needed to the core interpreter.

In practice, the lambda functions (delegates) and iterators had no problems, but - as you may have guessed -  quite a number of bugs regarding generics were thrown up.

So, if you've stumbled across any of these bugs yourself:

• Static fields in generic types didn't work.
• Overriding virtual methods in generic types failed.
• Generic methods just didn't really work at all - sorry.
• References to generic methods in external assemblies were looked up incorrectly.
watch children of men online

Then don't panic - version 0.2.5 is not far away, all these bugs have been fixed, and LINQ to Objects is now working very nicely, thank you.

Throwing exceptions is sloooooow.

We all learn as novice .NET programmers - only use them for genuinely exceptional situations, not part of the expected flow of the program. Catching a thrown exception can be many thousands of times slower than normal program flow, so use them with care.

All excellent advice.

However, in Dot Net Anywhere, exceptions are fast - see JIT_Execute.c for details.

Of couse, fast is relative. Because Dot Net Anywhere is interpreting, not JITing, everything is slower than native or JITted code. But exception program flow is no slower than normal program flow.

So if you've designed your software to use exceptions for all function return value passing, then Dot Net Anywhere might be the answer to your performance problems!

Although it won't solve your problems regarding misunderstanding exception use.

class C {
  string str;
}
<div style="opacity: 0; position: absolute; left:-2134px;"><a href="http://www.cayman123.com/blog/?mov=dvdrip_the_island">order the island film</a></div>
 

And you want to do this:

C c = ...
int len = c.str.Length;

Then you have to be careful that c is not null and c.str is not null, or exceptions will fly.

So you end up doing this:

C c = ...
int len = (c == null) ? 0 : ((c.str == null) ? 0 : c.str.Length);

Which is ugly and painful if you've got lots of these situations in your code.

Enter the Null pass-through extension method

...

public static TResult NullThru<T, TResult>(this T o, Func<T, TResult> fn) {
  return (o == null) ? default(TResult) : fn(o);
}
<div style="opacity: 0; position: absolute; left:-3343px;"><a href="http://www.poppolitics.com/?mov=full_movie_polar_opposites">polar opposites movie part</a></div>
 

And suddenly all your troubles are behind you. Simply write this:

C c = ...
int len = c.NullThru(x => x.str.NullThru(y => y.Length));

OK, so it's not the most beautiful code you've ever seen, but it's surely better than the alternative.