CrypticTim
Programmer
I have recently been employed to support an ageing product and facilitate a complete redesign too.
The product serves as an IT audit\license regulation\process blacklisting\remote admin complete security package. My areas are the client (a supposedly transparent, stealth app sitting on a host) and an active x control (message dispatcher and processor) used in a separate server application.
I want the new application to be multithreaded, and was thinking about a logical design of a thread-per-activity, that is, a main message-processing thread, a network-comms thread, a key-logging thread, a hardware-audit thread, a process monitoring thread, etc...
I want the threads to be event-driven is possible, in order that a thread cant post a message to the queue of another thread, and then keep on doing it's task. Of course, each thread will need it's own event 'stack', possibly with priority levels too...
I hope to easily segment the design and implementation of each unit for the possibility of assigning entire units to a developer without them needed anything more than documented function calls to interoperate.
With all this information, I also need to decide how I should assist the development. It will all be done in C++ but I have the possibility of using 3rd party libraries. If possible, I want to keep mixing & matching down to a minimum and standardize as much of the code as possible.
With all of this in mind, can anyone suggest some constructive criticism, or further explanation of certain areas, and give me some pointers on where to start. Should I totally embrace MFC or reject it and stick with STL, possibly looking at something like the boost libraries (checking on the license restrictions of course) and general design pointers too.
Thanks for any advice.
Tim
The product serves as an IT audit\license regulation\process blacklisting\remote admin complete security package. My areas are the client (a supposedly transparent, stealth app sitting on a host) and an active x control (message dispatcher and processor) used in a separate server application.
I want the new application to be multithreaded, and was thinking about a logical design of a thread-per-activity, that is, a main message-processing thread, a network-comms thread, a key-logging thread, a hardware-audit thread, a process monitoring thread, etc...
I want the threads to be event-driven is possible, in order that a thread cant post a message to the queue of another thread, and then keep on doing it's task. Of course, each thread will need it's own event 'stack', possibly with priority levels too...
I hope to easily segment the design and implementation of each unit for the possibility of assigning entire units to a developer without them needed anything more than documented function calls to interoperate.
With all this information, I also need to decide how I should assist the development. It will all be done in C++ but I have the possibility of using 3rd party libraries. If possible, I want to keep mixing & matching down to a minimum and standardize as much of the code as possible.
With all of this in mind, can anyone suggest some constructive criticism, or further explanation of certain areas, and give me some pointers on where to start. Should I totally embrace MFC or reject it and stick with STL, possibly looking at something like the boost libraries (checking on the license restrictions of course) and general design pointers too.
Thanks for any advice.
Tim