[KSWORK2001]

What

sceNetResolverStartNtoaMultipleRecords threw as unimplemented. The (rid, hostname, records, timeout, retry, flags) signature, the 384-byte records layout (10 records of a 16-byte address union, af and padding, then records, recordsv4 and padding) and the cleared-then-filled output follow the shadPS4 reimplementation of the PS4 library, which has a body and a test for it; not confirmed on a PS5 title.

The lookup delegates to host DNS as sceNetResolverStartNtoa does: IPv4-only, one entry per address with duplicates dropped, at most 10 records, af 2 per record and recordsv4 == records. Argument checks follow the sibling (EINVAL for a null hostname or records, EBADF for an unknown resolver, the hostname must be 1..255 bytes as the SDK's SCE_NET_RESOLVER_HOSTNAME_LEN_MAX), and a failed lookup returns RESOLVER_ENODNS and records it for sceNetResolverGetError. As for the sibling, timeout, retry and flags are ignored (shadPS4 runs the ASYNC flag on a worker thread and skips numeric hostnames for the 0x10000 flag, and separates four resolver error codes); all recorded in TechnicalDebt.

tools/pr_overlap.py reports #1119 (structures added at the same spot in GuestSceNet.cpp; no shared exports) and #1158, #1206 (neighbouring TechnicalDebt.md line). No dependency on any of them; happy to rebase once one lands.

Tested

Windows 11, MinGW-w64 GCC 15.2.0 (WinLibs x86_64-ucrt-posix-seh r7), Ninja, based on 6c48ace (rebased to df16c4c before pushing).

• ctest -R guest_sce_net: passed with the new checks - localhost resolves to 1..10 records with af 2 and a 127.x address, null hostname / null records / empty hostname return EINVAL, .invalid returns RESOLVER_ENODNS and sets the resolver error, a destroyed resolver returns EBADF.
• Linux: not run locally; the changed lookup path is the sibling's, which runs there on every CI push.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes

[oneandonlydean]

PPSA14632 imports sceNetResolverStartNtoaMultipleRecords (#734). Does it stop there on main? With the title ID and the log line this can go in; otherwise I'll close it until a title does.

[hikazey]

Title evidence for this family. sceNetResolverStartNtoaMultipleRecordsEx is the first stop on main 4b6ab6b for five titles:

• four from @SleglJan's run in Four open-source homebrew titles stop at start-up on unresolved imports (sysctl, pthread_set_name_np, isatty, mkstemp, signal sets, Opus decoders) #1578 (PPSA99177, PPSA99505, PPSA99515, PPSA99997);
• EVO-PLAYER PPSA99039 v0.11.0 (released today), relinked with --windows and run on Windows 11: FAIL: unresolved ELF import sT4nBQKUPqM from libSceNet.prx.

These titles import the Ex variant, not the one this PR implements, but the layout is the same. EVO-PLAYER's source (tools/native-app/stubs/evo_dns.c, GPL) declares

int sceNetResolverStartNtoaMultipleRecordsEx(int rid, const char *hostname, void *info, int timeout, int retry, int flags);

and reads the result as "SceNetResolverInfoEx, as SharpProspero lays it out": ten 32-byte records (16-byte address union, int family at +16, 12 reserved), the record count at 320 and the IPv4 count at 324, 384 bytes in all. That's this PR's NetResolverRecords. It calls it with timeout, retry and flags all 0, clears 384 bytes, puts a canary after them and checks it, and falls back to sceNetResolverStartNtoa if the call fails or the result doesn't parse.

Would you like to add Ex here, with the same body and layout? Or should it be a separate pull request that depends on this one? I can do the follow-up and check it with EVO-PLAYER, which should then get past the resolver to its next stop. Either way, this PR needs a rebase first.

AI-assisted: yes (Claude Code).

[LeandroLP23]

I have sceNetResolverStartNtoaMultipleRecordsEx ready as a separate PR: same 384-byte layout, the lookup shared with sceNetResolverStartNtoa through a lookup_ipv4 helper that this PR's non-Ex call could reuse. With it PS5VR (PPSA99177) gets past sT4nBQKUPqM on Windows and stops at sceVideoOutGetResolutionStatus (#1714). I'll open it once its fork CI finishes, in the next few minutes, so @KSWORK2001 doesn't need to add it here.

[MarcZX10]

The latest runtime evidence in #1578 is for sceNetResolverStartNtoaMultipleRecordsEx, which is a distinct NID from the non-Ex export this PR implements. The earlier maintainer question about whether PPSA14632 stops on this exact non-Ex import (title ID plus the unresolved-import log line) still has no answer in this PR, so the new Ex evidence does not settle this PR’s title relevance. Please add that exact evidence before treating the change as a current compatibility blocker. If continuing, this head c88e9af is 558 commits behind current main 0447793, is marked dirty, and currently has no checks; rebase and rerun upstream Build/Conventions on the final head.

[LeandroLP23]

Opened as #1838.

[github-actions]

Progress report (f145139 → 60f5be8)

📈 System libraries: 84.79% (+0.03%, +1 implemented functions)

✅ 1 implemented

Library	Name
libSceNet	sceNetResolverStartNtoaMultipleRecords

[oneandonlydean]

Closing: no title is shown stopping at sceNetResolverStartNtoaMultipleRecords on main. The titles in #1578 stop at the Ex variant, which #1838 now implements. Reopen when the non-Ex call is a title's next stop on main, with the log line.