Services API: Difference between revisions
No edit summary |
mNo edit summary |
||
Line 1: | Line 1: | ||
Nintendo provides application developers with an API, which communicate with certain services. Services, in this sense, are system processes running in the background which wait for incoming requests. When a process wants to communicate with a service, it first needs to get a handle to the named service, and then it can communicate with the service via interprocess communication. Each service has a name up to 8 characters, for example "nim:u". | Nintendo provides application developers with an API, which communicate with certain services. Services, in this sense, are system processes running in the background which wait for incoming requests. When a process wants to communicate with a service, it first needs to get a handle to the named service, and then it can communicate with the service via interprocess communication. Each service has a name up to 8 characters, for example "nim:u". | ||
Handles for services are retrieved from the service manager port, "srv:". Services are an abstraction of ports, they operate the same way except regular ports can have their handles retrieved directly from a SVC. | Handles for services are retrieved from the [[Services|service manager port]], "srv:". Services are an abstraction of ports, they operate the same way except regular ports can have their handles retrieved directly from a SVC. | ||
For a description of how commands and arguments are passed to services, see [[IPC Command Structure]]. | For a description of how commands and arguments are passed to services, see [[IPC Command Structure]]. |