Am 25.08.2015 um 23:59 schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rainer,
On 8/25/15 5:53 PM, Rainer Jung wrote:
Am 25.08.2015 um 20:41 schrieb Christopher Schultz:
On 8/25/15 11:49 AM, Rainer Jung wrote:
I just tried the isapi_redirector build using VC 2010 and the
Makefile.amd64. No additional flags, just setting up the
compiler with "setenv /Release /x64" (as usual for MSVC) before
running it. Then changing into the iis src directory and
running "nmake -f Makefile.amd64" which results in
Release_amd64/isapi_redirect.dll (the IIS plugin) and
Release_amd64/isapi_redirect.pdb (the symbol file needed for
debugging). The build was done on Windows 7 64 Bits
Professional, but I think that is less important then the MSVC
version used.
Since I'm using the 2010 compiler, the produced binary has a
dependency on the MSVCR100.dll runtime library, which must be
installed independently on the system if not yet available, but
at least there are redistributables for it provided by
Microsoft, see
https://www.microsoft.com/en-US/download/details.aspx?id=5555.
I have checked the dependency using the "depends.exe"
dependency walker (similar to Unix/Linux ldd), see
http://www.dependencywalker.com/.
I'd hope that the usual runtime library compatibility issues
are not the problematic for the ISAPI redirector as for mod_jk
on Windows. Maybe IIS can cope better with plugins using
different versions of the runtime libs. I definitely don't have
a version 6 compiler to prevent using the newer runtime libs.
I believe we go through great pains with tcnative to build
against MSVCRT.DLL because, evidently, that is guaranteed to be
available on any modern Windows system (I think that means
win2k/NT4.0+... possibly back to win95). This reduces the
installation complexity for the end user, but requires lots of
work on the part of the packager.
I'd like to know what the community thinks about building
against MSVCRT100.DLL, which is essentially the same thing and I
would imagine that everyone has that DLL these days. (The issue,
of course, is that we can't bundle it ourselves due to licensing
restrictions.)
Can we statically-link instead of using the DLL? Would that be
very stupid? Seems like it would solve everything.
AFAIR the original problem about the msvc runtime libs is, that
different versions are not compatible with each other. The one
needed by MSVC 6 (msvcrt.dll) is compatible with newer ones (the
ones with numbers in their name), but newer ones for different
numbers are not compatible with each other. Using different
numbered versions in the same process can lead to crashes etc.
I'm pretty sure that fprintf is compatible across versions, no? But
Ha! Not far from one of the real problem examples:
http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell
And MS says in
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx:
"The "best" example of this maintainability problem could be found in
the old implementation of the printf family of functions. The CRT
provides 142 different variations of printf, but most of the behavior is
the same for all of the functions, so there are a set of common
implementation functions that do the bulk of the work. These common
implementation functions were all defined in output.c in the CRT
sources(1). This 2,696 line file had 223 conditionally compiled regions
of code (#ifdef, #else, etc.), over half of which were in a single 1,400
line function. This file was compiled 12 different ways to generate all
of the common implementation functions. Even with the large number of
tests that we have for these functions, the code was exceedingly brittle
and difficult to modify."
But it seems, if this old blog describes what actually happened in the
meantime, that starting with version 14 they moved from incompatible
versions to using backwards compatible libs. Maybe some light at the
horizon.
the version-less DDL is reliably available on all modern systems,
right? That's the real issue: is the library available on the target
system. Using the version-less library gives us the widest
compatibility without requiring the user to install one of the MSVC++
redistributable packages.
This is a problem, if your process consists of different pieces
compiled with different MSVC versions and thus loading different
msvc libs.
Oh, so it might depend upon whatever IIS uses. So.. how can we tell
which MSVC was used by a particular IIS version?
I'd hope that this is less likely to happen for IIS, but I haven't
yet checked, whether IIS on newer systems itself still only has a
dependency on MSVCRT.dll or also on newer versions. I hope not.
Still there could be a problem if people add other extensions
introducing such incompatibilities.
So I think this is less about end user installation hassle. Adding
the msvc redistribution once to systems isn't that uncommon as a
task on windows. It is more about being compatible with msvc
runtime libs loaded by other components inside the same process.
The MS tool chain isn't suited to support modular software that's
combined from different suppliers.
Okay, good to know.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
