- <para>Link the program with the "threaded" runtime system.
- This version of the runtime is designed to be used in
- programs that use multiple operating-system threads. It
- supports calls to foreign-exported functions from multiple
- OS threads. Calls to foreign functions are made using the
- same OS thread that created the Haskell thread (if it was
- created by a call-in), or an arbitrary OS thread otherwise
- (if the Haskell thread was created by
- <literal>forkIO</literal>).</para>
-
- <para>More details on the use of "bound threads" in the
- threaded runtime can be found in the <ulink
- url="../libraries/base/Control.Concurrent.html"><literal>Control.Concurrent</literal></ulink> module.</para>
-
- <para>The threaded RTS does <emphasis>not</emphasis>
- support using multiple CPUs to speed up execution of a
- multi-threaded Haskell program. The GHC runtime platform
- is still single-threaded, but using the
- <option>-threaded</option> option it can be used safely in
- a multi-threaded environment.</para>
+ <para>Link the program with the "threaded" version of the
+ runtime system. The threaded runtime system is so-called
+ because it manages multiple OS threads, as opposed to the
+ default runtime system which is purely
+ single-threaded.</para>
+
+ <para>Note that you do <emphasis>not</emphasis> need
+ <option>-threaded</option> in order to use concurrency; the
+ single-threaded runtime supports concurrency between Haskell
+ threads just fine.</para>
+
+ <para>The threaded runtime system provides the following
+ benefits:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Parallelism<indexterm><primary>parallelism</primary></indexterm> on a multiprocessor<indexterm><primary>multiprocessor</primary></indexterm><indexterm><primary>SMP</primary></indexterm> or multicore<indexterm><primary>multicore</primary></indexterm>
+ machine. See <xref linkend="using-smp" />.</para>
+
+ <para>The ability to make a foreign call that does not
+ block all other Haskell threads, and to invoke
+ foreign-exported Haskell functions from multiple OS
+ threads. See <xref linkend="ffi-threads" />.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fno-gen-manifest</option>
+ <indexterm><primary><option>-fno-gen-manifest</option></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>On Windows, GHC normally generates a
+ <firstterm>manifest</firstterm><indexterm><primary>manifest</primary>
+ </indexterm>file when linking a binary. The
+ manifest is placed in the file
+ <literal><replaceable>prog</replaceable>.exe.manifest</literal>
+ where <replaceable>prog.exe</replaceable> is the name of the
+ executable. The manifest file currently serves just one purpose:
+ it disables the "installer detection"<indexterm><primary>installer detection</primary>
+ </indexterm>in Windows Vista that
+ attempts to elevate privileges for executables with certain names
+ (e.g. names containing "install", "setup" or "patch"). Without the
+ manifest file to turn off installer detection, attempting to run an
+ executable that Windows deems to be an installer will return a
+ permission error code to the invoker. Depending on the invoker,
+ the result might be a dialog box asking the user for elevated
+ permissions, or it might simply be a permission denied
+ error.</para>
+
+ <para>Installer detection can be also turned off globally for the
+ system using the security control panel, but GHC by default
+ generates binaries that don't depend on the user having disabled
+ installer detection.</para>
+
+ <para>The <option>-fno-gen-manifest</option> disables generation of
+ the manifest file. One reason to do this would be if you had
+ a manifest file of your own, for example.</para>
+
+ <para>In the future, GHC might use the manifest file for more things,
+ such as supplying the location of dependent DLLs.</para>
+
+ <para><option>-fno-gen-manifest</option> also implies
+ <option>-fno-embed-manifest</option>, see below.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fno-embed-manifest</option>
+ <indexterm><primary><option>-fno-embed-manifest</option></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>The manifest file that GHC generates when linking a binary on
+ Windows is also embedded in the executable itself, by default.
+ This means that the binary can be distributed without having to
+ supply the manifest file too. The embedding is done by running
+ <literal>windres</literal><indexterm><primary><literal>windres</literal></primary>
+ </indexterm>; to see exactly what GHC does to embed the manifest,
+ use the <option>-v</option> flag. A GHC installation comes with
+ its own copy of <literal>windres</literal> for this reason.</para>
+
+ <para>See also <option>-pgmwindres</option> (<xref
+ linkend="replacing-phases" />) and
+ <option>-optwindres</option> (<xref
+ linkend="forcing-options-through"
+ />).</para>