rikyoz
commented
5 years ago Hi!
I'd like to build this on Linux so my project can zip files without depending on libz. Would it be possible to separate the Windows-dependent parts from a platform-independent core, so that I can integrate the compression functionality into my project? If you can give me some ideas how to do this, I could give it a try.
The support to Linux is a feature that I definitely want to implement in bit7z, however it is not an easy task.
The main problem lies in the Bit7zLibrary class (header and implementation), which provides the access to functions packed in the 7-zip Windows DLLs: such class works by using the Win32 API for dynamic loading DLLs, thus a porting to Linux would require to modify this class in such a way to make it deal also with the .so file of p7zip (and possibly in a way transparent to all other bit7z's classes which uses Bit7zLibrary!).
Moreover, also all the filesystem utility functions/classes (e.g. FSIndexer, FSItem etc...) are heavily coupled with the Win32 API. When I started writing bit7z, I thought of using a cross platform library (such as boost::filesystem) or the code already included in 7-zip: however, both would have added too much code to bit7z, making the size of the binaries too big for the little static library I was thinking. Hence, I decided to use the raw Win32 API, since the functionalities I needed were few, and I had already decided to stick to the Windows platform (it was difficult to understand how to use the 7-zip DLLs in itself, let alone take into consideration also other platforms).
Finally, it must be investigated whether there are significant differences between 7-zip and p7zip that may request other changes (e.g. the inclusion of p7zip source code in place of 7-zip's one), as well as many other details.
It is a big work to do, and I wish to be able to start it in a next major version (e.g. v4.0), together with other functionalities, such as the support to full static inclusion of 7-zip (instead of dynamically use the DLLs). For now, I'm concentrating on cleaning and improving the existing source code, as well as implementing other features/issues.
It would also be nice to perform in-memory operations on the basis of stdlib classes such as
istreamandostream. I wouldn't normally have data in avector<byte_t>format. It can be converted without a copy, but it requires an awkward usage of vector. This is one the main reasons we have the stream classes.
This is an interesting feature I didn't think about, since when I implemented in-memory operations I needed to work on buffers, and not streams, as input/output. 7-zip uses its own stream interfaces, hence I will probably need to create classes implementing them and "translating" istream/ostream operations. I will investigate this and eventually try to implement it in the next v3.1 (I'm also thinking of creating new public classes like BitStreamCompressor and BitStreamExtractor or adding functions such as compressStream and extractStream to the old classes, but I'm open to any API suggestion!).
I'd like to build this on Linux so my project can zip files without depending on libz. Would it be possible to separate the Windows-dependent parts from a platform-independent core, so that I can integrate the compression functionality into my project? If you can give me some ideas how to do this, I could give it a try.
It would also be nice to perform in-memory operations on the basis of stdlib classes such as
istreamandostream. I wouldn't normally have data in avector<byte_t>format. It can be converted without a copy, but it requires an awkward usage of vector. This is one the main reasons we have the stream classes.