Skip to content

Commit 5567500

Browse files
committed
chore: clean readme
1 parent 57c5839 commit 5567500

5 files changed

Lines changed: 6 additions & 148 deletions

File tree

packages/windows-hermes/README.md

Lines changed: 1 addition & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -1,27 +1,3 @@
11
# @nativescript/windows-hermes
22

3-
NativeScript Windows runtime on **Microsoft's prebuilt Hermes** (`hermes.dll`, which exports both
4-
`napi_*` and the JSR C API), with no Node/Bun/Deno host. The engine-neutral
5-
`runtime::napi_engine` WinRT interop runs unchanged over Hermes's `napi_env`.
6-
7-
## As an app runtime (drop-in for `@nativescript/windows`)
8-
Publishes as `@nativescript/windows-hermes`, the **same** WinUI 3 framework as
9-
`@nativescript/windows` with the Hermes runtime DLL — swap the dependency and an app runs
10-
unchanged. Build the framework with the engine flag:
11-
```sh
12-
pwsh -File ../../template/build.ps1 -Engine hermes # or: npm run build
13-
```
14-
The engine → runtime-DLL adapter (the C ABI the WinUI 3 host P/Invokes) follows the reference
15-
implementation in `../windows-quickjs/src/abi.rs`. See `../README.md` for the full contract.
16-
17-
## Standalone host (dev/bench)
18-
```sh
19-
cargo build --release --manifest-path packages/windows-hermes/Cargo.toml
20-
target/release/nativescript-windows.exe # runs the WinRT demo, exit 0
21-
```
22-
build.rs links `vendor/x64/hermes.lib`, forward-exports Hermes's `napi_*` from the exe (so napi-sys
23-
resolves them), and copies `hermes.dll`/`hermes-icu.dll` next to the binary.
24-
25-
## Notes
26-
- Prebuilt engine binaries are committed under `vendor/` — see `vendor/README.md` for provenance
27-
(Microsoft.JavaScript.Hermes NuGet) and the refresh recipe.
3+
NativeScript Windows runtime on **Microsoft's prebuilt Hermes**

packages/windows-hermes/package.json

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"name": "@nativescript/windows-hermes",
3-
"version": "0.1.0-alpha.0",
3+
"version": "0.1.0-alpha.1",
44
"description": "NativeScript Windows runtime (Hermes engine) with a WinUI 3 app template",
55
"keywords": [
66
"NativeScript",

packages/windows-jsc/README.md

Lines changed: 2 additions & 44 deletions
Original file line numberDiff line numberDiff line change
@@ -1,17 +1,7 @@
11
# @nativescript/windows-jsc
22

3-
NativeScript Windows runtime on **JavaScriptCore**, no Node. **Working** — the full WinRT demo
4-
passes (`exit 0`): typed WinRT calls, a 20-call stress loop, and a `JsonObject` round-trip.
3+
NativeScript Windows runtime on **JavaScriptCore**.
54

6-
## As an app runtime (drop-in for `@nativescript/windows`)
7-
Publishes as `@nativescript/windows-jsc`, the **same** WinUI 3 framework as `@nativescript/windows`
8-
with the JavaScriptCore runtime DLL — swap the dependency and an app runs unchanged. Build the
9-
framework with the engine flag (needs a real `JavaScriptCore.lib` in `vendor/x64`):
10-
```sh
11-
pwsh -File ../../template/build.ps1 -Engine jsc # or: npm run build
12-
```
13-
The engine → runtime-DLL adapter (the C ABI the WinUI 3 host P/Invokes) follows the reference
14-
implementation in `../windows-quickjs/src/abi.rs`. See `../README.md` for the full contract.
155

166
## The engine binary — Playwright's WebKit (current)
177
The official WebKit WinCairo buildbot is dead (last Windows build Sept 2024), and there's no NuGet/npm
@@ -20,36 +10,4 @@ WebKit constantly:
2010

2111
```
2212
https://playwright.download.prss.microsoft.com/dbazure/download/playwright/builds/webkit/<rev>/webkit-win64.zip
23-
```
24-
(`<rev>` from `packages/playwright-core/browsers.json` in microsoft/playwright — 2331 at time of
25-
writing; the vendored `JavaScriptCore.dll` is dated 2026-07-14). It exports the full JSC C API and
26-
depends only on `icuin77.dll` / `icuuc77.dll` (+ `icudt77.dll` data).
27-
28-
`vendor/x64/` holds (committed, no LFS): `JavaScriptCore.dll` (33 MB), `icudt77.dll` (32 MB),
29-
`icuin77.dll`, `icuuc77.dll`, and `JavaScriptCore.lib` — an **import lib generated from the DLL's
30-
exports** (no `.lib` ships in the zip):
31-
```sh
32-
llvm-objdump -p JavaScriptCore.dll | awk '/Export Table/{f=1;next} f&&/0x/{print $NF}' \
33-
| grep -E '^(JS|WK|k)' | awk '{print ($0 ~ /^k/) ? $0" DATA" : $0}' > exports # k* are DATA symbols
34-
printf 'EXPORTS\n' > JavaScriptCore.def; cat exports >> JavaScriptCore.def
35-
lib /def:JavaScriptCore.def /machine:x64 /out:JavaScriptCore.lib
36-
```
37-
38-
## Build & run
39-
```sh
40-
cargo build --release --features jsc_link --manifest-path packages/windows-jsc/Cargo.toml
41-
target/release/nativescript-windows.exe
42-
```
43-
`build.rs` links `JavaScriptCore.lib` and copies the DLLs beside the exe.
44-
45-
## Shim = napi-android's JSC provider (public C API), + two Windows fixes
46-
`jsc-api.cpp` is over JSC's stable public C API (no WebKit internals), so it's version-robust. Two
47-
bugs surfaced on Windows and are fixed in the vendored shim:
48-
- **UTF-16 read truncation**: `CopyTo` did `memcpy(buf, chars, size)` where `size` is a count of
49-
2-byte `JSChar` → copied half the bytes (`'hi'``'h'`). Fixed to `size * sizeof(JSChar)`.
50-
- **napi functions weren't constructors**: `FunctionInfo`'s `JSClassDefinition` set `callAsFunction`
51-
but not `callAsConstructor`, so a JS `Proxy` over them wasn't a constructor (`new
52-
Windows.Data.Json.JsonObject()` → "not a constructor"). Added a `CallAsConstructor` callback (the
53-
JSC analog of the QuickJS `JS_SetConstructorBit` fix; V8's napi functions are constructable by
54-
default).
55-
Also `EXTERN_C` on the JSR bring-up decls (`jsr_common.h`) so the Rust host's `extern "C"` resolves.
13+
```

packages/windows-quickjs/README.md

Lines changed: 1 addition & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -1,27 +1,3 @@
11
# @nativescript/windows-quickjs
22

3-
NativeScript Windows runtime on **embedded QuickJS** (quickjs-ng + the napi-android node_api shim),
4-
with no Node/Bun/Deno host. The engine-neutral `runtime::napi_engine` WinRT interop runs unchanged
5-
over the shim's `napi_env`.
6-
7-
## As an app runtime (drop-in for `@nativescript/windows`)
8-
Publishes as `@nativescript/windows-quickjs`, the **same** WinUI 3 framework as
9-
`@nativescript/windows` with the QuickJS runtime DLL — swap the dependency and an app runs
10-
unchanged. Build the framework with the engine flag:
11-
```sh
12-
pwsh -File ../../template/build.ps1 -Engine quickjs # or: npm run build
13-
```
14-
`src/abi.rs` (the `host_dll` feature) is the reference implementation of the engine → runtime-DLL
15-
adapter (the C ABI the WinUI 3 host P/Invokes). See `../README.md` for the full contract.
16-
17-
## Standalone host (dev/bench)
18-
```sh
19-
cargo build --release --manifest-path packages/windows-quickjs/Cargo.toml
20-
target/release/nativescript-windows.exe # runs the WinRT demo, exit 0
21-
```
22-
`--no-default-features` builds only the engine smoke lib (no napi/v8).
23-
24-
## Notes
25-
- The engine is compiled from `vendor/` (quickjs-ng fork + shim); see `vendor` sources.
26-
- Carries a fix for a double-free in the shim's finalizer (`quickjs-api.c`
27-
`JSFinalizeValueCallback`) — worth upstreaming to napi-android.
3+
NativeScript Windows runtime on **embedded QuickJS**

packages/windows-v8/README.md

Lines changed: 1 addition & 53 deletions
Original file line numberDiff line numberDiff line change
@@ -1,55 +1,3 @@
11
# @nativescript/windows-v8
22

3-
NativeScript Windows runtime on **V8** — the same engine our classic runtime is built on. No Node.
4-
5-
## As an app runtime (drop-in for `@nativescript/windows`)
6-
Publishes as `@nativescript/windows-v8`, the **same** WinUI 3 framework as `@nativescript/windows`
7-
with a napi-backed V8 runtime DLL — swap the dependency and an app runs unchanged. Build the
8-
framework with the engine flag:
9-
```sh
10-
pwsh -File ../../template/build.ps1 -Engine v8 # or: npm run build
11-
```
12-
The engine → runtime-DLL adapter (the C ABI the WinUI 3 host P/Invokes) follows the reference
13-
implementation in `../windows-quickjs/src/abi.rs`. See `../README.md` for the full contract.
14-
15-
## Standalone host
16-
Reuses napi-android's `v8-api.cpp` (napi over V8's C++ API), **ported to V8 14.7**, compiled against
17-
the `v8` crate's bundled headers and linked against its prebuilt rusty_v8 (V8 14.7). The Android
18-
bring-up (`jsr.cpp`) is replaced by `csrc/win_jsr.cpp`. Full WinRT demo passes (`exit 0`):
19-
static-method resolution, typed WinRT calls, a 20-call stress loop, and a `JsonObject` round-trip.
20-
21-
```sh
22-
cargo build --release --manifest-path packages/windows-v8/Cargo.toml
23-
target/release/nativescript-windows.exe
24-
```
25-
26-
## Why this was tractable (no ABI nightmare)
27-
The `v8` crate's default config has **pointer compression and the sandbox OFF** (they're opt-in
28-
cargo features we don't enable), so V8 uses plain/uncompressed pointers — there are **no ABI-matching
29-
defines** and none of the corruption risk that config would bring. The port was therefore a bounded
30-
API migration, not an ABI hunt.
31-
32-
## What the port involved (V8 13 → 14.7)
33-
- Build recipe: C++20 + `/Zc:__cplusplus` (MSVC reports the real `__cplusplus`), locate the crate's
34-
`v8/include`, stub `<android/log.h>`, `NAPI_EXTERN``__declspec(dllexport)`, define `__V8_13__`
35-
(take the shim's modern `SetAccessorProperty` etc. paths). No pointer-compression/sandbox defines.
36-
- API migrations: `String::Write/WriteUtf8/WriteOneByte``*V2` (+ `WriteFlags`); mandatory pointer
37-
**type tags** on internal fields / `External` (safe defaults `kEmbedderDataTypeTagDefault` /
38-
`kExternalPointerTypeTagDefault`); `Context::GetIsolate()` removed → `Isolate::GetCurrent()`;
39-
interceptor setters return `v8::Intercepted` (`ReturnValue<void>`).
40-
- Platform init done from **Rust** (`v8::new_default_platform``V8::initialize`) because
41-
`NewDefaultPlatform`'s `std::unique_ptr<Platform>` return can't be linked from the MSVC-STL shim
42-
(rusty_v8 uses V8's bundled libc++). See below.
43-
44-
## The libc++ boundary — solved, including zero-copy
45-
rusty_v8 is built with V8's bundled libc++, so V8 API methods whose signatures involve
46-
`std::shared_ptr`/`unique_ptr<BackingStore>` can't be linked directly from this MSVC-STL shim.
47-
Handled without any copy:
48-
- Reads use `ArrayBuffer::Data()` (the direct `void*` accessor — no `BackingStore`).
49-
- `napi_create_external_arraybuffer` is **true zero-copy**: it goes through rusty_v8's own
50-
`extern "C"` bindings (`v8__ArrayBuffer__NewBackingStore__with_data`, the unique→shared converter,
51-
`v8__ArrayBuffer__New__with_backing_store`) which pass the backing store as raw pointers / an
52-
opaque 16-byte `shared_ptr`, then bridges the returned pointer back to a `Local` (a `Local` is one
53-
pointer). The buffer aliases the source memory; the napi finalizer runs from the BackingStore
54-
deleter on GC. **Verified:** `interop.arrayBufferFromBuffer(CryptographicBuffer.GenerateRandom(8))`
55-
`byteLength=8`, `instanceof ArrayBuffer`, no copy. So the IBuffer→ArrayBuffer perf path is intact.
3+
NativeScript Windows runtime on **V8**

0 commit comments

Comments
 (0)