Как подключить ассемблер в visual studio 2019

Создание проекта на языке ассемблера в Microsoft Visual Studio Express 2010

Создание проекта консольного или оконного Windows-приложения не отличается от рассмотренного для языков программирования Си и C++.

После того, как в Visual Studio появилось окно проекта (в левой части появившегося окна отображается Обозреватель решений), для добавления нового файла программы в проект выбираем по правой кнопке мыши на папке Файлы исходного кода меню Добавить->Создать элемент.
В появившемся окне выбираем Файл C++ (.cpp), задаем имя файла и вручную добавляем к нему расширение asm. Нажимаем кнопку Добавить.

В появившемся окне набираем текст программы. В качестве примера можно использовать следующий текст:

.686P
.MODEL FLAT, STDCALL
.STACK 4096
.DATA
MB_OK EQU 0
STR1 DB «Моя первая программа»,0
STR2 DB «Привет всем!»,0
HW DD ?
EXTERN MessageBoxA@16:NEAR
.CODE
START:
PUSH MB_OK
PUSH OFFSET STR1
PUSH OFFSET STR2
PUSH HW
CALL MessageBoxA@16
RET
END START

Далее необходимо сообщить среде разработки, что данный файл является программой на языке ассемблера, и для корректного включения его в проект требуется использовать Microsoft Macro Assembler. Для этого выбираем для проекта (по правой клавише мыши) опцию Настройки построения.

В появившемся окне ставим галочку для masm (Microsoft Macro Assembler) и нажимаем OK.
Теперь нужно проверить, что для файла на языке ассемблера установился соответствующий инструмент сборки. По правой кнопке мыши для файла с расширением .asm выбираем опцию Свойства.

В появившемся окне для выбранного файла отмечаем инструмент сборки Microsoft Macro Assembler.

Для построения проекта выбираем меню Отладка->Построить решение.

В случае успешного построения в нижней части окна отображается Построение: успешно 1.

Для запуска приложения выбираем меню Отладка->Начать отладку.

Результат выполнения программы:

Изменить тип приложения с консольного на оконное

Чтобы убрать консоль (поменять тип приложения с консольного на оконное, или наоборот) необходимо обратиться к меню Свойства проекта, вызванного по правой кнопке мыши.
В появившемся окне выбрать раздел Компоновщик->Система, и в разделе Подсистема поменять тип с Консоль на Windows (или наоборот).

Повторная сборка и запуск программы на выполнения выдадут следующий результат (консоли нет):

Подсветка синтаксиса языка ассемблера

Для того, чтобы включить подсветку синтаксиса языка ассемблера в Microsoft Visual Studio Express 2010 необходимо загрузить файл usertype и распаковать его в папку

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

Для подключения подсветки синтаксиса выбираем меню Сервис->Параметры

В появившемся окне выбрать Текстовый редактор->Расширение файла и вручную добавляем расширение asm. Нажимаем кнопку Добавить, затем — OK.

После перезапуска Microsoft Visual Studio Express 2010 подсветка синтаксиса языка ассемблера будет активна.

Комментариев к записи: 23

Ошибка средств компоновщика LNK2019

Скомпилированный код функции делает ссылку или вызов символа, но компоновщик не может найти определение символа в любом из библиотек или файлов объектов.

За этим сообщением об ошибке следует неустранимая ошибка LNK1120. Чтобы устранить ошибку LNK1120, сначала необходимо исправить все LNK2001 и LNK2019 ошибки.

Возможные причины

Существует множество способов получить эту ошибку. Все из них включают ссылку на функцию или переменную, для которых компоновщик не мог разрешить или найти определение. Компилятор может определить, когда символ не объявлен, но не может определить, когда символ не определен. Это связано с тем, что определение может находиться в другом исходном файле или библиотеке. Если символ ссылается на символ, но никогда не определен, компоновщик создает неразрешенную externошибку символа al.

Ниже приведены некоторые распространенные проблемы, вызывающие ошибку LNK2019.

Исходный файл, содержащий определение символа, не компилируется

В Visual Studio убедитесь, что исходный файл, определяющий символ, компилируется как часть проекта. Проверьте выходной каталог промежуточной сборки для соответствующего OBJ-файла. Если исходный файл не компилируется, щелкните правой кнопкой мыши файл в Обозреватель решений, а затем выберите свойства, чтобы проверка свойства файла. На странице «Общие свойства>конфигурации» должен отображаться тип элемента компилятора C/C++. В командной строке убедитесь, что исходный файл, содержащий определение, компилируется.

Файл объекта или библиотека, содержащая определение символа, не связана

В Visual Studio убедитесь, что файл объекта или библиотека, содержащая определение символов, связан в рамках проекта. В командной строке убедитесь, что список файлов для ссылки включает файл объекта или библиотеку.

Объявление символа не совпадает с определением символа.

Убедитесь, что в объявлении и определении используется правильная орфография и заглавная буква, а также везде, где используется или вызывается символ.

Функция используется, но тип или число параметров не совпадают с определением функции.

Объявление функции должно соответствовать определению. Убедитесь, что вызов функции соответствует объявлению и что объявление соответствует определению. Код, вызывающий шаблоны функций, также должен иметь соответствующие объявления шаблона функции, которые включают те же параметры шаблона, что и определение. Пример несоответствия объявления шаблона см. в примере LNK2019e.cpp в разделе «Примеры».

Функция или переменная объявлена, но не определена

LNK2019 может возникать, если объявление существует в файле заголовка, но не реализуется соответствующее определение. Для функций-членов или static элементов данных реализация должна включать селектор класса область. Пример см. в разделе Missing Function Body or Variable.

Соглашение о вызове отличается от объявления функции и определения функции.

Некоторые соглашения о вызовах ( __cdecl , , __stdcall __fastcall и __vectorcall ) кодируются как часть декорированного имени. Убедитесь, что соглашение о вызове совпадает.

Символ определяется в файле C, но объявлен без использования extern «C» в файле C++

Файл, скомпилированный как C, создает декорированные имена символов, отличающихся от украшенных имен для тех же символов, объявленных в файле C++, если только вы не используете extern «C» модификатор. Убедитесь, что объявление соответствует компоновке компиляции для каждого символа. Аналогично, если символ определяется в файле C++, который будет использоваться программой C, в определении следует использовать extern «C» .

Символ определяется как static и позже ссылается за пределами файла.

В C++, в отличие от C, глобальные constмуравьи имеют static связь. Чтобы обойти это ограничение, можно включить const инициализации в файл заголовка и включить этот заголовок в файлы CPP или сделать переменнуюconst неантой и использовать ссылку constна муравей для доступа к нему.

Элемент static класса не определен

Член static класса должен иметь уникальное определение или будет нарушать правило одноопределенного определения. Член static класса, который не может быть определен встроенным, должен быть определен в одном исходном файле с помощью полного имени. Если он не определен вообще, компоновщик создает LNK2019.

Зависимость сборки определяется только как зависимость проекта в решении

В более ранних версиях Visual Studio этот уровень зависимостей был достаточно. Однако начиная с Visual Studio 2010 Visual Studio требует ссылки на проект в проект. Если у вашего проекта нет ссылки на проект в проект, может появиться эта ошибка компоновщика. Чтобы устранить ошибку, добавьте ссылку одного проекта на другой.

Точка входа не определена

Код приложения должен определить соответствующую точку входа: main или wmain для консольных приложений, а WinMain также wWinMain для приложений Windows. Дополнительные сведения см. в разделе main «Аргументы функции» и «Командная строка» или WinMain «Функция». Чтобы использовать пользовательскую точку входа, укажите /ENTRY параметр компоновщика (символ точки входа).

Создание консольного приложения с помощью параметров для приложения Windows

Если сообщение об ошибке похоже на неразрешенный символ al, на который ссылается функцияfunction_name, ссылка используется /SUBSYSTEM:CONSOLE вместо /SUBSYSTEM:WINDOWS .WinMainextern Дополнительные сведения об этом параметре и инструкции по настройке этого свойства в Visual Studio см. в разделе /SUBSYSTEM (Указание подсистемы).

Вы пытаетесь связать 64-разрядные библиотеки с 32-разрядным кодом или 32-разрядными библиотеками с 64-разрядным кодом.

Библиотеки и файлы объектов, связанные с кодом, должны быть компилированы для той же архитектуры, что и код. Убедитесь, что библиотеки, на которые ссылается проект, компилируются для той же архитектуры, что и проект. Убедитесь, /LIBPATH что свойство или дополнительное свойство каталогов библиотек указывает на библиотеки , созданные для правильной архитектуры.

Вы используете различные параметры компилятора для подстраивание функций в разных исходных файлах

Использование встроенных функций, определенных в CPP-файлах, и смешение в различных исходных файлах параметров компилятора для встраивания функций может привести к возникновению ошибки LNK2019. Для получения дополнительной информации см. Function Inlining Problems.

Вы используете автоматические переменные за пределами их область

Автоматические переменные (области видимости функции) могут использоваться только в области видимости данной функции. Эти переменные не могут объявляться extern и использоваться в других исходных файлах. Пример см. в разделе Automatic (Function Scope) Variables.

Вы вызываете встроенные функции или передаете типы аргументов встроенным функциям, которые не поддерживаются в целевой архитектуре.

Например, если вы используете встроенную AVX2 функцию, но не указывайте /ARCH:AVX2 параметр компилятора, компилятор предполагает, что встроенная функция является externаль-функцией. Вместо создания встроенной инструкции компилятор создает вызов символа external с тем же именем, что и встроенная инструкция. Когда компоновщик пытается найти определение этой отсутствующей функции, он создает ошибку LNK2019. Убедитесь, что используются только встроенные и типы, поддерживаемые целевой архитектурой.

Вы смешиваете код, использующий машинный wchar_t код с кодом, который не используется

Работа по соответствию языка C++ в Visual Studio 2005 сделала wchar_t собственный тип по умолчанию. Если не все файлы были скомпилированы с помощью одинаковых /Zc:wchar_t параметров, ссылки на тип могут не разрешаться для совместимых типов. Убедитесь, что wchar_t типы во всех библиотеках и файлах объектов совместимы. Обновление из wchar_t typedef или использование согласованных /Zc:wchar_t параметров при компиляции.

При связывании устаревшей библиотеки static возникают ошибки и *printf* *scanf* функции.

Библиотека static , созданная с помощью версии Visual Studio до Visual Studio 2015, может вызвать LNK2019 ошибки при связывании с UCRT. Файлы заголовков UCRT и теперь определяют множество *printf* вариантов *scanf* как inline функции. Встроенные функции реализуются меньшим набором общих функций. Отдельные экспорты встроенных функций недоступны в стандартных библиотеках UCRT, которые экспортируют только общие функции. Существует несколько способов устранения этой проблемы. Мы рекомендуем перестроить устаревшую библиотеку с текущей версией Visual Studio. Убедитесь, что код библиотеки использует стандартные заголовки для определений *printf* и *scanf* функций, вызвавших ошибки. Еще одним вариантом для устаревшей библиотеки, которую нельзя перестроить, является добавление legacy_stdio_definitions.lib в список библиотек, которые вы связываете. Этот файл библиотеки предоставляет символы для *printf* функций, *scanf* которые встраиваются в заголовки UCRT. Дополнительные сведения см. в разделе «Библиотеки» в разделе «Общие сведения о потенциальных проблемах обновления».

Проблемы со сторонними библиотеками и vcpkg

Если эта ошибка возникает при попытке настроить стороннюю библиотеку в рамках сборки, рассмотрите возможность использования vcpkg. vcpkg — это диспетчер пакетов C++, использующий существующие средства Visual Studio для установки и сборки библиотеки. vcpkg поддерживает большой и растущий список сторонних библиотек. Он задает все свойства конфигурации и зависимости, необходимые для успешной сборки в рамках проекта.

Средства диагностики

Иногда трудно определить, почему компоновщик не может найти определенное определение символов. Часто проблема заключается в том, что вы не включили код, содержащий определение в сборке. Кроме того, параметры сборки создали различные декорированные имена для externсимволов al. Существует несколько средств и параметров, которые помогут диагностировать ошибки LNK2019.

• Параметр /VERBOSE компоновщика поможет определить, какие файлы ссылается компоновщик. Этот параметр поможет проверить, включен ли в сборку файл, содержащий определение символа.
• /SYMBOLS Служебная DUMPBIN/EXPORTS программа позволяет определить, какие символы определены в файлах библиотеки dll и объектов или библиотек. Убедитесь, что экспортированные декорированные имена соответствуют декорированным именам компоновщика.
• Служебная UNDNAME программа может показать эквивалентный неоцененный externсимвол al для украшенного имени.

Примеры

Ниже приведены несколько примеров кода, вызывающего ошибки LNK2019, а также сведения об устранении ошибок.

Символ объявлен, но не определен

В этом примере переменная al объявлена extern, но не определена:

// LNK2019.cpp // Compile by using: cl /EHsc /W4 LNK2019.cpp // LNK2019 expected extern char B[100]; // B isn't available to the linker int main() < B[0] = ' '; // LNK2019 >

Ниже приведен еще один пример объявления переменной и функции, extern но не указано определение:

// LNK2019c.cpp // Compile by using: cl /EHsc LNK2019c.cpp // LNK2019 expected extern int i; extern void g(); void f() < i++; g(); >int main() <> 

Если i и g не определены в одном из файлов, включенных в сборку, компоновщик создает LNK2019. Чтобы исправить ошибки, включите файл исходного кода, который содержит определения, в процесс компиляции. Кроме того, можно передать .obj файлы или .lib файлы, содержащие определения компоновщика.

Элемент static данных объявлен, но не определен

LNK2019 также может возникать, когда static член данных объявлен, но не определен. В следующем примере показано возникновение ошибки LNK2019 и приводятся сведения по ее устранению.

// LNK2019b.cpp // Compile by using: cl /EHsc LNK2019b.cpp // LNK2019 expected struct C < static int s; >; // Uncomment the following line to fix the error. // int C::s; int main()

Параметры объявления не соответствуют определению

Код, вызывающий шаблоны функций, должен иметь соответствующие объявления шаблона функции. Объявления должны содержать те же параметры шаблона, что и определение. В следующем примере показано возникновение ошибки LNK2019 для определяемого пользователем оператора и приводятся сведения по ее устранению.

// LNK2019e.cpp // compile by using: cl /EHsc LNK2019e.cpp // LNK2019 expected #include using namespace std; template class Test < // The operatorfriend ostream& operator<<(ostream&, Test&); >; template ostream& operator<<(ostream& os, Test& tt) < return os; >int main() < Testt; cout 

Несогласованные wchar_t определения типов

В этом примере создается библиотека DLL с экспортом, который использует WCHAR , в который разрешается wchar_t .

// LNK2019g.cpp // compile with: cl /EHsc /LD LNK2019g.cpp #include "windows.h" // WCHAR resolves to wchar_t __declspec(dllexport) void func(WCHAR*) <> 

Следующий пример использует библиотеку DLL в предыдущем примере и создает LNK2019, так как типы unsigned short* и WCHAR* не совпадают.

// LNK2019h.cpp // compile by using: cl /EHsc LNK2019h LNK2019g.lib // LNK2019 expected __declspec(dllimport) void func(unsigned short*); int main()

Чтобы устранить эту ошибку, измените unsigned short или wchar_t WCHAR скомпилируйте LNK2019g.cpp с помощью /Zc:wchar_t- .

См. также

Дополнительные сведения о возможных причинах и решениях для LNK2019, LNK2001 и LNK1120 ошибок см. в вопросе Stack Overflow: What is an undefined reference/unresolved external symbol error and how do I fix it?

Visual Studio не видит заголовочный файл

Не могу понять, почему файл заголовочный подключен, но при сборке Visual Studio его не видит. переделываю библиотеку с 32 битов в 64 бита.

Отслеживать
задан 17 дек 2018 в 9:03
2,909 7 7 золотых знаков 44 44 серебряных знака 85 85 бронзовых знаков

У вас на первом скриншоте явно видно, что master_dll_defines.h лежит в каких-то ..\..\headers . В настройках проекта на втором скриншоте я у вас никакого headers не вижу. В чем смысл второго скриншота, если по нему не видно, есть ли там эти headers или нет? Почему вы не раскрыли список каталогов перед тем как делать скриншот?

17 дек 2018 в 9:39

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

Возможно, у вас VS не настроен для работы с данной папкой. Подобной вопрос уже поднимался. Проверьте директории в tools > options > directories.

Либо в свойствах проекта в параметре Additional > Include Directories необходимо указать путь ко всем папкам (Settings > Configuration Properties > C\C++ > General).

Отслеживать
ответ дан 17 дек 2018 в 9:10
46 4 4 бронзовых знака

tools > options > directories. не может быть ибо у меня открыт только одни проект . Settings > Configuration Properties > C\C++ > General обновил вопрос там как раз так и сделано

17 дек 2018 в 9:19
@timob256, попробуйте указать другую директорию
17 дек 2018 в 9:29

В треугольных скобках в #include указываются стандартные хедеры реализации (т.е. "системные" заголовки). Я никогда не слышал о таком стандартном хедере, как master_dll_defines.h . Почему у вас вдруг использованы треугольные скобки для включения этого заголовка? Это относится и к остальным заголовкам со странными названиями.

Если вы хотите, чтобы заголовочный файл искался в путях, настроенных в локальных установках вашего проекта, используйте "" , а не треугольные скобки.

Отслеживать
ответ дан 17 дек 2018 в 9:19
AnT stands with Russia AnT stands with Russia
69.1k 3 3 золотых знака 62 62 серебряных знака 139 139 бронзовых знаков
Поменял, как не работало так и не работает
17 дек 2018 в 9:28

@timob256: Так а путь прописан? У вас на скриншоте явно видно, что master_dll_defines.h лежит в ..\..\headers . В настройках я у вас никакого headers не вижу.

17 дек 2018 в 9:32

Кажется так, кроме тех случаев где это не так чуть больше чем полностью 🙂 Как раз треугольные скобки используются при поиске в путях, а обычные кавычки для поиска по обсалютному пути. Автор может добавить собственные директории в пути компилятора (проекта), и тогда это будет работоспособно.

17 дек 2018 в 9:47

@NewView Возможно, но это не повод злоупотреблять. Треугольные скобки предназначены для хедеров "известных компилятору". Для пользовательских хедеров - только кавычки.

Загрузка, установка и настройка рабочей нагрузки Linux

Проекты Linux поддерживаются в Visual Studio версии 2017 и выше. Чтобы увидеть документацию для этих версий, установите в данной статье селектор Версия Visual Studio в Visual Studio 2017 или Visual Studio 2019. Он находится в верхней части оглавления на этой странице.

Вы можете использовать интегрированную среду разработки Visual Studio в Windows для создания, редактирования и отладки проектов C++, которые выполняются в удаленной системе Linux, на виртуальной машине или в подсистеме Windows для Linux.

Вы можете работать с имеющейся базой кода, где CMake не требуется преобразовывать в проект Visual Studio. Если база кода является кроссплатформенной, в Visual Studio можно создавать решения как для Windows, так и для Linux. Например, с помощью Visual Studio можно редактировать, выполнять сборку и отлаживать свой код в Windows. Затем можно быстро перенацелить проект для Linux на сборку и отладку в среде Linux. Файлы заголовков Linux автоматически копируются на ваш локальный компьютер. Visual Studio использует их для обеспечения полной поддержки технологии IntelliSense (завершение операторов, переход к определению и т. д.).

Чтобы использовать любой из этих сценариев, требуется рабочая нагрузка Разработка для Linux на C++.

Установка Visual Studio

1. В поле поиска Windows введите "Visual Studio Installer":
2. Найдите установщик в разделе Приложения и дважды щелкните его. Когда откроется установщик, нажмите кнопку "Изменить" и перейдите на вкладку "Рабочие нагрузки". Прокрутите вниз до других наборов инструментов и выберите разработку Linux с помощью рабочей нагрузки C++.

Выбрана рабочая нагрузка разработки Linux. Выделена область сведений об установке, в которой перечислены сведения, включенные в рабочую нагрузку. В состав которых входят основные функции Visual Studio C++, среда выполнения Windows Universal C, разработка Visual C++ для Linux. Также выбран дополнительный компонент: средства Visual C++ для CMake и Linux.

Варианты создания среды Linux

Если у вас нет компьютера Linux, можно создать виртуальную машину Linux в Azure. Дополнительные сведения см. в статье Краткое руководство. Создание виртуальной машины под управлением Linux на портале Azure.

В Windows 10 и более поздних версий можно установить и настроить использование определенного дистрибутива Linux в подсистеме Windows для Linux (WSL). См. подробнее руководство по установке подсистемы Windows для Linux в Windows 10. Если не удается получить доступ к Microsoft Store, можете вручную скачать пакеты дистрибутивов WSL. WSL — это удобная консольная среда, но ее не рекомендуется использовать для графических приложений.

Для проектов Linux в Visual Studio необходимо установить следующие зависимости в удаленной системе Linux или WSL:

• Компилятор — Visual Studio 2019 и более поздних версий полностью поддерживает GCC и Clang.
• gdb — Visual Studio автоматически запускает gdb в системе Linux и использует интерфейс отладчика Visual Studio для обеспечения всех возможностей отладки в Linux.
• rsync и zip — благодаря включению rsync и zip Visual Studio может извлекать файлы заголовков из системы Linux в файловую систему Windows для использования технологией IntelliSense.
• make
• openssh-server (только удаленные системы Linux) — Visual Studio подключается к удаленным системам Linux через безопасное SSH-соединение.
• CMake (только для проектов CMake) — вы можете установить статически связанные двоичные файлы CMake для Linux.
• ninja-build (только для проектов CMake) — Ninja является генератором по умолчанию для конфигураций Linux и WSL в Visual Studio 2019 версии 16.6 или более поздней версии.

В следующих командах предполагается, что вы используете g++ вместо clang.

Для проектов Linux в Visual Studio необходимо установить следующие зависимости в удаленной системе Linux или WSL:

• gcc — Visual Studio 2017 полностью поддерживает GCC.
• gdb — Visual Studio автоматически запускает gdb в системе Linux и использует интерфейс отладчика Visual Studio для обеспечения всех возможностей отладки в Linux.
• rsync и zip — благодаря включению rsync и zip Visual Studio может извлекать файлы заголовков из системы Linux в файловую систему Windows для использования технологией IntelliSense.
• make
• openssh-server — Visual Studio подключается к удаленным системам Linux через защищенное SSH-соединение.
• CMake (только для проектов CMake) — вы можете установить статически связанные двоичные файлы CMake для Linux.

Настройка Linux: Ubuntu в WSL

Если вы используете WSL, для сборки и отладки не требуется добавлять удаленное подключение или настраивать SSH. Использование zip и rsync является обязательным для автоматической синхронизации заголовков Linux в Visual Studio и включения поддержки Intellisense. ninja-build требуется только для проектов CMake. Если необходимые приложения отсутствуют, их можно установить с помощью следующей команды:

sudo apt-get install g++ gdb make ninja-build rsync zip 

Использование Ubuntu в удаленных системах Linux

В целевой системе Linux должны быть установлены openssh-server, g++, gdb и make. ninja-build требуется только для проектов CMake. Должна быть запущена управляющая программа ssh. Использование zip и rsync необходимо для автоматической синхронизации удаленных заголовков на локальном компьютере, чтобы обеспечить поддержку Intellisense. Если этих приложений еще нет, их можно установить следующим образом.

В командной строке оболочки на компьютере Linux выполните следующую команду:

sudo apt-get install openssh-server g++ gdb make ninja-build rsync zip 

sudo service ssh start 

Использование Fedora в WSL

В Fedora используются установщик пакетов dnf. Чтобы скачать g++, gdb, make, rsync, ninja-build и zip, выполните следующую команду:

sudo dnf install gcc-g++ gdb rsync ninja-build make zip 

Использование zip и rsync является обязательным для автоматической синхронизации заголовков Linux в Visual Studio и включения поддержки Intellisense. ninja-build требуется только для проектов CMake.

Использование Fedora в удаленных системах Linux

На целевой машине под управлением Fedora используются установщик пакетов dnf. Чтобы скачать openssh-server, g++, gdb, make, ninja-build, rsync и zip, а затем перезапустить управляющую программу ssh, сделайте следующее: ninja-build требуется только для проектов CMake.

В командной строке оболочки на компьютере Linux выполните следующую команду:

sudo dnf install openssh-server gcc-g++ gdb ninja-build make rsync zip 

sudo systemctl start sshd 

Дальнейшие действия

Теперь вы можете создать или открыть проект Linux, а также настроить его для выполнения в целевой системе. Дополнительные сведения см. в разделе:

• Создание нового проекта Linux на основе MSBuild C++
• Настройка проекта Linux CMake