Git conversion: Make reactos the root directory, move rosapps, rostests, wallpapers...

[reactos.git] / reactos / sdk / lib / 3rdparty / stlport / doc / README.windows

diff --git a/reactos/sdk/lib/3rdparty/stlport/doc/README.windows b/reactos/sdk/lib/3rdparty/stlport/doc/README.windows
deleted file mode 100644 (file)
index 7389ff9..0000000
--- a/reactos/sdk/lib/3rdparty/stlport/doc/README.windows
+++ /dev/null
@@ -1,55 +0,0 @@
-Note for Windows users:\r
-\r
-  It is highly recommended to declare the Windows OS version you are\r
-targetting when building the library as well as when using it. You can do so\r
-thanks to the well known Microsoft macros WINVER, _WIN32_WINDOWS or\r
-_WIN32_WINNT, see your platform SDK documentation for a description\r
-of those macros and how to use them. To define it when building the\r
-library, use the configure script --extra-cxxflag option. Here is the\r
-configuration to build STLport using Visual Studio 2005 and targetting\r
-Windows XP:\r
-\r
-configure -c msvc8 --extra-cxxflag "/D_WIN32_WINNT=0x0501"\r
-\r
-  If you do not declare it at build time STLport will adapt to the PSDK in\r
-use, windows.h gives a default value to WINVER. However, when using the\r
-library, windows.h is not necessarily included, at least not by STLport\r
-internally, so none of the macros are defined which will result in an\r
-inconsistency in the build process which most of time will generate undefined\r
-behavior at runtime.\r
-\r
-  Here is the main reason for following this advise, the Windows 95\r
-compatibility issue:\r
-\r
-  Because of a modification in the behavior of the Win32 API functions\r
-InterlockedIncrement and InterlockedDecrement after Windows 95, STLport\r
-libraries built for Windows 95 cannot be used to generate an application\r
-built for Windows XP for instance. So, if you build STLport with a Windows\r
-95 PSDK, STLport will be ready for Windows 95. If you then use it without\r
-defining _WIN32_WINDOWS to signal Windows 95 compatibility, STLport will\r
-consider that it can use latest Windows OS features like the new\r
-InterlockedIncrement and InterlockedDecrement functions which change the\r
-memory footprint of some internal STLport objects making it incompatible\r
-with the libraries built for Windows 95.\r
-\r
-  Normally, doing so wouldn't generate any compilation or link error, you\r
-would only experiment undefined behavior at runtime. In order to make this\r
-problem more obvious STLport forces a link time error in debug mode (_DEBUG\r
-macro defined).\r
-\r
-Unresolved symbol will be:\r
-  - 'building_for_at_least_windows98_but_library_built_for_windows95'\r
-  if you are trying to use STLport libraries built for Windows 98 or later\r
-  to generate an application targetting the Windows 95 platform.\r
-  - 'building_for_windows95_but_library_built_for_at_least_windows98'\r
-  if you are trying to use STLport libraries built for Windows 95 to generate\r
-  an appliation targetting the\r
-  \r
-  Windows XP platform for instance.\r
-\r
-  Of course, targetting the latest Windows OS versions will give you the best\r
-performance from STLport. This is why when none of the platform macros are\r
-defined STLport consider that there is no minimum OS requirement and will\r
-use the latest API functions. There is only one exception to this behavior,\r
-the SwitchToThread function that is used only if you define _WIN32_WINNT to a\r
-value higher or equal to 0X0400.\r