windows 32-bit binary, please?

[Vangelis66]

Humongous thanks for bringing this project out of stagnation! 👍 I was extremely excited to see that you are now also providing yourself Windows binaries 🥇

... Imagine how let down I ended up feeling when I discovered that your offered executable AtomicParsley.exe is only 64-bit!

I am fully aware that 64-bit is today's norm, but not all of us Windows users are on that architecture yet... 😞 Especially people like me on older hardware with limited RAM (Win7 SP1 32-bit with 3GB RAM); would it be much asking for a win32 executable along the already provided win64 one?

Many thanks in advance, keep up the sterling efforts!

PS: I know self-compilation is always an option, but installing/configuring/running a compilation toolchain (MSYS2/MinGW I believe is being currently offered as 64-bit, only...) on low-end hardware (with a 32-bit OS) defeats the purpose...

[github-actions[bot]]

Thanks for filing an issue! Please note that this project is only passively maintained, so your best bet for getting an issue resolved is through a pull request that is easy to verify!

[wez]

Thanks for the praise :)

However, I don't have bandwidth to dig into making or supporting 32-bit binaries.

I'll definitely consider a PR to https://github.com/wez/atomicparsley/blob/master/.github/workflows/ci.yml that enables a 32-bit windows build, provided it doesn't make it more difficult to maintain.

(FWIW, the reason I first contributed to this project was to make it work properly on 64-bit systems!)

[nicolaasjan]

@Vangelis66 I'm a bit late to the party, but I managed to make a 32-bit binary from the latest source, using Visual Studio in a Windows 7 VM. 😎

cmake -A Win32 .

cmake --build . --config Release

However, it complained about zlib not being present and I had no idea how to implement that... It worked though (but not on Windows XP...).

[Link removed; see comment below]

[wez]

Thanks for chiming in, however, I'm going to remove links to external binaries that are made here. it's a matter of trust: I can't personally vouch for third-party binaries and I don't want this repo to lead folks towards binaries that either may not be there in the future, or, in the very worst case, somehow get compromised.

The best thing you can do to get a 32-bit available from here is to contribute the CI changes needed to build it.

[nicolaasjan]

Thanks for chiming in, however, I'm going to remove links to external binaries that are made here. it's a matter of trust: I can't personally vouch for third-party binaries and I don't want this repo to lead folks towards binaries that either may not be there in the future, or, in the very worst case, somehow get compromised.

The best thing you can do to get a 32-bit available from here is to contribute the CI changes needed to build it.

I understand your concerns. 🙂 Unfortunately I don't have the knowledge to make CI changes, otherwise I would have done that.

@Vangelis66 Did you manage to download the binary before it got removed? Otherwise I can give it to you via a PM at the MSFN forum.

[pukkandan]

This should be sufficient to create the release: https://github.com/pukkandan/atomicparsley/commit/f6f8f9f04f54b0568c40ac8074179e863404b616. But I don't have an x86 device to confirm that the binary works.

Example build: https://github.com/pukkandan/atomicparsley/releases/tag/test https://github.com/pukkandan/atomicparsley/actions/runs/3750093391

PS: Consider switching to actions/checkout@v2

[wez]

@pukkandan: looks plausible! Could you submit that as a PR? And also one for actions/checkout@v2 while you're in there? Thanks!

[pukkandan]

Will do so once OP confirms that the build actually works

[Vangelis66]

@pukkandan

It was very noble of you to jump in on this ❤️ 👍 ... More so, if one considers the fact yt-dlp_x86.exe isn't practically dependent on AtomicParsley.exe 99% of the time, since media container tagging has been delegated to the mutagen python module 👍 ...

It's true, though, that the upstream project, youtube-dl, still depends on AP for MP4 container tagging (and an alternative route like #29581+#29593 hasn't yet been either reviewed or considered for merging 😞 ) ...

Whatever recent-ish (ca. 2014-2015) win32 AP binaries could be found on line were hosted mostly on Bitbucket, and these later vanished towards the end of 2020, when AP code repos (original+forks), being of the mercurial (hg) format, were removed by BB/Atlassian 😞 ...

The move, by wez, from an autoconf/automake compilation to a cmake-based one, necessitating MS Visual Studio, made things even harder for me here 😿 (up to v0.9.6, I could still compile the code with a 2017-era MSYS2_x86 copy I kept...).

This should be sufficient to create the release: https://github.com/pukkandan/atomicparsley/commit/f6f8f9f But I don't have an x86 device to confirm that the binary works.

once OP confirms that the build actually works

While your coding effort is highly praiseworthy 👍 , unfortunately it did not produce the desired outcome :sob: ... Something is still amiss, because at https://github.com/pukkandan/atomicparsley/releases/tag/test both archives AtomicParsleyWindows.zip and AtomicParsleyWindowsx86.zip (which, if you noticed, are of the same filesize 😉 ) contain the ~exact~ same binary, AtomicParsley.exe, sized 278 KiB, which is of the x64 architecture 😢 ; here's how MediaInfo reports it:

and when I tried launching it, it, of course, produced this:

FTR, the win32 binary kindly compiled by @nicolaasjan via MS VS2019 is a true 32-bit one, and launches fine out-of-the-box under Vista SP2 x86; as a bonus to "retrocomputing" enthusiasts, it'll also launch under Windows XP SP2+ x86 if the sub system value in its PE Header is lowered from 6.0 to 5.1 👍 ... Sadly, as it was compiled from locally downloaded source, it suffers from #23 (empty version string) ...

There's another AP fork (with slightly different code), part of another organisation which compiles and provides AP win32 binaries for its "own usage", that I'd like to point pukkandan to:

https://github.com/get-iplayer/atomicparsley
https://github.com/get-iplayer/atomicparsley/commits/cf70a71 (latest zlib release is now 1.2.13)
https://github.com/get-iplayer/atomicparsley/blob/get_iplayer/CMakeLists.txt
https://github.com/get-iplayer/atomicparsley/blob/get_iplayer/.github/workflows/ci.yml
https://github.com/get-iplayer/atomicparsley/blob/get_iplayer/.github/workflows/release.yml

No doubt the clues for successfully compiling, via GitHub Actions, AtomicParsley_x86.exe (ideally with zlib support included 😉 ) based on latest wez source are to be found inside the linked files... I'm no coder, sadly, so can't do this myself 😊 ... FWIW, "their" latest release (but its code is older/different to wez's), AtomicParsley-0.9.7-get_iplayer.2-windows-i686.zip, launches fine here in my 32-bit OS 🎉 ...

Many thanks to all the savvy persons involved, "Have a Merry Christmas" to all that observe it :santa: ... Festive regards 😄 !

[nicolaasjan]

both archives AtomicParsleyWindows.zip and AtomicParsleyWindowsx86.zip (which, if you noticed, are of the same filesize) contain the exact same binary, AtomicParsley.exe, sized 278 KiB, which is of the x64 architecture

They're not exactly identical, because the SHA1-sums of the executables are different. ;)

[wez]

@pukkandan https://stackoverflow.com/a/52846043/149111 seems to be the simplest way to inform cmake about the architecture, without hardcoding specific versions of visual studio tools

[Vangelis66]

They're not exactly identical, because the SHA1-sums of the executables are different.

Indeed they are (different) 😉 :

./AtomicParsleyWindowsx86/Release/AtomicParsley.exe

SHA1 File Checksum: 1B1EF075B82F5EB99906F320B3A25C94F94DD009

and

./AtomicParsleyWindows/Release/AtomicParsley.exe

SHA1 File Checksum: 87DDCF6853FEE52F8C09DC320CC793C0C7B6B7EB

In my defence, I didn't think of calculating file checksums at the time I posted, because I was (only) basing my "assumption" on what Windows Explorer reported about file sizes:

./AtomicParsleyWindowsx86/Release/AtomicParsley.exe
Size: 278 KB (285.184 bytes)
Size on disk: 280 KB (286.720 bytes)

and

/AtomicParsleyWindows/Release/AtomicParsley.exe
Size: 278 KB (285.184 bytes)
Size on disk: 280 KB (286.720 bytes)

i.e. identical figures... As a rule of thumb, 64-bit binaries are noticeably larger in size compared to respective 32-bit ones compiled from the same source code...

[pukkandan]

However, it complained about zlib not being present and I had no idea how to implement that... It worked though (but not on Windows XP...).

@nicolaasjan How did you get it to build? For me, the build command throws error after "Could NOT find ZLIB". See https://github.com/pukkandan/atomicparsley/actions/runs/3763543108/jobs/6397140009

[nicolaasjan]

@nicolaasjan How did you get it to build? For me, the build command throws error after "Could NOT find ZLIB". See https://github.com/pukkandan/atomicparsley/actions/runs/3763543108/jobs/6397140009

But your second attempt (attempt 6) worked (?)

This was compiled locally using Visual Studio 2019 in a Windows 7 VM though (not via GitHub actions). It showed the same warning, but continued anyway.

[Vangelis66]

For me, the build command throws error after "Could NOT find ZLIB"

Normally, that shouldn't be a deal-breaker, because of 2aa76ad And yes, Nico's build doesn't comprise zlib; however, it's a desired dependency:

zlib - used to compress ID3 frames & expand already compressed frames, available from http://www.zlib.net/

I am by no means an expert on this 😜 , but, supposedly, you should grab the latest zlib source (1.2.13), build it first with VS and then make the lib(s) produced "available" to the AP compilation routine...

The linux recipe for the fork I linked previously contains below code:

https://github.com/get-iplayer/atomicparsley/blob/get_iplayer/.github/workflows/release.yml#L23

The Windows recipe is:

https://github.com/get-iplayer/atomicparsley/blob/get_iplayer/.github/workflows/release.yml#L33-L39

Thanks a bunch for your continued efforts 👍 !

[pukkandan]

But your second attempt (attempt 6) worked (?)

Look at the release workflow, I'm not editing CI currently

The linux recipe for the fork I linked previously contains below code:

https://github.com/get-iplayer/atomicparsley/blob/get_iplayer/.github/workflows/release.yml#L23

The Windows recipe is:

https://github.com/get-iplayer/atomicparsley/blob/get_iplayer/.github/workflows/release.yml#L33-L39

That is pretty much the same as what I am doing. But it is insufficient. The CMakeLists.txt will need to be updated too. Regrettably, fixing that is currently beyond my skills

[wez]

@pukkandan looking at https://github.com/get-iplayer/atomicparsley#visual-studio suggests that:

cmake . -A Win32 would do 32-bit, while cmake . -A x64 would do 64. They're also using -DSTATIC_LINK=ON but I'm not sure if that will change anything in the very basic cmake setup used here; they have a more complex cmake script.

I would suggest focusing this issue on 32-bit building and leaving zlib for a separate PR. For that, you may be able to copy https://github.com/get-iplayer/atomicparsley/blob/get_iplayer/CMakeLists.txt#L86-L129 in and it looks like it might do the job.

[howyallare]

How did you get it to build? For me, the build command throws error after "Could NOT find ZLIB"

The CMakeLists.txt will need to be updated too.

The build failure is unrelated to zlib or CMakeLists.txt - just a few mistakes in the workflow - so I've taken up the baton. If someone with a 32-bit system can verify the binary at link below, I'll make a PR.

https://github.com/howyallare/atomicparsley/releases/download/2022-12-29-01/AtomicParsleyWindowsX86.zip

I leave zlib support to someone else. It's a pretty esoteric corner of atomicparsley, so only worth including for parity with other platforms.

[Vangelis66]

If someone with a 32-bit system can verify the binary at link below

I'm elated to report success!

As the build was compiled with VS2022, it depends on file vcruntime140.dll (32-bit), if the latest (compatible with your WinOS) MSVC++2015-2022 redistributable (x86) isn't installed system-wide... Sub system value inside its PE header is set at 6.0, so that build will run out-of-the-box on Windows Vista (SP2) x86 and higher...

atomicparsley --version
AtomicParsley version: 20221223.170737.0 c8437f3f882ef39a3b9c29a3604f68bc38dfeac9 (utf16)

Thus, many thanks and congrats to howyallare 🥇 ❤️ !!!

As was said, static linking wo(u)ld be irrelevant without zlib. I leave zlib support to someone else.

I don't want to jinx my God-sent good luck 😉 , but would that "someone" be willing to fill in the missing bits? 😄

The CMakeLists.txt will need to be updated too.

FWIW, https://cmake.org/cmake/help/latest/ and here's how the "fork" did it: https://github.com/get-iplayer/atomicparsley/commit/f14472e

Many thanks nicolaasjan and pukkandan for putting things into motion again... Much obliged to all who contributed to a fruitful result 😺 💯 ...

Happy Holidays!

[howyallare]

GitHub elected not to install the MSVC toolset for XP support on latest Windows CI runners. There may be a way to install it as part of the build, but I couldn't care less about XP. Someone who uses XP can take that up.

[howyallare]

Updated version built with static linkage of MSVC runtime library (64- and 32-bit):

https://github.com/howyallare/atomicparsley/releases/download/2022-12-29-02/AtomicParsleyWindows.zip https://github.com/howyallare/atomicparsley/releases/download/2022-12-29-02/AtomicParsleyWindowsX86.zip

[wez]

Thanks to @howyallare, their PR has been merged, and https://github.com/wez/atomicparsley/releases/tag/20221229.172126.d813aa6 should now have a 32-bit windows binary available.