Convert crlf->lf line endings.

Windows/DOS users should enable core.autocrlf from now on:

  git config --global core.autocrlf true

1 files changed, 163 insertions, 163 deletions

diff --git a/docs/README.WIN32 b/docs/README.WIN32
index ce595076bd..97e1ffb7a7 100644
--- a/docs/README.WIN32
+++ b/docs/README.WIN32
@@ -1,163 +1,163 @@
-File: docs/README.WIN32

-

-Last updated: Apr 25, 2007 - Karl Schultz - kschultz@users.sourceforge.net

-

-Quick Start

------ -----

-

-Unzip the MesaLib, MesaGLUT, and MesaDemos ZIP files into the same

-directory.  The libs and demos build separately, so if you do not care

-about the demos or GLUT, you only need to unzip MesaLib.  If you unzip

-more than one ZIP file, they all need to be unzipped into the same

-directory.  Don't worry, you will not overwrite anything.

-

-The Windows build system uses Microsoft Visual Studio.  Project files

-for a specific version of Visual Studio are in their own directory in

-the top-level "windows" directory.  For example, Visual Studio 8 files

-are in windows/VC8.

-

-Support has been dropped for versions of Visual Studio prior to 8. The

-main reason is because Microsoft now provides a free compiler and

-developer environment.  Visual Studio Express can be found at

-

-http://msdn.microsoft.com/vstudio/express/visualc/default.aspx

-

-You'll also need the Platform SDK.  Instructions for obtaining and

-using the SDK with Visual Studio Express can be found at

-

-http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/

-

-If you are stuck using VC6 or VC7, you may start with these project

-files, but you may need to modify them to reflect changes in the

-Mesa source code tree.  If you sucessfully update the project files,

-please submit them to the author of this document so that they may

-be included in the next distribution. 

-

-The project files to build the core Mesa library, Windows Mesa

-drivers, OSMesa, and GLU are in the mesa directory.  The project files

-to build GLUT and some demo programs are in the progs directory.

-

-Makefiles are no longer shipped or supported, but can be generated

-from the projects using Visual Studio.

-

-

-Windows Drivers

-------- -------

-

-At this time, only the GDI driver is known to work.  Most of the demos

-in progs/demos should work with this driver.

-

-Source code also exists in the tree for other drivers in

-src/mesa/drivers/windows, but the status of this code is unknown.

-

-The GDI driver operates basically by writing pixel spans into a DIB

-section and then blitting the DIB to the window.  The driver was

-recently cleaned up and rewitten and so may have bugs or may be

-missing some functionality.  The older versions of the CVS source may

-be useful in figuring out any problems, or report them to me.

-

-To build Mesa with the GDI driver, build the mesa, gdi, and glu

-projects in the Visual Studio workspace found at

-

-	windows/VC8/mesa/mesa.sln

-

-The osmesa DLL can also be built with the osmesa project.

-

-The build system creates a lib top-level directory and copies

-resulting LIB and DLL files to this lib directory.  The files are:

-

-	OPENGL32.LIB, GLU32.LIB, OSMESA32.LIB

-	OPENGL32.DLL, GLU32.DLL, OSMESA32.DLL

-

-If the MesaDemos ZIP file was extracted, the DLL files are also copied

-to the demos directory.  This facilitates running the demos as described

-below.

-

-

-GLUT and Demos

----- --- -----

-

-A Visual Studio workspace can be found at 

-

-	windows/VC8/progs/progs.sln

-

-It can be used to build GLUT and a few demos.  The GLUT lib and DLL

-are copied to the top-level lib directory, along with the Mesa libs.

-

-The demo build system expects to find the LIB files in the top level

-lib directory, so you must build the Mesa libs first.  The demo

-executables are placed in the demos directory, because some of them

-rely on data files found there.  Also, the Mesa lib DLL's were copied

-there by the Mesa lib build process.  Therefore, you should be able to

-simply run the demo executables from the demo directory.

-

-If you want to run the demos from the Visual Studio, you may have to

-change the startup directory and explicitly state where the executables are.

-

-You may also build all the demo programs by using a makefile.  Go to

-the progs/demos directory and make sure you have executed VCVARS32.BAT

-or whatever setup script is appropriate for your compiler.  Then,

-

-	nmake -f Makefile.win

-

-should build all the demos.

-

-

-Build System Notes

------ ------ -----

-

-VC6 (not actively supported)

----

-

-Visual Studio 6 does not recognize files with the .cc extension as C++

-language files, without a lot of unnatural tweaking.  So, the VC6

-build process uses custom build steps to compile these files in the

-GLU library.

-

-Two additional configurations are provided, Debug x86 and Release x86

-that activate the shader code compilation by defining SLANG_86.  It is

-unknown if and how this works.

-

-VC7 (not actively supported)

----

-

-The above-mentioned .cc problem does not exist in this version.

-

-VC8

----

-

-No notes.

-

-

-General

--------

-

-After building, you can copy the above DLL files to a place in your

-PATH such as $SystemRoot/SYSTEM32.  If you don't like putting things

-in a system directory, place them in the same directory as the

-executable(s).  Be careful about accidentially overwriting files of

-the same name in the SYSTEM32 directory.

-

-The DLL files are built so that the external entry points use the

-stdcall calling convention.

-

-Static LIB files are not built.  The LIB files that are built with are

-the linker import files associated with the DLL files.

-

-The si-glu sources are used to build the GLU libs.  This was done

-mainly to get the better tessellator code.

-

-To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE

-to the project settings.  You will also need to edit src/mesa.def to

-change all the gl* symbols to mgl*.  Because this is easy to do with a

-global replace operation in a text editor, no additional mangled

-version of mesa.def is maintained or shipped.

-

-If you have a Windows-related build problem or question, it is

-probably better to direct it to me (kschultz@users.sourceforge.net),

-rather than directly to the other Mesa developers.  I will help you as

-much as I can.  I also monitor the Mesa mailing lists and will answer

-questions in this area there as well.

-

-

-Karl Schultz

+File: docs/README.WIN32
+
+Last updated: Apr 25, 2007 - Karl Schultz - kschultz@users.sourceforge.net
+
+Quick Start
+----- -----
+
+Unzip the MesaLib, MesaGLUT, and MesaDemos ZIP files into the same
+directory.  The libs and demos build separately, so if you do not care
+about the demos or GLUT, you only need to unzip MesaLib.  If you unzip
+more than one ZIP file, they all need to be unzipped into the same
+directory.  Don't worry, you will not overwrite anything.
+
+The Windows build system uses Microsoft Visual Studio.  Project files
+for a specific version of Visual Studio are in their own directory in
+the top-level "windows" directory.  For example, Visual Studio 8 files
+are in windows/VC8.
+
+Support has been dropped for versions of Visual Studio prior to 8. The
+main reason is because Microsoft now provides a free compiler and
+developer environment.  Visual Studio Express can be found at
+
+http://msdn.microsoft.com/vstudio/express/visualc/default.aspx
+
+You'll also need the Platform SDK.  Instructions for obtaining and
+using the SDK with Visual Studio Express can be found at
+
+http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/
+
+If you are stuck using VC6 or VC7, you may start with these project
+files, but you may need to modify them to reflect changes in the
+Mesa source code tree.  If you sucessfully update the project files,
+please submit them to the author of this document so that they may
+be included in the next distribution. 
+
+The project files to build the core Mesa library, Windows Mesa
+drivers, OSMesa, and GLU are in the mesa directory.  The project files
+to build GLUT and some demo programs are in the progs directory.
+
+Makefiles are no longer shipped or supported, but can be generated
+from the projects using Visual Studio.
+
+
+Windows Drivers
+------- -------
+
+At this time, only the GDI driver is known to work.  Most of the demos
+in progs/demos should work with this driver.
+
+Source code also exists in the tree for other drivers in
+src/mesa/drivers/windows, but the status of this code is unknown.
+
+The GDI driver operates basically by writing pixel spans into a DIB
+section and then blitting the DIB to the window.  The driver was
+recently cleaned up and rewitten and so may have bugs or may be
+missing some functionality.  The older versions of the CVS source may
+be useful in figuring out any problems, or report them to me.
+
+To build Mesa with the GDI driver, build the mesa, gdi, and glu
+projects in the Visual Studio workspace found at
+
+	windows/VC8/mesa/mesa.sln
+
+The osmesa DLL can also be built with the osmesa project.
+
+The build system creates a lib top-level directory and copies
+resulting LIB and DLL files to this lib directory.  The files are:
+
+	OPENGL32.LIB, GLU32.LIB, OSMESA32.LIB
+	OPENGL32.DLL, GLU32.DLL, OSMESA32.DLL
+
+If the MesaDemos ZIP file was extracted, the DLL files are also copied
+to the demos directory.  This facilitates running the demos as described
+below.
+
+
+GLUT and Demos
+---- --- -----
+
+A Visual Studio workspace can be found at 
+
+	windows/VC8/progs/progs.sln
+
+It can be used to build GLUT and a few demos.  The GLUT lib and DLL
+are copied to the top-level lib directory, along with the Mesa libs.
+
+The demo build system expects to find the LIB files in the top level
+lib directory, so you must build the Mesa libs first.  The demo
+executables are placed in the demos directory, because some of them
+rely on data files found there.  Also, the Mesa lib DLL's were copied
+there by the Mesa lib build process.  Therefore, you should be able to
+simply run the demo executables from the demo directory.
+
+If you want to run the demos from the Visual Studio, you may have to
+change the startup directory and explicitly state where the executables are.
+
+You may also build all the demo programs by using a makefile.  Go to
+the progs/demos directory and make sure you have executed VCVARS32.BAT
+or whatever setup script is appropriate for your compiler.  Then,
+
+	nmake -f Makefile.win
+
+should build all the demos.
+
+
+Build System Notes
+----- ------ -----
+
+VC6 (not actively supported)
+---
+
+Visual Studio 6 does not recognize files with the .cc extension as C++
+language files, without a lot of unnatural tweaking.  So, the VC6
+build process uses custom build steps to compile these files in the
+GLU library.
+
+Two additional configurations are provided, Debug x86 and Release x86
+that activate the shader code compilation by defining SLANG_86.  It is
+unknown if and how this works.
+
+VC7 (not actively supported)
+---
+
+The above-mentioned .cc problem does not exist in this version.
+
+VC8
+---
+
+No notes.
+
+
+General
+-------
+
+After building, you can copy the above DLL files to a place in your
+PATH such as $SystemRoot/SYSTEM32.  If you don't like putting things
+in a system directory, place them in the same directory as the
+executable(s).  Be careful about accidentially overwriting files of
+the same name in the SYSTEM32 directory.
+
+The DLL files are built so that the external entry points use the
+stdcall calling convention.
+
+Static LIB files are not built.  The LIB files that are built with are
+the linker import files associated with the DLL files.
+
+The si-glu sources are used to build the GLU libs.  This was done
+mainly to get the better tessellator code.
+
+To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE
+to the project settings.  You will also need to edit src/mesa.def to
+change all the gl* symbols to mgl*.  Because this is easy to do with a
+global replace operation in a text editor, no additional mangled
+version of mesa.def is maintained or shipped.
+
+If you have a Windows-related build problem or question, it is
+probably better to direct it to me (kschultz@users.sourceforge.net),
+rather than directly to the other Mesa developers.  I will help you as
+much as I can.  I also monitor the Mesa mailing lists and will answer
+questions in this area there as well.
+
+
+Karl Schultz