[Mono-dev] [SPAM] Re: Tests failures when running on MS.NET

[Andreas Nahr]

> -----Ursprüngliche Nachricht-----
> Von: mono-devel-list-bounces at lists.ximian.com 
> [mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag 
> von Gert Driesen
> Gesendet: Mittwoch, 9. Januar 2008 18:06
> An: Atsushi Eno; Eyal Alaluf
> Cc: mono-devel-list at lists.ximian.com
> Betreff: [SPAM] Re: [Mono-dev] Tests failures when running on MS.NET
> 
> 
> ----- Original Message -----
> From: "Atsushi Eno" <atsushi at ximian.com>
> To: "Eyal Alaluf" <eyala at mainsoft.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Wednesday, January 09, 2008 2:38 PM
> Subject: Re: [Mono-dev] Tests failures when running on MS.NET
> 
> 
> > Hello,
> > 
> > Agreed. If there's no objection I'd welcome such a change 
> (or will do if 
> > no one does but not sure when).
> 
> Having it in managed code (where it's easier to have 
> different "tables" for each profile) is not an option I assume?

Imho the problem is that this option would need a lot of research from
somebody very familiar with the core OS level.
We had that discussion quite a few year back and this were some results (as
far as I can remember):
Embedding will give you:
* Automatic memmapping through the OS without any additional work to do (So
we don't (have to) care about which part of tables to load into memory and
which not) OSs are usually good at doing that.
* No hassle with endianess. The Runtime is Arch dependent anyways, so you
get the correct endianess with embedded tables.
* Source code visibility. You can change/inspect (by hand) individual
values.
* Does not add any additional complexity to the build process.
* Already existing and implemented
Disadvantages are potentially:
* No easy way for different versions.
* You may include things in the runtime which are not needed for a specific
application that would better be included in a specific assembly.
* Bloats the runtime size.
* To add a new/change a table you always have to touch both runtime and
classlibrary.

One of the solutions I found back then that MAY be possible (did not have
the time to completely research it): Embed the data tables into the specific
assembly (Into the manifest) as a binary data blob. This removes the
disadvantages above however will come with a host of new problems:
* The data would have to be binary. Which means you need toolapps to create
it (this is already true for some/most of the tables anyways)
* You would need a way to get a pointer to the data fast without a lot of
overhead (Current overhead is just one internalcall and a single line of C
code)
* Unclear if you still get free memmapping (showstopper if you need to
preload all table data manually)
* The class library (potentially) becomes arch-dependent because the
embedded binary data is arch-dependent (No good way to solve: Either include
both doubling size or live with the fact and ship arch-dependent libraries)
* More complicated build process that needs additional steps to create/embed
the binary data.
* Somebody has to do it

Greetings
Andreas