Next

[MacroModel]

No description provided.

[MacroModel]

我先在代码库里定位并理解 win32_process_io、throw_win32_error 以及相关 Win32 API 封装的定义，以核对此 win32.h 文件对 Win32/MSDN 的使用是否正确。随后我会并行检索多处关键词来构建完整上下文。

[1 tool called]

结论

• 该库自带的 include/fast_io_hosted/process/process/win32.h 并非微软系统头（MSDN 里没有 win32.h），而是库的 Win32 进程封装实现文件；整体对 Win32 API 的使用与 MSDN 一致，关键常量与调用约定正确。
• 主要建议：在使用 CreateProcess* + STARTF_USESTDHANDLES 时，确保传给子进程的标准句柄本身“可继承”；如目标平台为 Vista+，可升级为 STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST 以避免多余句柄被继承。

与 MSDN 对照的关键点（节选）

• 等待/错误处理：使用 WaitForSingleObject(INFINITE) 等待，失败返回 WAIT_FAILED(0xFFFFFFFF) 并通过 GetLastError 取错。代码已在关闭句柄前保存错误码，符合 MSDN 关于“调用其他 API 可能覆盖 LastError”的提醒。

inline ::std::uint_least32_t win32_wait_user_process_or_thread(void *hprocess_thread) noexcept
{
	return ::fast_io::win32::WaitForSingleObject(hprocess_thread, 0xFFFFFFFF);
}

auto const status{win32::details::win32_wait_user_process_or_thread(ppob.hnt_user_process_info.hprocess)};
if (status == 0xFFFFFFFF) [[unlikely]]
{
	if constexpr (throw_eh)
	{
		throw_win32_error();
	}
	else
	{
		return {static_cast<::std::uint_least32_t>(-1)};
	}
}

// get exit code
::std::uint_least32_t exit_code{};
if (!::fast_io::win32::GetExitCodeProcess(ppob.hnt_user_process_info.hprocess, __builtin_addressof(exit_code)))
{
	throw_win32_error();
}

• CreateProcess* 与标准句柄：设置了 STARTF_USESTDHANDLES(0x00000100)，并将 bInheritHandles=TRUE，符合 MSDN 使用要求；同时清除了父进程“管道另一端”的可继承位，避免不必要继承。

::fast_io::win32::startupinfow si{};
si.cb = sizeof(si);
// ... 省略：为 si.hStdInput/Output/Error 赋值 ...
si.dwFlags = 0x00000100;

::std::uint_least32_t dwCreationFlags{0x00000400 /*CREATE_UNICODE_ENVIRONMENT*/};
// ... 省略：按需要 OR 上 CREATE_NEW_PROCESS_GROUP / CREATE_NEW_CONSOLE ...

::fast_io::win32::process_information pi{};
if (!::fast_io::win32::CreateProcessW(address_begin, const_cast<char16_t *>(actrual_args), nullptr, nullptr, 1,
									  dwCreationFlags, (void *)envs, nullptr, __builtin_addressof(si), __builtin_addressof(pi)))
{
	throw_win32_error();
}

• NT 路径到 DOS 路径转换：通过 K32GetMappedFileName*/GetMappedFileName* 获取 \Device\... 前缀，再用 QueryDosDevice* 解析卷设备名或处理 \Device\Mup\ UNC 情况，逻辑符合惯例（MSDN 建议也可用 GetFinalPathNameByHandleW，见“改进建议”）。

#if !defined(_WIN32_WINNT) || _WIN32_WINNT >= 0x601
	::fast_io::win32::K32GetMappedFileNameW
#else
	::fast_io::win32::GetMappedFileNameW
#endif
	(reinterpret_cast<void *>(static_cast<::std::ptrdiff_t>(-1)),
	 pMem,
	 pszFilename,
	 0x2000)) [[unlikely]]

char16_t DosDevice[4]{0, u':', 0, 0};
char16_t NtPath[1025];
// ... 遍历 A:..Z: 并用 QueryDosDeviceW 比较前缀，命中则替换为盘符 ...

建议与潜在风险（基于 MSDN）

• 确保子进程用到的标准句柄“可继承”：
  • 目前仅对“父进程不需要继承的管道另一端”执行了 SetHandleInformation(..., HANDLE_FLAG_INHERIT, 0) 清除继承位（见下段）；若管道端初始未设为可继承，子进程可能拿不到有效句柄。建议在把句柄塞进 si.hStdInput/Output/Error 后，显式把该端标记为可继承（与 MSDN 样例一致）。

if (processio.in.win32_pipe_in_handle)
{
	si.hStdInput = processio.in.win32_pipe_in_handle;

	if (!::fast_io::win32::SetHandleInformation(processio.in.win32_pipe_out_handle, 0x00000001 /*HANDLE_FLAG_INHERIT*/, 0)) [[unlikely]]
	{
		throw_win32_error();
	}
}

• 最小改动示例（在设置 si.hStd* 后补一行，确保该端可继承；若句柄是由外部传入且已经可继承，则不影响）：

// 在设置 si.hStdInput/Output/Error 之后追加（示例以 hStdInput 为例）
if (si.hStdInput) {
	if (!::fast_io::win32::SetHandleInformation(si.hStdInput, 0x00000001 /*HANDLE_FLAG_INHERIT*/, 0x00000001 /*HANDLE_FLAG_INHERIT*/)) {
		throw_win32_error();
	}
}

• Vista+ 的更稳妥方案：使用 STARTUPINFOEX 与 PROC_THREAD_ATTRIBUTE_HANDLE_LIST 精确白名单控制继承句柄，避免 bInheritHandles=TRUE 带来非预期句柄继承（MSDN 推荐实践）。
• 可读性建议：将字面量替换为命名常量（如 INFINITE、STARTF_USESTDHANDLES、CREATE_UNICODE_ENVIRONMENT、DUPLICATE_SAME_ACCESS、HANDLE_FLAG_INHERIT）。功能不变，方便对照 MSDN。
• 获取映像路径的现代做法：若目标系统为 Vista+，可优先用 GetFinalPathNameByHandleW 简化 K32GetMappedFileName* + QueryDosDevice* 的路径转换，并在较老系统回退到当前实现。
• 设计注意：win32_family_process 析构器会阻塞等待进程退出（见 close_win32_user_process_information_and_wait）。这在语义上更像“join”，符合某些使用场景，但可能导致误用时卡住线程；建议在文档中强调或提供非阻塞析构/显式 detach 的安全用法。

总体评价

• 与 MSDN 的语义基本一致，资源管理（保存 GetLastError、先 wait 再 GetExitCodeProcess、关闭顺序）正确。按上面的继承位与现代 API 建议做小幅调整，会更健壮、可读性更好、且更贴合微软推荐实践。

• 我检查了 include/fast_io_hosted/process/process/win32.h 中上述位置，给出了插入位置与最小改动示例；如需，我可以按你的目标平台范围（例如 Vista+/Win7+）直接给出完整的 STARTUPINFOEX 版本编辑建议。

• 另外提醒：MSDN 确实没有系统级 win32.h 头，本仓库此文件为库内部实现，命名上可能会与系统头认知混淆；若团队中有此困惑，可考虑在 README/注释中注明或调整文件名以避免歧义。

• 若你希望，我可以把“确保标准句柄可继承”的改动具体插到 Wide/ANSI 两个分支的正确行号处并给出完整 edits。

[trcrsired]

乱改一通

if constexpr (sizeof(::std::uintmax_t) > sizeof(off_t))
{
    if (offset > static_cast<::std::uintmax_t>(::std::numeric_limits<off_t>::max()))
    {
        throw_posix_error(EINVAL);
    }
}
long ret{system_call<__NR_mmap, long>(addr, len, prot, flags, fd, offset)};

为何这里要改long. fast_io禁止使用long能理解么？

[trcrsired]

fast_io不允许使用int long之类

[MacroModel]

@trcrsired fixed

[trcrsired]

CI failed.

[MacroModel]

CI failed.

MSVC linker failed due to unresolved symbol

[MacroModel]

现在别合并

[MacroModel]

我还有clone3 和posix线程要写
win32上你用createthread没有任何问题，crt都能正确初始化，用errno和c++ thread_local完全没毛病。https://github.com/reactos/reactos/blob/bb7a6134c42c676d5abb5e14dae8a3d7c2f5568d/sdk/lib/crt/process/threadx.c#L6

[MacroModel]

但是posix上问题很多吗，你用clone3就不能用crt那些东西，得自己手动初始化，要么就pthread

[MacroModel]

finished

[trcrsired]

但是posix上问题很多吗，你用clone3就不能用crt那些东西，得自己手动初始化，要么就pthread

那就调用pthreads.反正又不是std::threads