bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57386: 29.0.50; support make-symbolic-link without admin priviledge


From: Eli Zaretskii
Subject: bug#57386: 29.0.50; support make-symbolic-link without admin priviledge on Windows
Date: Thu, 25 Aug 2022 12:09:10 +0300

> From: Kiên Nguyễn Quang <kien.n.quang@gmail.com>
> Date: Thu, 25 Aug 2022 17:52:50 +0900
> Cc: 57386@debbugs.gnu.org
> 
>  That's a separate problem, which we will resolve if and when it
>  becomes relevant.  For now, this problem doesn't exist, since AFAIK
>  there are no features yet which we want to use that are available only
>  in Windows 11 and later.  So please assume that version checks in
>  Emacs are reliable, and always will be, no matter what MS says about
>  that.
> 
>  Thanks.
> 
> The new flag is available starting from Windows 10 Creator update, which 
> means two (or 3? I don't know)
> updates after the first Windows 10 release.
> Since the version returned for all Windows 10 are the same, you see, that's 
> the problem.

If that's the problem (is anyone who has Windows 10 still likely to
use those old releases, given the automatic updates in Windows 10 that
cannot be turned off? and if they do, do they indeed get
ERROR_INVALID_PARAMETER?), we can handle that as well.  We have
already an API for accessing the Registry (see w32-read-registry and
its C counterpart w32_read_registry), and report-emacs-bug already
uses it to obtain the full description of the version, the build
number and all.  If needed, we can use a similar technique to make an
accurate version test.

> I think the error is already caught and should be replaced with the new one 
> if we retry calling the API, can you
> elaborate more on how it can still affect Emacs?

When you call an API with a parameter that is invalid, you are risking
an exception, depending on the API and the build (debug or not).  This
has various unpleasant consequences; in the worst case, the Emacs
process could be terminated.  As documented, the problem is limited to
CRT functions, but our general policy is to avoid that even when using
the Win32 APIs.  And version check is a simple enough way of avoiding
that, so I see no reason not to do it here.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]