On Sun, Jun 19, 2011 at 11:03 PM, Juan Jose Garcia-Ripoll <span dir="ltr"><<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div class="im">On Sat, Jun 18, 2011 at 6:06 PM, Bill Robinson <span dir="ltr"><<a href="mailto:airbaggins@gmail.com" target="_blank">airbaggins@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Just wanted to bump that I've run into this as well and would appreciate a fix if anyone out there has one.</blockquote><div><br></div></div><div>I am working on that. Unfortunately it requires changes in ECL to cope with this limitation in Microsoft's compiler.</div>

</div></blockquote></div><br>Ok, I more or less have finished something that works around this problem. The idea is that compiled data is no longer stored as a C string, but rather appended to compiled files and loaded using mmap() or open()/read() by ECL itself.<br>

<br>The only problem so far is standalone programs. Unlike in FASL files, in this case it is _very_ hard to find out the place where compiled data resides (the executable file), because there is no portable way to do that:<br>

<br>- argv[0] is not guaranteed to keep the name of the executable<br>- the file itself may be renamed or moved<br>- in some systems (embedded systems, phones, etc) there might not be any notion of file system at all.<br>

..<br><br>Help would be very welcome in solving this problem.<br><br>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>