Hi,

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 shell32.dll

Regards

Russ

---
This email has been checked for viruses by AVG.
http://www.avg.com

Russell Davies wrote

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 shell32.dll

Apologies, I meant in package fcl-pdf

Regards
Russ

---
This email has been checked for viruses by AVG.
http://www.avg.com

Russell Davies wrote

Hi, 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 shell32.dll

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.

Florian Klämpfl wrote

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.

Just out of curiosity: is thei library loaded dynamically or statically? I expect Lazarus will want to continue support for XP for some time, if possible also with the 3.2.x version of fpc as compiler back-end.

Bart

Hi,

XP is still important

yesterday I had a dream about some kind of ebook reader with multiple pages, like 7 displays in a row on a foldable sheet, each for one page. (and something about a washing machine) At first the displays looked like Android, but when you took it apart, you noticed there was no software on the display devices, and underneath each display device there was a second device looking kind of like the mobile emitter in Voyager which was doing all the processing and which was actually running Windows XP

Best,
Benito

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 https://msdn.microsoft.com/de-de/library/windows/desktop/bb762188(v=vs.85).aspx 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.

Michael.

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.

Please, don't drop XP support! Is it so difficult or inconvenient? At least while new Windows versions keep some functions for compatibility. And even after dropping such functions from Windows, it is still possible to keep max compatibility in compiler itself (to run on Windows XP, must not use such functions) and in RTL (allow not use such functions with conditional defines).

It still feels *very early* to drop support for Windows XP. I haven't used it properly in years, but I can't say the same about the target user audience. I still test some builds against Windows XP.

It would be a shame to drop support for Windows XP over SHGetKnownFolderPath(), when alternatives like SHGetFolderPath() and even older SHGetSpecialFolderPath() still work in all existing NT versions, including 2000, XP, 7, 8, 10. I totally support the use of newer API when it is available, however it is not too difficult to use an older API with dynamic bindings, especially if we are talking about a single function.

A proposal:
1) Use windirs.GetWindowsSpecialDir in fpttf.pp, which already uses a more backwards compatible SHGetFolderPath().
2) Optionally, improve windirs.GetWindowsSpecialDir to use a newer SHGetKnownFolderPath() when it is available.

If this is suitable, I can produce a patch for both.

Denis

I would not bother with 1, since the goal is to remove the reference to a font directory on windows and use the font API of the OS.

Michael.

Am 01.02.2018 14:08 schrieb "Denis Kozlov" :

A proposal:
1) Use windirs.GetWindowsSpecialDir in fpttf.pp, which already uses a more backwards compatible SHGetFolderPath().
2) Optionally, improve windirs.GetWindowsSpecialDir to use a newer SHGetKnownFolderPath() when it is available.

If this is suitable, I can produce a patch for both.

I would be in favor of this, especially as it hides the gritty details from fpttf.pp.
Report them as two separate issues, please.

Regards,
Sven

Am 01.02.2018 14:31 schrieb "Michael Van Canneyt" :

On Thu, 1 Feb 2018, Denis Kozlov wrote:

A proposal:

I would not bother with 1, since the goal is to remove the reference to a font
directory on windows and use the font API of the OS.

But why implement retrieving the folder multiple times? It's the purpose of the WinDirs unit after all and it can default to the newer API if it's available.

Regards,
Sven

By replacing it with a 'better' call, you lower the need for the switch to the font API.

Michael.

Denis Kozlov wrote

It still feels *very early* to drop support for Windows XP. I haven't used it properly in years, but I can't say the same about the target user audience. I still test some builds against Windows XP.

This may be a very stupid question, but please believe me it is not as troll-y as it might sound...

What would be the point of supporting older CPUs, if we don't actually support the OS that runs/ran on them? Or the other way around, there'd be no point in generating code compatible with a specific processor if the minimum supported *OS* doesn't run on that cpu.
I'm specifically not talking about the compiler itself (or Lazarus), just being able to target a platform. That mostly limits the RTL I guess.

I still support Win2000 with one application (with just a few compat shims), and used to have a Delphi 4 install specifically for one (industry) machine running NT4 at a previous gig. At my current one, we have a Win95 box running expensive hardware. True, I ported that program to Win32 last year (Did you know BC++ 5 runs on Win10? I didn't.), but still... that stuff is not as rare as one might hope.

What I'm trying to say: it would be amazing if there was a way to be forward-compatible without entirely scrapping old stuff. Maybe do the same as MS does, and have IFDEFs for the API level in the headers? I wouldn't mind having to recompile the RTL.

By the way: Dropping XP support also drops ReactOS support. I'm not sure if we ever officially had it, but it is on the Wiki.

Martok

Improved windirs.GetWindowsSpecialDir is ready:
https://bugs.freepascal.org/view.php?id=33133

The submitted patch contains the following changes:
1. Added FOLDERID_* constants, required for SHGetKnownFolderPath.
2. Added mapping of legacy CSIDL_* constants to FOLDERID_* constants.
3. Overloaded GetWindowsSpecialDir to work with both CSIDL_* or FOLDERID_* constants.
4. Changed GetWindowsSpecialDir to fallback to an alternative API (using appropriate remapping of parameters) when the default API function is not available.

Existing code that uses GetWindowsSpecialDir(CSIDL_*) should not be affected, except for an improved forward compatibility when the deprecated SHGetFolderPath is finally removed from Windows API, in which case a newer API function will be used automatically.

Denis

I would have preferred that you always use the new function when available, but since you'd then be doing what Microsoft is already doing, so I won't make a point out of it. I will apply and test the patch, thank you.

Michael.

That was my original plan, to use the new API by default.

But then I decided to stay on the safe side, for compatibility reasons, continue using old API when you make the call using old API constants (CSIDL_*). For example, old API adds trailing path delimiter while the new API does not. Of course, users should ensure their trailing path delimiter themselves, but there could be other peculiarities which might affect the end users.

So for now, users of GetWindowsSpecialDir can make a conscious decision to upgrade to the default use of new API by using FOLDERID_* constants instead of CSIDL_* constants.

Denis