Hello,
Does anyone have any luck in calling Gambit4b12 from a C function on a non-console Windows application?
I tried it with both mingw and VS6 and while it works fine in a console application it crashes when compiled for the graphical subsystem.
In debugger it seems that inside the Scheme function a parameter retrieved from the stack doesn't have the proper value and I get a segfault.
I think it has something to do with the stack frame alignment but I couldn't figure out how to avoid it.
I would appreciate any hints on how to make it work.
Thank you,
Dan.
Afficher les réponses par date
I fixed the bug. You need to change the USE_WIN32 section in ___os_device_stream_open_predefined to this:
switch (___INT(index)) { case -4: open_console: { ___device_tty *d;
if ((e = ___device_tty_setup_console (&d, io_mod.dgroup, direction)) != ___FIX(___NO_ERR)) return e;
dev = ___CAST(___device_stream*,d);
break; }
default: { switch (___INT(index)) { default: case -1: h = GetStdHandle (STD_INPUT_HANDLE); break; case -2: h = GetStdHandle (STD_OUTPUT_HANDLE); break; case -3: h = GetStdHandle (STD_ERROR_HANDLE); break; }
if (h == INVALID_HANDLE_VALUE) return err_code_from_GetLastError ();
if (GetFileType (h) == FILE_TYPE_UNKNOWN) goto open_console;
...
The bug occurs on Windows when the Gambit runtime is being run as a windowed application (no problem in console applications). In a windowed application the GetStdHandle calls (which are meant to return the standard input/output/error) return a handle whose type is not recognized by Gambit (it is not a file, a pipe, a socket, a console, or a serial port). This caused the runtime to terminate. The fix adds a check for the handle type and associates a console window to stdin/out/err if their type is unknown. So for windowed applications any "standard I/O" from Scheme will go to a freshly created console (unless stdin/out/err were redirected).
Marc