GSoC 2017 progress on JyNI

Work on linking/error LNK2019: unresolved external symbol The last two weeks I spent on fixing unresolved external symbols. While it was straight forward with GCC and clang to ignore unresolved symbols (i.e. implicit definitions in GCC or by passing "-undefined dynamic_lookup" to clang) at compile time, there seems to be no such option with MSVC. Anyway, it's not a bad idea to fix these symbols as they can become runtime errors at some point, so tried to get this done. Here is an excerpt from the list of failing symbols: dl_nt.obj : error LNK2019: unresolved external symbol __imp_LoadStringA referenced in function DllMain unicodeobject.obj : error LNK2019: unresolved external symbol __imp_CharPrevA referenced in function is_dbcs_lead_byte stringobject.obj : error LNK2019: unresolved external symbol stringlib_partition referenced in function string_partition stringobject.obj : error LNK2019: unresolved external symbol stringlib_rpartition referenced in function stri...

During the last two weeks I almost completed the C99 to C89 conversion process . This was a lot of work, but mostly routine. The only mentionable issue was to use PyAPI_FUNC correctly . Especially it wasn't obvious to me that building CPython on Windows requires the Py_BUILD_CORE preprocessor definition . This stuff is usually automated by configure script or setup.py. For JyNI I prefer to have a transparent toolchain configuration, at least at this stage. As of this writing, the only pieces not yet ported are dynload_shlib and JyNI-loader . Both involve switching to dll loading mechanism and thus more thought. I.e. bridging POSIX and Windows dynamic loading machanisms in suitable crossplatform manner. Getting this right and doing the linking phase is the next step on the agenda.