Most people visiting this site want just a Windows program executable, normally that's enough, if you want help using it, mail me from the support page, I love getting questions.
Please don't look at the code, it's not too re-usable but - it's GPL v 3 , so please abuse as necessary.
I originally published the source on codeguru.com, but due to file size (site not designed for full-blown applications) issues and lack of version-control I moved to sourceforge.
The source code is free to download from the sourceforge website. You can also browse the code in SVN here . It's not the greatest codebase considering I started writing it about 12 years ago and it's showing its age badly. Something most software does after it has been maintained for more than 10 years incidentally.
I recently added a MSI project installer and some initial automated test framework code to the project. The test-framework is not getting a lot of my time, mainly because it's only to prevent regressions, and mainly because to do it right I'll really need to spend a day each out of the next 50 weekends creating test-code to do the job right. I'm not that brave.
Source documentation does not exist, primarily because when I started writting this program, the concept was furthurest from my mind, I was wanting to do just one thing, simulate a Texas-Instruments TI500 serial port, because there was only one available to me in the country, and it was on loan for 2 weeks, after that it was going to sit in the hottest town in South Africa if I needed to test with it. So the design was pretty hurried, and getting doxygen to generate a diagram was pretty much spaghetti by the time I got around to it.
--todo: paste the doxygen diagram in here anyway someday--
Basically the design uses inheritance a lot as opposed to interfaces which I currently prefer these days.
Both the serial and TCP modes use a thread for communications, they use a syncronization object to then get access to an array and some parameters which describe all of the registers, inside the sync object the threads can modify the register array data and can post a hint message up to the main UI thread (only MFC threads can update the UI, worker threads may not do so without slowly hosing MFC). Along with a notification that the comms LEDs must update and a notification about which registers need to be repainted (the GUI only repaints registers that are visible and modified, else the graphics load would get ugly) there are also per-station LEDs to update.
Once that is done, a debugging trace message is posted as text into the debugging queue, and the sync unlocked.
The GUI thread handles the messages and paints accordingly, when it comes to handling the debugging trace, it uses a circular buffer, this patttern is popular and has worked for me well in the past.