Professional Documents
Culture Documents
CHANGELOG
CHANGELOG
---------
[date] [ver]
2007-??-?? 0.0.1 pre-alpha version, fairly unstable; nothing much going on;
everything is a bloody mess
- reading directory
structure from root block is now possible in a very basic way
TODO: get rid of hardcoded
disk name (maybe let user specify disk name?)
TODO: support
subdirectories up to 2nd or 3rd level
(ideally, make things
*recursive*, but this is nothing for the faint of heart)
2008-10-28 0.0.12 fixed stupid bug in memory allocation routine, which built
up the structure
perfectly, but did not
free it properly - sometimes caused nasty GPFs.
Also merged block[i] and
block[i]->lword[i] allocations into one routine
(allocation was previously
done in two separate ones, which made no sense)
2008-11-04 0.0.22 Put old menu routines back in from first version.
Wrote __endian-aware__ get...
() functions which can get a
byte, word or long word from
either the superstructure or the
substructure. A Linux user
encouraged me to avoid using original
hton*()/ntoh*() macro family
names, because on his OS, these
would appear "in use" and
cause trouble! Thanks, fixed!
Still TODO:
Saddam/IRAK virus infection detection and decoding. The latter is not that easy
because the whole
block is (XOR?) encoded against something yet to figure out.
2008-11-11 0.1.0 ZIP files are now supported! After some fiddling with
Gilles Vollant's "minizip" contribution
(part of JL Gailly's & Mark Adler's zlib package), it
turned out that minizip unpacked to hard disk
instead of to memory buffer - no use for that, sorry! Also
in respect to users wanting to
check their READ-ONLY ADF CD-Rs!!)
So I switched to LiteUnzip.DLL API for unzipping. Not only
this works very well, but it also keeps
the executable size reasonably small.
Fixed ugly protection fault in a loop inside evalBitmap()!
(Don't you EVER attempt to read one boolean word BEYOND
the 1759th one! (arghh!!))
2008-11-12 0.1.1 ZIP file support code continued; now also more detail
possible in log file output.
RC is virtually ready for release!
2008-11-13 0.1.2 Some more minor fixes; trimmed down program header in
batch mode even more, because the BAT
[RC1] file is supposed to run unattended.
Added another variant of the LAMER virus (the one randomly
infecting blocks) with other case
in spelling (LAMER vs. Lamer).
2008-11-18 0.1.3bis source updates only! Win32 binary works and needs no
fixes.
Minor Linux tweaks:
- got rid of stricmp() completely by simply using a
combination of strcmp() and my own
strToUpper() function.
- due to malfunctioning endian macros: complete rewrite of
endian preprocessor stuff.
Now supports specialties of Linux, FreeBSD, NetBSD and
Cygwin. Put into its extra file now,
byteorder.h. Should build OOTB now on Linux-ish systems!
2008-11-21 0.1.4 Now uses typified log files: _NDOS, _ERR(oneus), _VIRUS,
_FFS, _OK, _IOERR (for I/O errors).
Fixed false reports of allegedly "correct" BAM key
detection with ZIP files, also helped
to trim down log file size even more.
DATA block checks now include header key check to avoid
phony detection of "data blocks"
in NDOS disks. Tricky stuff, because DATA blocks got no
secondary type.
Now supports over- and underdumps, as well as both types
of extended ADFs.
(Note: Due to their MFM-based nature, extended ADFs cannot
yet be scanned. Sorry!)
2009-10-23 0.2.0alpha3 Hooray, DMS checking finally works great now! (uses a
heavily stripped-down xDMS code
which had
to be partly rewritten so that it unpack directly to memory buffer in order
to avoid
ugly temp file writeouts)
- FILE
viruses that ADFCHK can detect now:
--
Jeff/Butonic (v3.10) [1.31 was already recognized correctly in alpha1]
-- Eleni 1
(MessAngel-B)
Other
stuff:
- Rob
Northen Copylock block ID ("RNC" signature) is now detected as well
and ...
FINALLY! Decomplexified adfchkerr.c by a great extent! Lots of redundant stuff has
now
been
removed.
Made printBAMInfo() more general and bigger in order not
to clog up the fairly comprehensive
core routine.chkErr() too much.
Forced
_NDOS suffix for even more NDOS disks (still too many NDOS disks were misreported
as
'_OK' in
the logs, which makes no sense since this condition is indeterminable when NDOS!)
Enhancements:
- Since
deep block T_DATA (0x08) scanning is still unsatisfying to me (if one of the
criteria
is not met,
block is deemed BLKTYPE_UNKNOWN), I've now rewritten the routines which handle
recognition
of data blocks (e. g. bad seq number, BUT valid header key etc.)
Everything
is much more refined now.
Rescanning
TOSEC set brought up a handful of new disk images with this type
of errors
(previously undetected)