3rd‑party C‑Runtime DLL.
</p>
</div><!-- answer -->
+<button>What is Cygwin, and how does it differ from MinGW?</button>
+<div class="answer">
+<p>Originated by Steve Chamberlain, in 1995, like MinGW,
+Cygwin is a system which aims to make (primarily) GNU tools
+available on the MS‑Windows platform;
+however, the two systems adopt <em>entirely different</em> 
+methodologies to achieve this objective.
+</p>
+<p>Both systems are based on GNU tooling,
+and both use the GNU Compiler Collection (GCC) as the means
+of production for their respective application suites.
+Since GNU is fundamentally a POSIX system,
+both MinGW and Cygwin tools exhibit a POSIX feel;
+however, whereas MinGW strives to minimize its POSIX influence,
+using the MS‑Windows API <em>directly</em>, 
+and thus,
+MinGW applications may be classified as <em>native</em> 
+MS‑Windows applications,
+Cygwin has a much loftier objective ... it aims to provide a complete
+emulation of the <em>entire</em>  POSIX.1 API!
+This emulation is encapsulated within a single <code>cygwin1.dll</code>
+shared object library, which serves as a bridge between the POSIX.1 API
+and the MS‑Windows API, and upon which <em>all</em> 
+Cygwin applications are dependent; consequently,
+Cygwin applications are <em>not</em>  classified
+as <em>native</em>  MS‑Windows applications.
+</p>
+<p>The availability of the POSIX.1 API,
+furnished by <code>cygwin1.dll</code>, does generally reduce
+the effort required to port GNU applications to Cygwin,
+(for example, POSIX functions such as <code>fork()</code>,
+<code>mmap()</code>, and <code>ioctl()</code> may not be
+<em>readily</em>  implemented in terms of the MS‑Windows API,
+and would require <em>significant</em>  porting
+effort — if indeed it is even
+feasible — to
+support them in MinGW applications);
+however, the reduced porting burden of Cygwin <em>does</em> 
+incur the cost of the dependency on <code>cygwin1.dll</code>,
+and its attendant commercial,
+or strict “<em>copyleft</em> ” (GPL),
+licensing requirement.
+</p>
+</div><!-- answer -->
<button>What is MSYS?</button>
<div class="answer">
<p>A contraction of “Minimal SYStem”,
>the MinGW File Release System</a>.
</p>
</div><!-- answer -->
+<button>What is “make”, and how do I use it?</button>
+<div class="answer">
+<p>Originating in Unix,
+and now specified as a formally required POSIX.1 utility,
+(and even emulated by Microsoft, with varying degrees of fidelity,
+originally preserving the name <code>make</code>,
+and more recently supplanted by <code>nmake</code> ),
+<code>make</code> is a utility program to assist in the
+maintenance of an entire suite of application software,
+(or indeed,
+in the maintenance of any suite of published documents
+which must be generated from a collection of document source files).
+</p>
+<p>Controlled by a configuration file, known as a <code>makefile</code>,
+(or maybe, by a hierarchical system of <code>makefiles</code> ),
+which defines a “<em>dependency graph</em> ”,
+in which the relationships between generated files
+and their respective source files are specified,
+together with the sequences of commands which must be executed,
+to regenerate each of the generated files from its respective sources,
+<code>make</code> will, when invoked, compare the time‑stamps
+of each of the generated files with <em>all</em> 
+of its prerequisite source files, and,
+for any generated file which does not yet exist,
+or is found to be older than
+<em>any one</em>  (or more) of its sources,
+run the sequence of commands to create, or regenerate that file.
+This may offer significant benefit of time saving,
+when a large collection of generated files is to be maintained,
+since any which are found to be up‑to‑date,
+when <code>make</code> is invoked,
+do not need to be generated again.
+</p>
+<p>The MinGW.OSDN Project offers two variants of
+the GNU implementation of <code>make</code>,
+(which supports many functional enhancements over traditional Unix
+<code>make</code>, and POSIX <code>make</code> ):
+a variant simply called <code>make</code>,
+which must be run in the MSYS shell environment,
+and a further variant suitable for use from <code>cmd.exe</code>,
+known as <code>mingw32‑make</code>.
+Each of these is used in, fundamentally, the same manner.
+However, a discussion of <em>how</em>  to use them would be
+too extensive to conveniently cover here;
+we suggest that you refer to <a target="_blank" rel="noopener noreferrer"
+ href="https://www.gnu.org/software/make/manual/"
+>the online GNU <code>make</code> manual</a> for guidance.
+</p>
+</div><!-- answer -->
<button>How can I get help, if I can’t find an answer here?</button>
<div class="answer">
<p>Presumably,
>this additional user guide</a>.
</p>
</div><!-- answer -->
+<button>I’m working on Windows‑XP,
+but the MinGW compiler doesn’t seem to recognize this;
+is this a bug?
+</button>
+<div class="answer">
+<p>No, it is <em>not</em>  a bug.
+The version of Windows, on which you are working,
+is <em>fundamentally irrelevant</em> ;
+what <em>is</em>  important is the extent to which
+you would like your application to run on older versions of Windows,
+and, in line with MinGW.OSDN’s legacy platform support policy,
+the MinGW compiler sets its <em>default level</em>  of API
+support <em>very</em>  conservatively,
+to ensure support for <em>all</em>  versions of Windows,
+from Windows‑NT4 (or Windows‑95) onwards.
+</p>
+<p>Of course,
+you may wish to take advantage of some newer API capabilities,
+which are not supported on these legacy versions of Windows,
+and you are willing to sacrifice legacy support in order to do so.
+In this respect,
+MinGW and Microsoft’s compilers exhibit similar behaviour,
+(although newer versions of Microsoft’s SDK may set a less
+conservative level of legacy support);
+if you wish to support any API function,
+which is not supported by the compiler’s default Windows version,
+then the onus is on <em>you</em>  to enable support for the
+newer API version,
+as stipulated in <a target="_blank" rel="noopener noreferrer"
+ href="https://docs.microsoft.com/en-gb/cpp/porting/modifying-winver-and-win32-winnt"
+>this Microsoft documentation</a>,
+(but note that,
+whereas Microsoft no longer offer support for Windows‑2000,
+or earlier, nor any version of Windows‑9x,
+MinGW <em>does</em>  endeavour to support these legacy Windows versions,
+by setting <code>WINVER</code> and
+<code>_WIN32_WINNT</code> — and
+<code>_WIN32_WINDOWS</code> for
+Windows‑9x — to
+appropriate values,
+as defined in the MinGW version of <code><sdkddkver.h></code> ).
+</p>
+</div><!-- answer -->
<button>Why does the MinGW linker
persistently report “undefined reference” errors,
when I have specified all of the libraries
OSDN Git Service
