B7rian / ripsum

Faster sha256 checksums
Apache License 2.0
0 stars 0 forks source link

Windows 7 binary #13

Open sergeevabc opened 2 months ago

sergeevabc commented 2 months ago

Dear @B7rian, I am not a developer, but an ordinary user, who is looking for the fastest implementation of SHA256 to run on vintage hardware (Core2Duo SSE3 with 4 GB RAM). Could you be so kind to attach *.exe of Ripsum to this issue so that I could try it?

B7rian commented 2 months ago

Hi Alexsandr. Sorry, but I don't have access to a Windows 7 machine. I am trying to think of where I might find one but no luck yet.

On May 9, 2024 4:30:12 PM EDT, Aleksandr Sergeev @.***> wrote:

Dear @B7rian, I am not a developer, but an ordinary user, who is looking for the fastest implementation of SHA256 to run on vintage hardware (Core2Duo SSE3 with 4 GB RAM). Could you be so kind to attach *.exe of Ripsum to this issue so that I could try it?

-- Reply to this email directly or view it on GitHub: https://github.com/B7rian/ripsum/issues/13 You are receiving this because you were mentioned.

Message ID: @.***>

sergeevabc commented 2 months ago

I have been trying to build ripsum myself using w64devkit by @skeeto, but see no makefile to proceed via make command.

skeeto commented 2 months ago

I see it's a CMake build, and I don't distribute that with w64devkit, but the source is straightforward enough that you don't actually need it. You'll need a development build of OpenSSL, and the FireDaemon one was the simplest option I could find. (Building OpenSSL with GCC requires Perl, so don't bother trying.) Then to build ripsum:

$ c++ -Iopenssl-3/x64/include -Lopenssl-3/x64/lib -o ripsum src/*.cpp -lssl -lcrypto

Optimize to taste. (IMHO, depending on OpenSSL just for SHA-256 is rather excessive. On the other hand, that implementation does seem to be quite well-optimized!)

However, there was one issue in ChecksumLine.cpp converting the regex capture into a path, which doesn't compile. This might be a bug in ripsum, or maybe a bug in libstdc++. (I give it 50/50 odds.) I had to convert through a string:

--- a/src/ChecksumLine.cpp
+++ b/src/ChecksumLine.cpp
@@ -50,3 +50,3 @@ ChecksumLine::ChecksumLine(std::string aLine)
    //but this was throwing an exception on Linux 
-    mPath = captures[2];
+    mPath = std::string{captures[2]};

I'm not so familiar with std::filesystem. In theory the string ought to be decoded through std::filesystem::u8path, but in my tests it automatically decoded as UTF-8 without it anyway, and wide paths worked fine.

B7rian commented 1 month ago

I'm glad you were able to get it to work. I did build for windows 10 or 11 at one point (maybe using msys2) and had to add a UTF-16 to UTF-8 converter as NTFS uses UTF-16 filenames and paths. The solution was ugly so I removed it - your modification seems to be solving the same problem(?) much more cleanly.

Reference: https://stackoverflow.com/questions/2050973/what-encoding-are-filenames-in-ntfs-stored-as#2051018

On May 16, 2024 6:14:16 PM EDT, Christopher Wellons @.***> wrote:

I see it's a CMake build, and I don't distribute that with w64devkit, but the source is straightforward enough that you don't actually need it. You'll need a development build of OpenSSL, and the FireDaemon one was the simplest option I could find. (Building OpenSSL with GCC requires Perl, so don't bother trying.) Then to build ripsum:

$ c++ -Iopenssl-3/x64/include -Lopenssl-3/x64/lib -o ripsum src/*.cpp -lssl -lcrypto

Optimize to taste. (IMHO, depending on OpenSSL just for SHA-256 is rather excessive. On the other hand, that implementation does seem to be quite well-optimized!)

However, there was one issue in ChecksumLine.cpp converting the regex capture into a path, which doesn't compile. This might be a bug in ripsum, or maybe a bug in libstdc++. (I give it 50/50 odds.) I had to convert through a string:

--- a/src/ChecksumLine.cpp
+++ b/src/ChecksumLine.cpp
@@ -50,3 +50,3 @@ ChecksumLine::ChecksumLine(std::string aLine)
  //but this was throwing an exception on Linux 
-    mPath = captures[2];
+    mPath = std::string{captures[2]};

I'm not so familiar with std::filesystem. In theory the string ought to be decoded through std::filesystem::u8path, but in my tests it automatically decoded as UTF-8 without it anyway, and wide paths worked fine.

-- Reply to this email directly or view it on GitHub: https://github.com/B7rian/ripsum/issues/13#issuecomment-2116293602 You are receiving this because you were mentioned.

Message ID: @.***>