Tree [8a2086] master /
History



File Date Author Commit
doc 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
API.html 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
APP.html 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
Leiame.html 2014-07-27 Tibério Vítor Tibério Vítor [43296d] 1.0.5, ready to increase\!
License unknown
Licença unknown
Makefile 2014-08-18 Tibério Vítor Tibério Vítor [8a2086] Makefile per buildmake update.
PLANO 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
Readme.html 2014-07-27 Tibério Vítor Tibério Vítor [43296d] 1.0.5, ready to increase\!
difbaplica.c 2012-11-09 TvTooninhu TvTooninhu [a98feb] PPF3 undo reading fix
difbaplica.h 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
difbcheca.c 2012-11-09 TvTooninhu TvTooninhu [a98feb] PPF3 undo reading fix
difbcheca.h 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
difbcria.c 2014-07-11 Tibério Vítor Tibério Vítor [1b5183] Only makebuild system left.
difbcria.h 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
difbgeral.c 2014-07-11 Tibério Vítor Tibério Vítor [1b5183] Only makebuild system left.
difbgeral.h unknown
difbin_form.c 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
difbin_form.h 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
en.po unknown
format.c 2014-07-11 Tibério Vítor Tibério Vítor [1b5183] Only makebuild system left.
format.h 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
ips.h 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
ppf.c unknown
ppf.h 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
rle.c 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
rle.h 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
terminal.c 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
tunacheca.c 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
tunachecap.1 2014-07-27 Tibério Vítor Tibério Vítor [43296d] 1.0.5, ready to increase\!
tunacria.c 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
tunacriap.1 2014-07-27 Tibério Vítor Tibério Vítor [43296d] 1.0.5, ready to increase\!
tunaplica.1 2014-07-27 Tibério Vítor Tibério Vítor [43296d] 1.0.5, ready to increase\!
tunaplica.c 2012-11-07 TvTooninhu TvTooninhu [28a110] 1.0.0 GIT START
tunatch.1 2014-07-27 Tibério Vítor Tibério Vítor [43296d] 1.0.5, ready to increase\!
tunatch.3 unknown
tunatch.pot unknown

Read Me

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
<meta content="application/xhtml+xml; charset=utf-8" http-equiv="content-type"/>
<meta content="en" http-equiv="content-language"/>
<meta content="index, tvtoon" name="robots"/>
<meta content="Tunatch project documentation." name="description"/>
<title>Tunatch readme.</title>
</head>

<body>

<h1>Tunatch readme.</h1>

<h2>1 - Index.</h2>

<ul>

<li>
<a href="#h2.0">2 - Introduction.</a>

<ul>

<li>
<a href="#h2.1">2.1 - Features.</a>
</li>

<li>
<a href="#h2.2">2.2 - Requirements.</a>
</li>

<li>
<a href="#h2.3">2.3 - Usage.</a>

<ul>
<li><a href="#h2.3.1">2.3.1 - Tunaplica.</a></li>
<li><a href="#h2.3.2">2.3.2 - Tunacriap.</a></li>
<li><a href="#h2.3.3">2.3.3 - Tunachecap.</a></li>
<li><a href="#h2.3.4">2.3.4 - Tunasertap.</a></li>
<li><a href="#h2.3.5">2.3.5 - Tunatch.</a></li>
</ul>

</li>

</ul>

</li>

<li>
<a href="#h3.0">3 - Known Issues.</a>
</li>

<li>
<a href="#h4.0">4 - Contact.</a>
</li>

</ul>

<h2 id="h2.0">2 - Introduction.</h2>

<p>
Tunatch, from "tu no patch" (you in the patch, *coff* nothing to do with my nickname),
is a project for applying, creating, manipulating and checking differential
binary patches.
The objective, besides dealing with different formats, is to create an official
platform to be used in operational systems, as I have not seen something like that
being explored.
</p>

<p>
In the future, this project will support known formats like XDelta, UPS and even
NINJA, but the purpose behind the implementation of such alternatives is
simply building a general base for their functions (delta and such).
Case you are wondering, yes, in its own format.
</p>

<p>
For details about the formats, commit to the "doc" folder (some docs aren't in
english).
</p>

<h2 id="h2.1">2.1 - Features.</h2>

<ul>

<li>
Application, creation and checking of basic differential binary patches.
</li>

<li>
Internal RLE (will be separated later) molded by IPS.
</li>

<li>
Expansion disponible, trough the extensible reading of programming
languages standards!
</li>

<li>
Written in C, but supporting totally C++ and, until noted otherwise,
32-bits safe!
</li>

<li>
EXCLUSIVE INCREMENTAL PATCH FOR MAINFRAMES! :O
</li>

<li>
Will never be fool proof!
</li>

</ul>

<h2 id="h2.2">2.2 - Requirements.</h2>

<ul>

<li>GNU Make.</li>
<li><a href="http://sourceforge.net/p/buildmake">BuildMake.</a></li>
<li>ANSI C compiler.</li>
<li>
Some implementations compatible with POSIX, take note: getopt() function; and
fseek() behavior, for the expansion while applying patches.
</li>
<li>Personal holdings tunalib (available at this project page).</li>

</ul>

<h2 id="h2.3">2.3 - Usage.</h2>

<p>
At the moment, comes with 3 programs: applier, creator and
checker for binary patches. A fourth one is planned to fix stuff.
</p>

<p>
To use other formats beyond default binary patch, the "-f" option must be
specified, followed by a valid identifier.
</p>

<p>
To know which identifiers are valid, and their relationship, use the "-l"
option.
</p>

<h2 id="h2.3.1">2.3.1 - Tunaplica.</h2>

<pre>
tunaplica [-e in_file] [-f format] -h [-p patch_file] -u --
</pre>

<p>
This applier needs at least 3 arguments: program, patch file name and the
application file name. If any argument is invalid, they will be evaluated
in this same order, then as input error.
</p>

<p>
The undo option (-u), at the moment being, only works with PPF3 holding such
data!
</p>

<p>
After the arguments closure mark (--), the next ones will be considered:
patch and input name.
Any others following arguments will be ignored.
</p>

<p>
The program solves the argumentation, returning "1" for argument errors;
then initializes the format type (being an invalid format still an argument
error) and the files ("2" for error); analyzes the type, according to the
patch header; and go to the patch application, calling the function according
to the type found.
The final check is made to know if there is a legit data size left in
the patch (footer, if any), returning error "3" or the operation success.
</p>

<h2 id="h2.3.2">2.3.2 - Tunacriap.</h2>

<pre>
tunacriap [-b block_size] [-d description] [-e original_file] [-f format]
          -h [-i endianess] -l [-m data_size] [-o offset_size]
          [-p patch_file] [-s modified_file] [-t binary_image_type] --
</pre>

<p>
This creator needs at least 3 arguments: program, patch file name, original
file name and modified file name. If any argument is invalid, they will be
evaluated in this same order, then as input error.
</p>

<p>
The options "-b", "-m" and "-o" are used to create variations of the default
binary patch, altering the units number limit (bytes), case you need or
wish to test something beyond the "max value". Cautious is needed to not create
defective patches with these options: the "-b" relies on "-m" and you cannot
break the limits from your machine, for a while.
Example: "-b 65535 -m 2 -o 3" equals IPS.
</p>

<p>
The "-d" option includes descriptions for formats using them.
Example: "-d \"Cool binary patch.\""
</p>

<p>
The "-i" option swaps the integers endianess of the default binary patch.
Example: "-i b", for "big endian", and "-i l", for "little endian".
</p>

<p>
The "-t" option tells the image type for formats using them.
Example: "-t 0" is the default binary image for PPF3.
</p>

<p>
After the arguments closure mark (--), the next ones will be considered:
patch name, original file name and modified file name.
Any others following arguments will be ignored.
</p>

<p>
The program solves the argumentation, returning "1" for argument errors,
then initializes the format type (being an invalid format still an argument
error), checking the proper options for the default binary patch
(argument error), and the files ("2" for error), writes the header according
to the format, go to the patch creation, calling the function according
to the type found; and go to the expansion route, depending on the result
from the creation and, again, according to the type.
The final condition is given by the return of the creation or the expansion.
</p>

<h2 id="h2.3.3">2.3.3 - Tunachecap.</h2>

<pre>
tunachecap [-e optional_input] [-f format] -h -l [-p patch_file] --
</pre>

<p>
The optional input file is used in format header checkups, like the file
size and byte sum.
</p>

<p>
After the arguments closure mark (--), the next ones will be considered:
patch name and optional input name.
Any others following arguments will be ignored.
</p>

<p>
The program solves the argumentation, returning "1" for argument errors;
then initializes the format type (being an invalid format still an argument
error) and the files ("2" for error); analyzes the checking type, according to
the patch header (needed because of PPF3 undo); repeat the process to the
header checking, informing the error total and individually for each format;
check whether the patch limits are bigger than the machine ones, informing if
the patch have surpassed them; check the main part of the patch, the modified
blocks, calling the function according to the type found, and showing the
results; and, finally, go back by the return of the block checking, in the
file, to check the end of the patch file, informing the result both from this
one and the final error quantity.
</p>

<h2 id="h2.3.4">2.3.4 - Tunasertap.</h2>

<p>Post apocalyptic patch fixer.</p>

<h2 id="h2.3.5">2.3.5 - Tunatch.</h2>

<p>
The lonely solution, always will have the basic! Don't trust on it for more
complex possibilities, it won't be supported!
</p>

<h2 id="h3.0">3 - Known Issues.</h2>

<p>
In a complete system, the "-f" option should not exist and you would use
proper functions from it to identification.
</p>

<p>
The creation of an undo-enabled PPF3 (or anything binary for that matter) patch
won't be supported! Firstly, I don't consider that good practice. If you really
want to do that it is better to just create 2 patches: the modified and the
undo one.
The application or undone from PPF3, with such data disponible, is supported!
Furthermore, if you wait, maybe the "XOR" version will be out soon...
</p>

<p>
Many things inside "format.c" should be, in theory, automatically generated.
What happens is that the small number of formats still don't intimidate me.
</p>

<p>
The repetitions found in "difbaplica.*", "difbcheca.*", "difbcria.*",
"difbgeral.*" and "format.c" are due, mainly, two motives: internal RLE and PPF.
Using C++ also would help a bit...
</p>

<p>
Yes, the way the header checkup is being made don't please me, being the PPF
the biggest problem. I think that creating a header buffer and getting
everything trough it will be the future.
</p>

<p>
I am still studying what to do about internationalization in my works...
</p>

<h2 id="h4.0">4 - Contact.</h2>

<p>
If you have some development work or suggestion, send me a mail trough Gmail:
tvtoon@gmail.com . It is the only mail address that I am still using.
I would be grateful to know how my program is compiling in others
platforms (something mobile-like would be great knowledge).
</p>

</body>

</html>