-----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 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. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJV3OVJAAoJEBzwKT+lPKRYtlAQAK9fjKt8GBjdYPS+X0VwFZJh q+7H81fCRayq8TEFFEA5wArJjzDrhxk4kPI9t6lz53zOQEH5hqS7XgvhvAJc7kFW iWbm2w0XL7j4tx4arZtmWVF49jjayKx/wlJirzR0uy3A26075aovDyha6UcTerah CwViFV5DVpEDZc1gTd/KWAkkZ+D0prZIdF02rC0YlR/U7cdbHUtJMil6LtxgrSNL lZ1G6xmaDe1nZ2GFaDCcTEacyseEFFk14nBwtGgfu2KYkx37wVgnb8Ixs35ah+FK J+Bn6/pQOgIy3oebgCa4JS2ELndz75Lp+JIrsR0/tJbY5ku7LJgYGfg/cSch9697 z6sAfr9iqgXSjab4zdsSkOz7HH3B2LOPFYFFlh0wDloMRClig/hSpYf5DFt2PA7w 3PK7qy/9UoyWSU3qAHEtTnSB35jCtaY4t0PzXyhaSS7fhSNr2Fsid4AOJX9Oi2BV WX8lONlrANxXtyUJMd01nQjvu7H5nmCEVagBCN9Qx/xdUSb8v9oBfqGYkdnNdY7I hYM3GHJyNX5LS3jSFoUc+TcawTZbAwjAw1dDu9YTGpSPZhWlCspyJ5pLe5+11WiD i2avR3blmKn6OLIX2YPO0e/5vPNDBBWelLslod2DAcPqnqqilRsdabFDOJPOxVgY a/riwxnkWspvGcFysdX3 =QJtF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
