Support Windows

[asmacdo]

Duct works by creating a new session to run all processes under.

I didn't look into this too deeply, but it does look possible. Still, I wouldnt feel comfortable just adding this until we test for the abandoning parent issue, blocked by: #44

From ChatGPT:

**For Windows, os.setsid is not available as it is specific to Unix-like systems. Instead, you can use subprocess.CREATE_NEW_PROCESS_GROUP in combination with Popen to achieve similar functionality. This flag creates a new process group, which allows you to manage the process more effectively.

Here is an example of how you can modify your Popen call to work on both Unix-like systems and Windows:

import os
import subprocess
import platform

def start_process(command):
    if platform.system() == "Windows":
        # Windows-specific implementation
        process = subprocess.Popen(command, creationflags=subprocess.CREATE_NEW_PROCESS_GROUP)
    else:
        # Unix-like system implementation
        process = subprocess.Popen(command, preexec_fn=os.setsid)
    return process

# Example usage
command = ["your_command", "arg1", "arg2"]
process = start_process(command)

This code will check the operating system and use the appropriate flag for creating a new process group. On Unix-like systems, it uses os.setsid, and on Windows, it uses subprocess.CREATE_NEW_PROCESS_GROUP. This should provide a functional equivalent to os.setsid for process management on Windows.**

[CodyCBakerPhD]

OK, after working for a while on #371, I did get a minimal proof of concept working while running a basic sleep command from one terminal using a separate python kernel with psutil to 'scan' for that PID and any children with a matching PPID (in place of UNIX session ID treatment, which has no analog in Windows)

However, the biggest blocker which then arises for integration is while the theory of collecting and parsing a sample is fine, when duct launches the given CLI command through a subprocess, psutil (and other approaches) lose access permissions, even when run in admin mode

Claude suggested the following rough sketch of how to adjust the subprocess deployment to pass admin privileges from the master duct terminal (which would be required in this case)

Details

def run_as_admin_windows(command: list[str]) -> subprocess.Popen: """Launch subprocess with admin privileges on Windows.""" if SYSTEM != "Windows": return subprocess.Popen(command)

# Use ShellExecute with runas
SEE_MASK_NOCLOSEPROCESS = 0x00000040

class SHELLEXECUTEINFO(ctypes.Structure):
    _fields_ = [
        ('cbSize', ctypes.c_ulong),
        ('fMask', ctypes.c_ulong),
        ('hwnd', ctypes.c_void_p),
        ('lpVerb', ctypes.c_wchar_p),
        ('lpFile', ctypes.c_wchar_p),
        ('lpParameters', ctypes.c_wchar_p),
        ('lpDirectory', ctypes.c_wchar_p),
        ('nShow', ctypes.c_int),
        ('hInstApp', ctypes.c_void_p),
    ]

sei = SHELLEXECUTEINFO()
sei.cbSize = ctypes.sizeof(sei)
sei.fMask = SEE_MASK_NOCLOSEPROCESS
sei.lpVerb = "runas"
sei.lpFile = command[0]
sei.lpParameters = " ".join(command[1:])
sei.nShow = 1

if not ctypes.windll.shell32.ShellExecuteExW(ctypes.byref(sei)):
    raise RuntimeError("Failed to elevate subprocess")

# This won't work exactly like Popen - you'll need to adapt
return sei.hProcess

but it is at this point that the complexity of adding Windows support may not be worth it

Question is, how badly do we want this feature?

If not, then feel free to close and stick to this being a UNIX-based tool.

[CodyCBakerPhD]

Also, a great annoyance is that the entire test suite would need to be refactored around cross-platform CLI calls to things like sleep and echo; I sketched how a fixture approach could simplify this but still a lot of work

[CodyCBakerPhD]

Worth mentioning WSL mostly seems to work as intended; only ~40 test failures mostly related to setsid commands through test_spawn_children

So likely it can't handle monitoring from children of the same session, but for a single PID works well