Calling from C on Windows
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
participants (2)
-
Dan Hristodorescu -
Marc Feeley