Click here to Skip to main content
14,843,569 members
Please Sign up or sign in to vote.
3.67/5 (2 votes)
I have created a program which uses a dll as its main system, in which I have created a debug system which reports to a file or sdtout or both.

but for a release version I wish to use a seperate application to use as a console for receiving the debug trace.

I want it to be independant of the application (.exe) so I have thaught of two methods to use and would like to know if either are applicable to what i need.

1. Use DDE to send info to an external app.

2. in the dll itself create a seperate process and inside it, a thread to act as the debug app thread ( if creating a process doesn't provide an initial thread. ) -> If the .exe initiates the dll, will a second process hang around without adverse effects if the .exe goes bang?

BTW, is this unmanaged code, or .Net?

You can't run a DLL as a process. I had to do the same thing a bunch of years ago, and I just used interprocess comms by sending registered messages back and forth between the apps. You can send pointers to strings between the apps. There are a number of non-COM methods for accomplishing what you want:

In the ineterest of completeness, there are a number of ways to implement interprocess comms that don't involve COM/DDE.

0) Registered messages that all of the applicable applications know about
1) Named pipes
2) TCP/IP sockets
3) Shared memory via a DLL.

IMHO, you'd be better off creating a modeless window in your application that the user can show/hide via hotkey or menu selection (or both), and stick the code for it into a DLL. That way, your app would use the DLL if it's there, or run normally without it.
ACE[^] has just what you need - a flexible robust mechanism for logging

Here is a wee bit of info on Using the ACE Logging Facility[^]

From your description, I would guess you could benefit from using ACE in a number of other ways too :)

Espen Harlinn
Not sure what you are trying to do, but it isn't difficult to create threads. You just have to be careful that you neither create too many nor create deadlocks and race conditions.
chris4562 21-Jan-11 7:59am
nah I use a few threads, this app needs to be completly independant of the app being debugged. I solved the problem with registered messages and memory file maps. A thread in an app that has its process terminated also dies.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900