"scheme_setjmp" under Windows DLL?

[Scorzelli Giorgio <scr.giorgio@cogesic.it>]

Hi,

I'm trying to isolate the MzScheme problem about "scheme_setjmp" 
instruction which seems not to save correctly the return address if it is 
invoked in a windows DLL.

I created a simple DLL library with the following two files (VisualC 
6.0/New/DLL/Empty Dll):

*** DLL.h ***
--------------------------------------------
         #ifndef _DLL_H__
         #define _DLL_H__

         #ifdef DLL_EXPORTS
         #define MYEXPORT __declspec(dllexport)
         #else
         #define MYEXPORT __declspec(dllimport)
         #endif

         MYEXPORT void init();
         MYEXPORT void eval ();

         #endif //_DLL_H__
--------------------------------------------



*** DLL.cpp ***
--------------------------------------------

         #include <scheme.h>

         #define DLL_EXPORTS
         #include "dll.h"

         static Scheme_Env* mySchemeEnv;


         MYEXPORT void init(){
                 mySchemeEnv=scheme_basic_env();
         }

         MYEXPORT void eval (){
                 if (scheme_setjmp(scheme_error_buf)){
                         return;//ERROR!!! HERE IS THE PROBLEM
                 }else {
                         Scheme_Object 
*v=scheme_eval_string("(i-want-error)", mySchemeEnv);
                 }
         }
--------------------------------------------


and a simple application (Visual C6.0/New/Console application - Make it 
dependant on the previous DLL):

*** MAIN.CPP ***
--------------------------------------------
         #include "dll.h"

         int main()
         {
                 init();
                 eval();
                 return 0;
         }
--------------------------------------------

When I run it it crashes (on DLL "eval" return instruction).
The debugger warns me about a strange stack condition with the following 
message:

--------------------------------------------
Debug Error!
Program F:\dll\main.exe
Module:
File i386\chkesp.c
Line: 42

The value of ESP was not properly saved across a function call.
This is usually a result of calling a function
declared with one calling convention with a function pointer declared
with a different calling convention
-----------------------------------

Can someone help me?

*************************************
Giorgio Scorzelli
scr.giorgio@cogesic.it
http://dia.uniroma3.it/~scorzell
*************************************