The Factor UI runs by default if it can:

• macOS: Double-click Factor.app or run open Factor.app in a Terminal to start the UI; run ./factor in the Terminal to start a command-line listener
• Windows: Double-click factor.exe, or run .\factor.com in a command prompt, to start the Factor UI
• Unix: Run ./factor in a shell to start the Factor UI if $DISPLAY is set. If $DISPLAY is not set, this will start a command line listener

To start a command-line listener on Windows or Unix, pass -run=listener to the VM. For more information about command line switches, see http://docs.factorcode.org/content/article-command-line.html.

Windows: Difference between factor.exe and factor.com

On Windows, factor.exe is the preferred executable to use when launching Factor from Windows Explorer, whereas factor.com should be used from the command prompt.

Running factor.exe from the command prompt will suppress standard input and output, and running factor.com from Windows Explorer will open a console window, even if the Factor UI is running.

On other platforms, the same Factor VM binary is able to be used in both command-line and graphical modes, but on Windows, whether or not a program can use the console is a property of the executable file itself, and not of the program's runtime. Two executables are needed; building solely as a console application is unacceptable, because even if a hack is added to the VM's main() function to hide the console as soon as the program starts in graphical mode, it would still flicker on the screen. There is no way around this with the Win32 API.

macOS: the Factor.app bundle

On macOS, the factor binary at the top level of the source tree cannot run the Factor UI; it always runs the command-line listener. The Factor.app bundle runs the UI by default.

It is also possible to run Factor.app in command-line mode, by issuing the following in the Terminal, and this is in fact equivalent to running the VM using the factor binary at the top-level:

./Factor.app/Contents/MacOS/factor -run=listener