Re: Windows 9X without KernelEx

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 16 Jun 2024 10:01:29 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The GDI32.DLL part is specific to the functions used by w32font.c.
> > But the idea is general: all of the APIs that we call directly are
> > supposed to be present in some system DLL, even though some of them
> > have stub implementations.  For example, I have SHELL32.DLL (dated Sep
> > 1998!) from my old Windows 9X system, and in it I see both
> > ShellExecuteW and SHFileOperationW exports.
> 
> Mine reports a creation time of May 11th 1998, but upon running `nm' I
> see that it indeed exports those two functions, and a test program
> compiled in MinGW:
> 
>   int
>   main ()
>   {
>     extern int ShellExecuteW ();
>     extern int SHFileOperationW ();
>     char *x = (char *) &ShellExecuteW;
>     char *y = (char *) &SHFileOperationW;
>   }
> 
> starts and exits with no error dialog, and yet Emacs still does not link
> if it imports either symbol.  Might there perhaps be symbol versioning
> mechanisms or parameters in object files that influence its view of
> external symbols?  I'm lost, sorry.

I think the reason is we don't link with -lshell32 anymore.  We used
to do that until Emacs 25, but dropped that since for some reason.
Can you see if adding that to the link command fixes this problem?

> > What prevents us from calling globals_of_w32 before
> > w32_init_current_directory?
> 
> It resets numerous other variables and also initializes the "console
> ctrl handler", which gave me plenty of pause.

Does it solve the problem, though?  The variables it resets need all
to be reset anyway, and in the pdumper build this reset is a no-op
(they are static variables not recorded in the pdumper file).  So I
don't necessarily see why moving it up would cause any problem.