Programowe tworzenie procesu - wieczny błąd #2

Programowe tworzenie procesu - wieczny błąd #2
JU
  • Rejestracja:ponad 4 lata
  • Ostatnio:ponad rok
  • Postów:8
0

Witam
Chciałem programowo stworzyć proces - jak wydało mi się to dość trywialne, rzuciłem okiem do dokumentacji i... nie wiem dlaczego to nie działa. Przejrzałem już chyba wszystkie wątki w internecie. Jakąkolwiek ścieżkę postaram się podać, to kończę z błędem nr. 2, czyli nie udało się znaleźć exe'ka.
Program pod MSVC 2019.

Kopiuj
#include <stdio.h>
#include <string>
#include <windows.h>

int main(){
    PROCESS_INFORMATION process_info;
    STARTUPINFO startup_info = {sizeof(STARTUPINFO)};
    
    std::string str = "C:\\Windows\\System32\\notepad.exe";

    BOOL result = CreateProcess(
        (LPCTSTR)str.c_str(),
        NULL, NULL, NULL, FALSE, 0, NULL, NULL,
        &startup_info, &process_info);
    
    if (!result) {
        fprintf(stderr, "CreateProcess failed %u\n", GetLastError());
        return 1;
    }

    CloseHandle(process_info.hThread);

    printf("New process started(pid: %u)",
        static_cast<unsigned int>(process_info.dwProcessId));

    WaitForSingleObject(process_info.hProcess, INFINITE);
    CloseHandle(process_info.hProcess);

    puts("The child process has exited\n");
    return 0;
}
edytowany 1x, ostatnio: cerrato
PerlMonk
Tytuł brzmi jak wieczne taju.
Azarien
  • Rejestracja:ponad 21 lat
  • Ostatnio:25 minut
5
Kopiuj
   BOOL result = CreateProcess(
         (LPCTSTR)str.c_str(),

A to się uda tylko jeżeli LPCTSTR jest const char*. Jednak domyślnie w MSVC2019 (i w ogóle już od bardzo dawna) to jest const wchar_t*, więc źle rzutujesz stringa i przekombinowujesz.

Kopiuj
    const wchar_t *str = L"C:\\Windows\\System32\\notepad.exe";

    BOOL result = CreateProcess(
        str,

albo jeśli już koniecznie musisz…

Kopiuj
    std::wstring str = L"C:\\Windows\\System32\\notepad.exe";

    BOOL result = CreateProcess(
        str.c_str(),

Poza tym zamiast hardkodowanej ścieżki powinno się użyć GetSystemDirectory albo SHGetFolderPathA (z parametrem CSIDL_SYSTEM) albo SHGetKnownFolderPath (z parametrem FOLDERID_System).

edytowany 1x, ostatnio: Azarien
kq
Nie lepiej TCHAR tu używać? I nie zależy to od marka UNICODE tak w ogólności?
Azarien
1) może i lepiej, ale byłoby to dużo więcej tłumaczenia jak to dokładnie działa… 2) rzeczywiście zależy, ale VS generuje projekt domyślnie z włączonym UNICODE. to się może w przyszłości zmienić, bo nowe buildy Windows 10 obsługują UTF-8 w ramach typu char, czyli przy wyłączonym UNICODE.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.