Visual Studio 2013 генерирует исключение в ntdll.dll при использовании библиотеки GLEW
Я пишу кроссплатформенный 3D-движок с использованием OpenGL. В прошлом я использовал OpenGL 1 с некоторыми расширениями, и он хорошо работал на Windows / Mac / Linux. Но теперь я решил использовать версию OpenGL 3.3. Переключение на OpenGL 3.3 вызвало сбой моего приложения при запуске.
Проблема в том, что когда я выбираю цель сборки Win32, VS использует библиотеки из папки C: / Windows / SysWOW64, которая является 64-битными библиотеками. И когда я выбираю цель сборки x64, VS использует библиотеки из C: / Windows / System32.
Я использую Visual Studio 2013 на Windows 8.1 x64.
Так что это ошибка Visual Studio, и я должен переключиться на другую IDE для сборки Windows, или я что-то не так с конфигурацией проекта Visual Studio OpenGL?
Решение
Проблема в том, что когда я выбираю цель сборки Win32, VS использует библиотеки из папки C: / Windows / SysWOW64, которая является 64-битными библиотеками.
Нету. SysWOW64 содержит 32-битные библиотеки.
И когда я выбираю цель сборки x64, VS использует библиотеки из C: / Windows / System32.
Да, потому что 64-битные библиотеки расположены в System32,
Прежде чем спросить: «Подожди, что ?! Какие наркотики опьяняли разработчиков Windows?» позвольте мне сказать вам, что на это есть свои вполне обоснованные причины. Проблема в том, что во многих программах где-то жестко прописан путь System32. И когда эти программы перекомпилируются для 64-битной версии, эти жестко запрограммированные пути остаются, и хотя они 64-битные, они ищут библиотеки в расположении System32. Это также причина, почему DLL-интерфейс OpenGL назван opengl32.dll также на 64-битных системах.
При запуске 32-разрядных приложений разрешение имен файловой системы прозрачно заменяет пути для разрешения в каталог SysWOW64.
Итак, в заголовке вашего вопроса вы спросили о сбое в ntdll.dll. Что об этом?
Другие решения