By default, the MIT ccache is in non-swappable memory in Windows, although you can force it to be written to disk.
As a test, since the GSSAPI is intended to be a standardized API, I removed the Gnu GSS "libgss-1.dll" mentioned above, and replaced it by the MIT-supplied "gssapi32.dll", renamed into "libgss-1.dll" (and included the rest of the MIT DLL:s in the path). The result was that when my application came to the point where it called the GSASL methods with the appropriate properties for the GSSAPI mechanism, the GSASL implementation managed to call those MIT GSSAPI DLL-routines, and the MIT Network Identity Manager was kicked into action, requested my authentication credentials, retrieved a TGT and then also retrieved exactly the service ticket I was asking for (it remained in the ccache until I killed it). Then my application crasched... But it feels like doable (maybe with a little communication with the MIT people) to get GSASL to work with MIT:s Windows GSSAPI-implementation.
One thing I was thinking about is that the information to GSASL contains the service hostname, while the ccache contains a TGT with the realm name. The only mapping between server-/domain name and realm is in the Kerberos authentication client configuration file. Does that mean that the Gnu GSS (on Linux) does not only retrieve the MIT ccache, but also parses the configuration file?