[fpc-devel] End of support for Win XP?
Michael Van Canneyt
michael at freepascal.org
Thu Feb 1 09:56:06 CET 2018
On Thu, 1 Feb 2018, Werner Pamler wrote:
> Am 30.01.2018 um 22:40 schrieb Florian Klämpfl:
>> Am 29.01.2018 um 21:11 schrieb Russell Davies:
>>> Just curious, does the use of SHGetKnownFolderPath() in trunk package
> winunits-base in fpttf.pp mean
>>> the end of Windows XP support as this function is not available in XP's
>> Probably yes, at least with the release of 3.2.0. After all, Win XP is
> almost for 4 years out of
>> support. But if somebody decides to stick with Win XP, he can stick also
> with FPC 3.0.x, it will not
>> stop working.
> I am absolutely no friend of shutting down support for old versions too
> early, in particular if it's for the reason of determining the Windows
> font directory. Why is it necessary to use SHGetKnownFolderPath for this
> purpose? In the times before Vista, this was done by SHGetFolderPath. In
> Microsoft says "This function replaces SHGetFolderpath. That older
> function is now simply a wrapper for SHGetKnownFolderPath." I interpret
> this that SHGetFolderPath still can be used.
And if you read SHGetFolderPath:
Deprecated. Gets the path of a folder identified by a CSIDL value.
Note As of Windows Vista, this function is merely a wrapper for SHGetKnownFolderPath.
The CSIDL value is translated to its associated KNOWNFOLDERID and then SHGetKnownFolderPath is called.
New applications should use the known folder system rather than the older CSIDL system,
which is supported only for backward compatibility.
Note the 'Deprecated'.
The PDF functionality is new. So it uses the known folder system which is
the current API.
I can agree that we should not too eagerly change old functionality to use newer APIs.
This means that if you recompile an old application with today's FPC, it
will still function as it was. That is the intent of 'backwards compatible'
or 'still supporting'.
But for new functionality, we use the current API's.
More information about the fpc-devel