Microsoft MVP성태의 닷넷 이야기
C/C++: 173. Windows / C++ - AllocConsole로 할당한 콘솔과 CRT 함수 연동 [링크 복사], [링크+제목 복사],
조회: 7436
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 3개 있습니다.)
.NET Framework: 851. WinForm/WPF에서 Console 창을 띄워 출력하는 방법
; https://www.sysnet.pe.kr/2/0/12000

.NET Framework: 1031. WinForm/WPF에서 Console 창을 띄워 출력하는 방법 (2) - Output 디버깅 출력을 AllocConsole로 우회
; https://www.sysnet.pe.kr/2/0/12581

C/C++: 173. Windows / C++ - AllocConsole로 할당한 콘솔과 CRT 함수 연동
; https://www.sysnet.pe.kr/2/0/13729




Windows / C++ - AllocConsole로 할당한 콘솔과 CRT 함수 연동

예를 하나 들어 볼까요? 간단하게 Visual C++ Console Application 프로젝트를 하나 만들고 아래와 같이 코딩한 후,

// Console Application "Console (/SUBSYSTEM:CONSOLE)"

#include <iostream>

int main()
{
    std::cout << "Hello World!\n";
    getchar();
}

실행하면 콘솔 창에 std::cout 출력과 getchar() 입력 함수가 잘 연동이 됩니다. 콘솔 프로그램(Windows CUI Program)은 윈도우 운영체제의 콘솔 창 서비스를 자동으로 지원받으면서 Visual C++의 초기 CRT 함수들이 그것과 연동하는 절차를 거치기 때문입니다.

반면, 위의 프로젝트를 Windows Application으로 만들거나, 아니면 간단하게 "Linker" / "System"의 "Subsystem"을 "Console (/SUBSYSTEM:CONSOLE)" 대신 "Windows (/SUBSYSTEM:WINDOWS)"로 바꾼 후 WinMain으로 코드를 변경하면,

// Windows GUI Application "Windows (/SUBSYSTEM:WINDOWS)"

#include <iostream>

int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
    std::cout << "Hello World!: " << result << std::endl;
    getchar();
    return 0;
}

이제 std::cout 출력은 어디에서도 볼 수 없고 getchar() 호출로 인한 블록킹도 발생하지 않습니다. 이런 경우 원한다면 AllocConsole을 이용해 별도의 콘솔 창을 띄우는 것이 가능한데요,

#include <iostream>
#include <Windows.h>

int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
    BOOL result = AllocConsole();
    std::cout << "Hello World!: " << result << std::endl;
    getchar();
    return 0;
}

그래도 여전히 std::cout와 getchar는 연동하지 않습니다. 왜냐하면, 표준 I/O 및 에러 출력을 초기화하는 CRT 함수는 WinMain의 시작 전 WinMainCRTStartup 단계에서 이미 끝나기 때문에, AllocConsole을 호출한다고 해서 그 초기화 작업이 다시 호출되지는 않기 때문입니다. 사실, AllocConsole은 Win32 API로써 운영체제에서 제공하는 시스템 함수에 속하므로 엄밀히 CRT 작업과는 독립적인 기능입니다. 결국, std::cout, getchar()는 새롭게 뜬 Console과 연동이 안 되는 것입니다.

물론, 수동으로 연결하는 것은 가능합니다. 가령, getchar() 함수의 정의를 보면,

// C:\Program Files (x86)\Windows Kits\10\Source\10.0.22621.0\ucrt\stdio

extern "C" int __cdecl getchar()
{
    return _fgetchar();
}

extern "C" int __cdecl _fgetchar()
{
    return fgetc(stdin);
}

extern "C" int __cdecl fgetc(FILE* const public_stream) // public_stream
{
    ...[생략]...
}

결국 특정 FILE 스트림으로부터 fgetc 입력을 받는 것이므로 AllocConsole로 열어 놓은 표준 I/O를 다음과 같이 직접 지정해 출력할 수 있습니다.

#include <iostream>
#include <Windows.h>
#include <stdio.h>
#include <io.h>
#include <fcntl.h>

// Windows GUI Application 프로젝트 유형
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
    BOOL result = AllocConsole();

    {
        HANDLE hStdIn = GetStdHandle(STD_INPUT_HANDLE);
        HANDLE hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);

        int fdIn = _open_osfhandle((long)hStdIn, _O_TEXT); // fdIn == 3
        int fdOut = _open_osfhandle((long)hStdOut, _O_TEXT); // fdOut == 4

        FILE* fpIn = _fdopen(fdIn, "rt");
        FILE* fpOut = _fdopen(fdOut, "wt");

        fprintf_s(fpOut, "Hello World: %d\n", result);
        fflush(fpOut);

        fgetc(fpIn);

        fclose(fpIn);
        fclose(fpOut);
    }
}




지난 글에서, *NIX의 open은, 사용하지 않는 file descriptor로부터 가장 낮은 번호를 할당한다고 했습니다. 이런 특징 때문에, *NIX에서는 0번을 닫고 새로운 파일을 열면 그것이 0번으로 할당돼, 표준 입력을 새롭게 지정하는 것이 가능합니다.

윈도우는 어떨까요? 위의 코드와 같은 경우, 엄밀히 0, 1, 2번이 사용 중이 아니므로 새롭게 파일을 열면 0번부터 시작해야 합니다. 하지만, _open_osfhandle을 호출한 결과는 (0번이 아닌) 3번부터 file descriptor를 받고 있습니다. 다시 말해, 윈도우는 가용한 가장 낮은 번호의 기준이 3번이라는 차이점이 있습니다.

그렇다면, 윈도우는 표준 I/O/Error를 새롭게 지정할 방법이 없는 것일까요? 이에 대해 검색해 보면,

AllocConsole() not displaying cout
; https://stackoverflow.com/questions/15543571/allocconsole-not-displaying-cout

답변에 따라 다음과 같이 freopen_s 함수를 이용할 수 있습니다.

BOOL result = AllocConsole();

FILE* fpIn = nullptr;
FILE* fpOut = nullptr;
freopen_s(&fpIn, "CONIN$", "r", stdin);
freopen_s(&fpOut, "CONOUT$", "w", stdout);

_ASSERT(fpIn == stdin);
_ASSERT(fpOut == stdout);

std::cout << "Hello World!: " << result << std::endl; // AllocConsole로 할당한 콘솔과 연동
getchar(); // AllocConsole로 할당한 콘솔과 연동

fclose(fpIn);
fclose(fpOut);

"CONIN$"은 CreateFile 함수에서 현재 응용 프로그램과 연결된 콘솔의 입력 핸들을 반환하는 특별한 이름입니다. (마찬가지로 "CONOUT$", "CONERR$"도 각각 출력, 에러에 해당합니다.) freopen_s 함수는 (2번째 인자인) 이름을 CreateFile로 열어 반환받은 핸들을 4번째 인자인 FILE*에 연결하는 역할을 합니다.
재미있는 것은, stdin/stdout의 정보를 CreateFile 핸들과 연결하긴 하지만, 내부적으로는 어쨌든 파일 open 작업을 거치기 때문에 새롭게 file descriptor를 할당받습니다.

std::cout << "stdin file descriptor: " << _fileno(stdin) << std::endl;
std::cout << "stdout file descriptor: " << _fileno(stdout) << std::endl;

/* 출력 결과:
stdin file descriptor: 3
stdout file descriptor: 4
*/

참고로, stdin, stdout, stderr은 (AllocConsole도 호출하지 않았고) 콘솔 응용 프로그램이 아니라면 -2 값을 가집니다.

// Windows GUI Application 프로젝트 유형

int old_stdin_fd = _fileno(stdin); // == -2 (_NO_CONSOLE_FILENO)
int old_stdout_fd = _fileno(stdout); // == -2 (_NO_CONSOLE_FILENO)
int old_stderr_fd = _fileno(stderr); // == -2 (_NO_CONSOLE_FILENO)

// C:\Program Files (x86)\Windows Kits\10\Source\10.0.10240.0\ucrt\inc\corecrt_internal_lowio.h

#define _NO_CONSOLE_FILENO ((intptr_t)-2)




만약 AllocConsole 호출 없이 freopen_s를 거치면 이후 getchar 함수 호출은 블록킹 없이 지나가는 수준으로 그치지만 std::cout의 경우에는 이런 assert 창이 뜹니다.

Program: ..._by_api\ConsoleApplication1\x64\Debug\ConsoleApplication1.exe
File: minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp
Line: 17

Expression: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 9/10/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2024-10-28 11시18분
VT sequences to "CONOUT$" vs. STD_OUTPUT_HANDLE #14215
; https://github.com/microsoft/terminal/discussions/14215

정리하면, "CONOUT$"은 언제나 콘솔 화면을 지칭하는 반면 STD_OUTPUT_HANDLE은 redirect 상태인 경우 그 대상을 가리키는 핸들값입니다.
정성태

... 76  77  78  79  80  81  82  [83]  84  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
11861정성태4/6/201919618디버깅 기술: 126. windbg - .NET x86 CLR2/CLR4 EXE의 EntryPoint
11860정성태4/5/201923470오류 유형: 527. Visual C++ 컴파일 오류 - error C2220: warning treated as error - no 'object' file generated
11859정성태4/4/201920699디버깅 기술: 125. WinDbg로 EXE의 EntryPoint에서 BP 거는 방법
11858정성태3/27/201921608VC++: 129. EXE를 LoadLibrary로 로딩해 PE 헤더에 있는 EntryPoint를 직접 호출하는 방법파일 다운로드1
11857정성태3/26/201919514VC++: 128. strncpy 사용 시 주의 사항(Linux / Windows)
11856정성태3/25/201919772VS.NET IDE: 134. 마이크로소프트의 CoreCLR 프로파일러 리눅스 예제를 Visual Studio F5 원격 디버깅하는 방법 [1]파일 다운로드1
11855정성태3/25/201921923개발 환경 구성: 436. 페이스북 HTTPS 인증을 localhost에서 테스트하는 방법
11854정성태3/25/201917576VS.NET IDE: 133. IIS Express로 호스팅하는 사이트를 https로 접근하는 방법
11853정성태3/24/201920385개발 환경 구성: 435. 존재하지 않는 IP 주소에 대한 Dns.GetHostByAddress/gethostbyaddr/GetNameInfoW 실행이 느리다면? - 두 번째 이야기 [1]
11852정성태3/20/201919605개발 환경 구성: 434. 존재하지 않는 IP 주소에 대한 Dns.GetHostByAddress/gethostbyaddr/GetNameInfoW 실행이 느리다면?파일 다운로드1
11851정성태3/19/201923359Linux: 8. C# - 리눅스 환경에서 DllImport 대신 라이브러리 동적 로드 처리 [2]
11850정성태3/18/201922387.NET Framework: 813. C# async 메서드에서 out/ref/in 유형의 인자를 사용하지 못하는 이유
11849정성태3/18/201921773.NET Framework: 812. pscp.exe 기능을 C#으로 제어하는 방법파일 다운로드1
11848정성태3/17/201918497스크립트: 14. 윈도우 CMD - 파일이 변경된 경우 파일명을 변경해 복사하고 싶다면?
11847정성태3/17/201922967Linux: 7. 리눅스 C/C++ - 공유 라이브러리 동적 로딩 후 export 함수 사용 방법파일 다운로드1
11846정성태3/15/201921611Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제
11845정성태3/15/201921763Linux: 5. Linux 응용 프로그램의 (C++) so 의존성 줄이기(ReleaseMinDependency) [3]
11844정성태3/14/201923082개발 환경 구성: 434. Visual Studio 2019 - 리눅스 프로젝트를 이용한 공유/실행(so/out) 프로그램 개발 환경 설정 [1]파일 다운로드1
11843정성태3/14/201918036기타: 75. MSDN 웹 사이트를 기본으로 영문 페이지로 열고 싶다면?
11842정성태3/13/201916383개발 환경 구성: 433. 마이크로소프트의 CoreCLR 프로파일러 예제를 Visual Studio CMake로 빌드하는 방법 [1]파일 다운로드1
11841정성태3/13/201916696VS.NET IDE: 132. Visual Studio 2019 - CMake의 컴파일러를 기본 g++에서 clang++로 변경
11840정성태3/13/201918319오류 유형: 526. 윈도우 10 Ubuntu App 환경에서는 USB 외장 하드 접근 불가
11839정성태3/12/201922237디버깅 기술: 124. .NET Core 웹 앱을 호스팅하는 Azure App Services의 프로세스 메모리 덤프 및 windbg 분석 개요 [3]
11838정성태3/7/201925867.NET Framework: 811. (번역글) .NET Internals Cookbook Part 1 - Exceptions, filters and corrupted processes [1]파일 다운로드1
11837정성태3/6/201939807기타: 74. 도서: 시작하세요! C# 7.3 프로그래밍 [10]
11836정성태3/5/201923377오류 유형: 525. Visual Studio 2019 Preview 4/RC - C# 8.0 Missing compiler required member 'System.Range..ctor' [1]
... 76  77  78  79  80  81  82  [83]  84  85  86  87  88  89  90  ...