[Ecls-list] ffi broken in windows

[Dustin Long]

Juan Jose Garcia-Ripoll wrote:
> On Dec 26, 2007 11:45 PM, Dustin Long <dlong at stevens.edu> wrote:
>   
>> Looking back on it, I'm not sure if your comments on my last patch were
>> correct. My patch only changed whether or not the immediate API call was
>> used to reload the .fasl file (in ecl_library_open), it would still
>> rerun initialization code (si_load_binary),
>>     
>
> It has taken me some time to remember all the issues with the windows
> port. Another reason why we copied the FASL files is that, once
> loaded, they cannot be rewritten. Say for instance you edit file
> foo.lsp, compile it and load it. If the file defines functions it does
> not get unloaded during garbage collection. Now you edit foo.lsp and
> try to compile it again. Windows will not allow you to overwrite the
> file foo.fasl. This is the reason why the loading process in windows
> goes as follows
>
> * We want to load foo.fasl
> * We copy foo.fasl to a brand new temporary file (say xxx2312.fasl)
> * The temporary file is marked as self-destructing
> * Things go on
> * Eventually, either ECL exits or all references to the functions in
> foo.fasl are deleted and the temporary file xxx2313.fasl gets unloaded
> and deleted.
>   
I wrote a lot of the code for that behavior, so I kept that procedure in 
mind when making this patch. But regardless, either of those two patches 
should work to fix the ffi problem, and I admit that the later one is 
somewhat cleaner in how it works, and uses less win32 calls. Just use 
which ever you prefer.

Dustin