I have the dm, cmd_disp, Evnt_srv, db_serv, and tiktrack
running. I did some radical revisions of the interface between
my "foundation" code and the application to allow all the
processes to be ported with very little tinkering of the source
There are two areas where I do need some clarification -- how
the message dispatcher fits into things and asynchronous pipes.
I am having a little trouble figuring out just what proxy and db_proxy
do. It seems that proxy.dll attaches to the message dispatcher and
passes DM_UNSOLICITED and selected ECS_ADR_OBJECT_FOUND
messages unchanged to db_proxy. In turn, db_proxy just relays the
messages still unchanged to db_api::md_dll_send. Here some
data blocks are added and the message is sent back to the message
dispatcher as DB_MSG_REBROADCAST. What was the reason
for separating db_proxy from db_serv? It seems like a lot of work
for little gain.
The second question has to do with asynchronous pipes. These
are used only two places: the tpm_api uses them in tpm_async_send
and in tpm_request_event. These do not seem to be used in the
actual scan core code. There is also a program in messdisp called
dmtest.cpp that uses asynchronous pipes. Is this useful or important?
My pipe system does now easily handle synchronous messages,
waiting for response data with a timeout period, but could not easily
do the async stuff. Could I forget about those cases?
Messages sent to the message dispatcher get distributed to
a variety of places, depending on what dll's the dispatcher
loads at startup time. Is it true that the only possibilities that
exist are the Asi (AsiDisp.dll), the ECS (md_evnt.dll), db_proxy
(proxy.dll) and, optionally, tiktrack (md_ttrak.dll)?
Specifically, in the messdisp directory, there is source code for
things like samdll, service_db, and win_disp. Is it true that these
are not part of the system? I believe that win_disp is now entirely
through the Asi and that the others are not used at all.
I have already ported md_evnt and md_ttrak. I have a question about