Re: Emacs portability requirements

[Bruno Haible]

Hi Eli,

> > 1) 
> > > On Windows 9X
> > > Emacs loads the UNICOWS.DLL shared library at startup to be able to
> > > use some functions ...
> > 
> > Can the source code call the functions of UNICOWS.DLL directly, or
> > do these functions all need to be call via pointers obtained via
> > GetProcAddress()?
> 
> In general, they can be called directly, since we load UNICOWS.DLL
> early at startup ...

Good. (I didn't expect such a "dynamic" feature from the Windows DLL system.)

> But there are a couple of exceptions (nothing is ever
> simple with this backward-compatibility business), as you can see if
> you search the Emacs sources for "unicows" (case-insensitively).

Yes, I saw that MultiByteToWideChar and WideCharToMultiByte are special.
Fortunately, Gnulib does not use them directly.

> > 2)
> > > As an example, this discussion mentions _wsetlocale, which according
> > > to my records is not in UNICOWS.DLL
> > 
> > Do you have a list of symbols that are safe to call? We have a database
> > of available symbols per platform in
> > https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/various-symlists
> > and it would be useful to add Windows9X+unicows there.
> 
> I use this list:
> 
>   
> http://svn.apache.org/repos/asf/openoffice/trunk/main/sal/systools/win32/uwinapi/unicows.dxp
> 
> It has never failed me till now.  I also have this DLL on my machine,
> so I can easily verify stuff using 'pexports' and the likes.  ...
> 
> AFAIK, all versions of MSVCRT.DLL since Windows NT have _wsetlocale.
> ...
> I also have MSVCRT.DLL from Windows 98 and from XP, and I verified
> with 'pexports' that it does have _wsetlocale

Thanks for the URL. I downloaded a couple of old versions of msvcrt.dll,
extracted the exported symbols, and added them to our database here:
https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/various-symlists
under window-9x/ and windows-nt/.

> Windows 9X in general don't have any _w* "wide" functions, and need to
> use UNICOWS.DLL to do so.

You're confusing me now. I see many _w* "wide" functions in the msvcrt
from 1996-1998. The symbols provided by UNICOWS.DLL are all capitalized,
and most of them end in 'W'.

The functions I mean, and which are likely candidates for use by Gnulib,
are:

_waccess
_wasctime
_wchdir
_wchmod
_wcmdln
_wcreat
_wcsdup
_wcsicmp
_wcsicoll
_wcslwr
_wcsncoll
_wcsnicmp
_wcsnicoll
_wcsnset
_wcsrev
_wcsset
_wcsupr
_wctime
_wenviron
_wexecl
_wexecle
_wexeclp
_wexeclpe
_wexecv
_wexecve
_wexecvp
_wexecvpe
_wfdopen
_wfindfirst
_wfindfirsti64
_wfindnext
_wfindnexti64
_wfopen
_wfreopen
_wfsopen
_wfullpath
_wgetcwd
_wgetdcwd
_wgetenv
_winmajor
_winminor
_winver
_wmakepath
_wmkdir
_wmktemp
_wopen
_wperror
_wpgmptr
_wpopen
_wputenv
_wremove
_wrename
_write
_wrmdir
_wsearchenv
_wsetlocale
_wsopen
_wspawnl
_wspawnle
_wspawnlp
_wspawnlpe
_wspawnv
_wspawnve
_wspawnvp
_wspawnvpe
_wsplitpath
_wstat
_wstati64
_wstrdate
_wstrtime
_wsystem
_wtempnam
_wtmpnam
_wtoi
_wtoi64
_wtol
_wunlink
_wutime
wcscat
wcschr
wcscmp
wcscoll
wcscpy
wcscspn
wcsftime
wcslen
wcsncat
wcsncmp
wcsncpy
wcspbrk
wcsrchr
wcsspn
wcsstr
wcstod
wcstok
wcstol
wcstombs
wcstoul
wcsxfrm
wctomb
wprintf
wscanf

Do you expect (generally) that these functions will work in Windows 9x+UNICOWS,
or not?

> > 3) Do you have a list of header files that are available in this 
> > environment?
> > I.e. does unicows come with a set of header files of its own, or is it 
> > merely
> > the set of header files from mingw, which we have in our database here:
> > https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=blob;f=platforms/various-includes/mingw.list
> > ?
> 
> UNICOWS.DLL does not come with header files AFAIK, it comes with the
> DLL and the corresponding .lib file.

OK. So what matters is the set of header files of early Microsoft SDKs
and early mingw.org versions. Here I have the list of header files from
mingw.org from 2003:
https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=blob;f=platforms/various-includes/mingw.list
locale.h is contained there.

So, would you agree that there is no problem with using <locale.h>?

> > 4) Is the condition for Emacs-specific code still 'defined emacs', or has it
> > changed over the years?
> 
> That is still the condition we use, yes.

Thanks.

Bruno