SetFilePointerEx function missing

[440bx]

Hello,

In FPC v3.2.2, the definition of SetFilePointerEx is missing in Windows.pas.

Possible definitions:

Code: Pascal  [Select][+][-]

1. const
2.   kernel32 = 'kernel32';
3.  
4. function SetFilePointerEx
5.            (
6.             InFile               : THANDLE;
7.             InDistanceToMove     : TLARGE_INTEGER;
8.             OutoptNewFilePointer : PLARGE_INTEGER;
9.             InMoveMethod         : DWORD
10.            )
11.          : BOOL; stdcall; external kernel32;
12.  
13.  
14. function SetFilePointerEx
15.            (
16.             InFile               : THANDLE;
17.             InDistanceToMove     : int64;    { instead of LARGE_INTEGER       }
18.             OutoptNewFilePointer : pint64;   {            PLARGE_INTEGER      }
19.             InMoveMethod         : DWORD
20.            )
21.          : BOOL; stdcall; external kernel32; overload;
22.  
23.  

The first definition mirrors the MSDN definition exactly (except parameter names and "T" prefixed type names.)  The second one would be a "nice to have" overload.

[Thaddy]

@440bx
pointers can not be negative so please, please declare them as unsigned.
We are not living in D2 days...

[440bx]

@440bx
pointers can not be negative so please, please declare them as unsigned.
We are not living in D2 days...

Wake up!!!

There are no negative pointers anywhere in the definitions I gave.  There are pointers to 64 bit integers, which can definitely be negative.  (LARGE_INTEGER is defined as a signed value)

As far as the D2 days, the definition that uses LARGE_INTEGER has nothing to do with the D2 days, it has everything to do with the fact that's the way it is defined by MS.  Check it out https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-large_integer-r1

BTW, that's the reason I suggested the overload with "pint64" (no... that's _not_ a signed pointer... <chuckle>)

Tell MS to stop using D2 ... it's a suggestion I have no doubt they will follow... you can claim credit to have guided them in the right direction.

That was entertaining... thank you for the chuckle.

[Fibonacci]

@Thaddy: Is it not enough coffee or too much coffee?

[marcov]

Fixed

[440bx]

Fixed

Great!

[Fibonacci]

Fixed

Code: Pascal  [Select][+][-]

1. function SetFilePointerEx(InFile : THANDLE; InDistanceToMove : Int64;OutoptNewFilePointer : PInt64;InMoveMethod : DWORD): BOOL; stdcall; external KernelDLL;

Can you explain the spacing?

Code: Pascal  [Select][+][-]

1. function GetFileSizeEx(InFileHandle : THANDLE;OutFileSize  : PLARGE_INTEGER): BOOL; stdcall;

Or this? 2 spaces before colon, why?

Code: Pascal  [Select][+][-]

1. function GetNumaProximityNode(ProximityId:ULONG; NodeNumber:PUCHAR):BOOL;stdcall;external 'kernel32.dll' name 'GetNumaProximityNode';

Here no spacing around colons. Why? At least be consistent.

https://gitlab.com/freepascal.org/fpc/source/-/blob/1ccc23fa7009aaa7d8ac756768e3d2712ae2be47/rtl/win/wininc/func.inc?blame=1#L1375

[Fibonacci]

https://gitlab.com/freepascal.org/fpc/source/-/blob/main/rtl/win/wininc/ascdef.inc?blame=1#L349

This function is commented out. I recently had to use this function so I had to declare it myself

Whats funny, TOPENFILENAME structure is available in Windows unit, and is only used by the functions commented out: GetOpenFileName and GetSaveFileName.

"peter authored 24 years ago" Time flies

[marcov]

Those early Peter commits are the original windows header. Back then commdlg functions were added to windows, but they were in commdlg unit in at least later (D4+) Delphis .

So at around 2008 they were retranslated, put commdlg in and mostly removed from unit Windows.

Probably the structure was left in as IIRC its packing was particularly hairy, and I never got confirmation that the commdlg one was good.

Note that as per Vista IFileDialog became the preferred way anyway, and it pretty much all legacy.

[Thaddy]

I think some other people need more coffee. Why a signed type? Deliberately half your reach?
Then again, I got this response from MS,

Code: Text  [Select][+][-]

1. Historical Reasons: The use of LARGE_INTEGER dates back to earlier versions of Windows, and changing it now would break backward compatibility with existing applications.

Which was unexpected to me.. No coffee needed.

[Fibonacci]

I think some other people need more coffee. Why a signed type? Deliberately half your reach?

Because:

LARGE_INTEGER = Represents a 64-bit signed integer value.

Your C compiler may support 64-bit integers natively. For example, Microsoft Visual C++ supports the __int64 sized integer type. For more information, see the documentation included with your C compiler.

Deliberately half your reach?

Thats 8388608 TB of data anyway

[Thaddy]

See the response that Microsoft gave me. posts crossed.
The signed type is just for historical reasons and backwards (curious which backwards?) compatibility.
Second answer:
"Haha, I get where you're coming from! The decision to use LARGE_INTEGER for file sizes in Windows APIs does seem a bit like a relic from the past, much like the infamous "640K ought to be enough for anybody" quote attributed to Bill Gates (though he denies ever saying it).

The use of LARGE_INTEGER is indeed a historical artifact, designed to maintain backward compatibility with older applications. While it does limit the range to half of what an unsigned 64-bit integer could offer, the practical limit is still vast—about 9.22 exabytes, which is more than sufficient for most current applications."

Now only who will pay my coffee.....
(and yes, I dropped the 640k )

[Fibonacci]

Actually you are half right

The starting point is zero or the beginning of the file. If this flag is specified, then the liDistanceToMove parameter is interpreted as an unsigned value.

This is the case if dwMoveMethod is FILE_BEGIN, but not for the other 2 flags.


EDIT: Ok, thats for the liDistanceToMove, you are talking about the pointer, that is lpNewFilePointer, I guess that could be PUInt64.

[Thaddy]

Did anybody miss the "more than sufficient"" part?
To paraphrase "A comedy of errors."
And yes, this is an official MS point of view.

[440bx]

It really doesn't matter that the file pointer cannot be negative. What matters is that it was originally defined by the O/S creators using LARGE_INTEGER and that will suffice for quite some time.  Therefore there is no good reason at this time to change it and risk breaking compatibility problems with existing apps.

I think it's much more useful to have the definition using int64 and pint64 because it's much more convenient than dealing with the LARGE_INTEGER structure.  That makes a difference and does not affect compatibility. 

When 63 bits become insufficient (don't hold your breath for that one), MS will have SetFilePointerEx2 that will use a 64 bit unsigned parameter thus allowing Thaddy to have one less thing to worry about