There is nothing to stop you using alternative compression libraries, I
have applications using different components each with their own versions
of zlib.
Yes, of course, but why increase final application size, and resources used, if we can simple add the possibility to not duplicate it, if not needed? If we are not going to use compression, or we are handling it in our own code, why link the zlib library?

The workaround to use the ZLibDll could work, but this unit is
loading the DLL at initialization

I don't believe anyone ever used the DLL, once the linked OBJ files
became stable.  It's a feature more likely to be removed, than changed so
every unit using zlib breaks.
I don't want to use the DLL version either, I'm running my own encoding code by handling it thru the OnContentEncode event, so that internal compression code is never called, but setting it to use the ZLIB DLL version means the ZLIB obj's are not linked. Just a workaround to achieve my desire to not duplicate resources. And, remember, at current version, you are offering the possibility to use the DLL version, so the proposed fix to load the DLL just when needed, and check for correct load before calling its functions, is really a need.

And the other suggestion to always call the OnContentEncode, if assigned and hoContentEncoding in server options, despite the internal content type and stream size checks?
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to