Если вы посмотрите на определение CreateProcess
:
BOOL WINAPI CreateProcess(
__in_opt LPCTSTR lpApplicationName,
__inout_opt LPTSTR lpCommandLine,
__in_opt LPSECURITY_ATTRIBUTES lpProcessAttributes,
__in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in BOOL bInheritHandles,
__in DWORD dwCreationFlags,
__in_opt LPVOID lpEnvironment,
__in_opt LPCTSTR lpCurrentDirectory,
__in LPSTARTUPINFO lpStartupInfo,
__out LPPROCESS_INFORMATION lpProcessInformation
);
Вы устанавливаете необязательный параметр __in_opt LPVOID lpEnvironment,
на NULL
.
Согласно указанному определению:
Указатель на блок среды для нового процесса. Если этот параметр имеет значение NULL, новый процесс использует среду вызывающего процесса.
cl.exe
получает информацию о местоположении и пути поиска в библиотеке от переменных среды - взгляните на setenv.bat
в каталоге VS. В этом случае ни ваш вызывающий процесс, ни целевой процесс не работают в среде, в которой установлены эти переменные.
У вас есть выбор - вы можете сами создать переменные среды в соответствии с MSDN:
Блок окружения состоит из блока с нулевым символом в конце
строки с нулевым символом в конце. Каждая строка имеет следующий вид:
name=value\0
Поскольку знак равенства используется в качестве разделителя, его нельзя использовать в
имя переменной среды.
Или вы можете потребовать, чтобы ваша программа запускалась из командной строки VS tools. Хорошей проверкой является то, что на самом деле проблема заключается в том, чтобы запустить вашу программу из этого приглашения, а не из Visual Studio, чтобы посмотреть, решит ли это проблему.
Причина, по которой не используется #include
, приводит к ошибке компоновщика из-за того факта, что если нет включений, cl.exe
не будет их искать, а затем ищет библиотеки времени выполнения C / C ++.
В качестве дополнительного примечания - я считаю, что стандартом в C ++ является #include <iostream>
, т.е. без .h
.