The "HACKING" file is usually a README for developers.

In case anyone else attempts to do anything to dclib's code, here as some of
the reasons why it is essentially planned to abandon it completely.

* Originally dclib used nothing from the standard C++ library,
instead implementing everything itself, including:
- A string class which used to claim it was implicitly shared in the header,
but it's not, and it's mostly passed around by value. Millions of strings used
to be burned through during filelist refresh, a bit less now.
- Pointer based linked list always with auto delete.
- Pointer based hash table where the "hash" function is take the
first character, recursively implemented to use more characters.
In addition the remove without delete always used to forget the
"without delete" part when more than the first character was used
(bug not hit by any current code).
- A thread class which calls it's "run" method repeatedly until somebody
calls stop, also it inherits the mutex class.

* Almost everything in dclib runs on the same thread (CManager), every
connection inherits CThread, none are started. Each hub or peer connection
has about 5 mutexes (CThread inherits CMutex, CConnection contains 2 CMutexes,
CDCProto has a CMutex, and then CClient and CTransfer have a CMutex). There is
mutex locking and unlocking everywhere, presumably mostly for protection
between CManager's thread and the GUI.

* The hash database keeps nothing in any particular order, and is implemented
using a few byte arrays, so is highly prone to error, plus the data saved to
disk is CPU (endian, word size) dependant.

* CSearchManager is mainly designed for taking hubs from a long list,
automatically connecting to them, sending a search, waiting for some results
for a little while, then leaving.

* There is no verification of the received data using the TTH leaf data,
mostly due to TTH support being added later without re-designing various
classes.

* Almost any change to dclib will break binary compatibility. dclib being
separate from valknut is not helpful.

* dclib using anything other than QT classes is not helpful.


There were some efforts to fix some of the above issues, usually re-writing
everything to use std::list or std::map instead of CList or CStringList, or
to not use up so many CString objects. Some improvements were made but most
efforts were not finished due to attention moving elsewhere.

I now consider creating a new ADC client, with support for the old NMDC
protocol, without using much from dclib or even valknut, done entirely
in QT 4.4, will not only end up better, but get there faster and with
less effort, than continuing to completely re-write dclib over and over again
a little bit at a time, attempting to improve it. Continuing to attempt to
improve dclib will most likely result in another 50 broken versions
and ADC support will never even get started.

--

Edward Sheldrake, ejs1920@yahoo.co.uk, October 2008

