Support LZX for encoding?

[landaire]

I've been doing some work on Xbox 360 stuff which uses LZX for its executable compression. I'll be straightforward and just say that I had Claude Code reimplement compression and threw it up here: https://crates.io/crates/lzxc

It seems to work well for this specific use-case. I did a cursory look to see what else in the ecosystem uses LZX and noted that this crate doesn't support encoding with LZX. I don't know if this is at all a priority for anyone building cab files though.

I understand if you don't want to use primarily LLM-generated code which is why I'm calling it out, but it seems to work well, and I tried to massage the API into something reasonable/did some microbenchmarks to get good speed out of it.

[mdsteele]

Thanks for reaching out and for the transparency. I'm perfectly happy to have cab depend on lzxc if you're happy to maintain lzxc if and when any bugs come up. (-: Having lzxd to validate against also helps.

Any chance you'd be up for sending a PR to start using lzxc in cab?

[landaire]

I can do that. What are you looking for in terms of testing? Roundtrip is an obvious one, but are there any specific Windows flows I should try to ensure Windows tooling handles the encoded archives?

[mdsteele]

Hmm. As I recall, the mszip implementation in this crate has some tests to compare against the system compressor when running tests on Windows (as in the Github workflow for this repo):

rust-cab/src/mszip.rs

Line 175 in 74dfdd7

#[cfg(target_env = "msvc")]

We could try to do a similar thing for LZX, although it's a little unclear to me whether or not the Windows system API that that test code is using supports LZX: https://learn.microsoft.com/en-us/windows/win32/api/compressapi/nf-compressapi-createcompressor

If that doesn't work, we may just need to stick with round-trip tests.