Let's assume that there are no command-line arguments. How do you pass input data to a program?

I'm thinking you'd write the input to a file with a specific name, such that the program knows to open and read it as input. However, how would one discover the name of that file? Usually, running a command-line program without arguments or with some standard help argument (e.g. \?) produces some instruction on how to use it. But given an environment with no command-line arguments, how does one discover how to operate a program?

Ah yes, one could read the program file and it could contain a standard header with this information. Though that somewhat postpones the issue - somehow you must then discover that standard.
–
Core XiiMar 19 '12 at 13:27

2

The idea is to dump all the strings in the program. This can display a lot of interesting information, and one of those could be name of the file he is looking for.
–
karlphillipMar 19 '12 at 13:29

In the .NET world, this is achieved with the use of an app.config file included with your source code. This is copied to the output folder with a name following the convention "MyApp.exe.config" where your application is "MyApp.exe".

A standardized, human-readable, self-documenting file describing the program's operation, supplied with it. Also known as a manual. Funny that didn't occur to me.
–
Core XiiMar 19 '12 at 13:43

I'm not sure what you're saying. I've not described the manual in the answer.
–
RichardMMar 19 '12 at 14:10

Well, that's the idea you gave me anyway. What I got from your answer was that there's some other, standardized file supplied with the program that hints to its operation one way or another.
–
Core XiiMar 19 '12 at 14:22

Yes indeed. Though, without command-line arguments, there are no pipes, and as such, standard I/O would likely not be present as it'd be somewhat useless.
–
Core XiiMar 19 '12 at 13:49

@CoreXii you may want to clarify your question pointing out that no standard I/O is expected to be used, either
–
gnatMar 19 '12 at 13:54

It's not that it isn't expected. If it's the best solution, it's certainly valid. But given that pipes don't exist, I'd explore others first.
–
Core XiiMar 19 '12 at 13:58

1

@Core Xii: Mistaken assumption. There is no reason to presume that pipes exist only in the presence of command lines. Win32 on Win95 is an obvious counter-example. It did have pipes, but not CMD.EXE (the 32 bits command line).
–
MSaltersMar 19 '12 at 15:01

You could look at COM, as implemented by Microsoft. In that system, the OS loads your DLL into memory when someone needs an object of your type. If anyone needs to pass information to that object, it can use the standard IUnknown::QueryInterface(GUID) method to obtain an well-known interface, and then pass information via that interface.

Of course, if your object doesn't have such an interface, it'd return E_NO_INTERFACE. But that's no different (just eassier to debug) than a CLI program ignoring its arguments.

Many Operating Systems already have the concept of "environment variables". This is a set of named values that are passed to every process, in addition to the command line arguments. Using C, you'd access them with getenv().

Similar to the /? convention for command lines, the OS writer can define a convention that the presence of a HELP variable in the environment means that a program should show usage information. In C code: if (getenv("HELP")) { ShowHelp(); }

If you have to instruct an application about its job without parameters I think you can call that...configuration in the more old meaning of the term. Depending on the environment (Windows or Linux?) and the language/framework (Java? Any .NET language?) your choice will be really different.
You speak about

an environment with no command-line arguments

so I guess you do not have a console application. Moreover I guess (again) that your application when launched will do its job and then terminate. So your question is "how users may change application options?".

You can use a configuration file, what - in this case a more advanced - user will expect depends on the environment. I don't think it's a good solution for end-users or non technical personnel. They have to know or to guess that in the application directory (or in the user home directory or something like that) there is a configuration file of some sort.

You can provide some kind of help (man page, plain text file, HTML help or HTML file) to teach your user what to search and where. I think you should always do this but sometimes technical details aren't clear for every user and you give them a chance to break your application in many many ways because a wrong configuration (they may save your configuration file with the wrong encoding, break its syntax, write something stupid).

Finally the solution I prefer: you may provide two applications, one to do the job and another one for configuration purposes. Configuration is still saved somewhere (so advanced users may enjoy more advanced esoteric options) and normal users will have a user-friendly interface (like xconfig, for example).

The format used to store these data is up to you. Usually I think to be coherent with the environment is the most important thing but how your application will be used is also important: you may use the Registry (in Windows), XML configuration files, JSON configuration files, INI-like configuration files. It depends on the kind of data you need to store. Sometimes a simple text file for command line arguments used as response file is enough.

UPDATED

If your application may have multiple configurations and multiple instances you need to make the configuration file runnable. How is environment dependant. In Windows, for example, you may register a ".MyApplication.config" file extension. Users won't run (with double click...) the application itself but the configuration file, application will be run by OS with the configuration as parameter.
Configuration will be a document and user will see that document, not the application (moreover you may provide extra verbs for editing).

It's not about configuration but input. While one might argue that the input to a program is a manner of configuration of its operation, the main point here is that each invocation of the program calls for different input, and several instances of the program may be running at once. Therefore it's not feasible to direct the program to the desired input from a single configuration file (as it would have to be opened exclusively by each party). Your assumption that the program does its job and terminates is correct.
–
Core XiiMar 19 '12 at 14:16

You read the user's manual. Then you use some sort of input device like a keyboard or mouse to control the program. If the program requires a large amount of data, you can direct it to a file. Directing a program to a file has varied widely through the ages, but has standardized to OS typical popup windows.

If it's a command line program, with no command line arguments, then you are dependent on the program's interface. At some point you probably have to type in the path to the file name.