Re: [fpc-devel] End of support for Win XP?

[Denis Kozlov]

On 06/02/2018 07:54, Michael Van Canneyt wrote:
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.


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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Michael Van Canneyt]

On Tue, 6 Feb 2018, Denis Kozlov wrote:


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.


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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Denis Kozlov]

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


On 01/02/2018 13:31, Sven Barth via fpc-devel wrote:
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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Martok]

Am 01.02.2018 um 14:08 schrieb Denis Kozlov:
> 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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Michael Van Canneyt]

On Thu, 1 Feb 2018, Sven Barth via fpc-devel wrote:


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



On Thu, 1 Feb 2018, Denis Kozlov wrote:

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


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

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Sven Barth via fpc-devel]

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



On Thu, 1 Feb 2018, Denis Kozlov wrote:

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 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Sven Barth via fpc-devel]

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Michael Van Canneyt]

On Thu, 1 Feb 2018, 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.


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.


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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Denis Kozlov]

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


On 30/01/2018 21:40, Florian Klämpfl wrote:

Am 29.01.2018 um 21:11 schrieb Russell Davies:

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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Michael Van Canneyt]

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:

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.


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.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Werner Pamler]

Am 30.01.2018 um 22:40 schrieb Florian Klämpfl:

Am 29.01.2018 um 21:11 schrieb Russell Davies:

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.


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.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Benito van der Zander]

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



Am 31.01.2018 um 13:44 schrieb Bart:

On Tue, Jan 30, 2018 at 10:40 PM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Bart]

On Tue, Jan 30, 2018 at 10:40 PM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP?

[Florian Klämpfl]

Am 29.01.2018 um 21:11 schrieb Russell Davies:
> 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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] End of support for Win XP? (fpc-devel Digest, Vol 165, Issue 16)

[Russ]

On 2018/01/29 10:11 PM, 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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel