MOSA Project

Fixed Conv*

Fixed Cgt

Fixed And, Call and Ceq

Converted Testcases from Gallio/mbUnit to NUni 2.5

Could be that I'll join a few minutes later. That depends...if my train is on time I'll be on time too. Any word from grover so far?

Here's the tentative agenda for tomorrow's meeting (in a bit less than 11 hours): 1. Sprint Development Updates - 0.1 has been released - 0.2 progress updates from Rootnode & Grover - 0.3 completed (before 0.2!) - 0.4 still in planning stage 2. ... [More] New Contributors - theanticol - Submitted patches to Pictor for TrueType font support - 54616E6E6572 - Added PE32/PE32+ support to mosacl 3. Development Tools - Move to NUnit? Gallio is not available on Linux. - Use Nant? - Bochs 4. New Web Site Update - Retrospectiva? - Move to "real" SVN repository 5. MOSA Operating System 6. Open Discussion [Less]

If mosacl can't find an mscorlib in the current folder, it checks a number of paths including the current Framework folder which is the Framework64 folder when mosacl is running in x64 mode. mosacl compiles code incorrectly when using Framework64 ... [More] mscorlib for reference purposes - and it is arguable both that we shouldn't be using PE32+ assemblies for 32-bit targetted compiles, and that we shouldn't be using the .NET mscorlib for reference anyway.The assembly loader's search paths need to be thought out a bit more and changed. [Less]

I discovered this in Mosa.Runtime.Loader.AssemblyLoader while running the test cases on x64 Win7 with VS2008 and Icarus GUI Test Runner - all attempts at mosacl usage fail because the assembly-resolving code in mosacl can't find mscorlib. ... [More] Specifically, the only one it finds is the one in %windows%\Microsoft.NET\Framework64 , which is a 64-bit PE and the Mosa PE-loading code cannot handle the format.Any single one of the following workarounds should work (I've tried a couple):* Have a 32bit PE of mscorlib in the working directory while you are running the MOSA compiler* Compile mosacl with x86 build configuration instead of AnyCpu to force MOSA compiler to run under 32bit* Use 'corflags' MS.NET utility to manually mark mosacl to require 32bit mode* Compile test-case assembly with x86 build configuration instead of AnyCpu to force MOSA compiler to run under 32bit* Use 'corflags' MS.NET utility to manually mark test-case assembly to require 32bit modeLong-term issues:* We need to implement PE32+* We need to make the assembly resolving code more intelligent about how it looks for an assembly to resolve a referenceIts important to keep in mind that while related, this has nothing to do with mosacl cross-compiling for x64 - and more of making sure that the compiler runs on .NET supported platforms.Comments: I'm closing this issue in lieu of a more concise one worded to drive this home. [Less]

I discovered this in Mosa.Runtime.Loader.AssemblyLoader while running the test cases on x64 Win7 with VS2008 and Icarus GUI Test Runner - all attempts at mosacl usage fail because the assembly-resolving code in mosacl can't find mscorlib. ... [More] Specifically, the only one it finds is the one in %windows%\Microsoft.NET\Framework64 , which is a 64-bit PE and the Mosa PE-loading code cannot handle the format.Any single one of the following workarounds should work (I've tried a couple):* Have a 32bit PE of mscorlib in the working directory while you are running the MOSA compiler* Compile mosacl with x86 build configuration instead of AnyCpu to force MOSA compiler to run under 32bit* Use 'corflags' MS.NET utility to manually mark mosacl to require 32bit mode* Compile test-case assembly with x86 build configuration instead of AnyCpu to force MOSA compiler to run under 32bit* Use 'corflags' MS.NET utility to manually mark test-case assembly to require 32bit modeLong-term issues:* We need to implement PE32+* We need to make the assembly resolving code more intelligent about how it looks for an assembly to resolve a referenceIts important to keep in mind that while related, this has nothing to do with mosacl cross-compiling for x64 - and more of making sure that the compiler runs on .NET supported platforms.Comments: ** Comment from web user: illuminus86 ** Patch submitted by tanner has been applied, and I made some additions that were needed for PE32+ support to actually work.However, PE32+ support does not seem to be enough to get the compiler to compile the assembly correctly, and every single testcase fails (though the Framework64 version of corlib appears to be successfully loading). The core of this issue is left unresolved - the assembly loader needs to reject the Framework64 folder as a candidate for assembly resolution. [Less]

Small patch from tanner that adds support for PE32+