As @csprabala so helpfully pointed in his linked answered thread:
OS Container (or System containers) and Application Container are both first and foremost containers, and that means they operate in a similar fashion by sharing the kernel and including everything they need in their "container image" respectively.
The difference mainly comes when OS containers will almost exclusively use the guest OS kernel directly using their own kernel API function (described here) like a VM would, but unlike a VM - which usually runs above a hypervisor (like Oracle VirtualBox or VMWare ESXi) and has hard disks represented as .vmdk
files, System containers run just like any other container on the host OS as a segregated set of processes.
On the contrary, Application containers that use Docker, cri-o or contained (all linked here) still rely on some sort of underlying container engine to serve as the medium to the guest os and run as regular processes on it (unless of different architecture then emulation is used) and that's why if you'd run docker as a service on a Linux distro and lets say a Java application on top of it and you'd check running processes with top
you'd see the java process running directly on the Host OS but of course separated with namespaces, PID trees (or Process Trees) and cgroups.
the implementation has some resemblance but is quite different in usage and low level works.