打开Windows控制台的标准输入/标准输出/标准输入/输出为win32和win64在C
首先,我不是一个Windows程序员(甚至不是Windows用户),我使用Linux上的交叉编译器也构建Win32和Win64。在挖网之后(甚至在这里问一个问题),我设法将代码片段放在一起,可以打开一个Windows控制台,并将它用于stdin/stdout/stderr。它适用于Win32,但该程序在Win64上崩溃。我猜这个问题是不同的长整型数据类型的大小,gcc甚至会对此提出警告。但是,由于我不知道一些Windows API类型的确切用途和大小,所以我无法弄清楚我应该改变什么。当然,最好的将是一些win32/win64独立解决方案。我也尝试在lStdHandle中使用“HANDLE”类型,但它甚至不能编译。任何人都可以帮忙吗?打开Windows控制台的标准输入/标准输出/标准输入/输出为win32和win64在C
int hConHandle;
long lStdHandle;
//HANDLE lStdHandle;
CONSOLE_SCREEN_BUFFER_INFO coninfo;
FILE *fp;
FreeConsole(); // be sure to release possible already allocated console
if (!AllocConsole()) {
ERROR_WINDOW("Cannot allocate windows console!");
return;
}
SetConsoleTitle("My Nice Console");
// set the screen buffer to be big enough to let us scroll text
GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &coninfo);
coninfo.dwSize.Y = 1024;
//coninfo.dwSize.X = 100;
SetConsoleScreenBufferSize(GetStdHandle(STD_OUTPUT_HANDLE), coninfo.dwSize);
// redirect unbuffered STDOUT to the console
lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "w");
*stdout = *fp;
setvbuf(stdout, NULL, _IONBF, 0);
// redirect unbuffered STDIN to the console
lStdHandle = (long)GetStdHandle(STD_INPUT_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "r");
*stdin = *fp;
setvbuf(stdin, NULL, _IONBF, 0);
// redirect unbuffered STDERR to the console
lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
fp = _fdopen(hConHandle, "w");
*stderr = *fp;
setvbuf(stderr, NULL, _IONBF, 0);
// Set Con Attributes
//SetConsoleTextAttribute(GetStdHandle(STD_ERROR_HANDLE), FOREGROUND_RED | FOREGROUND_INTENSITY);
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), FOREGROUND_GREEN | FOREGROUND_INTENSITY);
SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT);
SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE), ENABLE_ECHO_INPUT | ENABLE_LINE_INPUT);
它是一个句柄,所以你应该使用HANDLE
类型。投到INT_PTR
(或者SIZE_T
如果你的SDK真的过时了)当你拨打_open_osfhandle
时,使用long
可以截断值!
通常情况是这样。一个'HANDLE'可以是一个指针(例如'HMODULE'是模块的基地址),或者是一个特殊的值,比如'GetCurrentProcess'返回的'INVALID_HANDLE_VALUE'或'(HANDLE)-1'。在这些情况下,截断将会很糟糕。但是常规的内核句柄和窗口句柄保证适合32位“长”。同样,对于传递给'_open_osfhandle'的句柄,使用'intptr_t'而不是Windows typedef更加通俗易懂。 – eryksun
@eryksun一个控制台句柄并不总是一个正常的内核句柄,在某些情况下它是一个伪句柄,你不能假设任何有关这些位的东西。 HWND适用于32位,因为32位应用程序需要能够在64位应用程序中对HWND进行操作,但对于HANDLE来说,情况并非如此。 – Anders
Windows 8之前的版本中的控制台句柄实际上是由控制台本身管理的伪句柄,但实际上我们知道在这种情况下它们不是问题,无论我们可以合法*假设它们,因为控制台( Windows 7中的conhost.exe或真正旧版本的csrss.exe)以基本集3,7,11开始,并在复制句柄并为新屏幕缓冲区创建句柄时从那里开始递增。 – eryksun
我不确切地知道问题出在哪里。我没有设置在Linux上使用MinGW。如果您不构建控制台应用程序,它可能与无效的文件描述符有关。在这种情况下,CRT初始化文件描述符以将映射处理为无效句柄值,并且标准流将被初始化为-1 fileno
。但是我在代码中看不到这个问题。
但是,您的*stdin = *fp
黑客不是可移植的C.它适用于旧版本的MSVC,也可能与msvcrt.dll(MinGW由于缺乏更好的选择而有点可疑地使用)。但是,它不适用于新的通用CRT。在新的CRT一个FILE
定义如下:
typedef struct _iobuf
{
void* _Placeholder;
} FILE;
所以分配给*stdin
只是覆盖此_Placeholder
指针。内部结构实际上是如下:
struct __crt_stdio_stream_data
{
union
{
FILE _public_file;
char* _ptr;
};
char* _base;
int _cnt;
long _flags;
long _file;
int _charbuf;
int _bufsiz;
char* _tmpfname;
CRITICAL_SECTION _lock;
};
因此,所有你真的是覆盖其缓冲区_ptr
。
可移植重新打开标准流的方法是通过freopen
。因此,我所做的工作,但可能是别人有更好的解决方案,是freopen
NUL
设备,如果它是非控制台应用程序,它将流重置为有效的文件描述符。然后使用_dup2
来重定向底层文件描述符。例如:
#include <io.h>
#include <stdio.h>
#include <fcntl.h>
#include <Windows.h>
int wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPWSTR lpCmdLine, int nCmdShow)
//int wmain(int argc, wchar_t **argv)
{
int fdStd;
HANDLE hStd;
CONSOLE_SCREEN_BUFFER_INFO coninfo;
printf("Goodbye, World!\n");
/* ensure references to current console are flushed and closed
* before freeing the console. To get things set up in case we're
* not a console application, first re-open the std streams to
* NUL with no buffering, and close invalid file descriptors
* 0, 1, and 2. The std streams will be redirected to the console
* once it's created. */
if (_get_osfhandle(0) < 0)
_close(0);
freopen("//./NUL", "r", stdin);
setvbuf(stdin, NULL, _IONBF, 0);
if (_get_osfhandle(1) < 0)
_close(1);
freopen("//./NUL", "w", stdout);
setvbuf(stdout, NULL, _IONBF, 0);
if (_get_osfhandle(2) < 0)
_close(2);
freopen("//./NUL", "w", stderr);
setvbuf(stderr, NULL, _IONBF, 0);
FreeConsole();
if (!AllocConsole()) {
//ERROR_WINDOW("Cannot allocate windows console!");
return 1;
}
SetConsoleTitle("My Nice Console");
// set the screen buffer to be big enough to let us scroll text
GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &coninfo);
coninfo.dwSize.Y = 1024;
//coninfo.dwSize.X = 100;
SetConsoleScreenBufferSize(GetStdHandle(STD_OUTPUT_HANDLE), coninfo.dwSize);
// redirect unbuffered STDIN to the console
hStd = GetStdHandle(STD_INPUT_HANDLE);
fdStd = _open_osfhandle((intptr_t)hStd, _O_TEXT);
_dup2(fdStd, fileno(stdin));
SetStdHandle(STD_INPUT_HANDLE, (HANDLE)_get_osfhandle(fileno(stdin)));
_close(fdStd);
// redirect unbuffered STDOUT to the console
hStd = GetStdHandle(STD_OUTPUT_HANDLE);
fdStd = _open_osfhandle((intptr_t)hStd, _O_TEXT);
_dup2(fdStd, fileno(stdout));
SetStdHandle(STD_OUTPUT_HANDLE, (HANDLE)_get_osfhandle(fileno(stdout)));
_close(fdStd);
// redirect unbuffered STDERR to the console
hStd = GetStdHandle(STD_ERROR_HANDLE);
fdStd = _open_osfhandle((intptr_t)hStd, _O_TEXT);
_dup2(fdStd, fileno(stderr));
SetStdHandle(STD_ERROR_HANDLE, (HANDLE)_get_osfhandle(fileno(stderr)));
_close(fdStd);
// Set Con Attributes
SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE),
FOREGROUND_GREEN | FOREGROUND_INTENSITY);
SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE),
ENABLE_PROCESSED_OUTPUT | ENABLE_WRAP_AT_EOL_OUTPUT);
SetConsoleMode(GetStdHandle(STD_INPUT_HANDLE),
ENABLE_ECHO_INPUT | ENABLE_LINE_INPUT);
printf("Hello, World!\n");
Sleep(10000);
return 0;
}
非常感谢!看起来这个问题是通过使用HANDLE类型并将其转换为INT_PTR来解决的。它帮助解决了我现有解决方案的问题。不过,请不要误解我,也许你的解决方案会比我提出的解决方案更好(实际上不是我的工作,但是我可以从网络中猜测和组合起来......),但我现在很高兴至少有些行只修改它的效果不错:) –
@LGBGáborLénárt,当您使用VS 2015+构建新的CRT时,您的代码不会工作,您应该修复它以便于移植,而不是依赖于'FILE'的内部实现细节指针,它们在C中是不透明的。即使你没有直接访问这些字段,假设你可以执行'* stdin = * fp'就是每一个错误。 – eryksun
至于'HANDLE'问题,解决方案对我来说没有意义。在这种情况下,所有的手柄都适合“长”。我不会像你这样写,但我认为它应该起作用。我会用MSVC来尝试它,并试图找出它可能出错的地方。如果这是我自己的问题,我不会满意,直到我能够在调试器中准确诊断出错的地方。 – eryksun
你有调试过吗?它在哪里崩溃? – Peanut
它运行我在Visual Studio 2017中编译。您还应该检查函数的返回值。 – Peanut
其实我无法调试,因为我甚至不能尝试,我没有窗户,只是要求有人尝试。它是在Linux上用Mingw交叉编译器针对Windows编译的。 32位EXE似乎是好的,只有64位是问题。当然,它不是很好,我有问题,我不能调试太多,但我的项目大部分是平台无关的(win32/win64/OSX/Linux /等),只是这样的小事情是有问题的。 –