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

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Wed, 18 Dec 2013 17:07:07 +0100
> From: Corinna Vinschen <vinschen@redhat.com>
> 
> 
> [1:text/plain Hide]
> 
> 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.

It's still widely used in some parts of the world, I'm told.

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

That requires conversion back and forth, something best done in
wrapper functions, because otherwise we will need ugly ifdef's all
over the place.

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

Well, I just came up from such boring work (in Emacs), and I can tell
you it's nowhere near "a bit".  Maybe someone who can work on this
full-time could do this quickly, but there's no such person on board
for MinGW GDB at this time, AFAIK.

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

Does this mean that using \\?\ with ANSI-encoded file names buys us
520-byte file names?

>  The ANSI API is really something which should be avoided these
> days.

Unfortunately, given the way most Unix packages are written (using
'char *' for file names), this is easier said than done.  E.g., I'm
not aware of any other GNU package except Emacs that supports Unicode
APIs, and I don't think that's an accident.