[fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT

Hans-Peter Diettrich 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
> anything

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 
on what?

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 mailing list