honor configured batch size & reject unsupported ulimit

[DanHouseman]

Fixes native Windows batch-size handling and makes Unix-only --ulimit behavior explicit.

For example: Currently on Windows, RustScan ignores the batch-size value -b / --batch-size and instead uses the hard-coded AVERAGE_BATCH_SIZE value of 3000
This means a command like the following wont actually scan with the batch-size of 50.

rustscan -a 127.0.0.1 -b 50

This changes the Windows code path to honor the configured batch size and ensures diagnostics report the effective batch size actually used.

It also hides --ulimit from Windows help output and rejects it when supplied on Windows because ulimit is not applicable to native Windows.

Changes

• Use opts.batch_size as the effective batch size on native Windows.

• Preserve existing Unix batch-size and ulimit inference behavior.

• Report the effective batch size rather than the originally requested value in scan diagnostics.

• Hide --ulimit from Windows CLI help.

• Reject --ulimit on Windows with an explanatory error and exit code 2.

• Validate platform-specific options after configuration merging so ulimit supplied through .rustscan.toml is also rejected.

• Add Windows-specific unit coverage.

• Add tests/windows_correctness.rs integration coverage for:

  • Windows help output.
  • CLI --ulimit rejection.
  • Config-file ulimit rejection.
  • Propagation of an explicit Windows batch size through scanner startup.

Testing

Tested natively on Windows 11.

cargo build
cargo fmt
cargo clippy
cargo test

Windows integration tests:

cargo test --test windows_correctness -- --nocapture

Behavior

Before:

rustscan -a 127.0.0.1 -b 50

Opts.batch_size = 50
Effective scanner batch size = 3000

After:

rustscan -a 127.0.0.1 -b 50

Opts.batch_size = 50
Effective scanner batch size = 50

Unix behavior is unchanged.

Related work / acknowledgement

This PR has an overlap with existing PR #905, “Refactor port scanning and improve batch size handling,” by @0xxreacher:

PR #905 correctly identified that the no-open-ports warning reports opts.batch_size rather than the effective batch_size actually used by the scanner. I retained that correction here because it is also necessary for the Windows behavior fixed by this PR to report its runtime configuration accurately.

The primary Windows issue addressed here is separate: on native Windows, the #[cfg(not(unix))] path currently ignores the configured -b / --batch-size value entirely and instead hard-codes AVERAGE_BATCH_SIZE (3000). This PR makes Windows honor the requested batch size and adds Windows-specific handling and tests for the Unix-only --ulimit option.

With that said, credit should go to @0xxreacher for identifying the effective batch-size reporting issue in #905.

[0xxreacher]

Yoo, nice one Thanks for the shoutout on #905. Glad to see that fix carried over, and the Windows batch-size + --ulimit handling looks clean af. I’ll give the implementation and tests a proper look

[DanHouseman]

@0xxreacher

Absolutely! Gotta give credit where it’s due. 👍