first support for VS2015

[rainers]

This PR extracts internals of the VS runtime implementation of stdio into a separate module that can be implemented depending on the VS version.
This avoids having VS version specific conditionals in the public stdio module just leading to confusion when mixing prebuilt libraries with new code.

For now, this PR links the code for VS2013 or earlier versions, but the final version should put each module in a separate library. The compiler could then figure out what environment is used for linking and add the respective library to the link comand.

This PR works in combination with dlang/dmd#4879 by the compiler selecting the appropriate object file for the version of the LIBCMT library that will be used by link.exe.

[MartinNowak]

msvc14 missing

[rainers]

ATM you cannot link both stdio_msvc12 and stdio_msvc14 (this is the SRCS file). They both have to be added to MANIFEST, though.

[MartinNowak]

For now, this PR links the code for VS2013 or earlier versions, but the final version should put each module in a separate library. The compiler could then figure out what environment is used for linking and add the respective library to the link comand.

Can't we add both version to druntime and depending on a version declaration of the compiler import the correct msvcxx modules. That way we don't need to ship multiple libraries.

[rainers]

Can't we add both version to druntime and depending on a version declaration of the compiler import the correct msvcxx modules. That way we don't need to ship multiple libraries.

My current idea is to add the new modules as libraries or object files to the lib64 folder while phobos64.lib is independent of the VS version. There is a compile switch or some automatic detection to add the appropriate library to the link. I'm not sure if the defaultlib-mechanism is appropriate here.

I suspect a solution using versions will cause a lot of confusion, because every prebuilt library needs to be compiled with the same VC version as the executable. Shipped as binaries will need two versions if all VC versions are supposed to be supported.

[MartinNowak]

I suspect a solution using versions will cause a lot of confusion, because every prebuilt library needs to be compiled with the same VC version as the executable. Shipped as binaries will need two versions if all VC versions are supposed to be supported.

It also wouldn't work for druntim/phobos as DLL.

[MartinNowak]

The defaultlib switch is fairly underpowered.
We could use an improved dmd.conf to select the appropriate libs.
#1341

[MartinNowak]

I guess the easiest way forward is too hack support for VC detection into dmd's src/link.c.
We could then follow up with a nicer design later on.

[MartinNowak]

From ldc-developers#29 (comment)

another reasonable use case for integer versions (version(CRuntime_Microsoft >= 14) ...)

[rainers]

Updated to build stdio_msvc*.d to object files. Now needs dlang/dmd#4879

[WalterBright]

Rather than build a whole separate library, how about adding an extra .obj file that is linked in when using older VS?

[rainers]

Rather than build a whole separate library, how about adding an extra .obj file that is linked in when using older VS?

That's actually what this PR does now in combination with dlang/dmd#4879. It drags in a few symbols that are not always necessary, though (e.g. _flsbuf, _filbuf).

[MartinNowak]

It drags in a few symbols that are not always necessary, though (e.g. _flsbuf, _filbuf).

Would it help to use libs instead of objects?

[rainers]

Would it help to use libs instead of objects?

I just verified that my expectation was unfounded. The functions in the object files are generated into COMDATs, so they are only linked if referenced.

[rainers]

It also wouldn't work for druntim/phobos as DLL.

Sharing the C runtime between phobos.dll and an application would pretty much only work if both link against the same version of the MSVCRnnn DLLs. So a phobos DLL will have to be rebuilt for every VS version.

[MartinNowak]

Auto-merge toggled on

[MartinNowak]

Update for the build script dlang/installer#139.

[MartinNowak]

https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=1706290&isPull=true

d_do_test.obj : error LNK2019: unresolved external symbol _fputc_nolock referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZ12trustedFPUTCFNbNiNeiPS4core4stdc5stdio6_iobufZi
phobos64.lib(dmain2_61d_47b.obj) : error LNK2019: unresolved external symbol init_msvc referenced in function _d_run_main
phobos64.lib(stdio_b_408.obj) : error LNK2019: unresolved external symbol _fgetc_nolock referenced in function _D3std5stdio10readlnImplFPOS4core4stdc5stdio6_iobufKAawE3std5stdio4File11OrientationZm
d_do_test.exe : fatal error LNK1120: 3 unresolved externals

[rainers]

phobos64.lib(dmain2_61d_47b.obj) : error LNK2019: unresolved external symbol init_msvc referenced in function _d_run_main

The compiler has to select one of the new object files: dlang/dmd#4879

[yebblies]

Auto-merge toggled off

[rainers]

I have added stdio_msvc12.d to the library build so that the PR should pass the tester. It should also let the dmd PR build successfully with VS2013 or earlier. Once the latter is merged we can remove the file from the lib to also build with VS2015.

[kinke]

I like the approach with the 2 object files. I've just compared it to my patch for LDC (kinke@6a1c9d3), and these are the differences.

Because of the lacking version declaration, constants cannot be adjusted for VS 2015+, at least as long as one wants to keep them as compile-time constants and not as __gshared globals:

• TMP_MAX (short.max => int.max)
• L_tmpnam (13 => 260)
• _P_tmpdir isn't defined anymore
• _wP_tmpdir neither
• _IOREAD and friends neither

This PR keeps defining (v)snprintf as alias of _(v)snprintf. MSDN states:

vsnprintf is identical to _vsnprintf.

Scrap that. Looking at the inline definition in the 2015 stdio.h header, (v)snprintf uses the new C99-conformant mode (_CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR) and _(v)snprintf the legacy mode (_CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION).
This affects the output of floating point values and legacy _(v)snprintf doesn't terminate the string with null if is as long as or longer than the whole buffer and there's no space for the terminating null, instead of pruning the string and always emitting the null at the buffer end (standard-conformant). As you can imagine, that may make a huge difference. ;)
So in order to exploit the C99 conformant mode for VS2015+, we should declare (v)snprintf in stdio.d and implement it solely in stdio_msvc12.d by forwarding to legacy _(v)snprintf.

[rainers]

I think we should leave the constants as is ATM with comments that they apply to older version, but add alternatives with postfix _vc14 or similar for VS2015 and later.

So in order to exploit the C99 conformant mode for VS2015+, we should declare (v)snprintf in stdio.d and implement it solely in stdio_msvc12.d by forwarding to legacy _(v)snprintf.

I agree, we should use the C99 compliant version of snprintf as much as possible. Forwarding might also be done through /alternatename:snprintf=_snprint. See #1360

[kinke]

Cool, what a handy undocumented linker pragma. 👍

Forwarding might also be done through /alternatename:snprintf=_snprintf.

Exactly, a perfect fit!

I think we should leave the constants as is ATM with comments that they apply to older version, but add alternatives with postfix _vc14 or similar for VS2015 and later.

Hmm, then people may start using them and then we won't be able to get rid of them for quite a while. It would also encourage people to start/continue writing unportable, MS-specific code. I doubt there's much code relying on these constants out there in the D wilderness anyway, so I'd prefer keeping the constants (with comments) as-is for some time until we remove VS 2013- support from druntime.
Note that that step will allow us to get rid of quite a few special cases for MS runtimes, in both normal code as well as unit tests, and make druntime more streamlined once we can rely on a (mostly) C99-conformant host C runtime on all platforms...

Edit: #1361