Re: [RFA] Fix cygwin compilation failure due to nameless LOAD_DLL_DEBUG_EVENT causes ntdll.dll to be missing

[Corinna Vinschen <vinschen@redhat.com>]

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

On Dec 18 17:45, Eli Zaretskii wrote:
> > Date: Wed, 18 Dec 2013 12:20:45 +0100
> > From: Corinna Vinschen <vinschen@redhat.com>
> > 
> > In theory, you should never use the ANSI API on Windows, unless you're
> > still building GDB for Windows 9x, which should be really, really dead
> > by now, hopefully.
> 
> Did we decide to drop Windows 9X support?  Unicode APIs will not work
> on Windows 9X (in fact, I think Windows will refuse to run such a
> gdb.exe), unless we link against unicows.dll.

I didn't say that.  I said I *hoped* that 9x is dead by now.

> > - The ANSI API only supports a single- or doublebyte codeset in almost
> >   all language versions of Windows.  There are only a handful languages
> >   which are using UTF-8 as ANSI codeset on Windows, most use something
> >   like CP1252 or some other codeset which is not capable of handling all
> >   UNICODE characters.
> > 
> > - The ANSI API restricts filenames to MAX_PATH (260) characters, while
> >   the UNICODE API and the underlying OS allow paths of up to 32K.
> 
> But the MinGW build of GDB is still in the ANSI codepage world, and
> will probably remain there for the observable future, because Windows
> runtime and file APIs don't understand UTF-8 encoding,

They do understand UNICODE if you use the wide char functions.

> and switching
> to wchar_t everywhere in GDB is unthinkable.  So unless someone
> volunteers to provide wrappers for all the library functions GDB calls
> that accept or return file names, and make those wrappers accept UTF-8
> encoded file names, we are stuck.

For a start it might be feasible to use the already existing UNICODE
code in windows-nat.c.  Implementing wrappers for the msvcrt functions
used elsewhere in the code at one point shouldn't be that hard, just
a bit of boring work.

> > Cygwin is using the UNICODE and native NT APIs exclusively
> 
> Sure, but Cygwin uses its own runtime.
> 
> > so paths in Cygwin are only restricted by the maximum OS capability
> > of 32K, and the influence of the PATH_MAX setting of 4096.
> 
> Are you sure that 32K capability cannot be had with ANSI file names
> using the \\?\ notation?

Yes.  The \\?\ notation only works in the UNICODE API[*].  The reason
is that the ANSI API is just a thin layer over the actual UNICODE
functionality, and the conversion from ANSI to UNICODE is done using a
per-thread fixed-size buffer of 520 bytes.  The ANSI API is really
something which should be avoided these days.


Corinna

[*] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]