[fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT
DrDiettrich1 at aol.com
Wed Feb 8 16:00:14 CET 2012
Felipe Monteiro de Carvalho schrieb:
> 2012/2/8 Tomas Hajny <XHajT03 at hajny.biz>:
>> If your intention was to keep the programs
>> working with Win9x, this won't help because the program containing
>> unresolved imports wouldn't start anyway. Is there any other reason?
> Windows9x has all W functions,
Right. Other (post-9x) functions cause more trouble, because these
prevent an application from starting at all. That's why Win9x support
should either provide workarounds for all API functions, which are not
natively available, or (much easier) should exclude all these
declarations. One more reason for a dedicated Win9x RTL.
> Microsoft added them as stubs to avoid
> this kind of problem. They all exist and they all simply don't do
They *do* the string conversion, necessary for calling the "native"
functions internally. In Win9x the W functions convert strings into
Ansi, on NT the A versions convert strings into WideString. So what's
the real benefit of conditionally calling A/W functions, and depending
There exist at least two cases, worth more consideration:
1) UTF-8 strings. These require a conversion, regardless of subsequent
calls of the A or W function version. Here the knowledge of Windows
version can prevent excess A/W conversions inside the OS implementation.
2) Filenames. Here I'm not sure, because even Win9x uses UTF-16
filenames on the disks, and thus the W versions should be preferred.
OTOH the MSDN "Note that Unicode support on Windows Me/98/95 requires
Microsoft Layer for Unicode." suggests that testing for *this* update is
the only relevant check, in any A/W calling decision.
More information about the fpc-devel