Windows 9X without KernelEx

Windows 9X without KernelEx

[Po Lu via Emacs development discussions.]

Having become concerned that Emacs doesn't function on the complete set
of systems advertised in nt/README*, and after a comparison of the
symbol imports of emacs.exe with those exported by system libraries on
MS-Windows 95 confirmed my fears, I've produced a patch that should
enable Emacs to function on all Windows 9X systems with UNICOWS.DLL,
whether or not KernelEx is installed.  It further converts the linker
dependency on USP10.DLL to an optional dependency, because information
on the internet as to the availability of USP10.DLL on Windows 95 is too
ambiguous and contradictory to be trusted.

It has not been put to the test, but barring glaring oversights or
prejudice to modern Windows users, might this be installed now in its
untested condition?  Otherwise we are liable to proceed to more
important business till the release, by which time it will be far too
late.

2024-06-14    Po Lu <luangruo@yahoo.com>

	* configure.ac: Do not link with -lusp10 on non-Cygwin W32
	systems.

	* src/emacs.c (main): Call init_w32notify.

	* src/w32.c (w32_init_file_name_codepage): Clear
	g_b_init_is_windows9x, so that is_windows_9x may return values
	independent of the dump system before globals_of_w32 is called.
	Set w32_unicode_filenames to 0, again that it may be independent
	of its value at the time of dumping.
	(pfnCancelIo): New function pointer.
	(sys_write): Do not call CancelIo when absent.
	(init_ntproc): Initialize pfnCancelIo.

	* src/w32.h (init_w32notify): New function declaration.

	* src/w32fns.c (pfnSendInput): New function.
	(funhook): Use new function pointer.
	(setup_w32_kbdhook): Return if !pfnSendInput.
	(Fx_create_frame): Do not register Uniscribe font drivers if
	Uniscribe is unavailable.
	(pfnSHFileOperationW): New variable.
	(Fsystem_move_file_to_trash): Call SHFileOperationW through such
	variable.
	(pfnShellExecuteExW): New variable.
	(Fw32_shell_execute): Call ShellExecuteExW through such variable.
	(pfnGetMenuBarInfo, pfnGetWindowInfo): New variables.
	(Fw32_frame_geometry): Call GetWindowInfo and GetMenuBarInfo
	through those variables.  When the former is absent, substitute
	GetWindowLongA and GetWindowRect for the same.
	(pfnShell_NotifyIconW): New function pointer.
	(add_tray_notification, delete_tray_notification)
	(Fw32_notification_notify): Call Shell_NotifyIconW through such
	function pointer, punting when it is unavailable.
	(Fw32_notification_close): Likewise.
	(globals_of_w32fns): Initialize new function pointers.

	* src/w32notify.c (pfnReadDirectoryChangesW, pfnCancelIo): New
	variables.
	(watch_end, watch_completion, WINAPI, remove_watch)
	(Fw32notify_rm_watch, Fw32notify_valid_p): Call
	ReadDirectoryChangesW and CancelIo through those variables.
	(init_w32notify): Attempt to load those functions from
	kernel32.dll.

	* src/w32term.c (w32_set_window_size): Do not call GetMenuBarInfo
	when absent.
	(syms_of_w32term): Document status of feature consequently
	unavailable on Windows 95.

	* src/w32uniscribe.c (pfnScriptItemize, pfnScriptShape)
	(pfnScriptPlace, pfnScriptGetGlyphABCWidth, pfnScriptFreeCache)
	(pfnScriptGetCMap): New function pointers.
	(uniscribe_close, uniscribe_shape, uniscribe_encode_char)
	(uniscribe_check_otf_1): Call Uniscribe functions through the
	same.
	(syms_of_w32uniscribe_for_pdumper): Load Uniscribe library and
	required functions from the same, and if unavailable, return while
	leaving uniscribe_available intact.

diff --git a/configure.ac b/configure.ac
index f75c0a98820..e4ce59b8a05 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3133,7 +3133,7 @@ AC_DEFUN
       NATIVE_IMAGE_API="yes (w32)"
       W32_OBJ="$W32_OBJ w32image.o"
     fi
-    W32_LIBS="$W32_LIBS -lwinmm -lusp10 -lgdi32 -lcomdlg32"
+    W32_LIBS="$W32_LIBS -lwinmm -lgdi32 -lcomdlg32"
     W32_LIBS="$W32_LIBS -lmpr -lwinspool -lole32 -lcomctl32"
     W32_RES_LINK="\$(EMACSRES)"
     CLIENTRES="emacsclient.res"
diff --git a/src/emacs.c b/src/emacs.c
index d786bc65141..bb3070ed2fa 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -2187,6 +2187,7 @@ main (int argc, char **argv)
      Emacs.  */
   init_environment (argv);
   init_ntproc (will_dump_p ()); /* must precede init_editfns.  */
+  init_w32notify ();
 #endif
 
   /* AIX crashes are reported in system versions 3.2.3 and 3.2.4
diff --git a/src/w32.c b/src/w32.c
index 1c6a56bcbd9..67aec88cb65 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -1683,6 +1683,15 @@ w32_valid_pointer_p (void *p, int size)
 void
 w32_init_file_name_codepage (void)
 {
+  /* This must be initialized to a suitable value lest it be in a dumped
+     Emacs erroneously set to that of the build system during
+     startup.  */
+  g_b_init_is_windows_9x = false;
+  if (is_windows_9x ())
+    w32_unicode_filenames = 0;
+  else
+    w32_unicode_filenames = 1;
+
   file_name_codepage = CP_ACP;
   w32_ansi_code_page = CP_ACP;
 }
@@ -9261,6 +9270,9 @@ sys_read (int fd, char * buffer, unsigned int count)
 /* From w32xfns.c */
 extern HANDLE interrupt_handle;
 
+/* Functions required for serial port communications.  */
+static BOOL (WINAPI *pfnCancelIo) (HANDLE);
+
 int
 sys_write (int fd, const void * buffer, unsigned int count)
 {
@@ -9350,7 +9362,8 @@ sys_write (int fd, const void * buffer, unsigned int count)
 		     Don't bother cleaning up as we may only get stuck
 		     in buggy drivers.  */
 		  PurgeComm (hnd, PURGE_TXABORT | PURGE_TXCLEAR);
-		  CancelIo (hnd);
+		  if (pfnCancelIo)
+		    (*pfnCancelIo) (hnd);
 		  errno = EIO;	/* Why not EINTR? */
 		  nchars = -1;
 		  break;
@@ -10555,6 +10568,13 @@ init_ntproc (int dumping)
     /* Reset the volume info cache.  */
     volume_cache = NULL;
   }
+
+  {
+    HANDLE kernel32 = GetModuleHandle ("kernel32");
+
+    if (kernel32)
+      pfnCancelIo = (void *) get_proc_addr (kernel32, "CancelIo");
+  }
 }
 
 /* shutdown_handler ensures that buffers' autosave files are up to
diff --git a/src/w32.h b/src/w32.h
index cf470ae9901..8a732de7e79 100644
--- a/src/w32.h
+++ b/src/w32.h
@@ -249,6 +249,9 @@ #define FILE_DONT_CLOSE         0x1000
 /* Used instead of execvp to restart Emacs.  */
 extern int w32_reexec_emacs (char *, const char *);
 
+/* Initialize w32notify.c.  */
+extern void init_w32notify (void);
+
 #ifdef HAVE_GNUTLS
 #include <gnutls/gnutls.h>
 
diff --git a/src/w32fns.c b/src/w32fns.c
index 5b0e4a895d0..81261281ae9 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -2613,6 +2613,9 @@ my_post_msg (W32Msg * wmsg, HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
 }
 
 #ifdef WINDOWSNT
+
+static UINT (WINAPI *pfnSendInput) (UINT, LPINPUT, int);
+
 /* The Windows keyboard hook callback.  */
 static LRESULT CALLBACK
 funhook (int code, WPARAM w, LPARAM l)
@@ -2689,8 +2692,8 @@ funhook (int code, WPARAM w, LPARAM l)
 		     can prevent this by setting the
 		     w32-pass-[lr]window-to-system variable to
 		     NIL.  */
-		  if ((hs->vkCode == VK_LWIN && !NILP (Vw32_pass_lwindow_to_system)) ||
-		      (hs->vkCode == VK_RWIN && !NILP (Vw32_pass_rwindow_to_system)))
+		  if ((hs->vkCode == VK_LWIN && !NILP (Vw32_pass_lwindow_to_system))
+		       || (hs->vkCode == VK_RWIN && !NILP (Vw32_pass_rwindow_to_system)))
 		    {
 		      /* Not prevented - Simulate the keypress to the system.  */
 		      memset (inputs, 0, sizeof (inputs));
@@ -2705,7 +2708,7 @@ funhook (int code, WPARAM w, LPARAM l)
 		      inputs[1].ki.dwFlags
 			= KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP;
 		      inputs[1].ki.time = 0;
-		      SendInput (2, inputs, sizeof (INPUT));
+		      (*pfnSendInput) (2, inputs, sizeof (INPUT));
 		    }
 		  else if (focus != NULL)
 		    {
@@ -2758,7 +2761,7 @@ funhook (int code, WPARAM w, LPARAM l)
 	  inputs[1].ki.dwFlags =
 	    (hs->flags & LLKHF_EXTENDED) ? KEYEVENTF_EXTENDEDKEY : 0;
 	  inputs[1].ki.time = 0;
-	  SendInput (2, inputs, sizeof (INPUT));
+	  (*pfnSendInput) (2, inputs, sizeof (INPUT));
 	  /* Stop processing of this Win sequence here; the
 	     corresponding keyup messages will come through the normal
 	     channel when the keys are released.  */
@@ -2815,6 +2818,9 @@ setup_w32_kbdhook (HWND hwnd)
 {
   kbdhook.hook_count++;
 
+  if (!pfnSendInput)
+    return;
+
   /* This hook gets in the way of debugging, since when Emacs stops,
      its input thread stops, and there's nothing to process keyboard
      events, whereas this hook is global, and is invoked in the
@@ -6168,7 +6174,8 @@ DEFUN ("x-create-frame", Fx_create_frame, Sx_create_frame,
   if (harfbuzz_available)
     register_font_driver (&harfbuzz_font_driver, f);
 #endif
-  register_font_driver (&uniscribe_font_driver, f);
+  if (uniscribe_available)
+    register_font_driver (&uniscribe_font_driver, f);
   register_font_driver (&w32font_driver, f);
 
   gui_default_parameter (f, parameters, Qfont_backend, Qnil,
@@ -8285,6 +8292,8 @@ DEFUN ("x-file-dialog", Fx_file_dialog, Sx_file_dialog, 2, 5, 0,
 
 \f
 #ifdef WINDOWSNT
+static int (WINAPI *pfnSHFileOperationW) (LPSHFILEOPSTRUCTW);
+
 /* Moving files to the system recycle bin.
    Used by `move-file-to-trash' instead of the default moving to ~/.Trash  */
 DEFUN ("system-move-file-to-trash", Fsystem_move_file_to_trash,
@@ -8344,7 +8353,10 @@ DEFUN ("system-move-file-to-trash", Fsystem_move_file_to_trash,
 	    | FOF_NOERRORUI | FOF_NO_CONNECTED_ELEMENTS;
 	  file_op_w.fAnyOperationsAborted = FALSE;
 
-	  result = SHFileOperationW (&file_op_w);
+	  /* This is stated to exist on all versions of Windows NT Emacs
+	     supports.  */
+	  eassert (pfnSHFileOperationW);
+	  result = (*pfnSHFileOperationW) (&file_op_w);
 	}
       else
 	{
@@ -8409,6 +8421,10 @@ DEFUN ("w32-send-sys-command", Fw32_send_sys_command,
   return Qnil;
 }
 
+#ifndef CYGWIN
+static BOOL (WINAPI *pfnShellExecuteExW) (LPSHELLEXECUTEINFOW);
+#endif /* !CYGWIN */
+
 DEFUN ("w32-shell-execute", Fw32_shell_execute, Sw32_shell_execute, 2, 4, 0,
        doc: /* Get Windows to perform OPERATION on DOCUMENT.
 This is a wrapper around the ShellExecute system function, which
@@ -8618,7 +8634,7 @@ parameters (e.g., \"printto\" requires the printer address).  Otherwise,
   doc_w = xmalloc (doclen * sizeof (wchar_t));
   pMultiByteToWideChar (CP_UTF8, multiByteToWideCharFlags,
 			SSDATA (document), -1, doc_w, doclen);
-  if (use_unicode)
+  if (use_unicode && pfnShellExecuteExW)
     {
       wchar_t current_dir_w[MAX_PATH];
       SHELLEXECUTEINFOW shexinfo_w;
@@ -8670,7 +8686,7 @@ parameters (e.g., \"printto\" requires the printer address).  Otherwise,
       shexinfo_w.lpDirectory = current_dir_w;
       shexinfo_w.nShow =
 	(FIXNUMP (show_flag) ? XFIXNUM (show_flag) : SW_SHOWDEFAULT);
-      success = ShellExecuteExW (&shexinfo_w);
+      success = (*pfnShellExecuteExW) (&shexinfo_w);
       xfree (doc_w);
     }
   else
@@ -9051,6 +9067,9 @@ DEFUN ("w32-window-exists-p", Fw32_window_exists_p, Sw32_window_exists_p,
   return Qt;
 }
 
+BOOL (WINAPI *pfnGetMenuBarInfo) (HWND, LONG, LONG, PMENUBARINFO);
+static BOOL (WINAPI *pfnGetWindowInfo) (HWND, PWINDOWINFO);
+
 DEFUN ("w32-frame-geometry", Fw32_frame_geometry, Sw32_frame_geometry, 0, 1, 0,
        doc: /* Return geometric attributes of FRAME.
 FRAME must be a live frame and defaults to the selected one.  The return
@@ -9113,7 +9132,16 @@ DEFUN ("w32-frame-geometry", Fw32_frame_geometry, Sw32_frame_geometry, 0, 1, 0,
   block_input ();
   /* Outer rectangle and borders.  */
   window.cbSize = sizeof (window);
-  GetWindowInfo (FRAME_W32_WINDOW (f), &window);
+  if (pfnGetWindowInfo)
+    (*pfnGetWindowInfo) (FRAME_W32_WINDOW (f), &window);
+  else
+    {
+      /* Windows 95.  */
+      memset (&window, 0, sizeof window);
+      window.dwStyle = GetWindowLongA (FRAME_W32_WINDOW (f),
+				       GWL_STYLE);
+      GetWindowRect (FRAME_W32_WINDOW (f), &window.rcWindow);
+    }
   external_border_width = window.cxWindowBorders;
   external_border_height = window.cyWindowBorders;
   /* Title bar.  */
@@ -9141,7 +9169,10 @@ DEFUN ("w32-frame-geometry", Fw32_frame_geometry, Sw32_frame_geometry, 0, 1, 0,
   menu_bar.cbSize = sizeof (menu_bar);
   menu_bar.rcBar.right = menu_bar.rcBar.left = 0;
   menu_bar.rcBar.top = menu_bar.rcBar.bottom = 0;
-  GetMenuBarInfo (FRAME_W32_WINDOW (f), 0xFFFFFFFD, 0, &menu_bar);
+
+  /* XXX: How to implement this on Windows 95?  */
+  if (pfnGetMenuBarInfo)
+    (*pfnGetMenuBarInfo) (FRAME_W32_WINDOW (f), 0xFFFFFFFD, 0, &menu_bar);
   single_menu_bar_height = GetSystemMetrics (SM_CYMENU);
   wrapped_menu_bar_height = GetSystemMetrics (SM_CYMENUSIZE);
   unblock_input ();
@@ -10027,6 +10058,8 @@ DEFUN ("w32--menu-bar-in-use", Fw32__menu_bar_in_use, Sw32__menu_bar_in_use,
 
 #if defined WINDOWSNT && !defined HAVE_DBUS
 
+static BOOL (WINAPI *pfnShell_NotifyIconW) (DWORD, PNOTIFYICONDATAW);
+
 /***********************************************************************
 			  Tray notifications
  ***********************************************************************/
@@ -10293,7 +10326,7 @@ add_tray_notification (struct frame *f, const char *icon, const char *tip,
 	    }
 	}
 
-      if (!Shell_NotifyIconW (NIM_ADD, (PNOTIFYICONDATAW)&nidw))
+      if (!(*pfnShell_NotifyIconW) (NIM_ADD, (PNOTIFYICONDATAW)&nidw))
 	{
 	  /* GetLastError returns meaningless results when
 	     Shell_NotifyIcon fails.  */
@@ -10325,7 +10358,7 @@ delete_tray_notification (struct frame *f, int id)
       nidw.hWnd = FRAME_W32_WINDOW (f);
       nidw.uID = id;
 
-      if (!Shell_NotifyIconW (NIM_DELETE, (PNOTIFYICONDATAW)&nidw))
+      if (!(*pfnShell_NotifyIconW) (NIM_DELETE, (PNOTIFYICONDATAW)&nidw))
 	{
 	  /* GetLastError returns meaningless results when
 	     Shell_NotifyIcon fails.  */
@@ -10391,9 +10424,9 @@ DEFUN ("w32-notification-notify",
                     broken into lines.  The body text can be up to 255
                     characters long, and will be truncated if it's longer.
 
-Note that versions of Windows before W2K support only `:icon' and `:tip'.
-You can pass the other parameters, but they will be ignored on those
-old systems.
+Note that versions of Windows before W2K support only `:icon' and
+`:tip', and that this function does nothing on Windows 95.  You can pass
+the other parameters, but they will be ignored on those old systems.
 
 There can be at most one active notification at any given time.  An
 active notification must be removed by calling `w32-notification-close'
@@ -10409,7 +10442,7 @@ DEFUN ("w32-notification-notify",
   enum NI_Severity severity;
   unsigned timeout = 0;
 
-  if (nargs == 0)
+  if (nargs == 0 || !pfnShell_NotifyIconW)
     return Qnil;
 
   arg_plist = Flist (nargs, args);
@@ -10468,7 +10501,7 @@ DEFUN ("w32-notification-close",
 {
   struct frame *f = SELECTED_FRAME ();
 
-  if (FIXNUMP (id))
+  if (FIXNUMP (id) && !pfnShell_NotifyIconW)
     delete_tray_notification (f, XFIXNUM (id));
 
   return Qnil;
@@ -11489,6 +11522,14 @@ globals_of_w32fns (void)
   SetGestureConfig_fn
     = (SetGestureConfig_proc) get_proc_addr (user32_lib,
 					     "SetGestureConfig");
+  pfnGetMenuBarInfo
+    = (void *) get_proc_addr (user32_lib, "GetMenuBarInfo");
+  pfnGetWindowInfo
+    = (void *) get_proc_addr (user32_lib, "GetWindowInfo");
+#ifdef WINDOWSNT
+  pfnSendInput
+    = (void *) get_proc_addr (user32_lib, "SendInput");
+#endif /* WINDOWSNT */
 
   {
     HMODULE imm32_lib = GetModuleHandle ("imm32.dll");
@@ -11519,7 +11560,17 @@ globals_of_w32fns (void)
     get_proc_addr (wtsapi32_lib, "WTSRegisterSessionNotification");
   WTSUnRegisterSessionNotification_fn = (WTSUnRegisterSessionNotification_Proc)
     get_proc_addr (wtsapi32_lib, "WTSUnRegisterSessionNotification");
-#endif
+
+  HMODULE shell32_lib = GetModuleHandle ("shell32");
+  pfnSHFileOperationW
+    = (void *) get_proc_addr (shell32_lib, "SHFileOperationW");
+  pfnShellExecuteExW
+    = (void *) get_proc_addr (shell32_lib, "ShellExecuteExW");
+#ifndef HAVE_DBUS
+  pfnShell_NotifyIconW
+    = (void *) get_proc_addr (shell32_lib, "Shell_NotifyIconW");
+#endif /* !HAVE_DBUS */
+#endif /* WINDOWSNT */
 
   /* Support OS dark mode on Windows 10 version 1809 and higher.
      See `w32_applytheme' which uses appropriate APIs per version of Windows.
diff --git a/src/w32notify.c b/src/w32notify.c
index c93e8796fe2..b3ba1357a05 100644
--- a/src/w32notify.c
+++ b/src/w32notify.c
@@ -120,6 +120,12 @@ #define DIRWATCH_SIGNATURE 0x01233210
 /* Used for communicating notifications to the main thread.  */
 struct notifications_set *notifications_set_head;
 
+/* Function pointers.  */
+static BOOL (WINAPI *pfnReadDirectoryChangesW) (HANDLE, PVOID, DWORD, BOOL,
+						DWORD, PDWORD, LPOVERLAPPED,
+						LPOVERLAPPED_COMPLETION_ROUTINE);
+static BOOL (WINAPI *pfnCancelIo) (HANDLE);
+
 static Lisp_Object watch_list;
 
 /* Signal to the main thread that we have file notifications for it to
@@ -175,7 +181,7 @@ watch_end (ULONG_PTR arg)
   HANDLE hdir = (HANDLE)arg;
 
   if (hdir && hdir != INVALID_HANDLE_VALUE)
-    CancelIo (hdir);
+    (*pfnCancelIo) (hdir);
 }
 
 /* A completion routine (a.k.a. "APC function") for handling events
@@ -252,10 +258,10 @@ watch_completion (DWORD status, DWORD bytes_ret, OVERLAPPED *io_info)
 
   /* Calling ReadDirectoryChangesW quickly to watch again for new
      notifications.  */
-  if (!ReadDirectoryChangesW (dirwatch->dir, dirwatch->buf,
-			      DIRWATCH_BUFFER_SIZE, dirwatch->subtree,
-			      dirwatch->filter, &_bytes, dirwatch->io_info,
-			      watch_completion))
+  if (!(*pfnReadDirectoryChangesW) (dirwatch->dir, dirwatch->buf,
+				    DIRWATCH_BUFFER_SIZE, dirwatch->subtree,
+				    dirwatch->filter, &_bytes,
+				    dirwatch->io_info, watch_completion))
     {
       DebPrint (("ReadDirectoryChangesW error: %lu\n", GetLastError ()));
       /* If this call fails, it means that the directory is not
@@ -270,7 +276,7 @@ watch_completion (DWORD status, DWORD bytes_ret, OVERLAPPED *io_info)
 
   /* If we were asked to terminate the thread, then fire the event. */
   if (terminate)
-    SetEvent(dirwatch->terminate);
+    SetEvent (dirwatch->terminate);
 }
 
 /* Worker routine for the watch thread.  */
@@ -284,10 +290,10 @@ watch_worker (LPVOID arg)
 
   if (dirwatch->dir)
     {
-      bErr = ReadDirectoryChangesW (dirwatch->dir, dirwatch->buf,
-				    DIRWATCH_BUFFER_SIZE, dirwatch->subtree,
-				    dirwatch->filter, &_bytes,
-				    dirwatch->io_info, watch_completion);
+      bErr = (*pfnReadDirectoryChangesW) (dirwatch->dir, dirwatch->buf,
+					  DIRWATCH_BUFFER_SIZE, dirwatch->subtree,
+					  dirwatch->filter, &_bytes,
+					  dirwatch->io_info, watch_completion);
       if (!bErr)
 	{
 	  DebPrint (("ReadDirectoryChangesW: %lu\n", GetLastError ()));
@@ -436,7 +442,7 @@ remove_watch (struct notification *dirwatch)
 	DebPrint (("QueueUserAPC failed (%lu)!\n", GetLastError ()));
 
       /* We also signal the thread that it can terminate.  */
-      SetEvent(dirwatch->terminate);
+      SetEvent (dirwatch->terminate);
 
       /* Wait for the thread to exit.  FIXME: is there a better method
 	 that is not overly complex?  */
@@ -466,7 +472,7 @@ remove_watch (struct notification *dirwatch)
 	  CloseHandle (dirwatch->thr);
 	  dirwatch->thr = NULL;
 	}
-      CloseHandle(dirwatch->terminate);
+      CloseHandle (dirwatch->terminate);
       xfree (dirwatch->buf);
       xfree (dirwatch->io_info);
       xfree (dirwatch->watchee);
@@ -649,7 +655,7 @@ DEFUN ("w32notify-rm-watch", Fw32notify_rm_watch,
   if (!NILP (watch_object))
     {
       watch_list = Fdelete (watch_object, watch_list);
-      dirwatch = (struct notification *)xmint_pointer (watch_descriptor);
+      dirwatch = (struct notification *) xmint_pointer (watch_descriptor);
       if (w32_valid_pointer_p (dirwatch, sizeof(struct notification)))
 	status = remove_watch (dirwatch);
     }
@@ -687,7 +693,7 @@ DEFUN ("w32notify-valid-p", Fw32notify_valid_p, Sw32notify_valid_p, 1, 1, 0,
   if (!NILP (watch_object))
     {
       struct notification *dirwatch =
-	(struct notification *)xmint_pointer (watch_descriptor);
+	(struct notification *) xmint_pointer (watch_descriptor);
       if (w32_valid_pointer_p (dirwatch, sizeof(struct notification))
 	  && dirwatch->dir != NULL)
 	return Qt;
@@ -722,3 +728,18 @@ syms_of_w32notify (void)
 
   Fprovide (intern_c_string ("w32notify"), Qnil);
 }
+
+void
+init_w32notify (void)
+{
+  HANDLE kernel32 = GetModuleHandle ("kernel32");
+
+  /* Initialize pointers to IO functions that provide file
+     notifications.  In the event that these are absent, no harm will be
+     done, since their absence indicates that Emacs is running on
+     Windows 9X, where file notifications are unavailable at the
+     outset.  */
+  pfnCancelIo = (void *) get_proc_addr (kernel32, "CancelIo");
+  pfnReadDirectoryChangesW
+    = (void *) get_proc_addr (kernel32, "ReadDirectoryChangesW");
+}
diff --git a/src/w32term.c b/src/w32term.c
index 62037e3b2cd..30f0f9b50f9 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -7143,6 +7143,9 @@ w32fullscreen_hook (struct frame *f)
     f->want_fullscreen |= FULLSCREEN_WAIT;
 }
 
+/* Defined in w32fns.c.  */
+extern BOOL (WINAPI *pfnGetMenuBarInfo) (HWND, LONG, LONG, PMENUBARINFO);
+
 /* Change the size of frame F's Windows window to WIDTH and HEIGHT
    pixels.  If CHANGE_GRAVITY, change to top-left-corner window gravity
    for this size change and subsequent size changes.  Otherwise leave
@@ -7163,10 +7166,11 @@ w32_set_window_size (struct frame *f, bool change_gravity,
      third argument for AdjustWindowRect.  See bug#22105.  */
   info.cbSize = sizeof (info);
   info.rcBar.top = info.rcBar.bottom = 0;
-  GetMenuBarInfo (FRAME_W32_WINDOW (f), 0xFFFFFFFD, 0, &info);
+  if (pfnGetMenuBarInfo)
+    (*pfnGetMenuBarInfo) (FRAME_W32_WINDOW (f), 0xFFFFFFFD, 0, &info);
   menu_bar_height = info.rcBar.bottom - info.rcBar.top;
 
-  if (w32_add_wrapped_menu_bar_lines)
+  if (w32_add_wrapped_menu_bar_lines && pfnGetMenuBarInfo)
     {
       /* When the menu bar wraps sending a SetWindowPos shrinks the
 	 height of the frame then the wrapped menu bar lines are not
@@ -8323,7 +8327,9 @@ syms_of_w32term (void)
 This usually means that the resulting frame height is off by the number
 of wrapped menu bar lines.  If this is non-nil, Emacs adds the height of
 wrapped menu bar lines when sending frame resize requests to the Windows
-API.  */);
+API.
+
+This feature is unavailable on Windows 95.  */);
   w32_add_wrapped_menu_bar_lines = 1;
 
   /* Tell Emacs about this window system.  */
diff --git a/src/w32uniscribe.c b/src/w32uniscribe.c
index b3112912c76..2fe90afd5f6 100644
--- a/src/w32uniscribe.c
+++ b/src/w32uniscribe.c
@@ -108,6 +108,31 @@ memq_no_quit (Lisp_Object elt, Lisp_Object list)
   return (CONSP (list));
 }
 
+\f
+/* Uniscribe function pointers.  */
+static HRESULT (WINAPI * pfnScriptItemize) (const WCHAR *,
+					    int,
+					    int,
+					    const SCRIPT_CONTROL *,
+					    const SCRIPT_STATE *,
+					    SCRIPT_ITEM *, int *);
+static HRESULT (WINAPI * pfnScriptShape) (HDC, SCRIPT_CACHE *,
+					  const WCHAR *,
+					  int, int, SCRIPT_ANALYSIS *,
+					  WORD *, WORD *, SCRIPT_VISATTR *,
+					  int *);
+static HRESULT (WINAPI * pfnScriptPlace) (HDC, SCRIPT_CACHE *,
+					  const WORD *, int,
+					  const SCRIPT_VISATTR *,
+					  SCRIPT_ANALYSIS *,
+					  int *, GOFFSET *, ABC *);
+static HRESULT (WINAPI * pfnScriptGetGlyphABCWidth) (HDC, SCRIPT_CACHE *,
+						     WORD, ABC *);
+static HRESULT (WINAPI * pfnScriptFreeCache) (SCRIPT_CACHE *);
+static HRESULT (WINAPI * pfnScriptGetCMap) (HDC, SCRIPT_CACHE *,
+					    const WCHAR *,
+					    int, DWORD, WORD *);
+
 \f
 /* Font backend interface implementation.  */
 static Lisp_Object
@@ -202,7 +227,7 @@ uniscribe_close (struct font *font)
   else
 #endif
   if (uniscribe_font->cache)
-    ScriptFreeCache ((SCRIPT_CACHE) &(uniscribe_font->cache));
+    (*pfnScriptFreeCache) ((SCRIPT_CACHE) &(uniscribe_font->cache));
 
   uniscribe_font->cache = NULL;
 
@@ -320,8 +345,8 @@ uniscribe_shape (Lisp_Object lgstring, Lisp_Object direction)
   max_items = 2;
   items = xmalloc (sizeof (SCRIPT_ITEM) * max_items + 1);
 
-  while ((result = ScriptItemize (chars, nchars, max_items, NULL, NULL,
-				  items, &nitems)) == E_OUTOFMEMORY)
+  while ((result = (*pfnScriptItemize) (chars, nchars, max_items, NULL, NULL,
+					items, &nitems)) == E_OUTOFMEMORY)
     {
       /* If that wasn't enough, keep trying with one more run.  */
       max_items++;
@@ -344,17 +369,18 @@ uniscribe_shape (Lisp_Object lgstring, Lisp_Object direction)
     {
       int nglyphs, nchars_in_run;
       nchars_in_run = items[i+1].iCharPos - items[i].iCharPos;
-      /* Force ScriptShape to generate glyphs in the same order as
+      /* Force (*pfnScriptShape) to generate glyphs in the same order as
 	 they are in the input LGSTRING, which is in the logical
 	 order.  */
       items[i].a.fLogicalOrder = 1;
 
       /* Context may be NULL here, in which case the cache should be
          used without needing to select the font.  */
-      result = ScriptShape (context, (SCRIPT_CACHE) &(uniscribe_font->cache),
-			    chars + items[i].iCharPos, nchars_in_run,
-			    max_glyphs - done_glyphs, &(items[i].a),
-			    glyphs, clusters, attributes, &nglyphs);
+      result
+	= (*pfnScriptShape) (context, (SCRIPT_CACHE) &(uniscribe_font->cache),
+			     chars + items[i].iCharPos, nchars_in_run,
+			     max_glyphs - done_glyphs, &(items[i].a),
+			     glyphs, clusters, attributes, &nglyphs);
 
       if (result == E_PENDING && !context)
 	{
@@ -365,10 +391,12 @@ uniscribe_shape (Lisp_Object lgstring, Lisp_Object direction)
 	  context = get_frame_dc (f);
 	  old_font = SelectObject (context, FONT_HANDLE (font));
 
-	  result = ScriptShape (context, (SCRIPT_CACHE) &(uniscribe_font->cache),
-				chars + items[i].iCharPos, nchars_in_run,
-				max_glyphs - done_glyphs, &(items[i].a),
-				glyphs, clusters, attributes, &nglyphs);
+	  result
+	    = (*pfnScriptShape) (context,
+				 (SCRIPT_CACHE) &(uniscribe_font->cache),
+				 chars + items[i].iCharPos, nchars_in_run,
+				 max_glyphs - done_glyphs, &(items[i].a),
+				 glyphs, clusters, attributes, &nglyphs);
 	}
 
       if (result == E_OUTOFMEMORY)
@@ -390,9 +418,11 @@ uniscribe_shape (Lisp_Object lgstring, Lisp_Object direction)
 	}
       else
 	{
-	  result = ScriptPlace (context, (SCRIPT_CACHE) &(uniscribe_font->cache),
-				glyphs, nglyphs, attributes, &(items[i].a),
-				advances, offsets, &overall_metrics);
+	  result
+	    = (*pfnScriptPlace) (context,
+				 (SCRIPT_CACHE) &(uniscribe_font->cache),
+				 glyphs, nglyphs, attributes, &(items[i].a),
+				 advances, offsets, &overall_metrics);
 	  if (result == E_PENDING && !context)
 	    {
 	      /* Cache not complete...  */
@@ -400,10 +430,11 @@ uniscribe_shape (Lisp_Object lgstring, Lisp_Object direction)
 	      context = get_frame_dc (f);
 	      old_font = SelectObject (context, FONT_HANDLE (font));
 
-	      result = ScriptPlace (context,
-				    (SCRIPT_CACHE) &(uniscribe_font->cache),
-				    glyphs, nglyphs, attributes, &(items[i].a),
-				    advances, offsets, &overall_metrics);
+	      result
+		= (*pfnScriptPlace) (context,
+				     (SCRIPT_CACHE) &(uniscribe_font->cache),
+				     glyphs, nglyphs, attributes, &(items[i].a),
+				     advances, offsets, &overall_metrics);
 	    }
           if (SUCCEEDED (result))
 	    {
@@ -469,7 +500,7 @@ uniscribe_shape (Lisp_Object lgstring, Lisp_Object direction)
 			 then updated for each successive glyph in the
 			 grapheme cluster.  */
 		      /* FIXME: Should we use DIRECTION here instead
-			 of what ScriptItemize guessed?  */
+			 of what (*pfnScriptItemize) guessed?  */
 		      if (items[i].a.fRTL)
 			{
 			  int j1 = j;
@@ -496,7 +527,7 @@ uniscribe_shape (Lisp_Object lgstring, Lisp_Object direction)
 		  LGLYPH_SET_ASCENT (lglyph, font->ascent);
 		  LGLYPH_SET_DESCENT (lglyph, font->descent);
 
-		  result = ScriptGetGlyphABCWidth
+		  result = (*pfnScriptGetGlyphABCWidth)
 		    (context, (SCRIPT_CACHE) &(uniscribe_font->cache),
 		     glyphs[j], &char_metric);
 		  if (result == E_PENDING && !context)
@@ -505,7 +536,7 @@ uniscribe_shape (Lisp_Object lgstring, Lisp_Object direction)
 		      f = XFRAME (selected_frame);
 		      context = get_frame_dc (f);
 		      old_font = SelectObject (context, FONT_HANDLE (font));
-		      result = ScriptGetGlyphABCWidth
+		      result = (*pfnScriptGetGlyphABCWidth)
 			(context, (SCRIPT_CACHE) &(uniscribe_font->cache),
 			 glyphs[j], &char_metric);
 		    }
@@ -624,7 +655,8 @@ uniscribe_encode_char (struct font *font, int c)
      convert surrogate pairs to glyph indexes correctly.  */
     {
       items = (SCRIPT_ITEM *) alloca (sizeof (SCRIPT_ITEM) * 2 + 1);
-      if (SUCCEEDED (ScriptItemize (ch, len, 2, NULL, NULL, items, &nitems)))
+      if (SUCCEEDED ((*pfnScriptItemize) (ch, len, 2, NULL, NULL, items,
+					  &nitems)))
 	{
 	  HRESULT result;
           /* Surrogates seem to need 2 here, even though only one glyph is
@@ -635,14 +667,14 @@ uniscribe_encode_char (struct font *font, int c)
           SCRIPT_VISATTR attrs[2];
           int nglyphs;
 
-	  /* Force ScriptShape to generate glyphs in the logical
+	  /* Force (*pfnScriptShape) to generate glyphs in the logical
 	     order.  */
 	  items[0].a.fLogicalOrder = 1;
 
-          result = ScriptShape (context,
-				(SCRIPT_CACHE) &(uniscribe_font->cache),
-                                ch, len, 2, &(items[0].a),
-                                glyphs, clusters, attrs, &nglyphs);
+          result = (*pfnScriptShape) (context,
+				      (SCRIPT_CACHE) &(uniscribe_font->cache),
+				      ch, len, 2, &(items[0].a),
+				      glyphs, clusters, attrs, &nglyphs);
 
           if (result == E_PENDING)
             {
@@ -651,10 +683,11 @@ uniscribe_encode_char (struct font *font, int c)
               f = XFRAME (selected_frame);
               context = get_frame_dc (f);
               old_font = SelectObject (context, FONT_HANDLE (font));
-              result = ScriptShape (context,
-				    (SCRIPT_CACHE) &(uniscribe_font->cache),
-                                    ch, len, 2, &(items[0].a),
-                                    glyphs, clusters, attrs, &nglyphs);
+              result
+		= (*pfnScriptShape) (context,
+				     (SCRIPT_CACHE) &(uniscribe_font->cache),
+				     ch, len, 2, &(items[0].a),
+				     glyphs, clusters, attrs, &nglyphs);
             }
 
           if (SUCCEEDED (result) && nglyphs == 1)
@@ -670,9 +703,10 @@ uniscribe_encode_char (struct font *font, int c)
                  when shaped. But we still need the return from here
                  to be valid for the shaping engine to be invoked
                  later.  */
-              result = ScriptGetCMap (context,
-				      (SCRIPT_CACHE) &(uniscribe_font->cache),
-                                      ch, len, 0, glyphs);
+              result
+		= (*pfnScriptGetCMap) (context,
+				       (SCRIPT_CACHE) &(uniscribe_font->cache),
+				       ch, len, 0, glyphs);
               if (SUCCEEDED (result) && glyphs[0])
                 code = glyphs[0];
             }
@@ -942,7 +976,7 @@ uniscribe_check_otf_1 (HDC context, Lisp_Object script, Lisp_Object lang,
 
  no_support:
   if (cache)
-    ScriptFreeCache (&cache);
+    (*pfnScriptFreeCache) (&cache);
   return ret;
 }
 
@@ -1505,10 +1539,27 @@ syms_of_w32uniscribe_for_pdumper (void)
     return;
 
   /* Don't register if Uniscribe is not available.  */
-  HMODULE uniscribe = GetModuleHandle ("usp10");
+  HMODULE uniscribe = LoadLibrary ("usp10.dll");
   if (!uniscribe)
     return;
 
+  pfnScriptItemize = (void *) get_proc_addr (uniscribe, "ScriptItemize");
+  pfnScriptShape = (void *) get_proc_addr (uniscribe, "ScriptShape");
+  pfnScriptPlace = (void *) get_proc_addr (uniscribe, "ScriptPlace");
+  pfnScriptGetGlyphABCWidth
+    = (void *) get_proc_addr (uniscribe, "GetGlyphABCWidth");
+  pfnScriptFreeCache
+    = (void *) get_proc_addr (uniscribe, "ScriptFreeCache");
+  pfnScriptGetCMap
+    = (void *) get_proc_addr (uniscribe, "ScriptGetCMap");
+  if (!pfnScriptItemize || !pfnScriptShape || !pfnScriptPlace
+      || !pfnScriptGetGlyphABCWidth || !pfnScriptFreeCache
+      || !pfnScriptGetCMap)
+    {
+      FreeLibrary (uniscribe);
+      return;
+    }
+
   uniscribe_available = 1;
 
   register_font_driver (&uniscribe_font_driver, NULL);

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> Date: Fri, 14 Jun 2024 23:12:59 +0800
> From:  Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> Having become concerned that Emacs doesn't function on the complete set
> of systems advertised in nt/README*, and after a comparison of the
> symbol imports of emacs.exe with those exported by system libraries on
> MS-Windows 95 confirmed my fears, I've produced a patch that should
> enable Emacs to function on all Windows 9X systems with UNICOWS.DLL,
> whether or not KernelEx is installed.  It further converts the linker
> dependency on USP10.DLL to an optional dependency, because information
> on the internet as to the availability of USP10.DLL on Windows 95 is too
> ambiguous and contradictory to be trusted.
> 
> It has not been put to the test, but barring glaring oversights or
> prejudice to modern Windows users, might this be installed now in its
> untested condition?  Otherwise we are liable to proceed to more
> important business till the release, by which time it will be far too
> late.

We never really supported Windows 95, only Windows 98.  So I don't
think it makes sense to introduce all this complexity now, just to add
Windows 95 to the soup.

Or are you saying that there are problems on Windows 98 as well?

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> We never really supported Windows 95, only Windows 98.  So I don't
> think it makes sense to introduce all this complexity now, just to add
> Windows 95 to the soup.
>
> Or are you saying that there are problems on Windows 98 as well?

Probably, yes.  The Windows 95 portions of this change are only a
fractoon of the whole, in all likelihood, but I cannot swear to either
possibility as KernelEx dlls export plenty of functions called from
w32*.c, and my searching revealed no symbol list for Windows 98 online,
leaving me with no choice but to err on the side of caution.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 14 Jun 2024 23:37:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We never really supported Windows 95, only Windows 98.  So I don't
> > think it makes sense to introduce all this complexity now, just to add
> > Windows 95 to the soup.
> >
> > Or are you saying that there are problems on Windows 98 as well?
> 
> Probably, yes.  The Windows 95 portions of this change are only a
> fractoon of the whole, in all likelihood, but I cannot swear to either
> possibility as KernelEx dlls export plenty of functions called from
> w32*.c, and my searching revealed no symbol list for Windows 98 online,
> leaving me with no choice but to err on the side of caution.

I do have such lists, but no one said they are accurate, and I don't
have a system to try that.

If you are saying that Emacs doesn't work on Windows 98, then we need
to handle this one issue at a time.

First, does Emacs refuse to start on Windows 98, because some function
we call directly is unavailable there, even when UNICOWS.DLL is
installed?  If Emacs refuses to start due to some functions called
directly, please submit a bug with the names of those functions, and
this is something we _must_ solve (but can do that after the release
branch is created).

If Emacs does start, it means Windows 98 provides at least stubs for
those functions.  Then we need to consider each of the functions you
mentioned in the patch separately.  Some of them I'd simply ignore:
for example, it makes no sense to me to fix the Uniscribe support if
its broken, since we prefer HarfBuzz anyway.  Similarly for w32notify:
all we need is to make file-notifications unavailable on Windows 98.

Therefore, please submit a separate bug for each of the functions you
think are missing or don't work, and let's consider them each as a
separate issue.  Part of the consideration is the potential breakage
in the Windows port that could be caused on modern Windows systems --
if the risk is too high, I'd prefer to delay the solution to Emacs 31.
It would be good if each such bug report included results of actual
attempt to use those functions on Windows 98, if you can do that,
because then we'd have detailed information about the possible
breakage, and will be able to weigh our options based on solid facts.

Thanks.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I do have such lists, but no one said they are accurate, and I don't
> have a system to try that.
>
> If you are saying that Emacs doesn't work on Windows 98, then we need
> to handle this one issue at a time.
>
> First, does Emacs refuse to start on Windows 98, because some function
> we call directly is unavailable there, even when UNICOWS.DLL is
> installed?  If Emacs refuses to start due to some functions called
> directly, please submit a bug with the names of those functions, and
> this is something we _must_ solve (but can do that after the release
> branch is created).
>
> If Emacs does start, it means Windows 98 provides at least stubs for
> those functions.  Then we need to consider each of the functions you
> mentioned in the patch separately.  Some of them I'd simply ignore:
> for example, it makes no sense to me to fix the Uniscribe support if
> its broken, since we prefer HarfBuzz anyway.  Similarly for w32notify:
> all we need is to make file-notifications unavailable on Windows 98.
>
> Therefore, please submit a separate bug for each of the functions you
> think are missing or don't work, and let's consider them each as a
> separate issue.  Part of the consideration is the potential breakage
> in the Windows port that could be caused on modern Windows systems --
> if the risk is too high, I'd prefer to delay the solution to Emacs 31.
> It would be good if each such bug report included results of actual
> attempt to use those functions on Windows 98, if you can do that,
> because then we'd have detailed information about the possible
> breakage, and will be able to weigh our options based on solid facts.

As it's the weekends, I suppose I might install Windows 98 in a virtual
machine.  Fingers crossed.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> mentioned in the patch separately.  Some of them I'd simply ignore:
> for example, it makes no sense to me to fix the Uniscribe support if
> its broken, since we prefer HarfBuzz anyway.

BTW, there's no "fix" to Uniscribe support, but merely code that enables
Emacs to avoid linking to USP10.DLL, in the spirit of other OS features
whose existence is established at runtime.

Re: Windows 9X without KernelEx

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> [...] I don't think it makes sense to introduce all this complexity
> now, just to add Windows 95 to the soup.

Agreed.

BTW, would the below patch make sense?

diff --git a/nt/README b/nt/README
index 694e8854446..95606045681 100644
--- a/nt/README
+++ b/nt/README
@@ -4,7 +4,7 @@
   See the end of the file for license conditions.

   This directory contains support for compiling and running GNU Emacs on
-  Windows NT, Windows 95, and their successors.  This port supports all
+  Windows NT, Windows 98, and their successors.  This port supports all
   of the major functionality of the Unix version, including
   subprocesses, windowing features (fonts, colors, scroll bars, multiple
   frames, etc.), and networking support.

Re: Windows 9X without KernelEx

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> BTW, would the below patch make sense?

No, not at present, because it won't run on Windows 98 either, without
KernelEx.

Re: Windows 9X without KernelEx

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> BTW, would the below patch make sense?
>
> No, not at present, because it won't run on Windows 98 either, without
> KernelEx.

OK, following are my conclusions from tests conducted on "real" Windows
98 and 95 installations with no supplemental software but the Microsoft
Layer for Unicode.  These DLLs and symbols are missing (not merely
stubs) from English installations of both:

  USP10.DLL
  ScriptItemize
  ScriptShape
  ScriptPlace
  ScriptGetGlyphABCWidth
  ScriptFreeCache
  ScriptGetCMap

  Shell_NotifyIconW
  ShellExecuteExW
  SHFileOperationW
  ReadDirectoryChangesW

these symbols are absent from only Windows 95:

  CancelIo
  SendInput
  GetWindowInfo
  GetMenuBarInfo

all of which the patch posted renders optional or replaces.  The posted
modifications to `w32_init_file_name_codepage' are only necessary if
Emacs binaries produced on Windows NT systems are to start on 9X, which
explains why the crashes they resolve were not encountered in my earlier
testing on real hardware.  With said patch, Emacs is capable of
functioning on Windows 98 to the extent of running Gnus, connecting to a
IMAP and SMTP servers, reading and composing mail in English, and on
Windows 95, where I didn't succeed in configuring networking in the VM,
calling all Lisp functions affected by the patch without crashing or
returning obviously unsatisfactory results.

Of the functions exclusive to Windows 98, SendInput and CancelIo are
never called on 9X systems, since funhook is not installed on such
systems and file notifications are disabled on all 9X systems, and
GetWindowInfo and GetMenuBarInfo are either omitted on Windows 95 in the
patch, or trivially replaced, without complicating affected code.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 10:42:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > mentioned in the patch separately.  Some of them I'd simply ignore:
> > for example, it makes no sense to me to fix the Uniscribe support if
> > its broken, since we prefer HarfBuzz anyway.
> 
> BTW, there's no "fix" to Uniscribe support, but merely code that enables
> Emacs to avoid linking to USP10.DLL, in the spirit of other OS features
> whose existence is established at runtime.

Does Emacs refuse to start up on Windows 98 due to USP10.DLL?

I just checked, and my old Windows 98 did have USP10.DLL.  AFAIR,
Uniscribe came with IE 5, so I think every Windows system nowadays
should have it, if it's still being used.

If needed, we can document that Uniscribe is required for Emacs to run
on Windows 9X.  I'd prefer this to complicating the code more than we
already have.  Especially since Uniscribe is supported as a fallback,
and is likely to be removed at some future point.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 14 Jun 2024 21:07:00 -0700
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [...] I don't think it makes sense to introduce all this complexity
> > now, just to add Windows 95 to the soup.
> 
> Agreed.
> 
> BTW, would the below patch make sense?

Yes, done.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 12:45:02 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Stefan Kangas <stefankangas@gmail.com> writes:
> >
> >> BTW, would the below patch make sense?
> >
> > No, not at present, because it won't run on Windows 98 either, without
> > KernelEx.
> 
> OK, following are my conclusions from tests conducted on "real" Windows
> 98 and 95 installations with no supplemental software but the Microsoft
> Layer for Unicode.  These DLLs and symbols are missing (not merely
> stubs) from English installations of both:
> 
>   USP10.DLL
>   ScriptItemize
>   ScriptShape
>   ScriptPlace
>   ScriptGetGlyphABCWidth
>   ScriptFreeCache
>   ScriptGetCMap

As I said, I'm not sure Uniscribe is a problem in practice.  We could
make it a mandatory requirement, like UNICOWS.DLL, if needed.

>   Shell_NotifyIconW
>   ShellExecuteExW
>   SHFileOperationW
>   ReadDirectoryChangesW

Does Emacs fail to start due to these being absent?  If not, please
submit separate bug reports about each API if something bad happens
when the relevant code is executed in Emacs, and let's discuss each
such issue separately.  Solutions could be very different in each
case, from just letting the operation fail to adding a call through
function pointer, and anything in-between.

> these symbols are absent from only Windows 95:
> 
>   CancelIo
>   SendInput
>   GetWindowInfo
>   GetMenuBarInfo

Again, what bad things happen due to that?  Since we now officially
don't support Windows 95, can we just forget about those?

> Of the functions exclusive to Windows 98, SendInput and CancelIo are
> never called on 9X systems, since funhook is not installed on such
> systems and file notifications are disabled on all 9X systems, and
> GetWindowInfo and GetMenuBarInfo are either omitted on Windows 95 in the
> patch, or trivially replaced, without complicating affected code.

I interpret this as "there's no problem we should solve".

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Does Emacs refuse to start up on Windows 98 due to USP10.DLL?

Yes.

> I just checked, and my old Windows 98 did have USP10.DLL.  AFAIR,
> Uniscribe came with IE 5, so I think every Windows system nowadays
> should have it, if it's still being used.
>
> If needed, we can document that Uniscribe is required for Emacs to run
> on Windows 9X.  I'd prefer this to complicating the code more than we
> already have.  Especially since Uniscribe is supported as a fallback,
> and is likely to be removed at some future point.

I would be really averse to this solution, because the first two
downloads of this file I tried were flagged as viruses (or were
distributed as installer programs so flagged), and the alternative is
only small number of lines of extra code.  Of course, I possess a proper
copy of this file, but that fact is of no assistance to the next person.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> As I said, I'm not sure Uniscribe is a problem in practice.  We could
> make it a mandatory requirement, like UNICOWS.DLL, if needed.

Since Uniscribe is to be removed anyway, no harm will ever come of
rendering it optional, though if you consider this aspect of the patch
too dangerous for the release, it can wait till Emacs 31, as the dll
does exist on the machine that is meant to receive Emacs 30.

> Does Emacs fail to start due to these being absent?

Yes, the link loader won't load emacs.exe for want of these symbols,
which is the criterion I applied in compiling these lists.

> Again, what bad things happen due to that?  Since we now officially
> don't support Windows 95, can we just forget about those?

It's a little galling to see something declared "officially unsupported"
within 24 hours of my writing the code to restore support for it...

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 15:12:36 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does Emacs refuse to start up on Windows 98 due to USP10.DLL?
> 
> Yes.
> 
> > I just checked, and my old Windows 98 did have USP10.DLL.  AFAIR,
> > Uniscribe came with IE 5, so I think every Windows system nowadays
> > should have it, if it's still being used.
> >
> > If needed, we can document that Uniscribe is required for Emacs to run
> > on Windows 9X.  I'd prefer this to complicating the code more than we
> > already have.  Especially since Uniscribe is supported as a fallback,
> > and is likely to be removed at some future point.
> 
> I would be really averse to this solution, because the first two
> downloads of this file I tried were flagged as viruses (or were
> distributed as installer programs so flagged), and the alternative is
> only small number of lines of extra code.  Of course, I possess a proper
> copy of this file, but that fact is of no assistance to the next person.

Let's first hear from such a person, if he/she exists.  I don't want
to complicate our code, and thus run the risk of introducing bugs, on
behalf of a largely imaginary problem, sorry.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 15:22:09 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > As I said, I'm not sure Uniscribe is a problem in practice.  We could
> > make it a mandatory requirement, like UNICOWS.DLL, if needed.
> 
> Since Uniscribe is to be removed anyway, no harm will ever come of
> rendering it optional, though if you consider this aspect of the patch
> too dangerous for the release, it can wait till Emacs 31, as the dll
> does exist on the machine that is meant to receive Emacs 30.
> 
> > Does Emacs fail to start due to these being absent?
> 
> Yes, the link loader won't load emacs.exe for want of these symbols,
> which is the criterion I applied in compiling these lists.

If you add usp10.dll (and unicows.dll) to Windows 98, does Emacs start
then?  Or do any of the other missing APIs prevent it from starting?

> > Again, what bad things happen due to that?  Since we now officially
> > don't support Windows 95, can we just forget about those?
> 
> It's a little galling to see something declared "officially unsupported"
> within 24 hours of my writing the code to restore support for it...

We should have discussed this before your writing the code, to prevent
the unnecessary efforts.  I'm sorry for your wasted time, but I have
said many times before: this kind of issues should be discussed first.
I will keep saying that, in the hope that at some point this will
sink.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Let's first hear from such a person, if he/she exists.  I don't want
> to complicate our code, and thus run the risk of introducing bugs, on
> behalf of a largely imaginary problem, sorry.

I'm sorry if I haven't made myself clear.  Such a person is myself, who,
having installed a pristine copy of Windows 98 in a virtual machine,
cannot find a reassuring copy of USP10.DLL with which to test Emacs, and
is physically removed from the only other machine from which a
functioning copy might be taken.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 15:45:06 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Let's first hear from such a person, if he/she exists.  I don't want
> > to complicate our code, and thus run the risk of introducing bugs, on
> > behalf of a largely imaginary problem, sorry.
> 
> I'm sorry if I haven't made myself clear.  Such a person is myself

No, I mean a real person who has a Windows 98 system they use, without
usp10.dll on it.  As I already wrote, I _was_ such a person, years
ago, and I had usp10.dll on my computer.

I understand that it is easy to remove or rename usp10.dll and trigger
the problem, but I'm not interested in fixing such "artificial"
situations.

I hope I made myself clear this time, and we can stop arguing about
things that I thought were self-evident.

Re: Windows 9X without KernelEx

[Po Lu via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

> If you add usp10.dll (and unicows.dll) to Windows 98, does Emacs start
> then?  Or do any of the other missing APIs prevent it from starting?

I cannot test with USP10.DLL at the moment, but that aside, as I said,
all of the following prevent Emacs from starting on Windows 98:

  Shell_NotifyIconW
  ShellExecuteExW
  SHFileOperationW
  ReadDirectoryChangesW

and none of them are being defined by USP10.DLL, which as I understand
it is only concerned with multilingual text layout.

> We should have discussed this before your writing the code, to prevent
> the unnecessary efforts.  I'm sorry for your wasted time, but I have
> said many times before: this kind of issues should be discussed first.
> I will keep saying that, in the hope that at some point this will
> sink.

I re-read the following twice and considerably moderated its tone, but
it might continue to read as a flame to the sensitive, so, trigger
warning.  In nowise is it meant as a personal reflection on anyone in
this thread, though if anyone who passes by recognizes himself in the
same, he would do well to change his ways.

\f

Had I discussed this before writing the code, and if the same comment
prompted the arbitrary decision to be made of discontinuing support for
the system declared in the README, I would still be disappointed with
the preliminary investigation, initiated on account of several _express_
words in a document bearing every mark of authority and affirming
support for said system, having gone to waste on the back of an offhand
comment by someone uninvolved with the systems in question (which
investigation was decidedly not trivial: locating what appeared to be a
trustworthy symbol list, a system file from a 30-year-old operating
system against which to verify the list, and a host of other sundries
from three decades past, all late at night); and if it is said that I
ought to have asked this question before entering upon any sort of work
in that direction, then there is only one inference to be made, that our
READMEs and FAQs are not to be trusted, as their authors are liable to
change their minds the moment their attention returns to facts they have
previously written.

The truth is that these are matters which affect myself quite strongly,
because it is a recurring pattern in Free Software (and to a lesser
degree, proprietary software) development that has emerged and gained a
sorry amount of currency that when serious deliberations are raised on
any subject touching on support for computer systems, sometimes 3
decades of age, but as easily 5 or 10 years old, or any number of any
unit of time that meets with disapproval from certain quarters, along
come professional commentators from the peanut gallery who derail the
conversation in favor of simply repudiating past commitments that have
been matched both by words and by deeds, without regard for the
tremendous physical and mental investments that their fellow human
beings have put into meeting them, or attempting to intelligently
explore how best to fulfill them in future.  The losers in this game are
the users and the developers, of whom the one are compelled to choose
between the purchase of new hardware and being denied features and bug
fixes from new releases of such programs as they know and love, and the
other are subjected to unremitting abuse, till they relent to the
demands of the mob.  Having been on the receiving side in both roles, I
am naturally intensely motivated to guarantee that everything continues
to function to the only impartial specification, existing, written,
documentation, or otherwise I would have called it a day after restoring
lock files to working order on that one machine.

The latest episode being the Android port.  Any reasonable man would
expect supporting a broad selection of systems produced after 2010 to be
a public service, yet I am called a criminal, and my character is
questioned and assassinated by cowards secure behind the protection of a
SourceForge handle.  All for the cardinal sin of promoting the continued
use of computers featuring less censorship, sabotage, or disobedience
towards their owners, and where vulnerabilities in the OS enable
computer owners to assert their dominion over their own property.

And, though proceedings in this list has been remarkably civil by
comparison with the above, yet their essence dangerously approaches that
of the latter, which is deeply upsetting.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> No, I mean a real person who has a Windows 98 system they use, without
> usp10.dll on it.  As I already wrote, I _was_ such a person, years
> ago, and I had usp10.dll on my computer.
>
> I understand that it is easy to remove or rename usp10.dll and trigger
> the problem, but I'm not interested in fixing such "artificial"
> situations.

A fresh installation of Windows 98 from an image of its official retail
CD-ROM contains _no_ USP10.DLL, and Emacs as it is consequently will not
link.  Hardly artificial, I believe.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 17:39:14 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, I mean a real person who has a Windows 98 system they use, without
> > usp10.dll on it.  As I already wrote, I _was_ such a person, years
> > ago, and I had usp10.dll on my computer.
> >
> > I understand that it is easy to remove or rename usp10.dll and trigger
> > the problem, but I'm not interested in fixing such "artificial"
> > situations.
> 
> A fresh installation of Windows 98 from an image of its official retail
> CD-ROM contains _no_ USP10.DLL, and Emacs as it is consequently will not
> link.  Hardly artificial, I believe.

Please reread what I wrote in previous messages, I think I explained
why we can expect usp10.dll to be available on any Windows 98 system
that is in actual use.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Please reread what I wrote in previous messages, I think I explained
> why we can expect usp10.dll to be available on any Windows 98 system
> that is in actual use.

So far as existing installations that we're aware of are concerned, this
is true.  Hence I'm not insisting on the Uniscribe change appearing in
Emacs 30, but what is the harm in applying it to Emacs 31?  By your own
admission, Uniscribe is supposed to be obsolete, and the change will
enables at least myself to test Emacs without being required to manage a
private "DLL hell" or install Windoze Internet Exploder, whose Unix
edition has already given me enough grief for a lifetime.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 21:10:37 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please reread what I wrote in previous messages, I think I explained
> > why we can expect usp10.dll to be available on any Windows 98 system
> > that is in actual use.
> 
> So far as existing installations that we're aware of are concerned, this
> is true.  Hence I'm not insisting on the Uniscribe change appearing in
> Emacs 30, but what is the harm in applying it to Emacs 31?  By your own
> admission, Uniscribe is supposed to be obsolete, and the change will
> enables at least myself to test Emacs without being required to manage a
> private "DLL hell" or install Windoze Internet Exploder, whose Unix
> edition has already given me enough grief for a lifetime.

I'm not interested in complicating our code even a bit on behalf of
this non-problem.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not interested in complicating our code even a bit on behalf of
> this non-problem.

Testing Emacs on Windows is scarcely a non-problem.  Anyway, if I cannot
change your mind, I hope you won't object to my uploading the patch to a
feature branch, or providing it as a series of patches in nt?  Perhaps
we shall see precisely how insignificant the excess complexity is.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 17:35:45 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you add usp10.dll (and unicows.dll) to Windows 98, does Emacs start
> > then?  Or do any of the other missing APIs prevent it from starting?
> 
> I cannot test with USP10.DLL at the moment, but that aside, as I said,
> all of the following prevent Emacs from starting on Windows 98:
> 
>   Shell_NotifyIconW
>   ShellExecuteExW
>   SHFileOperationW
>   ReadDirectoryChangesW

This is strange.  Most of those are present in Emacs for a long time,
and I was somehow under the impression that Emacs did start on Windows
9X after their introduction.  Did you start Emacs with UNICOWS.DLL
available?  My references indicate that UNICOWS.DLL has the first 3 of
the above 4 APIs.  So I'd suggest to do for these 3 what we do for
MultiByteToWideChar, see w32.c:maybe_load_unicows_dll, and then see if
the problem is solved.  If that doesn't solve the problem,
i.e. doesn't allow Emacs to start, we can discuss what to do about
each of these 3 APIs.

ReadDirectoryChangesW is indeed absent from UNICOWS.DLL, so I think
globals_of_w32notify should attempt to load it, and if not available,
disable the file notifications by modifying the code we already have
in w32notify-add-watch:

  /* The underlying features are available only since XP.  */
  if (os_subtype == OS_SUBTYPE_9X
      || (w32_major_version == 5 && w32_minor_version < 1))
    {
      errno = ENOSYS;
      report_file_notify_error ("Watching filesystem events is not supported",
				Qnil);
    }

> > We should have discussed this before your writing the code, to prevent
> > the unnecessary efforts.  I'm sorry for your wasted time, but I have
> > said many times before: this kind of issues should be discussed first.
> > I will keep saying that, in the hope that at some point this will
> > sink.
> 
> I re-read the following twice and considerably moderated its tone, but
> it might continue to read as a flame to the sensitive, so, trigger
> warning.  In nowise is it meant as a personal reflection on anyone in
> this thread, though if anyone who passes by recognizes himself in the
> same, he would do well to change his ways.

I don't think what you wrote there is relevant here, sorry.  (We
definitely cannot be responsible for what nasty things people say on
SourceForge or in other forums.)

In general, any non-trivial work on something that is meant to improve
Emacs support for very old systems should be discussed first, even
before any significant research, to avoid waste of time and efforts.
I think we should limit such support to the minimum: what worked there
should continue working, and if some code prevents Emacs from starting
or being a useful editor there, we should fix that as simply and
safely as possible.

I cannot possibly prevent people from investing significant efforts
before starting a discussion, but then I cannot guarantee that we will
accept the resulting code changes, and so the risk of wasting those
efforts will be greater.

FTR, I still have on my system old files and system directories from
Windows 9X and from XP, and can at least explore what they exported
using 'pexports' and the likes.  I alsi have a list of symbols
exported by UNCOWS.DLL and an old Win32 API documentation which
indicates which APIs were available on Windows 9X.  So if you need to
do similar research in the future, you could ask me first.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 15 Jun 2024 17:35:45 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > If you add usp10.dll (and unicows.dll) to Windows 98, does Emacs start
>> > then?  Or do any of the other missing APIs prevent it from starting?
>> 
>> I cannot test with USP10.DLL at the moment, but that aside, as I said,
>> all of the following prevent Emacs from starting on Windows 98:
>> 
>>   Shell_NotifyIconW
>>   ShellExecuteExW
>>   SHFileOperationW
>>   ReadDirectoryChangesW
>
> This is strange.  Most of those are present in Emacs for a long time,

Perhaps everyone else had installed KernelEx?

> and I was somehow under the impression that Emacs did start on Windows
> 9X after their introduction.  Did you start Emacs with UNICOWS.DLL
> available?

I did, indeed.  But -lunicows is absent from the linker command line, so
emacs.exe is required to load the library, and its exports into function
pointers, at runtime, and I don't understand how symbol conflicts
between it and OS exports on NT systems are resolved.

> My references indicate that UNICOWS.DLL has the first 3 of the above 4
> APIs.  So I'd suggest to do for these 3 what we do for
> MultiByteToWideChar, see w32.c:maybe_load_unicows_dll, and then see if
> the problem is solved.  If that doesn't solve the problem,
> i.e. doesn't allow Emacs to start, we can discuss what to do about
> each of these 3 APIs.

The issue is that these functions don't appear to be defined elsewhere
than UNICOWS.DLL, even as stubs, with the result that they must be
loaded at runtime, from SHELL32/USER32.DLL, or the runtime link editor
(what is the proper nomenclature for this component on Windows?) will
fail to locate symbols imported by emacs.exe.  Which is all taken care
of in the patch I posted.

> ReadDirectoryChangesW is indeed absent from UNICOWS.DLL, so I think
> globals_of_w32notify should attempt to load it, and if not available,

This is taken care of in the patch, though in a new function, which
could be consolidated into globals_of_w32notify if it is run during
startup in dumped Emacs binaries.

> disable the file notifications by modifying the code we already have
> in w32notify-add-watch:
>
>   /* The underlying features are available only since XP.  */
>   if (os_subtype == OS_SUBTYPE_9X
>       || (w32_major_version == 5 && w32_minor_version < 1))
>     {
>       errno = ENOSYS;
>       report_file_notify_error ("Watching filesystem events is not supported",
> 				Qnil);
>     }

What's to be modified here?  `os_subtype == OS_SUBTYPE_9X' should
address all the 9X systems, right?

Finally, how say you to the change to w32_init_file_name_codepage?  It
is required to run binaries on 9X that are dumped on NT, and in its
absence, w32_unicode_filenames and is_windows_9x both return FALSE
during the early stages of initialization.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 22:18:23 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>   Shell_NotifyIconW
> >>   ShellExecuteExW
> >>   SHFileOperationW
> >>   ReadDirectoryChangesW
> >
> > This is strange.  Most of those are present in Emacs for a long time,
> 
> Perhaps everyone else had installed KernelEx?

It was you who ran Emacs on those systems, so you should ask yourself.
Maybe every Windows 9X system that is in real use does indeed have
KernelEx and whatever else is needed, because both IE and Office are
known to bring such system DLLs with them.

> > and I was somehow under the impression that Emacs did start on Windows
> > 9X after their introduction.  Did you start Emacs with UNICOWS.DLL
> > available?
> 
> I did, indeed.  But -lunicows is absent from the linker command line, so
> emacs.exe is required to load the library, and its exports into function
> pointers, at runtime, and I don't understand how symbol conflicts
> between it and OS exports on NT systems are resolved.

The way it's supposed to be resolved is that the system DLLs on
Windows 9X are supposed to have these symbols, whose implementations
are stubs that do nothing or fail.  This is clearly stated, for
example, in this comment in w32font.c:

  /* Several "wide" functions we use to support the font backends are
     unavailable on Windows 9X, unless UNICOWS.DLL is installed (their
     versions in the default libraries are non-functional stubs).  On NT
     and later systems, these functions are in GDI32.DLL.  The following
     helper function attempts to load UNICOWS.DLL on Windows 9X, and
     refuses to let Emacs start up if that library is not found.  On NT
     and later versions, it simply loads GDI32.DLL, which should always
     be available.  */
  static HMODULE
  w32_load_unicows_or_gdi32 (void)
  {
    return maybe_load_unicows_dll ();
  }

So I think we are missing something here, because this clearly used to
work in the past, on real Windows 9X systems.

> > My references indicate that UNICOWS.DLL has the first 3 of the above 4
> > APIs.  So I'd suggest to do for these 3 what we do for
> > MultiByteToWideChar, see w32.c:maybe_load_unicows_dll, and then see if
> > the problem is solved.  If that doesn't solve the problem,
> > i.e. doesn't allow Emacs to start, we can discuss what to do about
> > each of these 3 APIs.
> 
> The issue is that these functions don't appear to be defined elsewhere
> than UNICOWS.DLL, even as stubs, with the result that they must be
> loaded at runtime

See above: that's not what our (very old) comments say to me.

> > ReadDirectoryChangesW is indeed absent from UNICOWS.DLL, so I think
> > globals_of_w32notify should attempt to load it, and if not available,
> 
> This is taken care of in the patch, though in a new function, which
> could be consolidated into globals_of_w32notify if it is run during
> startup in dumped Emacs binaries.

Like I said: let's discuss each issue separately, not as a single
large patch which attempts to resolve several issues.

> > disable the file notifications by modifying the code we already have
> > in w32notify-add-watch:
> >
> >   /* The underlying features are available only since XP.  */
> >   if (os_subtype == OS_SUBTYPE_9X
> >       || (w32_major_version == 5 && w32_minor_version < 1))
> >     {
> >       errno = ENOSYS;
> >       report_file_notify_error ("Watching filesystem events is not supported",
> > 				Qnil);
> >     }
> 
> What's to be modified here?

I'd add the condition that ReadDirectoryChangesW couldn't be loaded
from UNICOWS.DLL.  Maybe.

> Finally, how say you to the change to w32_init_file_name_codepage?  It
> is required to run binaries on 9X that are dumped on NT, and in its
> absence, w32_unicode_filenames and is_windows_9x both return FALSE
> during the early stages of initialization.

I don't think I understand the issue.  Which static variables are not
reinitialized at startup and cause the above?  I see that globals_of_w
is unconditionally called during startup, and resets
g_b_init_is_windows_9x to zero; it thereafter calls is_windows_9x and
sets w32_unicode_filenames to zero on Windows 9X.  So I don't think I
understand the problem.  What did I miss?

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> It was you who ran Emacs on those systems, so you should ask yourself.
> Maybe every Windows 9X system that is in real use does indeed have
> KernelEx and whatever else is needed, because both IE and Office are
> known to bring such system DLLs with them.

Perhaps this is so, but I cannot be expected to reproduce 1:1 a PC that
has stood beneath a desk handling confidential information, and which
has been in continuous service, since 2008, in a virtual machine.

>> > and I was somehow under the impression that Emacs did start on
>> > Windows
>> > 9X after their introduction.  Did you start Emacs with UNICOWS.DLL
>> > available?
>> 
>> I did, indeed.  But -lunicows is absent from the linker command
>> line, so
>> emacs.exe is required to load the library, and its exports into
>> function
>> pointers, at runtime, and I don't understand how symbol conflicts
>> between it and OS exports on NT systems are resolved.
>
> The way it's supposed to be resolved is that the system DLLs on
> Windows 9X are supposed to have these symbols, whose implementations
> are stubs that do nothing or fail.  This is clearly stated, for
> example, in this comment in w32font.c:
>
>   /* Several "wide" functions we use to support the font backends are
>      unavailable on Windows 9X, unless UNICOWS.DLL is installed (their
>      versions in the default libraries are non-functional stubs).  On NT
>      and later systems, these functions are in GDI32.DLL.  The following
>      helper function attempts to load UNICOWS.DLL on Windows 9X, and
>      refuses to let Emacs start up if that library is not found.  On NT
>      and later versions, it simply loads GDI32.DLL, which should always
>      be available.  */
>   static HMODULE
>   w32_load_unicows_or_gdi32 (void)
>   {
>     return maybe_load_unicows_dll ();
>   }
>
> So I think we are missing something here, because this clearly used to
> work in the past, on real Windows 9X systems.

Yes, that's strange.  Is the comment meant to apply to all DLLs, or just
GDI32.DLL?

>> > My references indicate that UNICOWS.DLL has the first 3 of the
>> > above 4
>> > APIs.  So I'd suggest to do for these 3 what we do for
>> > MultiByteToWideChar, see w32.c:maybe_load_unicows_dll, and then
>> > see if
>> > the problem is solved.  If that doesn't solve the problem,
>> > i.e. doesn't allow Emacs to start, we can discuss what to do about
>> > each of these 3 APIs.
>> 
>> The issue is that these functions don't appear to be defined
>> elsewhere
>> than UNICOWS.DLL, even as stubs, with the result that they must be
>> loaded at runtime
>
> See above: that's not what our (very old) comments say to me.
>
>> > ReadDirectoryChangesW is indeed absent from UNICOWS.DLL, so I
>> > think
>> > globals_of_w32notify should attempt to load it, and if not
>> > available,
>> 
>> This is taken care of in the patch, though in a new function, which
>> could be consolidated into globals_of_w32notify if it is run during
>> startup in dumped Emacs binaries.
>
> Like I said: let's discuss each issue separately, not as a single
> large patch which attempts to resolve several issues.
>
>> > disable the file notifications by modifying the code we already have
>> > in w32notify-add-watch:
>> >
>> >   /* The underlying features are available only since XP.  */
>> >   if (os_subtype == OS_SUBTYPE_9X
>> >       || (w32_major_version == 5 && w32_minor_version < 1))
>> >     {
>> >       errno = ENOSYS;
>> >       report_file_notify_error ("Watching filesystem events is not supported",
>> > 				Qnil);
>> >     }
>> 
>> What's to be modified here?
>
> I'd add the condition that ReadDirectoryChangesW couldn't be loaded
> from UNICOWS.DLL.  Maybe.

Is that possible on NT?

>> Finally, how say you to the change to w32_init_file_name_codepage?
>> It
>> is required to run binaries on 9X that are dumped on NT, and in its
>> absence, w32_unicode_filenames and is_windows_9x both return FALSE
>> during the early stages of initialization.
>
> I don't think I understand the issue.  Which static variables are not
> reinitialized at startup and cause the above?  I see that globals_of_w
> is unconditionally called during startup, and resets
> g_b_init_is_windows_9x to zero; it thereafter calls is_windows_9x and
> sets w32_unicode_filenames to zero on Windows 9X.  So I don't think I
> understand the problem.  What did I miss?

w32_init_current_directory is called before globals_of_w32, and acts
upon values set on the build machine.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 15 Jun 2024 23:15:23 +0800
> 
> > The way it's supposed to be resolved is that the system DLLs on
> > Windows 9X are supposed to have these symbols, whose implementations
> > are stubs that do nothing or fail.  This is clearly stated, for
> > example, in this comment in w32font.c:
> >
> >   /* Several "wide" functions we use to support the font backends are
> >      unavailable on Windows 9X, unless UNICOWS.DLL is installed (their
> >      versions in the default libraries are non-functional stubs).  On NT
> >      and later systems, these functions are in GDI32.DLL.  The following
> >      helper function attempts to load UNICOWS.DLL on Windows 9X, and
> >      refuses to let Emacs start up if that library is not found.  On NT
> >      and later versions, it simply loads GDI32.DLL, which should always
> >      be available.  */
> >   static HMODULE
> >   w32_load_unicows_or_gdi32 (void)
> >   {
> >     return maybe_load_unicows_dll ();
> >   }
> >
> > So I think we are missing something here, because this clearly used to
> > work in the past, on real Windows 9X systems.
> 
> Yes, that's strange.  Is the comment meant to apply to all DLLs, or just
> GDI32.DLL?

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.

> > I'd add the condition that ReadDirectoryChangesW couldn't be loaded
> > from UNICOWS.DLL.  Maybe.
> 
> Is that possible on NT?

Maybe.  My references say it's available even in Windows NT, though.

> >> Finally, how say you to the change to w32_init_file_name_codepage?
> >> It
> >> is required to run binaries on 9X that are dumped on NT, and in its
> >> absence, w32_unicode_filenames and is_windows_9x both return FALSE
> >> during the early stages of initialization.
> >
> > I don't think I understand the issue.  Which static variables are not
> > reinitialized at startup and cause the above?  I see that globals_of_w
> > is unconditionally called during startup, and resets
> > g_b_init_is_windows_9x to zero; it thereafter calls is_windows_9x and
> > sets w32_unicode_filenames to zero on Windows 9X.  So I don't think I
> > understand the problem.  What did I miss?
> 
> w32_init_current_directory is called before globals_of_w32, and acts
> upon values set on the build machine.

What prevents us from calling globals_of_w32 before
w32_init_current_directory?

Re: Windows 9X without KernelEx

[Po Lu]

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.

> 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.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> 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.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> Date: Sun, 16 Jun 2024 08:36:28 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: stefankangas@gmail.com, emacs-devel@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.

I know why we dropped it: MinGW GCC adds -lshell32 by default, see
"gcc -dumpspecs".  But maybe you are using an old GCC version which
doesn't or something?  If you add "-v" to the link command line, do
you see "-lshell32" in the command printed by GCC?

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I know why we dropped it: MinGW GCC adds -lshell32 by default, see
> "gcc -dumpspecs".  But maybe you are using an old GCC version which
> doesn't or something?  If you add "-v" to the link command line, do
> you see "-lshell32" in the command printed by GCC?

Yes, I do, and also in the compiler's specs:

*lib:
[... ] -ladvapi32 -lshell32 -luser32 -lkernel32

I'll try to `make bootstrap', which I've been desperately avoiding on
Windows, where make is excruciatingly slow.

Re: Windows 9X without KernelEx

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> I'll try to `make bootstrap', which I've been desperately avoiding on
> Windows, where make is excruciatingly slow.

This did the trick, leaving only USP10, globals_of_w32, and
ReadDirectoryChangesW.  I think I'll postpone these to the next weekend.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 16 Jun 2024 19:34:29 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > I'll try to `make bootstrap', which I've been desperately avoiding on
> > Windows, where make is excruciatingly slow.
> 
> This did the trick, leaving only USP10, globals_of_w32, and
> ReadDirectoryChangesW.  I think I'll postpone these to the next weekend.

OK, thanks.  One mystery less is always a Good Thing...

Re: Windows 9X without KernelEx

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> I'll try to `make bootstrap', which I've been desperately avoiding on
>> Windows, where make is excruciatingly slow.
>
> This did the trick, leaving only USP10, globals_of_w32, and
> ReadDirectoryChangesW.  I think I'll postpone these to the next weekend.

I pushed changes to load functions defined in UNICOWS.DLL from that DLL
on Windows 9X systems, and other adjustments affecting USP10,
globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
possible that they should impact the Cygwin build, which I can't test.

Therefore, would you please arrange that this message fall on the right
ears for the contents of the branch to be tested in this configuration?

Thanks.

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 23 Jun 2024 16:35:34 +0800
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Po Lu <luangruo@yahoo.com> writes:
> >
> >> I'll try to `make bootstrap', which I've been desperately avoiding on
> >> Windows, where make is excruciatingly slow.
> >
> > This did the trick, leaving only USP10, globals_of_w32, and
> > ReadDirectoryChangesW.  I think I'll postpone these to the next weekend.
> 
> I pushed changes to load functions defined in UNICOWS.DLL from that DLL
> on Windows 9X systems, and other adjustments affecting USP10,
> globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
> possible that they should impact the Cygwin build, which I can't test.
> 
> Therefore, would you please arrange that this message fall on the right
> ears for the contents of the branch to be tested in this configuration?

That would be Ken and Corwin, I believe.

Re: Windows 9X without KernelEx

[Ken Brown]

On 6/23/2024 5:16 AM, Eli Zaretskii wrote:
>> From: Po Lu <luangruo@yahoo.com>
>> I pushed changes to load functions defined in UNICOWS.DLL from that DLL
>> on Windows 9X systems, and other adjustments affecting USP10,
>> globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
>> possible that they should impact the Cygwin build, which I can't test.
>>
>> Therefore, would you please arrange that this message fall on the right
>> ears for the contents of the branch to be tested in this configuration?
> 
> That would be Ken and Corwin, I believe.

Builds fine on Cygwin.

Ken

Re: Windows 9X without KernelEx

[Eli Zaretskii]

> Date: Sun, 23 Jun 2024 16:25:13 -0400
> Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> From: Ken Brown <kbrown@cornell.edu>
> 
> On 6/23/2024 5:16 AM, Eli Zaretskii wrote:
> >> From: Po Lu <luangruo@yahoo.com>
> >> I pushed changes to load functions defined in UNICOWS.DLL from that DLL
> >> on Windows 9X systems, and other adjustments affecting USP10,
> >> globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
> >> possible that they should impact the Cygwin build, which I can't test.
> >>
> >> Therefore, would you please arrange that this message fall on the right
> >> ears for the contents of the branch to be tested in this configuration?
> > 
> > That would be Ken and Corwin, I believe.
> 
> Builds fine on Cygwin.

Thanks.

Re: Windows 9X without KernelEx

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 23 Jun 2024 16:25:13 -0400
>> Cc: stefankangas@gmail.com, emacs-devel@gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>> 
>> On 6/23/2024 5:16 AM, Eli Zaretskii wrote:
>> >> From: Po Lu <luangruo@yahoo.com>
>> >> I pushed changes to load functions defined in UNICOWS.DLL from that DLL
>> >> on Windows 9X systems, and other adjustments affecting USP10,
>> >> globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
>> >> possible that they should impact the Cygwin build, which I can't test.
>> >>
>> >> Therefore, would you please arrange that this message fall on the right
>> >> ears for the contents of the branch to be tested in this configuration?
>> > 
>> > That would be Ken and Corwin, I believe.
>> 
>> Builds fine on Cygwin.
>
> Thanks.

I would like to know whether it also runs correctly?  I.e., evaluate:

  (set-frame-parameter nil 'font-backend "uniscribe")

and establish whether this font backend is really enabled, and also test
Fw32_shell_execute, for which I can't provide any more sophisticated or
specific instructions, sorry...

Thanks in advance.

Re: Windows 9X without KernelEx

[Ken Brown]

On 6/23/2024 4:25 PM, Ken Brown wrote:
> On 6/23/2024 5:16 AM, Eli Zaretskii wrote:
>>> From: Po Lu <luangruo@yahoo.com>
>>> I pushed changes to load functions defined in UNICOWS.DLL from that DLL
>>> on Windows 9X systems, and other adjustments affecting USP10,
>>> globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
>>> possible that they should impact the Cygwin build, which I can't test.
>>>
>>> Therefore, would you please arrange that this message fall on the right
>>> ears for the contents of the branch to be tested in this configuration?
>>
>> That would be Ken and Corwin, I believe.
> 
> Builds fine on Cygwin.

Sorry, I spoke too soon.  Without thinking, I did the default (GTK3) 
build, which is what I always do.  Obviously I should have done the 
Cygwin-w32 build (configure option --with-w32).  I've done that now, and 
the build fails as follows:

   CC       w32uniscribe.o
../../src/w32uniscribe.c: In function ‘syms_of_w32uniscribe_for_pdumper’:
../../src/w32uniscribe.c:1577:20: error: ‘uniscribe’ undeclared (first 
use in this function); did you mean ‘Quniscribe’?
  1577 |     get_proc_addr (uniscribe, "ScriptGetFontScriptTags");
       |                    ^~~~~~~~~
       |                    Quniscribe
../../src/w32uniscribe.c:1577:20: note: each undeclared identifier is 
reported only once for each function it appears in
make[2]: *** [Makefile:457: w32uniscribe.o] Error 1

The Cygwin-w32 build succeeds on master.

Ken

Re: Windows 9X without KernelEx

[Ken Brown]

On 6/24/2024 1:17 PM, Ken Brown wrote:
> On 6/23/2024 4:25 PM, Ken Brown wrote:
>> On 6/23/2024 5:16 AM, Eli Zaretskii wrote:
>>>> From: Po Lu <luangruo@yahoo.com>
>>>> I pushed changes to load functions defined in UNICOWS.DLL from that DLL
>>>> on Windows 9X systems, and other adjustments affecting USP10,
>>>> globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
>>>> possible that they should impact the Cygwin build, which I can't test.
>>>>
>>>> Therefore, would you please arrange that this message fall on the right
>>>> ears for the contents of the branch to be tested in this configuration?
>>>
>>> That would be Ken and Corwin, I believe.
>>
>> Builds fine on Cygwin.
> 
> Sorry, I spoke too soon.  Without thinking, I did the default (GTK3) 
> build, which is what I always do.  Obviously I should have done the 
> Cygwin-w32 build (configure option --with-w32).  I've done that now, and 
> the build fails as follows:
> 
>    CC       w32uniscribe.o
> ../../src/w32uniscribe.c: In function ‘syms_of_w32uniscribe_for_pdumper’:
> ../../src/w32uniscribe.c:1577:20: error: ‘uniscribe’ undeclared (first 
> use in this function); did you mean ‘Quniscribe’?
>   1577 |     get_proc_addr (uniscribe, "ScriptGetFontScriptTags");
>        |                    ^~~~~~~~~
>        |                    Quniscribe
> ../../src/w32uniscribe.c:1577:20: note: each undeclared identifier is 
> reported only once for each function it appears in
> make[2]: *** [Makefile:457: w32uniscribe.o] Error 1

I guess the problem is pretty obvious.  You just have to move "#ifdef 
WINDOWSNT" at line 1541 down a few lines.

Ken

Re: Windows 9X without KernelEx

[Corwin Brust]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Mon, Jun 24, 2024, 03:30 Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 23 Jun 2024 16:25:13 -0400
> > Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> > From: Ken Brown <kbrown@cornell.edu>
> >
> > On 6/23/2024 5:16 AM, Eli Zaretskii wrote:
> > >> From: Po Lu <luangruo@yahoo.com>
>
> > >> Therefore, would you please arrange that this message fall on the
> right
> > >> ears for the contents of the branch to be tested in this
> configuration?
> > >
> > > That would be Ken and Corwin, I believe.
> >
> > Builds fine on Cygwin.
>
> Thanks.
>

FTR I have been following this thread but am traveling internationally
without any Windows PC.  I look forward to trying out the branch.

>
>

[-- Attachment #2: Type: text/html, Size: 1594 bytes --]

Re: Windows 9X without KernelEx

[Ken Brown]

On 6/24/2024 6:11 PM, Ken Brown wrote:
> On 6/24/2024 1:17 PM, Ken Brown wrote:
>> On 6/23/2024 4:25 PM, Ken Brown wrote:
>>> On 6/23/2024 5:16 AM, Eli Zaretskii wrote:
>>>>> From: Po Lu <luangruo@yahoo.com>
>>>>> I pushed changes to load functions defined in UNICOWS.DLL from that 
>>>>> DLL
>>>>> on Windows 9X systems, and other adjustments affecting USP10,
>>>>> globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
>>>>> possible that they should impact the Cygwin build, which I can't test.
>>>>>
>>>>> Therefore, would you please arrange that this message fall on the 
>>>>> right
>>>>> ears for the contents of the branch to be tested in this 
>>>>> configuration?
>>>>
>>>> That would be Ken and Corwin, I believe.
>>>
>>> Builds fine on Cygwin.
>>
>> Sorry, I spoke too soon.  Without thinking, I did the default (GTK3) 
>> build, which is what I always do.  Obviously I should have done the 
>> Cygwin-w32 build (configure option --with-w32).  I've done that now, 
>> and the build fails as follows:
>>
>>    CC       w32uniscribe.o
>> ../../src/w32uniscribe.c: In function ‘syms_of_w32uniscribe_for_pdumper’:
>> ../../src/w32uniscribe.c:1577:20: error: ‘uniscribe’ undeclared (first 
>> use in this function); did you mean ‘Quniscribe’?
>>   1577 |     get_proc_addr (uniscribe, "ScriptGetFontScriptTags");
>>        |                    ^~~~~~~~~
>>        |                    Quniscribe
>> ../../src/w32uniscribe.c:1577:20: note: each undeclared identifier is 
>> reported only once for each function it appears in
>> make[2]: *** [Makefile:457: w32uniscribe.o] Error 1
> 
> I guess the problem is pretty obvious.  You just have to move "#ifdef 
> WINDOWSNT" at line 1541 down a few lines.

With that correction it builds fine, and uniscribe and w32-shell-execute 
work as expected.

Ken

Re: Windows 9X without KernelEx

[Po Lu]

Ken Brown <kbrown@cornell.edu> writes:

> On 6/24/2024 1:17 PM, Ken Brown wrote:
>> On 6/23/2024 4:25 PM, Ken Brown wrote:
>>> On 6/23/2024 5:16 AM, Eli Zaretskii wrote:
>>>>> From: Po Lu <luangruo@yahoo.com>
>>>>> I pushed changes to load functions defined in UNICOWS.DLL from that DLL
>>>>> on Windows 9X systems, and other adjustments affecting USP10,
>>>>> globals_of_w32 and ReadDirectoryChangesW to scratch/windows-98.  It is
>>>>> possible that they should impact the Cygwin build, which I can't test.
>>>>>
>>>>> Therefore, would you please arrange that this message fall on the right
>>>>> ears for the contents of the branch to be tested in this configuration?
>>>>
>>>> That would be Ken and Corwin, I believe.
>>>
>>> Builds fine on Cygwin.
>> Sorry, I spoke too soon.  Without thinking, I did the default (GTK3)
>> build, which is what I always do.  Obviously I should have done the
>> Cygwin-w32 build (configure option --with-w32).  I've done that now,
>> and the build fails as follows:
>>    CC       w32uniscribe.o
>> ../../src/w32uniscribe.c: In function ‘syms_of_w32uniscribe_for_pdumper’:
>> ../../src/w32uniscribe.c:1577:20: error: ‘uniscribe’ undeclared
>> (first use in this function); did you mean ‘Quniscribe’?
>>   1577 |     get_proc_addr (uniscribe, "ScriptGetFontScriptTags");
>>        |                    ^~~~~~~~~
>>        |                    Quniscribe
>> ../../src/w32uniscribe.c:1577:20: note: each undeclared identifier
>> is reported only once for each function it appears in
>> make[2]: *** [Makefile:457: w32uniscribe.o] Error 1
>
> I guess the problem is pretty obvious.  You just have to move "#ifdef
> WINDOWSNT" at line 1541 down a few lines.
>
> Ken

Please try again.

Re: Windows 9X without KernelEx

[Ken Brown]

On 6/26/2024 9:59 PM, Po Lu wrote:
> Ken Brown <kbrown@cornell.edu> writes:
>>
>> I guess the problem is pretty obvious.  You just have to move "#ifdef
>> WINDOWSNT" at line 1541 down a few lines.
>>
>> Ken
> 
> Please try again.

You're testing 'uniscribe' before it's been assigned a value:

   /* Don't register if Uniscribe is not available.  */
   HMODULE uniscribe;
   if (!uniscribe)
     return;

Ken

Re: Windows 9X without KernelEx

[Po Lu]

Ken Brown <kbrown@cornell.edu> writes:

> On 6/26/2024 9:59 PM, Po Lu wrote:
>> Ken Brown <kbrown@cornell.edu> writes:
>>>
>>> I guess the problem is pretty obvious.  You just have to move "#ifdef
>>> WINDOWSNT" at line 1541 down a few lines.
>>>
>>> Ken
>> Please try again.
>
> You're testing 'uniscribe' before it's been assigned a value:
>
>   /* Don't register if Uniscribe is not available.  */
>   HMODULE uniscribe;
>   if (!uniscribe)
>     return;
>
> Ken

Right.  In my defense it is fairly challenging to cut and paste text on
a phone.

Re: Windows 9X without KernelEx

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Right.  In my defense it is fairly challenging to cut and paste text on
> a phone.

Might I trouble you to test this again?

Re: Windows 9X without KernelEx

[Ken Brown]

On 6/27/2024 9:47 AM, Po Lu wrote:
> Po Lu <luangruo@yahoo.com> writes:
> 
>> Right.  In my defense it is fairly challenging to cut and paste text on
>> a phone.
> 
> Might I trouble you to test this again?

The Cygwin-w32 build now succeeds and appears to run as expected.  I 
tested the uniscribe functionality and w32-shell-execute.

Ken

Re: Windows 9X without KernelEx

[Po Lu]

Ken Brown <kbrown@cornell.edu> writes:

> On 6/27/2024 9:47 AM, Po Lu wrote:
>> Po Lu <luangruo@yahoo.com> writes:
>> 
>>> Right.  In my defense it is fairly challenging to cut and paste text on
>>> a phone.
>> Might I trouble you to test this again?
>
> The Cygwin-w32 build now succeeds and appears to run as expected.  I
> tested the uniscribe functionality and w32-shell-execute.
>
> Ken

Thanks, merged into emacs-30.