With disk based schemes, software often reads from specific sectors on a disk to determine the disk's validity. When you perform a disk format, the disk is formatted with specific sector sizes. Once the sector size changes, DOS cannot recognize it, thinking that it is a bad sector. Since this looks like a bad sector, a simple DISKCOPY will not work in copying such disks.
Interrupt 13h (the assembly mnemonic is INT 13) was commonly used to handle such copy protections. It is now very rare to encounter the once famed INT 13h copy protection method nowadays since it was quite easy to defeat. Any professional commercial software (including yours) will often use their own custom based disk I/O routines. This involves intimate access to I/O ports using IN and OUT instructions. It is probable that the I/O functions might be called from a "CALL" instruction.
Another disk based scheme used to denote legality of software is used during the installation process of the software. With certain programs, when you install it, it copies the files into the hard drive. But it also sets a specific sector in the hard drive so that the program can recognize it. This disk-based copy protection is almost completely out of the software industry.
However, a more difficult copy protection scheme exists that may sometimes prove to be even more difficult to crack. These schemes are commonly known as the doc checks in which the user must have a copy of the manual to bypass the protection. With programs compiled as true assembly (you can call them "normal" programs), these protections are not too bad to trace through. With programs that run scripts, this can he a real chore however. It is like running a program within a program.
As if these copy protection schemes weren't enough, software companies have also added trace inhibition schemes to their code. This means that it is much time consuming for someone to try and trace through your code. On the other hand if someone knows how these things work, it should not be too much of a problem for him. Run-time compression / decompression and encryption / decryption of files also make changes to the program difficult. In this case, the loader sure comes in handy. Also, when the data within the file changes due to overlays, loaders are also good to use.