Regression, mkisofs fails to link LNK2019,LNK2001 with VS2012, but does build properly with VS2010 and VS2013

I know that master doesn't support that toolchain anymore, but please don't close the issue right away. I think it is a small thing only, that may be totally achievable to get fixed in the older branches. *It is the only remaining build-issue the VS2012 toolchain.* I used a TASK therefore, and not a BUG. Trying to seek help.

It began to be a problem, when mkisofs was introduced on master (roughly in the year 2017).

This thing does affect all release-branches:
0.4.14-release-116-g8754623
0.4.13-release-182-g82134fa
0.4.12-release-210-g1c0d839
0.4.11-release-220-gd070613
0.4.10-release-238-g30eec82
0.4.9-release-250-ga89f4ed
0.4.8-release-258-gb9f03fa
0.4.7-release-291-g474eb3e
but for the sake of simplicity I will only argument for releases/0.4.7 here for the rest of the ticket:

I can properly build 0.4.7-release-291-g474eb3e with VS2010 in dbg cfg x86
I can properly build 0.4.7-release-291-g474eb3e with VS2013 in dbg cfg x86
But building 0.4.7-release-291-g474eb3e with VS2012 in dbg cfg x86 fails when linking mkisofs with:
buildlogVS2012_5.log

FAILED: mkisofs.exe 

cmd.exe /C "cd . && C:\Appz\RosBE2_1_6\Bin\cmake.exe -E vs_link_exe C:\Appz\MICROS~2.0\VC\bin\link.exe /nologo sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\boot.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\eltorito.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\hash.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\inode.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\isonum.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\joliet.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\match.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\mkisofs.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\multi.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\name.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\rock.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\stream.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\tree.c.obj sdk\tools\mkisofs\CMakeFiles\mkisofs.dir\schilytools\mkisofs\write.c.obj  /out:mkisofs.exe /pdb:mkisofs.pdb /version:0.0  /machine:X86 /MANIFEST:NO /debug /subsystem:console  sdk\tools\mkisofs\libmdigest.lib sdk\tools\mkisofs\libschily.lib sdk\tools\mkisofs\libsiconv.lib sdk\tools\mkisofs\libschily.lib && cd ."

libschily.lib(fnmatch.c.obj) : error LNK2019: unresolved external symbol _wctype referenced in function _rangematch

libschily.lib(match.c.obj) : error LNK2001: unresolved external symbol _wctype

mkisofs.exe : fatal error LNK1120: 1 unresolved externals

This is the only build-issue for the whole bootcd! If I exclude mkisofs from the build by putting a hashtag in the top-modules CMakelists.txt, then everything else builds and links fine!

Therefore and because both neighbors VS2010 and VS2013 don't run into this issue, I do think that it might be a relatively easy fix.

I already checked, the mkisofs is kind of configured about the toolchains capabilities regarding _wctype symbol by the file sdk/tools/mkisofs/reactos/xconfig.h

I already tried defining that to 0 or #undef'ing it. But it didn't help.

I assume that we have set some

#if !defined(_MSC_VER) || _MSC_VER >= xxxx

wrong here, or in some other file that has an impact on _wctype() .

Otherwise it wouldn't be plausible to have VS2010 and VS2013 succeeding here.
I would very much appreciate any help.