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.
This is a problem, if your process consists of different pieces compiled
with different MSVC versions and thus loading different msvc libs. One
example is the Apache web server provided/compiled by someone and a
module provided/compiled by someone else. Another might be the jvm
(java.exe) and a native library loaded into it. For instance the
java.dll contained in Java 1.8.0_51 and in 1.7.0_80 load msvcr100.dll.
So when Oracle updates their tool chain, they might switch to a newer
msvc runtime lib 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.
For reference see e.g.
https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
or
https://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.100%29.aspx
for MSVC 2010
(especially the paragraph starting with "If you have more than one DLL") and
https://msdn.microsoft.com/en-us/library/ms235460.aspx
I think from those descriptions the compatibility problem for tcnative
might be void, because likely we don't pass native objects across the
boundary, just references which are only natively used inside tcnative,
not in the JVM anywhere else.
For mod_jk the problem is harder, because there's a lot of data passed
between httpd and mod_jk.so. As someone wrote: "The same holds true in
case of simple C structures too. Although it is unlikely that, say for
an example, the order of struct tm or struct FILE, would change from one
version of Visual Studio to another, one can’t reply on such
assumptions." For the isapi redirector I'm undecided how likely a
problem is.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
