pbatard / bled Goto Github PK

Hi,

I started using bled in a Delphi project last weekend, to do this I compiled bled as DLL in Visual Studio 2019. I just changed the type in the project configuration. If you try this there will be two linker errors. The first one is easy to fix by adding shlwapi.lib so the PathMatchSpec function can be imported. I was unable to fix the second one: LNK2019 Unresolved External Symbol _xz_crc32 in function _dec_block.
I ended up commenting the lines where xz_crc32 is used because I don't need xz support, but I think it would be nice to be able compile bled as DLL out of the box. If you like I would PR my translated Delphi header or just link a gist so it can be found by others.

Hello, I'm a curious college mate trying to port this library to MacOS, but when I run the test programs I get errors such as:

DECOMPRESS TO FILE: Error: zip method 0 is not supported zip: -14
OR
DECOMPRESS TO FILE: Error: zip flags 1 and 8 are not supported zip: -14
The first one was for a zipped Github repo called flyver-sdk, and the second one was an ubuntu-16.04 LTS zipped image. I've only rewritten the libbb.h and defined Windows types and system calls.

In testing the resolution to issue #1422 in rufus, I/O performance is significantly worse when writing an image that in BZ compressed versus the straight uncompressed image. It seems that much of the performance loss is due to the [small] I/O buffer size.

Please change IOBUF_SIZE to 64K in decompress_bunzip2.c

The current test/data/xz.zip was produced using 7-zip on Windows and works fine with Bled.
However, when using a xz.zip produced on Linux (using the command zip -m xz xz.h for instance), Bled crashes in decompress_gunzip.c → huft_build() due to variable d and e being NULL from the huft_build(ll, 19, 19, NULL, NULL, &inflate_codes_tl, &bl); call.

NB: This looks similar to BusyBox bug 7796, though I am doubtful BusyBox's unzip suffers from the same issue, as it would have been widely reported otherwise.

See pbatard/rufus#1422 for the reasoning behind this.

Basically, similar to how users can provide their own print and progress function in bled_init(), they should also be able to provide their own implementation of full_write() (which is invoked in transformer_write and currently simply points to the _write() system call).

As per pbatard/rufus#580. This may require figuring out the expected extracted size beforehand though...