The uwinapi mess

[Stephan Bergmann]

We traditionally have a uwinapi.dll on Windows that works as a grab-bag 
of implementations of functions that are not yet available on all 
versions of Windows or not yet available in all versions of the MSVC 
runtime.  Demand for this has shrunk over time.

At least since 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=4479090e6063f6106c9cf08473f3cac1b12407e2> 
"Bring back the Duden hack" (June 2013), what uwinapi.dll exports is

> EXPORTS
> 	GetShortPathNameW PRIVATE
> 	snprintf
> 	snwprintf
> 	vsnprintf
> 	vsnwprintf

(cf. sal/systools/win32/uwinapi/uwinapi.def, and whatever the "PRIVATE" 
means).

According to 
<https://msdn.microsoft.com/en-us/library/windows/desktop/aa364989(v=vs.85).aspx> 
"GetShortPathName function", GetShortPathNameW/GetShortPathNameA are 
available in Kernel32.dll since Windows XP, so that one probably isn't 
relevant any longer anyway.

vsnprintf is available in the MSVC runtime at least since MSVC 2013, 
probably even earlier.

snprintf is availabe in the MSVC runtime since MSVC 2015.

snwprintf and vsnwprintf appear to be inventions of our own.  Depending 
on whether _UNICODE is defined, sntprintf and vsntprintf are defined to 
those in include/systools/win32/snprintf.h, but sntprintf and vsntprintf 
in turn appear to be inventions of our own, too.  (There are, however, 
_snwprintf, _vsnwprintf, __sntprintf, and _vsntprintf available in the 
MSVC runtime at least since MSVC 2013, probably even earlier.)  This 
smells a bit like we're cargo-culting those around while they should 
actually have been removed long ago.

Since 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=0c9ddb24ee0388d03c313caf5a45f1aa26049781> 
"Don't redefine snprintf as VS 2015 supports ISO standard" (September 
2015), inclusion of the four functions snprintf, snwprintf, vsnprintf, 
and vsnwprintf in uwinapi.dll is made conditional on building with < 
MSVC 2015.  That means that for LO 5.4 (where we bumped the baseline to 
MSVC 2015), the uwingapi.dll in official TDF builds will only export the 
one function GetShortPathNameW.

And whether the uwinapi functionality is exported through the SDK is 
somewhat ill-specified:  For one, from the two commits mentioned above, 
it looks like at least the Duden extension depended on it in some form. 
For another, we provide include/systools/win32/snprintf.h in the SDK. 
(Traceable back to 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=6c7659b584ea7ed3652ca4eb9a2297f36310c365> 
"move URE headers to include/", April 2013; not sure if we even included 
more files from include/systools/win32/ prior to that.)

Now, <https://gerrit.libreoffice.org/#/c/23198/> "gbuild: Remove MSVC 
2013 legacy code", among other things, tries to remove uwinapi.dll and 
its include/systools/win32/ include files completely.  My first reaction 
was to decouple the actual uwinapi removal from the other clean-up done 
there.  However, I only later noticed that the remaining uwinapi is 
almost empty anyway (due to 
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=0c9ddb24ee0388d03c313caf5a45f1aa26049781> 
"Don't redefine snprintf as VS 2015 supports ISO standard" as described 
above).

So, instead of disentangling that monster Gerrit change, deciding which 
parts are still relevant for the hypothetical left-alive uwinapi and 
would thus need to be retained, I guess we can just as well bite the 
bullet /now/ and decided how to proceed with uwinapi.

In the light of all the above, my suggestion now would be to discontinue 
uwinapi in LO 5.4.  Remove include/systools/win32/snprintf.h from the 
SDK and add to the release notes that that include file and uwinapi.dll 
itself (however 3rd party code would have been able to rely on it in the 
past) are gone.  This might mean that old extensions like the Duden one 
no longer work with 5.4, but presumably we already accidentally broke 
compatibility with those a while ago, anyway.  (And if/when we 
discontinue 32 bit builds of LO on Windows, support for such legacy 
extensions becomes moot anyway.)

Thoughts?