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
