From: "Bill Stoddard" <[EMAIL PROTECTED]> Sent: Friday, January 18, 2002 10:32 AM
> I think we concluded that e would rather not break binary compatability on Windows >or any > other platform. So the part of the patch commited on 12/28/01 12:03 AM that breaks > compatability needs to be removed or reworked. No, the original code was, simply, broken. We must find a way to break compatibility for modules using _those_few_functions_, alone. They are; ap_snprintf ap_table_do ap_bvputs ap_rprintf ap_log_error ap_log_rerror ap_log_printf My suggestion is that with seven broken declarations now fixed on Win32, we export with a leading underscore (exactly as they would normally get, if there were no .def file at all), and their ordinals changed. This will assure compatibility of _only_ those seven functions is toggled, without general and massive breakage across the board. I am very uncomfortable with (...) args using pascal conventions, and really do not trust these not to introduce some odd segfaults as things stand in Win32 land. And we note this in CHANGES so users aren't confused. Also, the symbol ap_set_callback_and_alarm and ap_set_name_virtual_host have been _newly_ misexported as NONSTD (not as serious), I need to check what EAPI already did with this one and fix them appropriately. Will spend some time Sat or Sun to close this issue. Roy said no breaking binary compatibility for new features, 2.0 is here. Ken resolved his complaint by changing the new feature to not break binary compatibility. Binary-brokenness of these _fixes_ are not new features. Bill
