本文将带您了解关于Ctrl-D的新内容，同时我们还将为您解释Unix和Ctrl-Z的相关知识，另外，我们还将为您提供关于C++不能获得进程ID（Windows）、C++Windows编译程序与Linu

本文将带您了解关于Ctrl-D的新内容，同时我们还将为您解释Unix和Ctrl-Z的相关知识，另外，我们还将为您提供关于C + +不能获得进程ID（Windows）、C++ Windows 编译程序与 Linux 的不同行为、Electron npm install 常见错误（Windows）、Electron入门应用打包exe（windows）的实用信息。

• Ctrl-D（Unix）和Ctrl-Z（Windows）的不同行为（ctrl+d和ctrl+z的区别）
• C + +不能获得进程ID（Windows）
• C++ Windows 编译程序与 Linux 的不同行为
• Electron npm install 常见错误（Windows）
• Electron入门应用打包exe（windows）

Ctrl-D（Unix）和Ctrl-Z（Windows）的不同行为（ctrl+d和ctrl+z的区别）

根据标题，我试图了解Ctrl + D / Ctrl + Z在一个while循环中的确切行为（我需要使用）。 我正在testing的代码如下：

#include <stdio.h> #include <stdlib.h> int main() { char str[80]; while(printf("Insert string: ") && gets(str) != NULL) { puts(str); } return 0; }

如果我的input只是一个Ctrl + D （或在Windows上Ctrl + Z ） gets返回NULL，程序正常退出。 不清楚的情况是，当我插入像house^D^D （Unix）或house^Z^Zn （Windows）的东西。

在第一种情况下，我的解释是getchar （或gets函数内的类似内容）等待read（）以获取input，第一个Ctrl + D刷新非空的缓冲区（因此不是EOF），然后第二次读取（）被称为EOF被触发。

在第二种情况下，我注意到，第一个Ctrl + Z被插入到缓冲区中，而后面的所有内容都被忽略。 因此，我的理解是第一次读取（）调用插入的house^Z和丢弃一切返回5（读取的字符数）。 （我说5，否则我认为一个简单的Ctrl + Z应该返回1而不触发EOF）。 然后程序等待来自用户的更多input，因此再次进行read（）调用。

我想知道我的工作方式是正确还是错误，哪一部分只是执行依赖（如果有的话）。

此外，我注意到在Unix和Windows中，即使在EOF被触发后，它在下面的gets()调用中似乎重置为false，我不明白为什么发生这种情况以及代码的哪一行。

奇怪的成员函数声明的错误

创build父级pipe理的两个subprocess

多核心架构上的multithreading

如何将hex字符转换为4位二进制表示？

Directory.GetFiles不返回文件

我真的很感激任何forms的帮助。

（12/20/2016）为了避免混淆，我大量编辑了我的问题

CMake为Tesseract和OpenCV

文件夹更衣室在C＃

如何确定哪个Windows Communication Foundation Service使用给定的端口？

如何以编程方式检测PC是否具有USB3function？

不间断地执行Cpp Linux代码

CTRL-D和CTRL-Z“文件末尾”指示器分别在Unix和Windows系统上有相似的用途，但实现方式相当不同。

在Unix系统上（包括像Linux这样的Unix克隆），CTRL-D虽然被正式描述为文件结束字符，但实际上却是一个分隔符。 它几乎与用于分隔行的行尾字符（通常是回车符或CTRL-M）完全相同。 这两个字符都告诉操作系统输入行已经完成，并使程序可用。 唯一的区别是，在行结束字符处，换行（CTRL-J）字符被插入到输入缓冲区的末尾以标记行的末尾，而在文件结束字符处不插入任何内容。

这意味着当你在Unix上输入house^D^D时， read系统调用将首先返回一个长度为5的缓冲区，其中包含5个字符。 当read被再次调用以获得更多的输入时，它将返回长度为0的缓冲区，其中没有字符。 由于在正常文件上读取的零长度表明已到达文件末尾，因此gets库函数也将其解释为文件结尾并停止读取输入。 然而，由于它用5个字符填充了缓冲区，所以它不返回NULL来表明它到达了文件的结尾。 而且由于它实际上并没有真正达到文件结尾，因为终端设备实际上不是文件，所以进一步的调用将进一步调用read ，这将返回用户输入的后续字符。

在Windows上，CTRL-Z的处理方式大不相同。 最大的区别在于它没有被操作系统专门处理。 当你在Windows上输入house^Z^Z^M ，只有回车符给予特殊处理。 就像在Unix上一样，回车使得输入的行对程序可用，但是在这种情况下，回车和换行被添加到缓冲区以标记行的结尾。 所以结果是ReadFile函数返回一个9字节长的缓冲区，其中包含9个字符house^Z^Z^M^J

它实际上是程序本身，特别是处理CTRL-Z的C运行库。 在Microsoft C运行时库的情况下，当它看到ReadFile返回的缓冲区中的CTRL-Z字符时，它会将其视为文件结束标记，并忽略其后的所有内容。 使用前面段落中的例子，最后调用ReadFile来获得更多的输入，因为从控制台（或其他设备）读取时看不到CTRL-Z字符的事实，而且还没有看到结尾（忽略）。 如果你再次按回车， gets将返回与填充7字节的house^Z （添加一个0字节表示字符串的结束）的缓冲区。 默认情况下，当从普通文件读取时，如果在文件中出现CTRL-Z字符，则忽略它之后的所有内容。 这是为了向后兼容CP / M，它只支持长度为128的倍数的文件，并使用CTRL-Z来标记文本文件真正应该结束的位置。

请注意，上述的Unix和Windows行为都只是用户输入的正常默认处理。 Unix处理CTRL-D只能在规范模式下从终端设备读取，并且可以将“文件结束”字符改为别的。 在Windows上，操作系统不会特别对待CTRL-Z，但是C运行时库是否取决于所读取的FILE流是处于文本模式还是二进制模式。 这就是为什么在可移植程序中，当打开二进制文件（例如fopen("foo.gif","rb") ）时，应该总是在模式字符串中包含字符b 。

C + +不能获得进程ID（Windows）

我有一个像这样的函数来获取一个进程的id是它的名字，然而它总是返回0，我试着每一个进程：

DWORD GetProcessId(std::string ProcessName) { HANDLE hsnap; PROCESSENTRY32 pt; DWORD PiD; hsnap = Createtoolhelp32Snapshot(TH32CS_SNAPPROCESS,0); pt.dwSize = sizeof(PROCESSENTRY32); do { if (!strcmp(pt.szExeFile,ProcessName.c_str())) { CloseHandle(hsnap); PiD = pt.th32ProcessID; return PiD; if (PiD != NULL) { return 0; } } } while (Process32Next(hsnap,&pt)); return 1; }

主要function：

int main() { DWORD pid = GetProcessId("calc.exe"); std::cout << pid; if (pid == 0) { printf("error 1"); getchar(); }//error return 0; }

通过Windows API函数replace对AfxGetInstanceHandle（）的调用

从任务计划的Windowsbatch file中杀死进程树

写入超过2.5GB后性能下降。 为什么？

在shmdt（）和shmctl（shmid，ipc_RMID，0）之前的进程中访问共享内存

从信号处理程序打印堆栈跟踪

如何build立提升python 3.4共享库win8.1 64位与msvc 10.0

在Python中查找每个正在运行的进程的path

没有溢出投在x64上

在Linux上更快地分配大型进程？

如何“docker运行”在最小的Linux安装一个shell会话，并立即拆除容器？

这里有几个问题。

首先， GetProcessId是一个Windows API函数的名称，它将一个HANDLE作为参数。 HANDLE通常被定义为void* ，所以这意味着任何指针都将满足函数签名。

你自己的GetProcessId需要一个std::string但是通过传递一个指向字符串常量的指针来调用它。 通常情况下，这样做可以， std::string可以由此构造，但是因为GetProcessId的Windows API版本已经匹配了编译器优先调用的函数签名。 所以基本上你自己的功能从来没有被实际调用过。

你自己的功能也有一些问题。 首先，通过循环的第一次迭代是与垃圾内存进行比较 – 您忘记调用Process32First ，所以pt在第一次通过时是未初始化的。 其次，如果这个过程没有找到，你正在泄漏hsnap句柄。

尝试以下操作：

DWORD MyGetProcessId(LPCTSTR ProcessName) // non-conflicting function name { PROCESSENTRY32 pt; HANDLE hsnap = Createtoolhelp32Snapshot(TH32CS_SNAPPROCESS,0); pt.dwSize = sizeof(PROCESSENTRY32); if (Process32First(hsnap,&pt)) { // must call this first do { if (!lstrcmpi(pt.szExeFile,ProcessName)) { CloseHandle(hsnap); return pt.th32ProcessID; } } while (Process32Next(hsnap,&pt)); } CloseHandle(hsnap); // close handle on failure return 0; } int main() { DWORD pid = MyGetProcessId(TEXT("calc.exe")); std::cout << pid; if (pid == 0) { printf("error 1"); getchar(); }//error return 0; }

编辑：我已经改变了函数不再使用一个std::string ，并使用lstrcmpi意味着它将作为一个Ansi或Unicode版本。 正如下面的评论员所建议的那样，现在你真的应该使用Unicode。

这里是C代码，在Windows上工作正常。 用进程名调用PID_GetProcessId，返回进程名的进程号

int PID_GetProcessId(char * name,PDWORD pid) { DWORD aProcesses[1024],cbNeeded,cProcesses; UINT32 i; if (!EnumProcesses( aProcesses,sizeof(aProcesses),&cbNeeded ) ) { //Error } /* Calculate how many process identifiers were returned. */ cProcesses = cbNeeded / sizeof(DWORD); /* Print the name and process identifier for each process. */ for ( i = 0; i < cProcesses; i++ ) { if( aProcesses[i] != 0 ) { if(PID_PrintProcessNameAndID( aProcesses[i],name ) == 1) { *pid = aProcesses[i]; break; } } } return 0; } int PID_PrintProcessNameAndID(DWORD processID,char * name) { char szProcessName[MAX_PATH]; HANDLE hProcess=NULL; char buff[200]=""; hProcess = OpenProcess( PROCESS_QUERY_informatION |PROCESS_VM_READ,FALSE,processID ); /* Get the process name. */ if (NULL != hProcess ) { HMODULE hMod; DWORD cbNeeded; if ( EnumProcessmodulees( hProcess,&hMod,sizeof(hMod),&cbNeeded) ) { GetmoduleeBaseNameA( hProcess,hMod,(LPSTR)szProcessName,sizeof(szProcessName)/sizeof(TCHAR) ); } } if(lstrcmpiA(szProcessName,name) == 0) { CloseHandle(hProcess); return 1; } return 0; CloseHandle( hProcess ); }

C++ Windows 编译程序与 Linux 的不同行为

#include <iostream>
#include <fstream>
#include <vector>


int main()
{
    
    std::ifstream ifile("city32.bmp");

    ifile.seekg(0,std::ios::end);
    std::size_t fsize = ifile.tellg();
    std::cout << "fsize=" << fsize << std::endl;

    ifile.seekg(0,std::ios::beg);
    std::vector<unsigned char> buf(fsize,0);
    std::cout << "vector size: " << buf.size() << std::endl;

    ifile.read((char*)&buf[0],fsize);

    for(int i = 0; i < buf.size(); ++ i)
    {
        std::cout << i << "." << (int)buf.at(i) << "  ";
    }
    std::cout << std::endl;

    std::ofstream ofile("city32_out.bmp");
    ofile.write((char*)&buf[0],fsize);
    ofile.close();

    ifile.close();

    return 0;

}

if not defined npm_config_node_gyp (node "C:\Users\Administrator\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\Users\Administrator\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Platform.targets(6
7,5): error MSB8020: 无法找到 v140 的生成工具(平台工具集 =“v140”)。若要使用 v140 生成工具进行生成，请安装 v140 生成工具。或者，可以升级到当前 Visual Studio 工具，方式是通过选择
“项目”菜单或右键单击该解决方案，然后选择“重定解决方案目标”。 [F:\project\electron-source\node_modules\better-sqlite3\build\deps\locate_sqlite3.vcxpr
oj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Users\Administrator\AppData\Roaming\npm\node_modules\node-gyp\lib\build.js:190:23)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:237:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Administrator\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd F:\project\electron-source\node_modules\better-sqlite3
gyp ERR! node -v v10.3.0
gyp ERR! node-gyp -v v5.0.2
gyp ERR! not ok

node-pre-gyp ERR! Completion callback never invoked!
node-pre-gyp ERR! System Windows_NT 10.0.17134
node-pre-gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "F:\\project\\electron-source\\node_modules\\@journeyapps\\sqlcipher\\node_modules\\node-pre-gyp\\bin\\node-pre-gyp" "install" "--fallback-to-build"
node-pre-gyp ERR! cwd F:\project\electron-source\node_modules\@journeyapps\sqlcipher
node-pre-gyp ERR! node -v v10.3.0
node-pre-gyp ERR! node-pre-gyp -v v0.10.0
node-pre-gyp ERR! This is a bug in `node-pre-gyp`.
node-pre-gyp ERR! Try to update node-pre-gyp and file an issue if it does not help:
node-pre-gyp ERR!     <https://github.com/mapbox/node-pre-gyp/issues>

npm install -g electron

electron .

npm install electron-packager -g

electron -v

npm install

npm start

electron-packager . ''HelloWorld'' --platform=win32 --arch=x64 --icon=icon.ico --out=./out --asar --app-version=0.0.1

npm run-script package