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.
A null reason, an unblock with no block left and an eye-to-eye query for a user other than the logged-in one now go through NotImplemented_nid_no_patch instead of throwing invented errors, since the console's answers to them are not measured.
AnyPS5 runs the title from its folder as /app0 and models none of these:
libSceDiscId and sceKernelHwGetBdDriveInfo throw, every libSceUsbStorage
device call throws, sceShellCoreUtilDeclareBeginOfExternalStorageAppMove
throws, and sceSystemServiceAddLocalProcessForPs2Emu throws, so the
running process is always the title's own PS5 executable.
sceSystemStateMgrIsBdDriveReady, sceShellCoreUtilIsUsbMassStorageMounted
and sceShellCoreUtilIsExternalStorageAppMoveInProgress return false, and
sceLncUtilIsPs2Emu writes false. A null output to sceLncUtilIsPs2Emu
throws, since no sceLncUtil function in the tree answers one.
AnyPS5 has no shell UI: sceSystemServiceGetStatus never reports a system
UI overlay or background execution, and the host has no auto power-off
timer. The shell UI therefore never takes the foreground, overlays the
impose screen, runs a screen saver or shuts down, and those queries
return false.
libSceHmd detects no headset, so there is no PS VR social screen and the
logged-in user's eye-to-eye distance was never adjusted. Another user ID
throws, since the console's error for it is not measured.
The sceSystemService twins forward to their sceShellCoreUtil and
sceLncUtil targets. sceSystemServiceIsEyeToEyeDistanceAdjusted returns
SYSTEM_SERVICE_ERROR_PARAMETER for a null output before forwarding, as
its neighbours do, and the sceShellCoreUtil forms throw for one.
Dean