Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PasXip.pas issue. #458

Open
ijbranch opened this issue Dec 1, 2024 · 7 comments
Open

PasXip.pas issue. #458

ijbranch opened this issue Dec 1, 2024 · 7 comments

Comments

@ijbranch
Copy link

ijbranch commented Dec 1, 2024

Hi Team,
I recently started to play in 64 bit. Normally I was 32 bit exclusive.
I ran up against an issue with paszip.pas, used in a couple of places in various 3rd Party libraries.
I kept geting an error at line 4341 or thereabouts: file_ := INVALID_HANDLE_VALUE;
Tracing, I found variable file_ was defined at line around 3963 as a DWORD: file_: dword;
This is fine in 32bit but problematic in 64bit.
The solution was to change the declaration to: file_: THandle;
Now paszip.pas builds without issue in both 32 & 64 bit.
HTH in some way..

Regards,
Ian

synopse pushed a commit that referenced this issue Dec 2, 2024
- as reported by #458
@synopse
Copy link
Owner

synopse commented Dec 2, 2024

Please try with the above commit, and close if it is OK for you.

I tried to fix all wrong occurrences of DWORD in this unit.

@ijbranch
Copy link
Author

ijbranch commented Dec 2, 2024

Builds & runs OK. Thank you.
Ian

@ijbranch ijbranch closed this as completed Dec 2, 2024
@ijbranch
Copy link
Author

ijbranch commented Dec 9, 2024

I was still experiencing issues with 64bit.
Examining INVALID_HANDLE_VALUE at the error line I found it to be a rediculous value: 1811674407373709551615.
Doing some research I found that INVALID_HANDLE_VALUE seems to be generally assigned a value of -1.
I made this change in PasZip:

{$WARNINGS OFF}
{$Q-,R-} // Turn range checking and overflow checking off

{ $D-,L-}

{$I Synopse.inc}

interface

uses
{$IFDEF MSWINDOWS}
Windows,
{$ELSE}
Types,
{$ENDIF MSWINDOWS}
SysUtils;

//////////////////////////////////////////////////////////////////////
const // This const add on 09/12/2024.
INVALID_HANDLE_VALUE = THandle(-1); // Add the constant here
/////////////////////////////////////////////////////////////////////

type
{$IFDEF HASCODEPAGE}
RawByteZip = RawByteString;
TZipName = type AnsiString(437);
{$ELSE}
RawByteZip = AnsiString;
TZipName = AnsiString;
{$ENDIF HASCODEPAGE}

I will advise if I have any more issues.

@ijbranch ijbranch reopened this Dec 9, 2024
synopse pushed a commit that referenced this issue Dec 9, 2024
@synopse
Copy link
Owner

synopse commented Dec 9, 2024

Please try with the above commit.

Using a function like in mORMot 2 seems a cleaner way.

@ijbranch
Copy link
Author

ijbranch commented Dec 9, 2024

No problem. Either way seems to work.
I will let you know after some more testing.

@zedxxx
Copy link
Contributor

zedxxx commented Dec 9, 2024

These variables must also be THandle types:

P.S. Also, there may be errors related to the fact that the variables used to store the size/offset have a Cardinal type (for files >2GB).

zedxxx added a commit to zedxxx/mORMot that referenced this issue Dec 10, 2024
@synopse
Copy link
Owner

synopse commented Dec 10, 2024

About the use of cardinal, this would need to support the Zip64 format, which is clearly out of scope of this small unit (it is a bit complex to implement).

We have mormot.core.zip.pas for full zip support, including the Zip64 format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants