Laura Michaels' MinGW FAQ

While I was the original maintainer of the MinGW FAQ, I picked up many tips and tricks for working with MinGW from the MinGW32 mailing list, its members, various MinGW related web sites and my own experience. Thanks go to the people who worked on MinGW, MinGW32 mailing list members and the site developers who maintained MinGW related web sites. Special thanks go to Franco Bez for some of his source code examples on how to create a dll using dllwrap and other suggestions he made for the original FAQ.

I no longer have the time or the need at work to stay as involved with what's going on with the MinGW project. I am not even using the official version of MinGW. I have switched to working directly with the GNU gcc/g++ compiler suite and a runtime library of my choice. However, I still, quite often, find myself referring to some of the information I collected in the FAQ over the years and to information I continue to collect. Since I find it useful, I'd like to share a copy of my personal version of the FAQ as it currently stands. For ease of maintenance, I've removed many of the off-site links. I do still post links related to C/C++ and MinGW on the CppDesign mailing list where it's easier to keep up-to-date with that type of information.

If you have any further questions, please refer them to the MinGW project of your choice. I will update this page as I run across any other interesting tips and tricks I'd like to remember.

Please note: This FAQ is copyrighted and it is in violation of copyright laws to distribute it without the permission of the author. If you're interested, feel free to read the reasoning behind this decision.

Table of Contents:

  1. What is MinGW?
  2. Copyright issues
  3. The Fracturing of MinGW
  4. msvcrt vs crtdll?
  5. Using older versions
  6. Where to get MinGW
  7. How to install
  8. Mailing lists
  9. MinGW as a portable app
  10. Other compiler distributions
  11. Help
  12. Runtime libraries
  13. Debugging
  14. IDEs and editors
  15. Using MinGW as a cross-compiler
  16. What is msys?
  17. How do I customize msys?
  18. Compiling and building
  19. How do I link to dlls created by other compilers?
  20. More compiling and building issues
  21. Compiler output
  22. COM support
  23. Preprocessing
  24. Make programs
  25. Patches
  26. Is there a package manager or build script system?
  27. GUIs/application frameworks/user interfaces
  28. Libraries
  29. Other programming tools
  30. Why is this FAQ copyrighted?

To the main page.

 
  1. What is MinGW?

    MinGW is a compiler system based on the GNU gcc/egcs projects that compiles code to be run on Win32 (Windows) systems. It provides C, C++ and Fortran compilers plus other related tools. 'MinGW' refers to the "Minimalist" Gnu-Win32 project. If you see references to MinGW32 instead of MinGW, they are referring to the same compiler system. The project's name change from MinGW32 to MinGW is to prevent the implication that MinGW will only works on 32 bit systems. As 64 and higher bit machines become more common, MinGW will evolve to work with them. The project was originally started by Colin Peters, was taken over and supervised by Mumit Khan. Earnie Boyd and other members of the MinGW mailing lists took over after Mumit. The original MinGW is now kept at Sourceforge and various members of the MinGW mailing lists help to maintain it. MinGW uses the Microsoft runtime libraries distributed with the Windows operating system.

    1. MinGW executables

      Gcc distributions such as MinGW provide a gcc executable which can be used to compile files in any language the distribution supports. They also provide other compiler drivers, which in the case of MinGW are executables such as g++, c++, g77, etc. These drivers invoke the appropriate compiler programs to compile your source code. Note that g++ and c++ are identical files except for the name difference. This is for historical purposes and allows backward compatibility with Unix compiler distributions which link c++ to g++. While you can compile and link different language files through the gcc program and the various other compiler drivers, it's recommended that you use the appropriate driver for the language you're working with. That way, determining what language specific libraries are needed and other language specific issues are all handled for you by the driver. The g++ and c++ executables are for C++, the g77 executable is for FORTRAN and the gcc executable is for C.

      Along with the compiler drivers, you'll find other tools in your bin directory. This includes cpp, a preprocessor which handles directives such as #include and #define. You'll also find windres, which is responsible for compiling Windows resource files into a usable format. The executables dlltool and dllwrap are programs used in creating and working with dlls (dynamic link libraries). The executable ar (i.e. archiver) lets you create and work with static libraries. The executable gdb is the GNU debugger. Other executables are in this directory as well. For more information on these programs, check out GNU documentation about them online or with your distribution.

     
    
  2. Copyright issues

    There are a variety of licenses for Open Source and freeware programs. Open Source software redistributes the source code with the project. Freeware often does not even let you see how the program you're using is created. Licenses such as the GNU General Public License (GPL) require you to redistribute your own source code when you add their code to your programs. The GNU Library General Public License (LGPL) isn't quite so strict, but you must make the LGPL source code available or at least allow users to replace the LGPL code with their own equivalent and have the program still work. Some source code is public domain and you can do whatever you like with it, including sell your own program which makes use of it. Licensing such as what FreeBSD uses is very lenient and lets you do practically whatever you please as well with a few restrictions. One of the nice features of MinGW in the past has always been that you can do whatever you wish with the programs you create using it and you are not required to distribute your own source code. You'll need a legal copy of crtdll.dll or msvcrt.dll already available on the Windows system the program will run on, but most Windows operating systems have one or both supplied with the operating system and they may be available from the Microsoft web site. That is no longer the case. I have contacted some of the MinGW developers and asked if they would be interested in dual licensing the current runtime libraries under the current license and a CC0 license in order to continue to use MinGW with regards to licensing in the same way it could be used in the past. I was told by one of the developers that he would not even consider it.

    While earlier versions of MinGW used a runtime library and Win32 headers that were in the public domain, the latest official version of MinGW does not. They've switched to a MIT style license. The reasoning behind the decision was stated to be that public domain was not recognized in all countries. The MingGW-w64 project was already providing their runtime libraries under copyright and MinGW has now followed suit. (Actually some of MinGW-w64 project's runtime library code still has the public domain designation in the files.) While the switch means you don't have to include the source for the runtime library with executables you create and want to distribute, the license states that "The above copyright notice, this permission notice and the below disclaimer shall be included in all copies or substantial portions of the Software." So at this point, I've found no clear official documentation stating whether one can continue to distribute executables created by MinGW without legally being required to distribute the runtime license with the product as well. If anyone can provide any further legal clarification on this issue, please contact me.

    Here is what I have been able to ascertain regarding legal issues, licenses and distribution...

    Unfortunately, rather than improving MinGW's legal status as far as the runtime is concerned, I found the whole current license issue rather vague. I've noticed some MinGW cross-compilers continuing to use the old runtime, but don't know if this will continue to occur in the forseeable future and if the GNU compiler suite will continue to work with the old MinGW runtime or whether it will be phased out. My personal preference would have been to see the runtime licensed under something like the Creative Commons CC0 1.0. That would have allowed users to continue to create programs with MinGW and distribute them without having to worry about distributing the proper licenses with them as well. It would also handle the issue of how to deal with countries that don't accept the public domain designation. Plus, CC0 is officially accepted as a GNU compatible license. For now, the old runtime still works, I have decided to keep using it or a CC0 fork of it directly with the GNU compiler suite. See the fracturing of MinGW for related information. If anyone else has concerns about this situation or would like to pool efforts to continue to work with a public domain and/or CC0 licensed runtime for MinGW, please let me know.

    For those interested in the actual legal details and technical points regarding copyright of the MinGW compiler system, copyright information is included in the headers and the source files of the compiler distribution package. Please be sure to check the information in the version of the compiler suite you downloaded as licensing may change with new distributions. Last time I checked, the following applied:

    Here are some further reference sources for the various licenses that apply to pieces of the MinGW distribution:

     
    
  3. The Fracturing of MinGW

    One could always build a MinGW compiler from source using the GNU compiler suite, the w32api and MinGW runtime libraries. Building it from scratch instead of using someone else's version meant one could build with whatever compiler flags or other options one desired and add additional libraries. For instance, at one point, MinGW used gmp, mpc and mpfr, but it could also add in cloog and ppl or isl to further optimize the compiler. For a long time most people were satisfied using the official MinGW releases. Most still prefer a pre-built version of MinGW over building from scratch (which can take several hours).

    Some time after I left the MinGW project, forks of MinGW started developing. The original MinGW project became difficult to install. There were disagreements between developers and would-be developers on priorities. One point of disagreement was developing a 64 bit version which was originally the plan when the name changed from MinGW32 to MinGW. However, the developers in charge at the time did not have the resources to support both platforms. There was no official support for cross compilers because the developers did not have the time and resources. There were two attempts to supply other Open Source libraries, mingwport and mygports. The official MinGW developers did not have the time and did not wish to support these projects themselves. They wanted volunteers to use their, for the most part undocumented, systems to submit work and maintain it for the MinGW project. In my opinion, neither option ever really got off the ground. If you want people to volunteer, make the guidelines for volunteering very clear. Unfortunately, that means when a MinGW developer wants an Open Source library that will build with MinGW, he/she has to do the porting work (repeating what every other developer who needs that library has to do) or needs to look to cross-compiler projects like MXE, OpenSuse's build system or Fedora's cross-compiler ports. The mailing list for MinGW became a place I was very uncomfortable asking questions because every time I posted, I'd start a small war. Why should asking where to find a specific resource spark fights among list members?

    For several years, I've seen the writing on the walls. If the project couldn't pull together and make outsiders feel welcome and safe asking for help, something was going to break. Something finally did. I remember when I first started using MinGW, I put a lot of effort into approaching Open Source projects and giving patches to make sure MinGW could use those libraries. MinGW has come a long way and a lot of Open Source projects now build with it. However, MinGW users are in danger of losing all the ground they've gained. The MinGW project has splintered and forked into several groups. The lack of compatibility between these groups means that all the efforts toward porting projects to MinGW are now split. We're basically dividing our forces. Remember the old adage of divide and conquer?

    To make matters worse, Microsoft Visual C/C++ is gaining ground and LLVM has put their support behind that option. Visual C/C++ is not a free option. You cannot build it from source or modify it. There is a free version, but some capabilities are reserved for the commercial versions. I've used several compilers and in the past, I've found Microsoft Visual C/C++ rather buggy. One version I worked with just wasn't suitable for production quality work. I am not surprised by Microsoft's push toward "managed code" because they have problems with unmanaged code in their own products such as former incarnations of their compilers.

    There are Open Source projects that never build their programs on Windows and only support Windows executables by building them on a POSIX machine such as Linux using a cross-compiler or Wine. While some people in this camp claim their projects are compatible with Windows development, they truly are not. They typically will not accept patches to make them more compatible either. Their main concern is developing on platforms they have access to. This may be fine for highly customized projects tuned to a particular system, but the projects I check into specifically claim to support cross-platform development. Just because a project builds on Linux with a cross-compiler or with Wine does not mean it will build without patching directly under Windows. I've run across several actual real world examples that confirm that. When MinGW could not be distributed easily, several groups splintered off to provide their own way of distributing it. That wasn't really bad competition for MinGW development. However, when there was no 64 bit support after several years, a group splintered off to supply that. Now when you ask a project if it works using MinGW, you have to know which version of MinGW, the original, the MinGW-w64 project (64 or 32 bit version), MXE, some Linux distribution's cross-compiler, etc. What builds with one version of MinGW does not necessarily build with another. It was bad enough when I couldn't get Open Source projects to build and there was only one version of MinGW. It's much harder to get projects to build now and much harder to get people involved with those projects to accept patches to fix the situation. If they don't accept the patches, one continually needs to fix the source every time a new version comes out just to get it to build. The Open Source community does regard choice as a good thing. However, fracturing of resources, unnecessary forks, lack of compatibility are not considered good things. Unfortunately, that's where we are now and I don't see a reversal in the near future.

    To further add to an already disturbing situation, MinGW has now changed the licensing on current and future versions of their runtime library. See copyright issues for details. Among the changes was an ABI change (to functions in dirent.c). So, code needs to be recompiled to use only the new runtime if one intends to switch. You cannot mix libraries, etc. between the two runtimes. It's supposed to be good practice to version shared libraries so that when the ABI changes one can use either the old or the new library and they can coexist. I checked the distributable files for the new MinGW runtime and the dll provides exactly the same version number and files have the same names as before. It makes it very difficult for software that uses another runtime to coexist with the current runtime.

    So, which MinGW distribution should your project use? Good question. At this point, I have no solid answers. Where can you turn to in order to find user friendly help on questions you have about the compiler? Again, good question. I have no solid answers. However, I'm frustrated enough with the current situation to attempt to create a more stable C/C++ environment of my own for compiling and building from source code. I'd also like to add better UTF-8 support to the runtime and/or a library that can be used with the runtime, to help improve internationalization issues when porting applications to Windows or writing cross-platform applications. If I do so, I would want to continue to maintain backward compatibility for applications that need to work with codepages or UTF-16. Remember the old adage, if you want something done right, do it yourself? It's beginning to look like if I want a stable environment and one where I don't have to worry about distributing runtime licenses, I'll have to build it myself. If anyone has similar goals and would like to add their support to such a project, please contact me. I've gone from just trying to build my own applications, to trying to build stable Open Source applications (like editors, etc.) that I can use when building my own applications, to trying to build a stable Open Source build environment (diff tools, archivers, shell, etc.). Now, I'm looking at more stable compiler options that can be built from scratch. The only places I currently don't have control over dealing with changes to the source are the operating system itself and the GNU compiler code (which I would prefer not to fork). It would be nice if enough other developers and/or groups were using the old MinGW runtime to continue to ensure that the GNU compiler suite continues to support its use. The GNU project has already discussed removing support for the MinGW project's code and only supporting the MinGW-W64 code.

    One other new and exciting option that has come to my attention is a work-in-progress to port the MUSL C library to Windows for use with GNU gcc. This would provide excellent support for porting POSIX programs to Windows. However, WIN32 support beyond what ntdll supplies would be lacking. There are other compiler and build environments available for Windows beyond MinGW even though the support isn't what it was years ago and most of the competition seems to have been removed. There is Microsoft's SFU environment (which they've pretty much deprecated). Microsoft was also stating they would not support Win32 development and would push for Metro only development for their Windows 8 compilers, but they've reversed their decisions. The Borland Windows C/C++ compiler hasn't been updated in years. The OpenWatcom project is talking about no longer placing support emphasis on Windows and instead concentrating on embedded systems where they currently have a niche. I found a fork of OpenWatcom on Sourceforge but the official OpenWatcom version hasn't been updated in a long time. There's llvm which looks promising, but doesn't support creating executables on Windows. They were using gcc/MinGW to generate executables and, as mentioned, are now looking at almost exclusively using Visual C/C++. As far as llvm being an Open Source compiler alternative for Windows, it fails if you're required to use Visual C/C++ just to build projects. If you run across any other alternatives or any friendly MinGW environment that's trying to build support and teamwork for working with the compiler rather than pushing people away, please let me know. As I've mentioned elsewhere, I have ports and patches for over five-hundred Open Source libraries and applications and still have no decent distribution location to share them with other developers. Personally, this is one of the reasons I prefer cross-platform development. If an operating system or compiler no longer suits your needs, you move to what's best for the job. I'll be interested to see what's going to become the next best thing (not the next most popular thing, but the next thing that really gets the job done).

  4. msvcrt vs crtdll?

    MinGW requires the Microsoft runtime libraries. Various versions of MinGW have used either the crtdll.dll or the msvcrt.dll to provide the needed routines. Crtdll was on all Win32 systems at one time, but is no longer updated my Microsoft. It was standard on platforms such as Windows 3.11/Windows NT 3.5 and platforms that use Win32s. Msvcrt is not guaranteed to be on older Windows operating systems, but it is more up-to-date and may offer more features. It handles threading better than crtdll and supplies functions such as _i64toa and _atoi64 that crtdll doesn't. The default runtime library target for MinGW is now msvcrt.dll. You will still find remnants in the MinGW code for crtdll.dll such as ifdefs for it in include files. I've read this has been completely removed in the new MinGW headers and runtime library. There used to be two versions of MinGW depending on which runtime library you wished to use with it. I don't know if there's still a way to work with crtdll.dll in preference to msvcrt.dll. There is not with the latest version of MinGW that uses the new runtime library. Most people had switched to using the version of MinGW that used msvcrt.dll in preference to the version that worked with the older dll.

     
    
  5. Using older versions

    The MinGW developers have always strongly recommendeded in the past that you use the latest version of MinGW. There are older versions available on the Internet or through books and CDs. Older versions may have more bugs than the latest version or lack support for certain C++ language features. Support on the MinGW mailing lists or from other resources is usually geared toward the latest release. If you are not sure of your version, you can type gcc -dumpversion to find out what you are using. Check the MinGW web site to find out what the latest verion number should be. Please be sure that you have downloaded and are working with the latest version if you expect official support from the developers, especially if you are having any difficulties with installation or use. Unfortunately, you now also need to know where to contact the appropriate developers for your version of MinGW if you want support. For instance, if you're using a MinGW cross-compiler, the main MinGW mailing lists are typically not very helpful when asking questions about it. See fracturing of MinGW for more details on this issue. Some newer versions are turning up with serious compatibility bugs for certain older versions of Windows. In those cases, updating to the latest version of MinGW is no longer a valid solution. Plus, different forks of MinGW now use different versions of the GNU gcc compiler and not all forks are using the latest versions.

     
    
  6. Where to get MinGW

    I am currently building my own version of MinGW from source directly from the GNU compiler suite and the old public domain MinGW runtime library and W32api. It does take quite some time to build and you do need a working GNU compiler to bootstrap from. However, the process was much easier than I thought it would be. Building from source is the best way to make sure you have control over what's built into your compiler and the various optimizations and compiler options selected as defaults. Since there is an interest from MinGW FAQ readers, I've detailed the steps I use in my article, MinGW from Source - How To Build the GNU Compiler Suite on Windows. Hopefully, it will make a useful example for those who wish to build MinGW to their own specifications. For those who don't want to build from source, I will be offering a copy of my build at Sourceforge in the near future as part of the LM BLD project.

    You can download the original MinGW or MinGW-w64 from Sourceforge. Other versions of MinGW such as those distributed by TDM and Bloodshed can be downloaded from their respective sites. If you're cross-compiling from Linux, check your distribution or projects like MXE. The official MinGW now uses mingw-get-inst for installation and mingw-get to udpate current installs. I've had issues in the past with it and have been unable to get it to work behind firewalls.

     
    
  7. How to install

    One thing that's changed over the years that I don't think is an improvement is the installation of MinGW. When the FAQ was originally written, all you had to do was download one zip file and place the contents in the directory you wanted. That made it really convenient to install and to move the distribution between machines, hard drives or external drives. Now there are several archived and compressed files associated with the original MinGW and it's hard to tell which ones to use. There is an official installer mingw-get-inst that uses mingw-get (the official way to get MinGW packages). I had serious issues with mingw-get and the installer not working properly behind firewalls. I have also downloaded source files directly from the Sourceforge files directory in the past especially when tools like mingw-get failed. Unfortunately, locations of files at the MinGW site seem to change frequently.

    There are other options besides using mingw-get. One easier way to install the original MinGW is to download a zip or archive file with all the files from the Qt project's web site. However, they're installation of MinGW is older than official versions. They also may not be using the particular fork of MinGW that you want to use with your projects. The MinGW-w64 project, a fork of MinGW, provides its own GNU based compiler chain for building 32 and 64 bit applications. You can use their archive files in place of the official MinGW system. Compatibility between the original MinGW 32 bit compiler and the one MinGW-w64 32 bit compiler is not guaranteed. Programs may also have issues building for 64 bit systems if they were designed for 32 bit ones (especially if the developer didn't make use of proper portable and cross-platform programming techniques). See the fracturing of MinGW for more details. The MinGW-w64 project provides a working substitute for MinGW, but they don't supply a good alternative to msys. They make use of msys (or msys2 a later Cygwin fork). There are other versions of MinGW available from various locations on the Internet such as the TDM-GCC.

    I used to install all my library files to the msys directory, so files didn't collide or co-mingle with the compiler. However, the MinGW team have redesigned things, so that the MinGW versions of most libraries and utilities (as opposed to the msys versions) need to be installed in the same directories used by the compiler's library, include and binary files. The MinGW versions are designed for general use on Windows, while the msys versions are specifically for use in the msys environment (and include special code to deal with POSIX style paths and other porting issues), so most developers are going to want the MinGW versions. Msys is a fork of an old Cygwin project, so an msys application will require using and distributing GPL licensed msys dll(s).

    You may also want to use a program like spkg, so you can easily uninstall these files again. However, if you use spkg, you'll probably need to change the names of the tarballs to match Slackware naming conventions and possibly may need to change their decompression format so that spkg knows how to work with them.

    Previous mingw installation steps:

    Download the MinGW distribution. If files are in zip format, unzip them. (Zip/unzip utilities are available from http://www.info-zip.org/pub/infozip/Info-ZIP.html.) If files are in another format, such as tar.gz or tar.lzma, you can use 7za to decompress them. (7zip and command line tool 7za are available from http://www.7-zip.org/.) You can also use a version of tar that can handle xz and lzma format. A standalone basic tar with BSD license is available from the MinGW downloads page. If the bin directory that holds MinGW executables isn't already in your path, add it. That's it.

    If you need help setting your path, try the following. On Windows NT, select Start/Settings/Control Panel/System/Environment and edit your path. For Windows XP, Start/Settings/Control Panel/System/Advanced/Environment Variables and edit your path. For Windows 95/98, edit your autoexec.bat file. If you already have a line that starts with PATH or SET PATH, add the MinGW bin directory to your list or you can add the following after the line that sets your path in autoexec.bat:
    SET PATH=C:\MinGW\bin;%PATH%
    Substitute the directory your MinGW binaries (such as gcc.exe) are located in for C:\MinGW\bin. If your autoexec.bat file runs any other batch files at the end of it, be sure to place the lines to change your path before calling another batch file. For example, my autoexec.bat file used to have a line that runs a batch file to change the screen color when it's done setting everything else. When I placed path changes after the batch file call, the path never gets updated. This is only a problem with calling other batch files (files with .bat extension). You can run programs like doskey from your autoexec.bat with no problem.

    1. Coexisting with djgpp and other compilers

      MinGW can be installed and run when other compilers are on your machine. I had djggp, OpenWatcom and the Borland command line compiler all coexisting happily on the same computer and could compile the same source code with any of these.

      The important thing is that MinGW needs to be able to find its executables in the file path. If you mix djgpp file paths with MinGW file paths, you can have problems when your system tries to find the appropriate executables. If you must have both compilers' locations in your path, make sure the proper one comes first in the list. The safest situation is to only have the compiler you're working with listed in your current path.

      • Batch file technique
        One solution djgpp users have found that lets them run both compilers is to create two batch files, one for each compiler. Set up correct paths and other environment variables in each batch file. Run the appropriate batch file before doing any compiling. You will need to run any compilation related commands in the window you ran the batch file in. I have a batch file to set specific path and environment variables for each of my compilers and keep the MinGW make program which is my default make program for all compilers in a common location that's always in my path. For flash drive users, you can specify paths relative to the batch file you're running on a removable drive. For instance, adding set path=%~dp0\mingw\bin;%path% to a batch file adds the mingw\bin subdirectory underneath the directory where you ran that batch file to your path.
      • Another solution is to create a link in Windows that will open up a DOS box (aka Command Prompt) and set the appropriate environment variables for each compiler through Windows. If you want an alternative to the Windows Command Prompt, you can use an Open Source program such as Console 2 available at Sourceforge. If you have both MinGW and msys installed, in Console, under Settings dialog, add a Tab name and set the shell for it to C:\mingw\msys\bin\sh.exe --login -i. (Update the directory location to point to your msys\bin directory.) You can specify other directories in your .profile in your msys user directory.
      • A third solution is to keep all path related information in your makefiles and create appropriate makefiles for each compiler. Then, you only need to make sure you're running the appropriate make program in the correct directory.
     
    
  8. Mailing lists

    There are now several mailing lists for MinGW. Also, as I mentioned above, there are several versions of MinGW. There's no longer one place to go for questions or problems. Check with wherever you got your particular distribution for more information on mailing lists and ways to contact that particular community. If you have any further questions or would like to get involved in MinGW, unfortunately, I can no longer recommend any one good place to get started.

    I do maintain a C/C++ related mailing list called CppDesign. It's purpose is to share information on C/C++ that may be of interest to experienced programmers and to discuss various design related issues and trade-offs. I will also be posting information on my LM BLD project and what I've learned from it to the list. Links and/or update information on any of the C/C++ compilers or other C/C++ development tools are welcome as is information on Open Source and free C/C++ libraries and source code. If you're looking for some of the interesting links to libraries and programs that used to be in this FAQ, CppDesign is the place to go.

     
    
  9. MinGW as a portable app

    A portable app is a program that can be moved and run easily from a removable drive like a USB flash drive. MinGW really isn't set up to run as a portable app. On the plus side, MinGW doesn't need to make any changes to your registry in order to run successfully. However, it does need to know where to look for the programs in the compiler suite that it needs to run. You can:

    The drive letters may need to be edited to point to your removable drive every time you run. You can use the path trick in the batch file technique to deal with changing drive letters.

    The MinGW installation executable is not set up as a portable app. You can run it once to get all the compressed and archived files you need to run MinGW or try to figure out what files you need on your own and download them from Sourceforge yourself.

    Msys is often used along with MinGW. Like the MinGW installation executable, the Msys installation executable is also not set up to run as a portable app. I have been able to get msys to run on a Windows system where I didn't have administration rights. I copied all the files from an installed version on my own machine to a location on the target machine. I ran the msys executable and let it fail when it didn't have certain rights on the machine. I did note that activating msys was much slower on the machine than it would be normally.

    Bloodshed Software has a package called Dev-C++ that includes the MinGW compiler suite and other tools such as an IDE. I have heard that there are ways to make this distribution run more like a standard portable app.

  10. Other compiler distributions

    Other compiler packages are available for Win32 systems. These include:

     
    
  11. Help

    For locations of help and tutorial files or sites, check on the CppDesign mailing list. These change frequently, so I'll no longer be trying to keep up with them in the FAQ.

    Luckily, some documentation does now come with MinGW itself. I do recommend the C and C++ library documentation that comes freely with OpenWatcom. It's very helpful. lcc-win also provides some good documentation. You can download a c.api file for SciTE users if you check the SciTE web site for details.

    If you need some good, simple examples of how to do common or useful things in C (and sometimes C++) check for the Snippets collection. It's now archived at various web sites.

     
    
  12. Runtime Libraries

    The gcc compiler series has been built successfully with many different runtime libraries. MinGW provided two different runtime library options, crtdll.dll and msvcrt.dll at one time. See the msvcrt vs crtdll section for more information. The msvcrt.dll is available on modern Windows operating systems while crtdll.dll is available with older versions of Windows. This means one or both are available on most, if not all, Windows operating systems. The Cygnus gcc distribution used the Cygnus runtime library which is available under the GNU General Public License. Similarly, the U/Win gcc distribution uses its own runtime library which is also available under the GNU General Public License. The main problem with using GPL'd runtime libraries is that all source (including your own) must be distributed with the executables created by the compiler. When crtdll.dll or msvcrt.dll are used as runtime libraries this is not an issue.

    MinGW also has its own runtime library code that interfaces with msvcrt.dll and supplies missing functionality. The win32api headers provide an API. In the past, these have always been in the public domain. So, distribution of executables built with it was not an issue. This has changed. See the copyright issues section for more details. MinGW-w64 has its own runtime library code different from MinGW. It's covered by a conglomeration of licenses including Zope, MIT style and GNU LGPL.

    Other runtime libraries are usable with MinGW/gcc. One such library that was in the works was PW32, the Posix-over-Win32 layer, at Sourceforge. It provides a subset of POSIX and UNIX functions. A new project is working on using a ported version of Musl with gcc. Other alternatives can be found at Sourceforge. Just run a search on MinGW and runtime. The OpenWatcom runtime library source is now available for download. Another option, if anyone's inclined to take on the project, might be to combine the GNU compiler suite with the Watcom runtime library.

     
    
  13. Debugging
    1. Write statements

      The simplest method of debugging is to add write statements to the code in order to tell what's going on. In C, puts and printf are useful. In C++, cout is helpful. In Windows, the MessageBox is helpful as long as you don't call it during a paint routine. If you do anything in a Windows application that tries to repaint the screen during a paint call, you can get stuck in an infinite loop. Some programmers find using assert statements a good method to help debug.

    2. Map files and crash addresses

      If you can get the address of a program crash and you have a map file for your program, you can locate the line or routine where the program crashed.

      Certain systems, such as Windows NT and some Windows 98 machines, have a program named Dr. Watson available which will supply information about a program when it crashes. Some commercial compilers also supply a program with this functionality. If you have one of these programs available on your system, you can use the address of the crash supplied by it to help locate the problem. If anyone knows of any freeware programs that duplicate this functionality or has source code to find the address during a crash, please let me know.

      Here are three ways to create a map file. Choose the method you like best. In these examples, I've used sample names such as file.map and file.exe. Change the map, executable and object files to ones more relevant to your particular project.

      ld file.exe -Map file.map
       
      nm --extern-only --defined-only -v --print-file-name file.exe > file.map
       
      g++ -Wl,-Map,file.map -o file file.o otherfile.o
      

      On systems such as Windows NT, you can specify what application is run when a program crashes. To do so, edit the Debugger value for the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug registry key and change it to the program you want run after a crash. Windows makes available the ID of the process to debug and an event ID to signal when the debugger finishes calling DebugActiveProcess. These can be passed via command line to the program listed as Debugger. Setting the auto value for this registry key to 1 causes the program listed as Debugger to automatically run. Setting it to 0 brings up a crash dialog instead.

    3. Dr. MinGW

      Dr. MinGW is a just-in-time exception handler for MinGW. It will automatically install itself as the default debugger in the registry if run with the proper options. If you do not already have some debugger installed on your system, you may have to add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug to your registry by hand before successfully running the install option. I've had issues running this on modern versions of Windows (especially if they're 64 bit). If anyone's had better luck on these systems, please let me know.

    4. StraceNT

      I've been developing for years, but have never used strace. I was recently trying to track down a problem on a Linux system using musl and the developers suggested I share the output from strace. It was actually helpful in tracking down the problem. Strace is a Linux utility, but I figured I'd check to see if there was a port for Windows. Someone has in fact created a version of strace for Windows called StraceNT. I really didn't have too much luck porting it to build with MinGW. (It compiles, but doesn't function properly.) It's designed for Visual C++. However, one can download prebuilt executables from the StraceNT web site and use them in conjunction with Windows executables to debug those executables.

    5. Debugger

      For more in depth debugging, you will most likely need the help of a debugger program. MinGW includes gdb (GNU debugger) in its distribution. I have not kept up with current development on gdb, but this was basically a command line debugger.

    6. GUI debugger

      Many people prefer a GUI front end to their debugger. I'm not aware if this has changed, but MinGW used to supply only a command line debugger in its distribution. This leaves two options for GUI debuggers.

      • Use a debugger from another compiler distribution. If you're using one from another compiler, you will have to recompile your source code with that compiler. OpenWatcom has a debugger with a decent graphical user interface. lcc-win32 had a GUI debugger project in the works as well.
      • Use a GUI front end to gdb. Search for GUI front end to gdb in your favorite search engine for more details. Two such projects I've heard of were Insight which required Cygwin and Jessie which was largely implemented in Java. There was source for a version of Insight available at the MinGW project in the download section at Sourceforge.
     
    
  14. IDEs and editors
    1. What IDEs are available?

      There are several IDEs (Integrated Development Environments) for Win32 platforms. Some are freeware and some are not. Some are specifically tailored to MinGW and others are for more general use. Please see the CppDesign mailing list and search the archive or ask the members there if you need recommendations. I do remember trying RSXIDE and finding it worked well with djgpp and MinGW and a DDE capable editor like PFE. I've also used Quincy with the Borland command line compiler, but it too works with MinGW.

    2. What editors are available?

      The various Emacs and Vi programs and their offshots such as Vim (Vi Improved) and Cream are always popular. If you want an easy to use console editor try nano (or pico). My current favorite Open Source programming editor is SciTE. It works beautifully with MinGW, other C/C++ compilers and other languages. It lets you intergrate compiling, building and running programs through the editor as well as giving the ability to click on compiler errors within the editor and jump to the appropriate files. It is now very flexible, but can be hard to figure out how to customize. See my article on SciTE customization tips for some help. I've been searching for console or more lightweight editors that are as customizable as SciTE. Two other editors based on the Scintilla editing component that SciTE uses are FXite (uses Fox Toolkit GUI) and textadept (offers a pdcurses based console version).

    3. Other reference sites

      As I mentioned, I used to maintain a list of links to IDEs and editors, but other sites have taken over the job and added many more options. A good search engine should be able to locate some of these sites. You can also check out TextEditors.org.

     
    
  15. Using MinGW as a cross-compiler

    MinGW can be used as a cross-compiler, operating on Linux and producing programs that work on Windows target machines. There are some openSUSE Build Service projects using MinGW as a cross-compiler. There's also the MinGW cross compiling environment project (aka MXE). They provide makefile recipes for building the cross-compiler and several Open Source projects. Certain Linux distributions also supply cross-compilers.

     
    
  16. What is msys?

    The information on msys has been moved to its own page. Please update any links accordingly.

     
    
  17. How do I customize msys?

    The information on msys has been moved to its own page. Please update any links accordingly.

     
    
  18. Compiling and Building
    1. How to create a console application

      Here's an example. The following is a code sample for a simple C program. Cut and paste it into a file named hello.c to try it out.

      #include <stdio.h>
       
      int main(int argc, char **argv)
      {
         printf ("Hello\n");
         return (0);
      }
       
       
      

      If you want to create a console mode executable hello.exe from a c file called hello.c, try the following:

      gcc -c hello.c
      

      This compiles hello.c into an object file, hello.o
       
      gcc -o hello hello.o
      

      This creates an executable hello.exe from hello.o

      Alternatively, you can compile and link in one step using:

      gcc -o hello hello.c 
       
       
      

      The following is a code sample for a simple C++ program. Cut and paste it into a file named hello.cpp to try it out.

      #include <iostream>
      int main(int argc, char **argv)
      {
        cout << "Hello" << endl;
        return (0);
      }
       
       
      

      For the C++ program, use the following to compile and link:

      g++ -c hello.cpp
      g++ -o hello hello.o
      
    2. How to create a windows application

      Here's an example. The following is a code sample for a simple Windows program. Cut and paste it into a file named hello.c to try it out.

      #include <windows.h>
       
      int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) 
      {
         MessageBox (NULL, "Hello", "Hello Demo", MB_OK);
         return (0);
      }
       
       
      

      If you want to create a Windows executable hello.exe, from a c file called hello.c, try the following:

      gcc -c hello.c
      

      This compiles hello.c into an object file, hello.o
       
      gcc -o hello hello.o -mwindows
      

      This creates an executable hello.exe from hello.o The -mwindows switch is needed to create Windows executables instead of console applications. It assures the appropriate Windows libraries are linked in for you.

      To get a console screen along with a standard windows application, add the -mconsole flag as well as -mwindows.

      If you have resources from a resource file (.rc) that also need to be added to your executable, you'll need to compile the resource file as well as your other source files and include the compiled resources when linking to create the executable. Here's an example that shows how to compile and link in a resource file named resfile.rc.

      windres -o resfile.o resfile.rc
      gcc -o hello hello.o resfile.o -mwindows
      
    3. How to create a library

      Here's an example. Cut and paste the following into a file named dllfct.h:

      #ifndef DLLFCT_H
      #define DLLFCT_H
       
      #ifdef __cplusplus
      extern "C" { 
      #endif 
       
      #ifndef BUILD_STATIC
      #ifdef BUILD_DLL
      // the dll exports
      #define EXPORT __declspec(dllexport)
      #else
      // the exe imports
      #define EXPORT __declspec(dllimport)
      #endif
      #else
      #define EXPORT
      #endif
       
      // function to be imported/exported
      EXPORT void tstfunc (void);
       
      #ifdef __cplusplus
      } 
      #endif 
       
      #endif
       
       
      

      Cut and paste the following into a file named dllfct.c:

      #include <stdio.h>
      #include "dllfct.h"
       
      EXPORT void tstfunc (void)
      {
         printf ("Hello\n");
      }
       
       
      

      Cut and paste the following into a file named hello.c:

      #include "dllfct.h"
       
      int main ()
      {
         tstfunc ();
         return (0);
      }
       
       
      

      To create the dll and an executable that uses it, try the following:

      gcc -c hello.c
      gcc -c -DBUILD_DLL dllfct.c
      dllwrap --output-lib=libtst.dll.a --dllname=libtst-1.dll --driver-name=gcc dllfct.o
      gcc -o hello.exe hello.o -L. -ltst.dll
      

      Note: While C functions in dlls are generally portable across compilers, I'm told that this isn't necessarily true for C++. When writing your own dlls, you can mark C++ functions and data in dlls as extern "C" (like in the example) to help bridge some of the C++ portability issues between compilers. See the MinGW32 mailing list archives for more portability concerns regarding dlls.

      There is a more modern syntax for creating a dll that looks more like the standard POSIX GNU syntax for shared libraries. It may also decrease output file sizes. After compiling the two C files, instead of using dllwrap, try the following commands:

      gcc -shared -s -Wl,--subsystem,windows,--out-implib,libtst.dll.a -o libtst-1.dll dllfct.o 
      gcc -o hello.exe hello.o -L. -ltst.dll
       
       
      

      To build a static library, remove the EXPORT definitions when compiling both C files. They only work with dynamic libraries. In the example, you can use the BUILD_STATIC define to remove them. You need to create the object files with the definitions removed. Then you can create a static library from one object file and link it the other object file to create an executable. If you've tried the previous examples, remove the object files, libraries and executable before trying this. Here's an example:

      gcc -c -DBUILD_STATIC dllfct.c
      gcc -c -DBUILD_STATIC hello.c
      ar rcs libtst.a dllfct.o
      gcc -o hello.exe hello.o -L. -ltst
       
       
      

      To create a dll (and .def file) from a static library (libtst.a):

      dlltool --export-all-symbols -D libtst-1.dll -l libtst.dll.a -z libtst.def libtst.a
      ranlib libtst.dll.a
      g++ -shared -s -def libtst.def -o libtst-1.dll libtst.a
      

      Once you have the dynamic library files, you can create an executable the same as in the dynamic library examples (last line of either example).

          
       
      
  19. How do I link to dlls created by other compilers?

    A library file (.lib or .a) is used in conjunction with a dll to let the compiler know what routines are available in the dll and how to connect to them. While dlls are supposed to be portable across compilers, the library file may not be. You can use the methods in the linking to dlls section to link to one. However, if you do not have the source files and do not want to use commands in your source code such as LoadLibrary, FreeLibrary and GetProcAddress, you can attempt to create a library file from the available dll. In order to create the library file, you will first need to create a definition file (.def).

    There are several methods that can be tried in order to create a definition file (.def) when one is not supplied.

    1. One option is the tool, pexports.
      If your dll has functions that use the Pascal calling convention, you'll need to use the -o option.
      There are various versions of this tool available on the Internet. The MinGW download section at Sourceforge is the best place to look. You can also check the cygwin site or one of the source code search engines if you have any trouble locating a copy with your favorite search engine. There's also a copy at the mingwrep project on Sourceforge in the altbinutils-pe section. You can use a code search engine such as Koders to find the source code. Search on a keyword such as pexports.h.
    2. Another option is the tool, impdef.
      There is a similar tool called reimp as well. I believe the latest version of impdef had a few more features than reimp at one point, but don't currently have enough information to confirm that. Check your favorite search engine for either of these programs.
      Other Windows compilers may supply their own versions of the impdef program that can be used to create a .def file which will work with any compiler. If you have another version of impdef from another compiler, you may wish to try it. Some handle the Pascal calling convention better than others. Borland has a version of impdef and other compiler utilities available for download at their Borland Community web site. Their Borland C++ version 5.5 compiler includes several utilities to help convert between standard formats, their formats and Microsoft's formats.
    3. Another option is to use nm which comes with the MinGW distribution.
      This option will not work for all dlls. Problems may occur if the dll is stripped or compiled as 16 bit. To use this technique, you'll need to filter the output from nm to create a def file. This can be done by hand in an editor or automated using tools like Perl (Practical Extraction and Report Language) or grep (global regular expression print) and sed (stream editor). Even with the automated methods, you may have to make some changes by hand if the Pascal calling convention is used by the dll. (Versions of sed and grep are available with msys from the MinGW distribution or from various sites that supply Unix style tools or from the self-hosting MinGW32 port distribution. The ActiveState version of Perl works well for me on Windows platforms. I've also found information on building microPerl on Windows using the official Perl source code and some patches. See the CPPDesign mailing list if you'd like details.) Here are examples of possible filtering techniques.
      • This example uses grep and sed. If you have a dll named file.dll that you wish to create a def file for named file.def, try the following:

        echo EXPORTS > file.def
        nm file.dll | grep ' T _' | sed 's/.* T _//' >> file.def
         
         
        

        To create a library file named file.a from the dll and def file, type:

        dlltool --def file.def --dllname file.dll --output-lib file.a
        
      • This example uses Perl. Copy the following Perl script to a file called dll.pl and use it:

        open (OUTFILE,">dll.def");
        print OUTFILE "EXPORTS\n";
        open (INFILE,"dll.fil");
        while(<INFILE>)
        {
           if ($_ =~ /T _/)
           {
              $line = $_;
              $line =~ s/.* T _//;
              print OUTFILE $line;
           }
        }
        close (INFILE);
        close (OUTFILE);
         
         
        

        If you have a dll file named file.dll. At the command line, type:

        nm file.dll > dll.fil
        perl dll.pl
        

        A def file named dll.def will be created. You can rename this as needed. You'll also probably want to delete dll.fil when you're finished with this process.

      • If you don't have any of these tools on your system, you can still use nm to create a def file and edit it by hand through an editor. For example:

        nm file.dll > dll.fil
        find " T _" dll.fil > dll.def
        

        Replace the line at the top of dll.def that was created by the find program and shows a file name with a line that says EXPORTS. Set your editor to search for T _ and erase it and anything on the line before it, leaving only the routine names in the file.

    4. One last option is objdump.
      If the previous options don't work, you can still try to create a def file using the output from the objdump program. The program is part of the MinGW distribution.
      Here's an example.
      objdump -p file.dll > dll.fil
      

      Search for [Ordinal/Name Pointer] Table in dll.fil and use the list of functions following it to create your def file.

    I was surprised to find a copy of one of my articles related to this topic currently available on the web. It was on how to access Oracle in C/C++ programs using MinGW and Oracle dlls. In the past, I was successful at creating C/C++ programs that were run standalone or as CGI programs and that connected to the Oracle database with dlls provided by an Oracle installation.

     
    
  20. More compiling and building issues
    1. main or WinMain?

      Windows programs use WinMain instead of main. However, MinGW is set up so that you can use either.

    2. Why are my executable sizes large?

      Some users on the MinGW32 mailing list have noticed ending up with unusually large executable sizes. This can happen if you leave in debugging information. To make your executables smaller, try linking with the -s switch or use the strip program on the final executable (not the object or library files). Compiling without the -g option is another alternative.

      If you're using strip, you can try strip --strip-all with executables, strip --strip-unneeded with shared libraries and strip --strip-debug with standard libraries. If you have further tips for best flags to use with strip, please share them on the CppDesign mailing list.

      You can also optimize your files using the various -O options. Adding -Os can help optimize for file size.

    3. Preventing command line globbing

      Globbing is a term used to refer to pattern matching of names using wildcard expansion. POSIX users (Linux, Unix, BSD and so on) are familiar with shell programs attempting to expand wildcard patterns into valid filenames. On Windows, this is not done by the standard command shell programs. So, MinGW developers moved the ability to glob filenames into the executables themselves. It typically isn't noticeable. However, if one is trying to build programs such as find or some versions of grep, the automatic expansion can obfuscate the original command line instructions to the program. If you want to make sure your MinGW generated executables do not automatically attempt to expand command line wildcards into filenames, add CRT_noglob.o (in the lib subdirectory) to the list of objects being compiled.

    4. Linking to other compilers' libraries

      Due to binary compatibility issues between different compilers, you cannot directly link in libraries or object code from one compiler to another compiler such as MinGW and expect it to work. The reverse is true as well. Even dlls are not completely portable across compilers. To deal with this issue, various standards such as COM and CORBA were created.

      If you want to use a library or objects from one compiler with another, the easiest way to do it is to have the source (.c, .cpp, .rc, .def, etc.) and to compile and build that code with the desired compiler and its tools. You can use the same dll with different compilers with varying degrees of success. You'll need either a .def file or to use calls such as LoadLibrary/GetProcAddress to do so. The self-hosting version of MinGW32 provides better support of Visual C++ binary compatibility. You can use certain libraries built with Visual C++ with this version of MinGW32 without having to rebuild them using MinGW and vice versa.

    5. Linking libraries

      If you place libraries before the object files that reference them, the linker will be unable to find them. The linker works left-to-right, single pass. The easiest way to avoid the problem is to place all libraries after the object files. It is also recommended that libraries to be linked with should not be repeated on the command line. While listing the same library more than once works with several linkers, the MinGW linker currently has problems with this situation and may leave needed routines out of the link when this is done.

      Here's an example of a line that links in multiple objects and libraries:

      gcc -o hello hello.o util.o pdcurses.a -ltst.dll
      

      The command links in the libraries pdcurses.a and libtst.dll.a to create an executable hello.exe.

    6. Linking to dlls

      Although dlls are supposed to be fairly portable across different Windows compilers, accessing dlls through a library file (.lib or .a) is not. The library file formats are specific to particular compilers and cannot be used portably with different compilers unless the compiler provides support for it.

      There are two ways to link to a dll.

      • Provide a library file to let the program know what routines are in the dll and where to find them.

        If you have object files for the dll created by MinGW, you can create def and library files. Here's one method to do so.

        dlltool --output-def file.def --output-lib libfile.a [list of objects]
        
        Substitute your object file names for [list of objects]. If you only have the dll file, see the section on how to create a def file for alternative techniques. Once you have a def file, you can create a library file (.a) in the proper format for MinGW using dlltool. For example:
        dlltool --def file.def --dllname file.dll --output-lib file.a
        
      • Use LoadLibrary/FreeLibrary and GetProcAddress.

        With this method, no library file (.lib or .a) is required. You can connect directly to the dll. LoadLibrary must be called before the dll can be accessed. FreeLibrary should be called before exiting the program. GetProcAddress is used to access specific functions in the dll by retrieving their addresses. You'll need to call GetProcAddress for each function from the dll you want to work with. Check a Win32 reference for more information on the use of these functions.

    7. What are other useful compiler flags?

      You can get help by using the --help option.
      For example:

      gcc --help
       
       
      

      You can display the compiler version using the -dumpversion option.

      You can display the platform using the -dumpmachine option.

      You can specify include files not in your path by using -I.
      For example:

      gcc -c hello.c -I../pdcurses
       
       
      

      You can use -g to add debug information for the debugger to work properly.

      You can use -D to specify a define.
      For example:

      gcc -c hello.c -D__WINDOWS__
       
       
      

      You can use -v to find out more about the executables being invoked.
      For example:

      gcc -v
       
       
      
    8. What are other useful linker flags?

      You can use -l as shorthand notation for a library. So a library such as libtst.a can be specified for linking using its full name or -ltst.

      You can specify a directory to find the library files in by using -L and giving the directory path (similar to -I).

      For newer versions of MinGW, the mingwm10.dll handles memory allocation/dellocation used with exception handling in a threaded environment. If you do not need threads in your application (-mthreads is not used as a switch), you will not have mingwm10.dll added. If mingwm10.dll is not linked in, you do not need to distribute it with the programs you create in order for those programs to run.

      Newer versions of MinGW attempt to work with dlls whenever possible. If you don't want to have to distribute the standard C or C++ library as separate dlls, you may need to add some switches. If you link statically with libraries, they may bring in debug information and make the files you build much larger. You can use the tricks listed in the why are my executable sizes large section to bring them back to more normal file sizes. Here's what to do to statically link standard libraries. In the link command, add one or both of the following, depending on which libraries you're using:

      -static-libgcc -static-libstdc++
       
       
      

      Trying the above with real world Open Source applications and libraries, I hit some linking issues when attempting to link dynamic libraries built this way with programs built this way. The error complained about a multiple definition of _Unwind_Resume in libgcc_eh.a. By adding -lgcc_eh after -static-libgcc, it seems to have resolved the issue for me.

     
    
  21. Compiler output
    1. Error redirection

      MinGW displays compilation and linking errors to stderr instead of stdout. To easily view these errors, you may need to redirect the output to stdout or a file. Some methods to do so include using one of the following programs:

      • redir,
        There was a copy at Mumit Khan's site. You can check Koders or another code search engine for the source code.
      • errfix,
        See the Errfix.C file in the Snippets collection.
      • On Windows NT systems, stderr can be redirected.
        For example: gcc --help 2>&1|more
      • Within msys or via the command prompt, stderr can also be redirected to stdout on later versions of Windows.
        For example: gcc --help 2>&1|less
    2. Keeping the DOS box open

      Some users have had trouble with the DOS box (aka Windows Command Prompt) closing after building a program and haven't been able to see their errors. The MinGW32 mailing list came up with several suggestions on how to deal with this. One suggestion from Franco Bez is as follows:

      By modifying a few Registry Keys - you can add a context menu item Run - stay open, so you simply right click on the Batch file and choose Run - stay open and your batch runs and stays open.

      The following Registry files do this and a little more:

      • context menu DOS Box for Folders and files - opens a dos box in the folder
      • context menu Notepad for all files, even those with missing/unknown extension - opens the file in Notepad for editing
      • context menu Run - stay open for bat, com and exe files

      Place the following lines in a file (such as Win95_98.reg or WinNT.reg) and simply merge the file for your system to your registry by doubleclicking it. The example below is for Windows NT. If you are using a Windows 95 or 98 system, change all the occurrences of cmd to command.com.

      REGEDIT4
       
      [HKEY_CLASSES_ROOT\*]
       
      [HKEY_CLASSES_ROOT\*\shell]
       
      [HKEY_CLASSES_ROOT\*\shell\dos_box]
      @="DOS Box"
       
      [HKEY_CLASSES_ROOT\*\shell\dos_box\command]
      @="cmd"
       
      [HKEY_CLASSES_ROOT\*\shell\open]
      @="Notepad"
       
      [HKEY_CLASSES_ROOT\*\shell\open\command]
      @="Notepad.exe %1"
       
      [HKEY_CLASSES_ROOT\Folder\shell]
       
      [HKEY_CLASSES_ROOT\Folder\shell\dos_box]
      @="DOS Box"
       
      [HKEY_CLASSES_ROOT\Folder\shell\dos_box\command]
      @="cmd /k cd %1"
       
      [HKEY_CLASSES_ROOT\batfile\shell]
       
      [HKEY_CLASSES_ROOT\batfile\shell\runstayopen]
      @="R&un - Stay open"
       
      [HKEY_CLASSES_ROOT\batfile\shell\runstayopen\command]
      @="cmd /k %1"
       
      [HKEY_CLASSES_ROOT\comfile\shell]
       
      [HKEY_CLASSES_ROOT\comfile\shell\runstayopen]
      @="R&un - Stay open"
       
      [HKEY_CLASSES_ROOT\comfile\shell\runstayopen\command]
      @="cmd /k %1"
       
      [HKEY_CLASSES_ROOT\exefile\shell]
       
      [HKEY_CLASSES_ROOT\exefile\shell\runstayopen]
      @="R&un - Stay open"
       
      [HKEY_CLASSES_ROOT\exefile\shell\runstayopen\command]
      @="cmd /k %1"
      
     
    
  22. COM support

    MinGW has some support for COM programs. Programmers have had much better luck writing COM applications in C than C++. Work is in progress to improve support. Check the MinGW32 mailing list archives for more details on COM and links to example files.

     
    
  23. Preprocessing

    A preprocessor allows you to programatically include a file in several other files without having to repeat the code in each files. It also lets you conditionally include certain parts of a file based on defined settings.

    Most C/C++ programs make use of the preprocessor. Even other languages like Fortran may make use of one to help with program maintenance issues. You can use the preprocessor on other file types as well such as HTML files to take advantage of its benefits for web development and help file creation. With web design, this technique can replace server side includes (SSI) or asp include files.

    Try this command to preprocess html files and be able to #include pieces of HTML code in them:

      
      g++ -C -E -P -x c sourcefilename.htm -o finaloutputfilename.html
     
     
    

    The -C option keeps the preprocessor from discarding C/C++ comments (lines starting with // or delimited with /* */). The -E option is needed with the -C option and causes the results of the preprocessor to show either to standard output or to an output file if one is given. The -P option keeps linemarkers generated for the included files from appearing in the output. The -x C option specifies the source language (in this case C). Since the file has an extension of .htm or .html instead of .c or .cpp, the precompiler does not know how to deal with the file. This tells it to deal with the file as if it was a C file. The -o option indicates the name of the output file, in this case finaloutputfilename.html

    In this example, I've given my source file the extension of .htm to keep from confusing it with the final result files with extensions of .html. You can also keep your source files in one directory and the output files in another. When you run the preprocessor from a command line be sure to substitute the names of the files you are working with for sourcefilename.htm and finaloutputfilename.html.

    To simplify the process even further, use a makefile to preprocess all the files for an entire web site with one command.

    If you need a more powerful preprocessor than one used by C/C++ compilers, the Open Source program gpp (general-purpose preprocessor) is a useful alternative.

     
    
  24. Make programs

    Working with a make program is one very good solution to keep from having to continually type all your compiler commands on the command line. There are several versions of make available both as freeware and commercially. A port of GNU make is available at the MinGW site and other Windows ports are available. A version of make that handles long command lines in a DOS environment or when working with DOS programs is available especially for djgpp with the djgpp distribution. Watcom includes wmake. Microsoft has a free version of their nmake program hiding somewhere at their web site. (Run a search at their site to find it.) Msys supplies a copy of make and actually prefers you use it and keep other versions you have out of the MinGW bin directory.

    To run make, type make at the command line in the directory where a makefile resides. If the file is not specifically named makefile, you'll need to specify the file name. For instance, to run a file named makeprog.mak, use the command:

    makefile -f makeprog.mak
     
     
    

    I have a Windows port of the GNU make program that I use for all my compilers. That gives me one common syntax to use for my makefiles since different companies' versions of make have their own way of doing things. I keep make in a general purpose utility directory that is part of my environment path, so it's usually the first version that's run whenever I need it. When I run msys, it doesn't look in that directory since it's not part of the enivornment path for msys. That way, msys uses its own version of make.

    When using make, be careful of tabs when editing your makefile. My editors are set to turn tabs to spaces and if you do that with your makefile, make won't work properly. The program requires tabs in certain locations of your makefile as part of the command syntax. There's an example of how to change tab settings when editing makefiles with the Scite editor in my SciTE Tips.

    Make can be used with a variety of languages and programs. You don't have to use it only with MinGW or only for C/C++. If you're into web development or creating help files, you can use make and the MinGW preprocessor in place of techniques such as SSI or templates as a method of adding repeated html code to several files.

    Here's a sample makefile for working with web pages. It runs any files with the .htm extension through the MinGW preprocessor and creates output files with the .html extension. It also cleans (deletes) any files with the *.html extension if you run make clean. Using this as a template, you can substitute .c or .cpp files for .htm files, .o files for .html and change the compiler directive to gcc -c or g++ -c to see this work for C/C++ files. You can also substitute file extensions and commands for other file types and languages that you work with.

    src=$(wildcard *.htm)
    objects = $(src:%.htm=%.html)
     
    all: $(objects)
    $(objects) : $(src);  g++ -C -E -P -x c $< -o $@
     
    #Use del or rm or deltree or whatever the name is of your machine's command to delete files.
    #Might need to include path to the command in some instances.
    #clean: ; /mingw/msys/bin/rm *.html
    clean: ; del *.html
     
     
    
  25. Patches

    If you have changes to source code, it may be easier to distribute them as patches than to send the entire code to someone or list the changes by hand. Patching is an automated process of updating files using tools such as patch and diff.

    Patches can be created by comparing two files with the diff program or from various version control systems such as RCS. Several versions of diff have been ported to Windows and DOS. Check sites that have Win32 ports of Unix style tools or use the version supplied with msys. There are also several versions of the patch program available for use in applying patches to source code. Detailed help information on using diff and patch and the various options available for working with them was also available in WinHelp format from the Virtually Un*x site.

    To create a patch, compare the two versions of the file with diff. Here's an example:

    diff --ignore-all-space old\file.cpp current\file.cpp > patch.diff
    

    The example ignores whitespace and compares the old version of file.cpp in directory old with the latest version in directory current. The output is redirected to a file. Most patches these days also include the -c or -u option which allows programmers to figure out what has changed in a file by viewing the context of the lines around it. Another common option is -r for working with entire directories instead of single files. The option -p may also be useful. It adds information on what C functions a change appears in. I typically use -Naurp for my own patches. Occasionally I'll add --strip-trailing-cr, if I need to deal with differences between line endings (linefeed versus carriage return plus linefeed).

    To patch a file, you'll need the original source file (old version) and the file with the patches created by diff. Here's an example of how to call patch:

    patch -o file.cpp ..\old\file.cpp patch.diff
    

    The command patches file.cpp in the old directory and outputs the updated file to file.cpp (specified by the -o option). Another useful switch for use with patch is -p which can affect the naming/location of files and can be used when working with compared directories. I typically place the unzipped or unarchived original source from an Open Source project in the src directory and the source I've changed in the tmp directory when creating a patch. Later, I can apply the patch I made using -p2.

     
    
  26. Is there a package manager or build script system?

    I've looked at several Linux package managers and the tools available on various BSD systems. I haven't been particularly happy with any of them. Slackware's slackbuild system comes the closest to what I'm comfortable with as a developer. However, very few of the solutions I've looked at work cross-platform (including on Windows) and none give you language implementation choices. I am working on my own build system to automate building of common Open Source programs and libraries in a cross-platform manner. For now, it uses bash and some Unix-like utility programs, but it's flexible enough to use other scripting languages like Javascript in the future. So, you can basically pick which set of base tools and what scripting language you want to work with on your system and it will go with that. I not only needed tools to automate building for my system, I also needed install and uninstall scripts to use while building programs with dependencies. I'm planning on adding better dependency support and capabilities to obtain and install source code and packages (executable programs and libraries). The system will work for low resource computers or machines that require Sneakernet to get files to and from their directories. Also in the plans are ways to provide internationalized documentation on how to use the provided packages, how they might work together and status information on packages installed or available. I have enough of the system operational to be able to do useful work with it, but I plan many more changes to it for the future. If anyone would like to discuss it further or would care to discuss design decisions and tradeoffs when building programs for your system or when creating your own package management systems, please contact me via the CppDesign mailing list. I would be very interested in sharing design issue discussions with other developers. I also have a LM BLDpage that gives a high level overview of the project.

    Other Windows Based Package Management Options

    Spkg is a package manager based on the Linux Slackware package management system. It has been ported to Windows. You'll find a copy at http://spkg.megous.com/.

    After recently working with some Linux Slackware variants, I found myself wondering what Windows had to offer as far as package management and packaging tools. Without a package manager, it can be very hard to keep track of all the various Open Source libraries that may get installed on your system while trying to build Open Source programs. I've had some success in porting a portion of the Tukaani Slackware pkgtool scripts and was able to port the program spkg to Windows. The spkg modifications for Windows have been integrated with the original source code to create the latest version of spkg. Source and Windows executable are available from the site mentioned above.

    MinGW does provide a system called mingwports. A mingwport is a group of files that create a template for porting libraries or programs. The files basically execute a series of commands to build a library or program from scratch. They automate all the steps a user would generally take to create that library or executable. It appears to work very similar to the SlackBuild script concept, but requires a lot more files. There was no official documentation, so I figured out how to use it myself and updated the offical MinGW wiki with a page containing what I learned from my experimentation with mingwport scripts. It may or may not still be available because the MinGW project has deprecated mingwports.

    The latest system the MinGW project is advocating is mygports which are very similar and supposedly compatible to cygports. Again, there's no real documentation on how to set them up, create or work with. I'm not going to the effort to figure out how to use this latest system that's come in to favor, because I don't know when it will become deprecated as well. Members of the MinGW project have also created mingw-get which is now part of the official way to install MinGW. It's very much like apt-get and works in a similar manner. I realize apt-get is very popular, but I'm personally not a big fan and I find the mingw-get system even more user-unfriendly than apt-get. My biggest issues with mingw-get (besides serious lack of decent documentation) is the inability to get it to download to the directories I want it to and lack of control as to which files get updated to new versions and how to get older versions for backward compatibility if needed. I find it much more difficult to use and maintain multiple versions of MinGW with the new mingw-get system in place. Supposedly, according to what documentation I could find, changing the sysroot paths in \MinGW\var\lib\mingw-get\data\profile.xml should change where mingw-get places files, but I haven't had much luck with this in a practical environment. Most of these issues might be rectified by clearer documentation, but I have no way of knowing at this point. I'm also still uncomfortable about the previous download problems I had with the tool. Unfortunately, if you want to avoid using mingw-get with MinGW installation, the only way is to download MinGW from somewhere else or build it yourself as mentioned in the how to install section.

    As far as package management tools and build scripts, Windows seems behind Linux in this area. This is probably because most average Windows users don't build all their programs from source or rely on a central location such as a distribution's repository to supply all their programs (executable files) for them. Linux users or the people in charge of a distribution's repository have to rebuild all (or several) programs in a distribution each and every time key libraries such as glibc change. Luckily, Windows usually has excellent backward compatibility and does not require this kind of major library change. There's a package management tool for SFU/SUA. Cygwin uses their installation program for package management. The MinGW project added mygports so they could make use of and be more compatible with the Cygwin package system. Some developers are using the openSUSE Build Service to create packages. However, there may still be issues to work out when downloading the files, dealing with the dependencies and get them out of their rpm formats into something more useable on Windows. There is code for package management systems for Windows at Sourceforge. I really haven't seen a lot of support and documentation in this area for Windows machines.

  27. GUIs/application frameworks/user interfaces
    1. Can I use MFC or OWL?

      MinGW provides access to the Win32 API. Theoretically, if you own the MFC source code you could build MFC libraries for MinGW. No one's tried this so far. If anyone does successfully accomplish it, please say so and it will be added to this document.

      For OWL owners, there is a port with additional features which supports various compilers including the gcc compiler line. Thanks to Greg Chicares on the MinGW32 mailing list for supplying this information. The latest information I could find on OWLNext project was at Sourceforge.

    2. Can I use X11 libraries and X Windows?

      Cygwin supplies the XWin server and X11 libraries to run X11 applications. However, they won't run without the Cygwin dlls. XMing provided an option to run X applications outside of Cygwin. It's a stand-alone X server. However, you need X11 libraries to build applications with. There was a post on the Wine wiki about an attempt to get Wine running with MinGW in order to run older Windows applications that might no longer work on current versions of Windows. The developer posted about getting as far as building X11 libraries.

      With that success in mind, I've since tried a few times to build X11 and an Xorg server natively on Windows. My latest try was a success. I now have a working XWin server and various standard X libraries such as X11. I've been able to port simple X programs like xfireworks, figurine, dclock, grabc and others and run them natively on Windows in conjunction with the XWin server.

      There are some porting issues to keep in mind when working with X libraries on Windows. There are collisions between Win32 header files and the X header files. One work-around was to use the XFree86Server flag with the Win32 headers, but this was deprecated and the flag is removed from newer MinGW runtime library versions. Another solution is to use the Xwindows.h and Xwinsock.h includes. The documentation in those include files does a good job of explaining the issues involved.

      My next step will be to try to build fltk and SDL so that they work with the X Windows libraries. That will allow me to port programs such as flxine to Windows. If anyone's interested in more details, you can contact me on the CppDesign mailing list.

    3. What GUIs/application frameworks/user interface libraries are available?

      There are a number of these available. The following are known to have worked with MinGW. There are several other libraries out there.

      • Curses, PDCurses, http://pdcurses.sourceforge.net/
      • PDCurses for "real" Windows, a fork of PDCurses that works in Windows and doesn't require console mode
      • Windows++, http://www.dilascia.com/wpp.htm
      • fltk, http://www.fltk.org/
        If you compile this and have any dlls for graphics libraries in your path, it will choose the dll over the static version even if you --enable-static and --disable-share
      • wxWidgets, http://wxwindows.org
      • Fox Toolkit
        Most Open Source applications appear to be written for version 1.6, but 1.7 provides additional internationalization support.
      • QT (There's also a download specifically for MinGW now at the QT web site.)
      • OWLNext
      • POCO
      • Ultimate++
      • AntTweakBar
      • Agar
      • V, http://vgui.sourceforge.net/
      • Open Amulet
     
    
  28. Libraries

    When I started this FAQ, I had to write some of the makefiles to get popular libraries to work with MinGW. Many didn't work. Today, along with several programs written specifically for MinGW or Windows programs ported from Visual C++ or other compilers to MinGW, quite a few popular Linux programs will compile with MinGW and even more will do so if you use msys. I'm leaving some of my previous library recommendations in the FAQ, but if you're looking for something specific, run a search on the Internet or ask on the MinGW or CppDesign mailing lists. I am very happy to report there are far too many libraries that work with MinGW for one person to list them all.

    You can check projects such as Gnuwin32 on Sourceforge or DevPaks created by the Dev C++ developers for pre-compiled standard libraries that you can easily add to MinGW and Msys.

    Here is a list of some of the libraries and programs from the original FAQ that could be built with MinGW.

    1. Graphics libraries
      • OpenGL

        OpenGl and related libraries have always been a nuisance to install with MinGW. The Openl32.dll is available with Windows itself. However, one needs the header files and a library to work with it. There were various versions and ports by developers, but OpenGL and it's related libraries were not completely a part of the official MinGW distribution. As it stands now, I believe the OpenGL headers and libopengl32.a are a part of the win32api and runtime library. Helper libraries such as glut are another story. In a typical MinGW distribution, one can find GL related header files (gl*.h) here: /MinGW/include/GL

        To link with the OpenGL library, don't forget the flags:
        -mwindows -lopengl32

        Since there were various ports by developers, one could find the glut library files with different names, such as libglut or libglut32. I recently looked into building the glut libraries from source and soon gave up. There's a better, more portable and more recently updated alternative. Freeglut is an Open Source implementation of glut available at Sourceforge. It builds fine with MinGW. Just remember to use --with-x=no when you configure.

      • DirectX

        The dlls and libraries are available. The headers are not. You can download the latest official DirectX version from Microsoft. You can use it on your system and develop with it and distribute applications you've built with it. Distributing DirectX itself can be an issue. Wine supplies some LGPL'd versions of the DirectX headers. MinGW-w64 supplies LGPL'd headers based on the Wine ones. MXE does something similar. You can use the headers from Wine as a starting point to create your own headers for DirectX. I've tried this in the past and it's worked well. This method has worked with programs like SDL, Milkytracker and Xine that can use DirectX. The headers are LGPL licensed, but if the Oracle v Google decision holds, APIs can't be copyrighted.

      • libpng and libjpeg and giflib and libtiff
        Check Sourceforge (or your favorite seach engine) for packaged versions of these already built and ready to be used in a Win32 environment. The patent on the GIF compression algorithm is now out of date, so the GIF format is a viable option for Open Source developers. There are libpng-apng patch files at Sourceforge as part of the libpng-apng project which provides animation capabilities to libpng.
      • libwebp, Google's web graphics format based on VP8 compression.
      • Mesa
      • Simple DirectMedia Layer, libu (widget library for SDL) and other multimedia libraries
      • Simple and Fast Multimedia Library (SFML)
    2. Database libraries
      • Xbase

        http://linux.techass.com/projects/xdb/
        Dbase/Clipper compatible, cross-platform database library. Successfully compiled with file locking off under MinGW.

      • libodbc++
        http://libodbcxx.sourceforge.net/
        C++ class library, similar to JDBC, for ODBC access. Compiled and built successfully with MinGW. For now, see the MinGW32 mailing list for some of the changes that were needed. See also, ODBC access below since ODBC is required to use this library.
      • Oracle access

        Oracle can be accessed using Oracle's pro*c and sqllib80.dll (or sqllib18.dll for those with older versions of pro*c). There was an example article on how to access Oracle from unsupported compilers at Oracle's web site. Oracle's OCI interface also works in some cases using oci.dll or ociw32.dll. Here's a link to an old article I wrote about how to access Oracle in C/C++ programs using MinGW and Oracle dlls.

      • ODBC access

        An ODBC manager (such as ODBC Data Sources program accessible via the Control Panel) is necessary to run ODBC programs. ODBC is available from Microsoft and other sources. Use your favorite search engine to see if you can find a version to download.

      • MetaKit

        Cross platform, C++ database library.

      • Hypertable

        http://www.hypertable.org/index.html
        Non-SQL databases for large scale web applications are now the rage. I've seen some mention of getting Hypertable to compile with MinGW.

    3. Other libraries

      Check the Available C++ Libraries FAQ at http://www.trumphurst.com/cpplibs/ for more options.

      • gettext

        GNU gettext is a library/tool used to help write internationalized and localized programs. I've attempted to build the library from source. It's not what I would consider a lightweight library and it's not very portable (needs patches just to build). It has a circular build dependency with iconv and newer versions also need several GTK+ libraries such as glib, libcroco and libxml2. I've since replaced it with two other lightweight libraries (one that supplies msgfmt, msgmerge and the other supplies gettext and libintl). It provides a minimal subset of GNU gettext's functionality but enough that it will work with the standard GNU autotools build system.

      • readline

        GNU readline library is used by various applications for command line editing. Some developers that prefer BSD style licenses have created a similar library called editline. There's a port of editline specifically to MinGW available at Sourceforge called MinGWEditLine. Appears to make a good replacement for readline.

      • zlib

        Compression library. Includes makefile for MinGW32.

      • pthreads

        Posix threads. A version of this library has been ported to Win32 to make up for missing Posix threading functionality on Windows. Check for RedHat's port or another Win32 version.

      • gnutls

        http://josefsson.org/gnutls4win
        Library used by some communications programs. If you prefer a BSD style license, check OpenSSL. If you want a Mozilla license check nss. There are also some lighter weight alternatives. Gnutls has a GPLv3 wrapper to emulate OpenSSL. Other solutions might not easily replace each other. If you're trying to build an Open Source application, check which solution it requires and offers support for. There are also important legal issues with regarding mixing licenses for some of these libraries with variously licensed applications.

      • POCO

        General purpose library providing network, parsing, threading, security, database and other functionality.

      • Ultimate++
      • Boost

        Cross platform, general purpose C++ libraries. Not the easiest library in the world to build and there's a lot to it, but some Open Source projects find these routines useful and portable.

      • ICU (International Components for Unicode)

        Cross platform, C/C++ internationalization library. Based on the work of IBM and others in internationalization. This library is used by Boost.

     
    
  29. Other programming tools

    Besides make, IDEs and editors and Debuggers, there are several basic utilities and tools that have become standards over the years.

    1. Unix style tools

      Many users have found Win32 or DOS versions of Unix programming tools very helpful. Search for the Gnuwin32 project at Sourceforge or UnxUtils at Sourceforge or archives of the Virtually UN*X tools. Gnuish MS-DOS collections found at many ftp archives have older versions of the standard GNU utilities ported to 16 bit DOS. Less, http://www.greenwoodsoftware.com/less/ is a very nice file filter for viewing files quickly. It's similar to the DOS more program, but less does more. The most up-to-date version of Unix style tools I've been able to find is the Busybox-W32 project. Busybox is a lightweight, compact replacement of standard GNU utilities and Busybox-W32 is a port of a version of it to Windows. I also want to mention msys at the MinGW site. It provides a Linux like shell environment and standard GNU tools. It's indispensible for compiling programs that need to go through the ./configure protocol. There's also GNU Bash for Windows which is based on a Cygwin port, but provides all the necessary files so you don't need to install Cygwin to use it. Microsoft is offering a shell called Powershell at their web site. It works on later versions of Windows and, among other things, provides some emulation of popular DOS, Unix/Linux shell commands.

      I'm in the process of porting various lightweight tools as part of my LM BLD project. I have some working such as find, xargs, mktemp, sha1sum, etc. Several more are in the works. I even have a program to display man pages on Windows.

    2. DOS tools

      For those who prefer working with tools other than those found in Unix environments, be sure to check out the DOS utilites at FreeDOS, http://www.freedos.org/ If you want utilities similar to standard MS DOS ones, this is a great place to look. FreeDOS utilities even includes a deltree version that works on Windows NT and other versions of Windows that no longer supply it. All tools at FreeDOS are compiled for DOS 16 bit systems. Source is included with most.

    3. Other tools

      My favorite Open Source tools (and some freeware ones too) are mentioned on my Switching to Open Source page.

      Some of the Open Source tools I like to use required patches to get them to work. I started a patches page to keep track of fixes I've had to do for code on various operating systems and compilers. The page includes some patches for Open Source programs that build using MinGW. I ended up with so many patches, I can no longer put them all up on one page. They are a large part of the LM BLD project which is providing me with a way to document all the patches I've needed to get applications to build successfully they way I want them to.

     
    
  30. Why is this FAQ copyrighted?

    I am a proponent of Open Source and Creative Commons style projects, so you may be wondering why I copyrighted this FAQ rather than using a GNU or Creative Commons licensing scheme. At the time I originally wrote the FAQ, I was monitoring the mingw32 mailing list daily and updating it as new and frequent questions appeared. I did not want versions of it proliferating all over the web, especially as it was a work in progress. I was hoping to keep the FAQ up-to-date and accurate. There's no way I could ensure the information I was disseminating was accurate and up-to-date if there were old copies being distributed elsewhere. My original intention was to have one copy only and other sites were welcome to link to it if they needed to refer to information. Please note that anyone distributing versions of this FAQ or the original versions is in violation of copyright laws. If you see old versions of the FAQ, please let the distributors know. If you have an old copy of the FAQ at your web site, please remove it. Please link to the current official MinGW information (typically at the site where you downloaded your particular fork of MinGW). If you want, you can link to the MinGW FAQ you are currently reading at my web site. I also believe strongly in fair use. You have the right to keep a copy of this document or various incarnations for personal use (not for distribution purposes).

    Since I'm no longer maintaining the official FAQ, I will not be updating this document nearly as often as I used to update the original. I have, however, decided to keep the copyright license intact, since I still intend to be updating the document and still do not want a proliferation of out-of-date MinGW documents widely distributed. I feel it's more beneficial to the community to have a place to go for reliable information on the project, rather than having several old, outdated copies on as many web sites as possible. Several web sites might reach more people, but if developers are unhappy with the product because the documentation is wrong or not user friendly, it's a disservice to that Open Source project. If you're as excited about the prospects of Open Source projects like MinGW and what they can do as I am, then please link or refer people to the official web sites instead of copying dated documentation. Also, please participate and help these projects keep their documentation up-to-date and accurate. Thank you.

 

To the main page.

 

Validate XHTML



The information on these pages is copyrighted by the author with all rights reserved. Reproduction of anything without the author's permission is in violation of copyright laws.
All original material is copyrighted:
(c) Copyright 1999, 2008 by Laura Michaels
All Rights Reserved
Last Update: 20140831