Forward the suspend, resume, kill, exception and ready-for-suspend wrappers to their LncUtil exports, as the debt records. The targets keep their documented throws, so behaviour is unchanged.
The branch defined SHELL_CORE_UTIL_ERROR_NULL_OUTPUT (0x80e30003) and
LNC_UTIL_ERROR_NULL_OUTPUT (0x80940005), while #10801 on main already
names the same values SHELL_CORE_UTIL_ERROR_INVALID_ARGUMENT and
LNC_UTIL_ERROR_INVALID_ARGUMENT. The two duplicates are gone and their
uses in the status exports and their tests take main's names. The
values, and so the behaviour, are unchanged.
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]>
sceSystemServiceLoadExec of a host executable ends this process after it
starts the target, so with ANYPS5_LOG_FILE set the target would inherit
the pipes of the log copy with no reader left. Call LogFileRelease before
the launch (after the existing restore of the kept standard error on
POSIX) so the target inherits the original streams.
LoadExec replaces the running process with the target executable on
Windows, Linux and macOS. With ANYPS5_LOG_FILE set the standard output and
error are the pipes the log copy reads, and its threads end with this
process, so the new executable would write into pipes nobody reads and a
POSIX one would be killed by SIGPIPE. Before the replacement starts, call
LogFileRelease, which empties the pipes into the file and puts the
original streams back on descriptors 1 and 2 (the standard handles on
Windows) when they still are the pipes. The new executable starts its own
copy from the inherited variable and appends to the same file.
With -DBUILD_TESTING=ON -DANYPS5_RELINKER_CLI=OFF the generate step
failed: exec_arguments, loadexec_arguments, guest_timed_join_import_*,
guest_runtime_lifecycle and agc_driver_guest_memory_lifetime_converted
name the relinker target, which core/relinker defines only when the
option is on. The option is now declared in the root CMakeLists.txt,
before core/libs, and those tests are registered only with the command
line, as core/relinker already does for its own command line tests.
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.
The status queries answer from what the tree already reports for these
services: libSceRemoteplay's connection status is DISCONNECT,
libSceSharePlay has neither a host nor a visitor, and
libSceGameLiveStreaming's status has isOnAir false. The ShellCore
setters that would change these answers throw.
sceSystemServiceGetRemoteplayStatus and
sceSystemServiceIsGameLiveStreamingOnAir forward to their
sceShellCoreUtil twins. sceSystemServiceGetRemoteplayStatus returns
SYSTEM_SERVICE_ERROR_PARAMETER for a null output before forwarding, as
sceSystemServiceGetNoticeScreenSkipFlag does. No sceShellCoreUtil
function in the tree answers a null output, so the sceShellCoreUtil
forms throw for one.
AnyPS5 never suspends the running title: sceSystemServiceGetStatus never
reports background execution and sceSystemServiceReceiveEvent has no
event to deliver. Enabling or disabling the suspend notification, and
blocking or unblocking a suspend, therefore change nothing and return
success. The sceSystemService notification calls forward to their
sceLncUtil twins.
A null reason and an unblock with no block left throw, since the
console's answers to them are not measured.
The new guest_system_service_status tests check each answer.
Dean