Windows 7 binary

[sergeevabc]

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]

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: #13 You are receiving this because you were mentioned. Message ID: ***@***.***>

[sergeevabc]

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

[skeeto]

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]

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](https://wiki.openssl.org/index.php/Binaries) 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: ```diff --- 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: #13 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>