Release v0.0.11

After a considerable amount of hacking, I’ve released v0.0.11 of Campy. This version fixes a number of problems with reading PE files. Again, most of the problems I have been encountering go back to the old DotNetAnywhere code and its lack of support for anything that has happened in .NET over the last 10+ years, e.g., additional metadata type tables, 64-bit code targets, type and assembly resolution, low-level metadata access, etc. Some changes are for undocumented Net Core hacks, such as a PE machine version 0xFD1D. A search in all of Github.com indicates that this occurs for native libraries, such as System.Collections.dll on Ubuntu 16.04. However, even though it is x64 native code, and you may think the assembly useless, it seems to contain metadata type information that is crucial in the analysis for type/assembly resolution, which you can verify using DotPeek. Incidentally, assembly resolution–the steps used by Net to figure out where and what assembly to load for a program–is somewhat fixed in Campy with the addition of lots of probing of the standard locations for assemblies, and checking “public key” for the correct version. Generics and String finally work again with changes to rewrite the stack types during compilation of a method. I fear, however, that it may be inadequate, for generics are quite complicated. There was a problem with Swigged.CUDA on Ubuntu, but that is now fixed.

So, slowly, Campy is coming up to speed with respect to being platform independent and able to work with a lot of C# (value types, reference types, generics). But, it still has a way to go: boxing, virtual methods, IOS, Mono assemblies, etc. And, it still has a number of bugs with C# generics, which can make it unstable, if not impossible, to use.

Note: While I appreciate why Steve Sanderson et al. switched from DotNetAnywhere to Mono with Blazor in late 2017, I am glad I chose DNA for Campy. Trading DNA for Mono is just trading one set of problems for another. If you’ve been in the business as long as I have (30+ years), you realize that you may think you and your code hot stuff, but someone can always improve on it–or rewrite it completely. That old programmer who wrote that original crapy code that you improved may come back and bite your ass off. That’s the nature of software.

Leave a Reply

Your email address will not be published. Required fields are marked *

This blog is kept spam free by WP-SpamFree.