Writing embedded systems applications requires special efforts on the part of the programmer, because of how these applications differ from non-embedded applications. First, an embedded program that crashes can cause damage or injury, while a non-embedded program (e.g. a word processor) may cause only a certain amount of user frustration. Embedded systems must handle the conceivable problems in stride and effectively recover from the inconceivable without help from users.Second, there are several special aspects to embedded code. Many embedded systems run standalone programs without the support of complete operating systems such as MS-DOS, so these programs must take control of relevant interrupt vectors (including error conditions such as divide by 0 and the Non-Maskable Interrupt). For these standalone programs, both the hardware and the program may require setup code. Programs compiled to run under MS-DOS contain startup and termination code to accept control from and return control to the operating system. Standard library functions that don't access MS-DOS under normal conditions may contain error-handling code that does access MS-DOS or that would terminate the program in an unacceptable fashion within an embedded system. In addition, some programs may attempt to access non-disk MS-DOS functions, such as those used to modify interrupt vectors. If you port such programs to an embedded system, you must provide code to perform equivalent functions within the embedded system operating environment. An embedded program must start (or restart) in a known state. Since the program cannot obtain state information from a command line, it must find initial state data in EPROM.