BizHawk

History

zeromus e318718a21 change libco_msvc_win32 to use vs2010, so as to avoid dependency on another (vc8) runtime.		2012-10-16 19:11:02 +00:00
..
Release	change libco_msvc_win32 to use vs2010, so as to avoid dependency on another (vc8) runtime.	2012-10-16 19:11:02 +00:00
libco_msvc_win32.c	change libco to use an msvc-compiled dll so that it doesnt get wrecked whenever the .net GC process suspends a thread in a coroutine. cant figure out how to get that same code working compiled by mingw32.	2012-09-09 19:02:13 +00:00
libco_msvc_win32.sln	change libco_msvc_win32 to use vs2010, so as to avoid dependency on another (vc8) runtime.	2012-10-16 19:11:02 +00:00
libco_msvc_win32.vcxproj	change libco_msvc_win32 to use vs2010, so as to avoid dependency on another (vc8) runtime.	2012-10-16 19:11:02 +00:00
readme.txt	change libco_msvc_win32 to use vs2010, so as to avoid dependency on another (vc8) runtime.	2012-10-16 19:11:02 +00:00
trying-to-port-to-mingw-win32.c	change libco to use an msvc-compiled dll so that it doesnt get wrecked whenever the .net GC process suspends a thread in a coroutine. cant figure out how to get that same code working compiled by mingw32.	2012-09-09 19:02:13 +00:00

readme.txt

* Why does this exist?

Because zeromus can't figure out how to successfully compile this code in mingw32.
My efforts are in trying-to-port-to-mingw-win32.c; I don't know why it isn't working.

* Why do we need this code?

Because libco needs to be a bit more properly win32 in order for it to get used from .net code.
.net throws exceptions in each thread when it needs to suspend them for GC. 
Those exceptions get garbled without more proper win32 stack frame setup, and the process terminates.
Additionally, you wont be able to debug very well from callbacks out of a coroutine into c# without this.
 * Note: you can't debug very well anyway due to mingw code having no debug symbols in the callstack.