Replace windows to windows-sys by youknowone · Pull Request #6356 · RustPython/RustPython

dependabot

15-21: WinHandle/WindowsSysResult and windows_sys imports look consistent

Importing WinHandle, WindowsSysResult, INVALID_HANDLE_VALUE, and MAX_PATH from the new windows_sys-based stack is appropriate and matches how the rest of the file uses these types/constants. No issues here.

76-79: CloseHandle wrapper correctly migrated to WinHandle/WindowsSysResult

Wrapping CloseHandle as fn CloseHandle(handle: WinHandle) -> WindowsSysResult<i32> and passing handle.0 matches the BOOL-returning Win32 API and keeps error handling centralized in WindowsSysResult.

82-96: GetStdHandle semantics preserved with WinHandle

The new GetStdHandle returning PyResult<Option<WinHandle>> correctly:

Treats INVALID_HANDLE_VALUE as an error via errno_err(vm).
Treats a NULL handle as None.
Wraps valid handles in WinHandle.

This preserves the old sentinel behavior while aligning with the new handle abstraction.

98-118: CreatePipe wrapper correctly handles HANDLE out-params

CreatePipe now:

Uses MaybeUninit<HANDLE> for read/write ends.
Wraps the resulting handles as WinHandle in the returned tuple.
Relies on WindowsSysResult(..).to_pyresult(vm)? for error propagation.

This is idiomatic and matches the windows_sys FFI conventions.

120-146: DuplicateHandle migration to WinHandle is sound

The updated DuplicateHandle:

Accepts WinHandle for src_process, src, and target_process.
Uses a MaybeUninit<HANDLE> out-parameter.
Wraps the duplicated handle in WinHandle on success.

The argument order and conversion of inherit/options look correct for the underlying API.

154-156: GetCurrentProcess returning WinHandle is consistent

Wrapping GetCurrentProcess() in WinHandle aligns it with other APIs that now traffic in WinHandle. This matches its intended use as a pseudo-handle passed into other FFI calls.

158-169: GetFileType correctly updated to accept WinHandle

Taking h: WinHandle and calling GetFileType(h.0) preserves behavior while tightening the handle type. The existing error check (file_type == 0 && GetLastError() != 0) is preserved and remains appropriate.

203-291: CreateProcess now returning WinHandle for process/thread handles

The updated CreateProcess:

Continues to set up STARTUPINFOEXW, environment, and attribute list as before.
Returns WinHandle(procinfo.hProcess) and WinHandle(procinfo.hThread) instead of raw handles.

This keeps FFI boundary concerns localized and is consistent with the new handle abstraction. No functional regressions are apparent in the startup-info or env/attribute handling in this diff.

294-311: OpenProcess error handling improved and aligned with WinHandle

The new OpenProcess wrapper:

Takes inherit_handle: bool and converts it via i32::from(inherit_handle) to the expected BOOL.
Checks handle.is_null() and maps failure to errno_err(vm).
Returns a PyResult<WinHandle> on success.

This is a clear improvement over returning a raw integer and manually checking for sentinel values at call sites.

You may want to run cargo test -p vm -- --nocapture (or your existing Windows test suite) on a Windows host to confirm that all Python-level callers of _winapi.OpenProcess correctly handle the new PyResult<WinHandle> return type and adjusted signature.

445-445: AttrList handle list size calculation matches usize-based handles

Using (handlelist.len() * size_of::<usize>()) as _ aligns the size passed to UpdateProcThreadAttribute with the type of handlelist: Vec<usize>. This keeps the allocation and size math consistent with how handles are represented here.

457-464: WaitForSingleObject correctly updated to take WinHandle

WaitForSingleObject(h.0, ms) with an error check on WAIT_FAILED mirrors the Win32 API behavior, now using the typed WinHandle wrapper. No issues with the conversion or error propagation via errno_err(vm).

467-477: GetExitCodeProcess wrapper correctly uses WinHandle and WindowsSysResult

The function:

Accepts h: WinHandle.
Uses MaybeUninit for the exit code out-parameter.
Wraps the call in WindowsSysResult(..).to_pyresult(vm)?.

This matches the underlying API’s contract and is consistent with the project’s WindowsSysResult error-handling pattern.

480-484: TerminateProcess wrapper migration is straightforward

Passing h.0 into TerminateProcess and wrapping the BOOL result in WindowsSysResult<i32> is correct and consistent with how other BOOL-based APIs are handled.

488-496: LoadLibrary uses windows_sys correctly and checks for null handle

LoadLibrary now:

Converts the path via to_wide_with_nul.
Calls LoadLibraryW from windows_sys.
Checks handle.is_null() and raises a runtime error on failure.
Returns handle as isize on success.

This matches the documented contract (NULL on failure) and keeps FFI details localized.

If this function is used by higher-level ctypes-like loaders, please ensure those callers still expect an isize and handle failures via exceptions rather than sentinel values.

499-515: GetModuleFileName correctly casts handle and bounds the UTF-16 slice

Casting handle to HMODULE and passing it to GetModuleFileNameW, then slicing path[..length] before UTF-16 decoding, is the standard pattern here. The MAX_PATH-based buffer and the length == 0 failure check are unchanged in behavior.