How to bundle a few small utilities into a single exe? - join

I've written a Windows 7 batch file that "calls" two small audio processing utilities, Tag.exe and SHNTools.exe (to extract a CUE sheet frm a large FLAC file and split it into tracks) which I would like to bundle all together, including the .CMD file, into a single executable file for my own ease-of-use. Is there a freeware that bundles small apps/programs/utils in this way? Or failing that, what's the easiest way to do this? Thanks.

Found one that does what I need: Bat-to-Exe Convertor by F2KO Software, which packaged up the batch file and the two utilities into a single file and executed all three perfectly, as written and as called, when that new .exe file was run.

Related

Unconcatenating files

I have a corrupted 7-zip archive that I am extracting manually using the method outlined by Igor Pavlov at this link. An intermediate result is a large file that is a bunch of files cat'ed together that must be separated manually. I understand that some file formats will need to be extracted manually by a human using discretion (text files, etc.) but many file formats encode the size of the file as part of the file itself (e.g. .zip). Furthermore, some files can be parsed and their size can be deduced with just a little information about the file format (e.g. .pdf). Let's say the large file consists of the following files concatenated together:
Key: <filename>(<contents>)
badfile(aaaaaaaaaaabbbbbbbbbcccccccdddddddd) -> zip1.zip(aaaaaaaaaaa)
badfile2(bbbbbbbbbcccccccdddddddd)
I am looking for a program that I can run on a large file (call it badfile) that can determine the type and size of the first logical file (let's say it's a .zip file) contained within and create a new file to hold the contents (e.g. zip1.zip since filenames are lost) and chop the file off the front of badfile. This would allow me to run the program in a loop to extract files with known types and/or pause and let the user handle the difficult cases. Does such a program exist? I know that the *nix command file(1) will do a lot of the work here, but there would be a lot of effort in encoding rules for sizing files (e.g. .pdf) that I would prefer to not duplicate.
I believe this question should be closed due to being off topic as it asks to find existing programs to solve the problem, but open bounty prevents close vote. However.
Does such a program exist?
Yes they exist is and are called data carving tools.
Some commom ones include scalpel and foremost and PhotoRec
A list of other tools is avaliable here

join two different files into one file inside a zip (or elsewhere compressed) file

I have two files inside a zip file.
Now, imagine these two files are big... REALLY big... so big that I can't uncompress them into my old, poor, tiny hard disk.
However, they are simple txt files, so the zipped version is quite small.
I need to JOIN the two files into ONE single file.
As they're too big to extract, I need to do this INSIDE the zip.
Is there a way to do this?
Example:
"compressed.zip" contains "part_1.txt" and "part_2.txt".
I want "compressed.zip" to contain one file, called "part_1_and_2.txt".
(If it's not possible with zip, I can pick another compressor... but the idea is the same: each uncompressed file is bigger than total capacity of my hard disk)
Tnx!
It seems like you just need to ensure that the storage requirements are low; I don't think the operation needs to occur "within the zip file" per se. You can do this with command-line tools (in Linux or with similar tools via Cygwin) in the following way:
Start with a tarred, gzipped file with your input files in it. Let that be compressed.tar.gz. Then you can extract the contents of the gzipped tar archive to standard output and pipe it back to gzip:
tar xzf compressed.tar.gz -O | gzip > part_1_and_2.txt.gz
The resultant compressed file is the text of part_1.txt and part_2.txt concatenated (though I suppose it is not the same as having a tar archive that contains one file, but perhaps this will be sufficient).
If you need to do this within a program, I would guess that libtar and zlib can perform this functionality programmatically, or you can run a script from your program.
You can use libzip (which in turn uses zlib) to read uncompressed data from the input files in turn and write a new output zip file. You would not need to store all of an uncompressed file on the mass storage or in memory. You can read and write a small chunk at a time, as you would without compression. I presume that you have room on your mass storage for all three of those zip files.

Open a CBZ/CBR file in IOS

I am looking to integrate opening/viewing CBZ/CBR file in iOS6 (A simple viewer like UIWebView that reads PDF file will be fine as well).
Are are there any libraries (Commercial or free) that are available for opening these file types?
Thanks in Advance
CBR files are renamed .rar files and CBZ files are renamed .zip files, so you can look for a solution from there. I've never come across a library file specifically targeted for them, but that might not exclude the possibility of one existing, but as they're just standard compression files renamed to make them more portable between CBR/CBZ readers you should be okay with standard decompression libraries.
The library will spit out a number of image files when the decompression has finished, if you extract one with a standard decompression tool you'll see how they'll be presented.

Is it possible to do a 'unity build' with Latex source files?

Those who know C++ may know what I mean by 'unity build':
*.cpp files of a project are all effectively #include-ed into a single supermassive source file following #include directives specified in *.cpp and *.h files
this source file is fed into the compiler
finish! You get the output binary!
Doing things this way means that there are that there are fewer intermediate files (*.o), fewer file reads and disk IO overheads, fewer invocations of the compiler, leading to a better build performance.
My question is, is this possible for Latex at all? I want it because there is a slow post-processing pass that I would like to run over .tex files before building my final .pdf using pdflatex. Currently, it takes around 7 seconds to process my growing list of .tex files. I believe that running this pass over one file is significantly faster. This motivates my question!
To summarize, I want to
'merge' all the .tex files into a supermassive .tex source file by following the \input{} and \include{} macros in each .tex file
feed the supermassive .tex source file into the slow post-processing pass (actually the Ott tex-filter, fyi)
pipe the output straight into pdflatex
finish! I get the output PDF file!
The first step is the problem here. Any ideas welcome. It's best if I don't need to write my own script to do this step!
Many thanks!
A good tool that can handle this is rubber, with the help of its combine module. It will gather all dependencies, and produce a single file ready for consumption.

BlackBerry - Unpack Zip File

I'm developing a BlackBerry application in which I need to unpack a zip file compressed with PKZIP. The package could have one file in it, or it could have 10; it will vary in each case. I know that the BlackBerry API has native support for GZip and Zlib, although I'm pretty sure that these methods aren't going to be helpful in my case. It doesn't look as if I can extract the individual files using these calls.
I've tried JZlib (http://www.jcraft.com/jzlib/), which compiled fine, but again it doesn't look as if the methods contained therein are going to allow me to pull the individual files.
It appears as if this is possible, as there's an application called Ziplorer (http://www.s4bb.com/software/ziplorer/) that claims to do perform this exact procedure. How they're doing it, however, escapes me.
So here I am after hours of Googling. I'm welcoming any insight into my problem with open arms.
"zip" algorithms are typically offshoots of the Lempel-Ziv-Welch algorithm. They are a fairly efficient stream compression algorithms, but because of how they function, you can't start to decompress at random points in the file, you have to start from the start.
Any product that claims to be able to decompress one file from a zip still has to decompress everything before it in the zip file in order to know how to decrypt the given file, or even, for that matter, where the file is in the archive.
If you can tolerate GPL code in your application, then this library http://jazzme.sourceforge.net/ that might work. However the project (and its parent project http://sourceforge.net/projects/jazzlib/) don't look like they're being developed.

Resources