[PATCH] Cygwin: add wrappers for newer new/delete overloads

[Jeremy Drake]

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.