AnyPS5 has no Remote Play or Share Play CPU budget service, and the
console's acquire and release results, a repeated acquire and a release
without an acquire are unmeasured, so the six exports throw on every call
as they do on main instead of reporting a made-up hold.
The guest test now asserts that all six calls throw, and the debt entry
moves to Unknown function info with the unresolved contract.
The absent-features entry said AnyPS5 exposes no USB mass storage and
that every libSceUsbStorage device call throws. Since #11046 and #11051,
libSceUsbStorage lists host volumes as devices when
APS5_USB_STORAGE_PASSTHROUGH is set (unset, the list is empty), while
sceShellCoreUtilIsUsbMassStorageMounted still answers false for every
index. The entry now says so, as a known gap: no source names what the
call returns for a passthrough device. No behaviour changes.
main's #10706 requires each export to be declared once, in its
library's public header. GuestSystemServiceStatus.cpp now includes
prx/libSceSystemService/include/SystemService.hpp instead of declaring
25 of its exports in its own extern "C" lines, as jotitadev suggested
in review.
Co-authored-by: jotitadev <[email protected]>
Only the Linux environment source has run; the Windows and macOS sources are
not built or run, and a second copy of the inline resolver in another DLL can
print its own fallback line.
Bare pt and es, the English variants, bare zh and the Latin American and
Portuguese-speaking regions are decisions, and languages the console has no
entry for fall back to English (United States) instead of a neighbour.
The mapping from a host locale to a console language is a choice of the
project, not something measured on a console; what a title does with the
resulting number is unmeasured as well.
The LncUtil collapsed dispatch entry, written by d4f2911b74 and
50c8103af2 (#9137), said its protected service implementations remain
unchanged. Of the functions whose signatures d4f2911b74 restored,
sceSystemServiceGetAppId answers for the running title since
7c83407e11 (#8354) and sceLncUtilGetAppId since 695041093b (#10801).
Only the status, GPU-crash, dialog-activation, shared-memory,
continue and VSH-ready calls still throw.
sceSystemServiceEnableSuspendConfirmationDialog and
sceSystemServiceDisableSuspendConfirmationDialog set an atomic flag
that sceShellCoreUtilGetSuspendConfirmationDialogFlag reads back for
the running title. The flag starts enabled. Another app ID still
throws NotImplemented_nid_no_patch because the console's answer is
unknown. AnyPS5 has no shell to suspend the title and show the
dialog, so the debt document lists the flag under Silent stubs.
sceSystemServiceSetGpuLoadEmulationMode and
sceSystemServiceGetGpuLoadEmulationMode, with the sceShellCoreUtil
Set/Get pair and their ByAppId variants, now share one atomic mode
instead of throwing. Modes 0 (off) and 1 (normal) are accepted; the
getter returns the mode itself rather than a result code. The initial
mode is 1. Any other mode, and any app ID other than the running
title, still throws NotImplemented_nid_no_patch because the console's
errors for them are unknown. The host GPU is not throttled, which the
debt document lists under Silent stubs.
The sceSystemServiceUsbStorage* exports jump straight into the USB storage
module, so call the matching libSceUsbStorage export instead of throwing.
RequestMapWSB keeps its marker while its two declarations disagree on the
fourth argument and the output type.
BunnyFl ran firmware 13.42's libSceSystemService.sprx in an emulator and
recorded the checks these calls make before they pass a request on. A
null title ID or one whose length isn't 9 makes sceSystemServiceGetAppId
and sceLncUtilGetAppId return -1 and sceLncUtilIsAppLaunched return
0x80940005. A null output, list, count or user returns 0x80940005 from
the LncUtil and SystemService calls and 0x80e30003 from
sceShellCoreUtilGetUserFocus, before the app ID is looked at, and a null
sceLncUtilLoadExec path returns 0x80940005.
What the module passes on as a request still throws: another
9-character title ID, another app ID, a list capacity of 0 and an empty
sceLncUtilLoadExec path.
sceLncUtilLoadExec takes the same path and null-terminated argument
list, which the SystemService call passes on to it on the console. It
returns sceSystemServiceLoadExec's result: the same parameter errors,
the same refusals for paths it cannot start, and "exit" ends the title
in the same way.
sceLncUtilIsAppSuspended, sceSystemServiceIsAppSuspended and
sceLncUtilIsSpeculativeLaunch write false for the running title's app
ID. The title that calls them is running and has no shell to suspend
it. It was started from the host rather than by sceLncUtilLaunchApp,
so no LncLaunchParam asked for a speculative launch. Another app ID
and a null output still throw.
sceLncUtilGetAppLaunchedUser, sceSystemServiceGetAppLaunchedUser and
sceShellCoreUtilGetUserFocus write the initial user for the running
title's app ID. That is the user sceUserServiceGetInitialUser and
sceUserServiceGetForegroundUser report. Another app ID and a null user
pointer still throw.
sceLncUtilGetAppId and sceLncUtilIsAppLaunched accept the running
title's ID as sceSystemServiceGetAppId does, and
sceLncUtilGetAppIdOfRunningBigApp returns what
sceSystemServiceGetAppIdOfRunningBigApp returns. Both big-app lists
write the running title's app ID as their only entry, because AnyPS5
runs one title. Another title ID, a null pointer and a list capacity of
0 still throw.
BunnyFl measured these cases against firmware 13.42's libSceSystemService
in the PR thread (behaviour only), so they no longer throw:
- sceShellCoreUtilGetRemotePlayStatus, GetSharePlayStatus and
GetGameLiveStreamingStatus return 0x80e30003 for a null output and
write nothing.
- sceSystemServiceGetRemoteplayStatus has no null check of its own: it
forwards, so a null output returns the ShellCoreUtil error, not
SYSTEM_SERVICE_ERROR_PARAMETER.
- sceLncUtilIsPs2Emu returns 0x80940005 for a null output.
- sceLncUtilUnblockAppSuspend with no block left returns
SCE_KERNEL_ERROR_EBUSY and changes nothing, before reading the reason.
A null reason in sceLncUtilBlockAppSuspend, a null reason in an unblock
while a block is held, sceShellCoreUtilGetSocialScreenStatus with a null
output and the service-answered eye-to-eye cases still throw, and the
debt entries say why.
Dean