views:

201

answers:

8

So I have a C program that runs on the Windows Platform that periodically sends emails of log files , it is supposed to run in the background with no interference. I don't want to make the email address a constant.

What are some ways to input an email address into this program?

I was thinking of a simple script that just takes parameters like email address, subject, etc. Then just make the script make a text file with like labels somewhat equivalent to:

TO email address FROM email address SUB sub

And then just have my program read these values and assign them to symbolic variables. than delete the config file.

What are some other ways?

A: 

Registry! :-P

Chris Jester-Young
Would the registry be a better bet?
+2  A: 

you can also use windows registry.

Ankit
Well there was hardly difference of some seconds
Ankit
+1  A: 

Is there a reason you couldn't modify the program to just read the arguments list you could pass with it during startup and set you "to" and "from" that way?

Example: program.exe [email protected] [email protected]

TheTXI
Well it is supposed to be "hidden process" it is the skeleton of a administration program.
If that is the case, the same method could be used in executing the program (though I doubt this is your big concern now based upon the new information) based upon whatever you decide to store, however you decide to store it. The other suggestions about using the windows registry seem to be pretty spot on. Other suggestions would include things like simple config files that keep track of these values for you.
TheTXI
+3  A: 

Putting on my lateral thinking cap here... How about you make the email address constant (or configurable, anyway) but make it a list address. Have your mail server manage subscriptions to the list. Now your program does what it's good for (collecting logs) and the mail server does what it's good for (distributing email) with a very small interface between them (the list address).

Editing some obscure configuration file or registry entry somewhere every time you need to add/remove someone from list of log recipients is probably not the best way to handle this.

veefu
A: 

I live in a linux world myself so i have pipes to take care of this situations but I have heard of the following being done on windows:

Its possible to take control over GUI elements (or controls) of other windows using APIs and for example fill out the To, From and Data fields and then send a pressed event to a button of a simple email program. The sneaky part is getting this to happen in the background. Once again using APIs it is possible to make the email program's window have the "hidden" state making it invisible. Hidden windows can still have their handles manipulated as if they were normal windows.

So this should give you the effect of background control of a program in windows, I know its been done but i have never looked in to it personally. It seems to not be the most efficient in the world but its a cool trick. :)

C-o-r-E
+4  A: 

Some other ways are:

  • Registry
  • Configuration file
  • Command line options
  • Environment variables
  • Shared memory

Registry

Using the registry is appropriate for many kinds of configuration information. By choosing a suitable place in the registry, you can make some configuration system-wide, some configuration per-user (which doesn't sound like your application but I'll mention it anyway), or any combination of the two. Windows manages the storage of the data and provides a rudimentary way for users to edit it (regedit.exe).

Using the registry makes it more difficult to run more than one instance of your program with different options at the same time.

Configuration file

You can store configuration information in a text file on disk. This allows you to keep the configuration in the same place (same folder) as the executable, which makes it easier to find (when using the registry, you have to tell the user where to look). Configuration files can usually be edited with a regular text editor. However, generally you will have to specify what format is to be used and to read and parse the text file, handling syntax errors if needed.

This method allows you to easily run more than one instance of your program, each with its own separate configuration file (if your app looks in its own directory for the config file, for example).

Command line options

Your program can read its configuration information from the command line, but you still have to store the data somewhere else. The command line can only support a limited amount of information before it gets unwieldy.

Environment variables

Your program could read its configuration information from environment variables. These might be variables that are set by a script that runs your programs (where you have the same problems as command line options, the data must still be stored somewhere else) or might be a globally set environment variable supplied by the system. Windows provides very primitive tools for changing the global environment, less accessible than even regedit. This choice is not often used on Windows.

Shared memory

This is an advanced technique that requires cooperation with some other program that puts the data into shared memory. And, like many other choices, the data must still be stored somewhere else in the first place. Not recommended unless you really know you need it.

Greg Hewgill
Could you point me in the direction for shared memory?
Have a look at the CreateFileMapping and MapViewOfFile Win32 API functions: http://msdn.microsoft.com/en-us/library/aa366537(VS.85).aspx Although the name refers to mapping files, you can create arbitrary shareable memory chunks by passing INVALID_HANDLE_VALUE for hFile.
Greg Hewgill
A: 

I personally would use Boost.Program_options, which would allow you to have a config file or command line parameters (or both!) -- though you tagged this C/C++, and Boost is for C++ only. Still, it shouldn't be hard in C just to have a config file and fscanf it. There's also always argc and argv.

rlbond
A: 

Your program could open a socket and accept data over the socket. Then you would need to have at least a simple protocol with some security. You'd probably also have to write a client of some sort. From your description, I would suggest one of the other answers provided, but this could be a viable option for some situations.

Sam Hoice