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.
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).