## Summary
- Fixed embedded resource path resolution when using
`Bun.build({compile: true})` API for Windows targets
- Fixed relative path handling for `--outfile` parameter in compilation
## Details
This PR fixes two regressions introduced after v1.2.19 in the
`Bun.build({compile})` feature:
### 1. Embedded Resource Path Issue
When using `Bun.build({compile: true})`, the module prefix wasn't being
set to the target-specific base path, causing embedded resources to fail
with "ENOENT: no such file or directory" errors on Windows (e.g.,
`B:/~BUN/root/` paths).
**Fix**: Ensure the target-specific base path is used as the module
prefix in `doCompilation`, matching the behavior of the CLI build
command.
### 2. PE Metadata with Relative Paths
When using relative paths with `--outfile` (e.g.,
`--outfile=forward/slash` or `--outfile=back\\slash`), the compilation
would fail with "FailedToLoadExecutable" error.
**Fix**: Ensure relative paths are properly converted to absolute paths
before PE metadata operations.
## Test Plan
- [x] Tested `Bun.build({compile: true})` with embedded resources
- [x] Tested relative path handling with nested directories
- [x] Verified compiled executables run correctly
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Zack Radisic <zack@theradisic.com>
### What does this PR do?
### How did you verify your code works?
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
## Summary
This PR fixes a panic that occurs when file operations use buffers
larger than 4GB on Windows.
## The Problem
When calling `fs.readSync()` or `fs.writeSync()` with buffers larger
than 4,294,967,295 bytes (u32::MAX), Bun panics with:
```
panic(main thread): integer cast truncated bits
```
## Root Cause
The Windows APIs `ReadFile()` and `WriteFile()` expect a `DWORD` (u32)
for the buffer length parameter. The code was using `@intCast` to
convert from `usize` to `u32`, which panics when the value exceeds
u32::MAX.
## The Fix
Changed `@intCast` to `@truncate` in four locations:
1. `sys.zig:1839` - ReadFile buffer length parameter
2. `sys.zig:1556` - WriteFile buffer length parameter
3. `bun.zig:230` - platformIOVecCreate length field
4. `bun.zig:240` - platformIOVecConstCreate length field
With these changes, operations with buffers > 4GB will read/write up to
4GB at a time instead of panicking.
## Test Plan
```js
// This previously caused a panic on Windows
const fs = require('fs');
const fd = fs.openSync('test.txt', 'r');
const buffer = Buffer.allocUnsafe(4_294_967_296); // 4GB + 1 byte
fs.readSync(fd, buffer, 0, buffer.length, 0);
```
Fixes https://github.com/oven-sh/bun/issues/21699🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Jarred Sumner <jarred@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
