bug#52295: 28.0.90; Killing text results in coding system complaint

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 52295@debbugs.gnu.org
> Date: Sun, 05 Dec 2021 17:26:11 +0800
> 
> >> >   selection-coding-system
> >> >   next-selection-coding-system
> >> 
> >> Both variables are nil.
> >
> > That's the problem.  But I don't understand why is that so.  The value
> > of selection-coding-system is set in globals_of_w32select, which is
> > called during startup, and where we have this code:
> >
> >   ANSICP = GetACP ();
> >   OEMCP = GetOEMCP ();
> >
> >   QANSICP = coding_from_cp (ANSICP);
> >   QOEMCP = coding_from_cp (OEMCP);
> >
> >   if (os_subtype == OS_SUBTYPE_NT)
> >     Vselection_coding_system = Qutf_16le_dos;
> >   else if (inhibit_window_system)
> >     Vselection_coding_system = QOEMCP;
> >   else
> >     Vselection_coding_system = QANSICP;
> >
> > On Windows 9X, this should assign the ANSI codepage to
> > selection-coding-system.  Since your codepage seems to be 1252, it
> > should assign the symbol 'cp1252-dos' to selection-coding-system, see
> > coding_from_cp.
> >
> > Why doesn't this happen in your case?
> 
> Maybe that variable is dumped during the build process, with a value
> appropriate for NT, and when Emacs starts on a 9X system some other code
> sees that it is invalid and sets it to nil?

No, the code above is run in the dumped Emacs, when it starts, not in
temacs.  So the values should reflect what happens when you start
Emacs on the Windows 9X system.

Could you perhaps add some printf's there to see what actually
happens?  It almost looks like that code doesn't get called (which
would be strange by itself), since coding_from_cp cannot possibly
return nil.  Or maybe the initial assignment does work, but then some
code resets the variable back to nil?