On Thu, 31 Jul 2025, Jeremy Drake via Cygwin-patches wrote: > On Thu, 31 Jul 2025, Corinna Vinschen wrote: > > > As I said, newer apps against older DLL is not exactly supported, > > vice versa should be. > > > > The problem is that the usual approach of API checking as in > > CYGWIN_VERSION_CHECK_FOR_EXTRA_TM_MEMBERS (we had more of these macros > > in the past, we got rid of them with the switch to 64 bit-only) doesn't > > work from inside the application, only from inside the DLL. While > > _cygwin_crt0_common is running, the version and api fields are filled > > with the values from the time the application has been built. The > > values of the currently loaded DLL are not accessible. We could add > > another cygwin_internal macro to return a pointer to the DLL's > > version info for this purpose. > > I noticed that dll_crt0_1 calls check_sanity_and_sync which performs some > checking on the per_process struct from the application, including if the > application's api_major is greater than the dll's. However, this is after > _cygwin_crt0_common already runs. I tested by downgrading to > 3.7.0-0.266 and running an executable that I had built with 267 (but not > using the new wrappers). It didn't crash during startup, but it did seem > to crash after forking (it was doing a posix_spawn). So maybe the > api_major check could catch this after the fact but before the corruption > caused any more issues. > > > Otherwise I don't see how a new app is supposed to know the size of > > per_process_cxx_malloc of an old DLL.
I tried bumping CYGWIN_VERSION_API_MAJOR to 1, and this results that new apps exit quickly with an old dll with " fatal error - cygwin DLL and APP are out of sync -- API version mismatch 1 > 0". Loading a DLL built with this new version at runtime also gives this error and exits the program.
