Я могу скомпилировать свой 32-битный проект ATL (библиотека COM) в режиме отладки не в Юникоде Visual C ++ 6.0 со всеми пакетами обновлений в 64-битной Windows 7. Он отлично работает в обоих случаях: если запустить его нормально или запустить от имени администратора.
Но сборка не-Unicode Release не удалась.
Для начала компилятору VC ++ не удалось найти включаемые файлы (например, schannel.h, который находился в другой папке, поскольку он принадлежит Platform SDK). Только базовая папка Include самого VC ++ была проверена компилятором в сборке выпуска (несмотря на то, что папка Platform SDK была указана в настройках и в любом случае в режиме отладки проблем не было). Я пытался скопировать включаемые файлы из SDK в какое-то место за пределами Program Files (x86), думая, что VC ++ 6.0 может быть недостаточно хорош с проблемами UAC (и не может каким-то образом получить доступ к включениям в исходном ограниченном расположении), но это не удалось Помогите. Наконец, я скопировал все файлы, которые компилятор не смог найти, прямо в папку Include самого VC ++, и это позволило мне продолжить.
Теперь компилятор жалуется по-новому (всего несколько примеров):
C: \ Program Files (x86) \ Microsoft Visual Studio \ VC98 \ INCLUDE \ wintrust.h (139): ошибка C2143: синтаксическая ошибка: отсутствует ‘;’ до ‘*’
C: \ Program Files (x86) \ Microsoft Visual Studio \ VC98 \ INCLUDE \ wintrust.h (139): ошибка C2501: ‘CMSG_SIGNER_INFO’: отсутствует спецификатор класса хранения или типа
C: \ Program Files (x86) \ Microsoft Visual Studio \ VC98 \ INCLUDE \ wintrust.h (139): ошибка C2501: ‘psSignerInfo’: отсутствует спецификатор класса хранения или типа
Но журнал ошибок больше не содержит ни одного «файла не найден» или чего-либо подобного. Тем не менее ошибки выглядят очень похоже на симптомы «файл не найден», но это только предположение. Во всяком случае, я скопировал полную папку включения Platform SDK в папку включения VC ++, но это не помогло.
Опять же, сборка отладки просто отлично. Затем я начал сравнивать параметры компиляции и компоновки не-Unicode-сборок Debug и Release MinDependency и наконец сделал их идентичными.
Я обнаружил, что единственное, что сводит VC ++ с ума — это количество отладочной информации, которое он помещает в результирующий файл.
Короче. Если я скомпилирую с ключом / Zl (база данных программ для редактирования и продолжения), это работает. Все остальное терпит неудачу (включая только базу данных программы).
Ранее, когда у меня была Win XP, у меня не было таких проблем. Можно ли по-прежнему работать со старым VC ++ 6.0 на 64-битной Win7? Мне отчаянно нужен старый VC ++, так как у новых слишком много проблем с совместимостью (у меня также есть VS 2008, и там все хорошо, но даже когда он связывается в MinDependency, полученный .DLL не работает с некоторыми очень старыми системами).
Я предполагаю, что VC ++ может даже использовать другой компилятор, когда используется ключ / Zl. Но это просто дикое предположение, и в любом случае я не знаю, как это проверить и что делать дальше. Есть какие-нибудь подсказки?
Фу, понял наконец! Каким-то образом дополнительное пространство было добавлено к каждому пути в Options / Directories, и это помешало VC ++ найти некоторые файлы include или lib (и это происходило в разных системах, XP и Seven, возможно, добавление пробела во время копирования / вставки пути к каталогу является типичным вещь). Интересно, что VC ++ несовместим с этим, и изменение режимов сборки, вероятно, активирует разные пути кода в компиляторе — некоторые пути выполняют обрезку имен каталогов, а другие — нет.
Других решений пока нет …