One should be aware that Norman Sandbox is a fully simulated computer.

When a file is scanned the first time after the NVC scan engine is initialized, a simulated computer is actually booted  in the computer's memory. This booting process starts off with a simulated ROM BIOS, which reads the boot sectors from the simulated hard drives and executes them; which load the OS system files, which loads the command shell.
This clean booted image is taken a snapshot of, to use for later scans.

There is a FAT on this simulated drive, along with directories and files. Once this is up, the file that is scanned is copied inside the simulated hard drive, and executed. The file may now do whatever it wants. It can infect files. It can delete files. It can copy itself over networks. It can connect to an IRC server. It can send mails. It can set up a listening port.

Every action it makes is registered by Norman's program, because it is effectively our emulator that does the actions based on the code in the file.

No code is executed on the real CPU except for the NVC emulator engine;  even the hardware in the simulated PC is emulated.

In other "sandbox" solutions, you will see that only parts of the environment is virtualized - the bulk of the code runs on real CPU, and when this code tries to f.ex. talk to Windows, it will be fed responses that seem to come from the OS, but instead come from some other code piece which may or may not be running on real CPU. This is in our view an insecure way of doing things; in addition it does not give the flexibility we want.

Take f.ex. a specially doctored executable, which has some kind of overflow or strange code combination designed to break out of limited environments. If this was running on real CPU, the code could have access to real memory and real CPU registers, thus in theory be able to break out of or crash the "sandbox".
However, if such an executable is running on a fully emulated CPU, the code could certainly crash the simulated computer; send the CPU into a loop; delete all files; but all this would happen to the simulated computer. The emulator engine would just say - "Hmm the simulated PC is not responding. Shutting down simulation." - or - if the code is really wacky - "This opcode or call sequence is not supported. Shutting down simulation."

The issue is not to monitor and stop possibly harmful actions in runtime, as is the case for many.
The issue is to figure out what the program would have done if it had been allowed to run wild on an unprotected machine, in an unprotected network.
Even if NVC is running on a Netware server, on Linux, OS/2 or DOS.