Skip to content

Reconsider exit code translation on Windows #114

Open
@jakepetroules

Description

@jakepetroules

A few thoughts on the exit code translation on Windows:

var status: DWORD = 0
guard GetExitCodeProcess(execution.processInformation.hProcess, &status) else {
// The child process terminated but we couldn't get its status back.
// Assume generic failure.
return .exited(1)
}
let exitCodeValue = CInt(bitPattern: .init(status))
guard exitCodeValue >= 0 else {
return .unhandledException(status)
}
return .exited(status)

Since Windows doesn't actually have signals, and there is only a single exit code, should we consider making the unhandledException case unavailable on Windows, and solely using exited?

(additionally, if GetExitCodeProcess fails we should probably just throw, to avoid confusing that case for an actual .exited(1))

And, given this code in SCF:

GetExitCodeProcess(process.processHandle, &dwExitCode)
            if (dwExitCode & 0xF0000000) == 0x80000000      // HRESULT
            || (dwExitCode & 0xF0000000) == 0xC0000000      // NTSTATUS
            || (dwExitCode & 0xF0000000) == 0xE0000000      // NTSTATUS (Customer)
            || dwExitCode == 3 {
                process._terminationStatus = Int32(dwExitCode & 0x3FFFFFFF)
                process._terminationReason = .uncaughtSignal

...should we consider providing some Windows-specific APIs to attempt to extract the specific HRESULT/NTSTATUS codes and their string counterparts? There's a huge namespace of Windows errors, and being able to programmatically retrieve their string values for display to a user to indicate why a process has failed could be really useful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions