Under many DPMI hosts, interrupts will always remain enabled in protected mode (i.e. the interrupt flag will be set at all times) to allow preemptive multitasking. Such hosts will maintain a virtual interrupt state for each virtual machine, trapping the execution of instructions that ordinarily affect the hardware interrupt flag and adjusting the client's virtual interrupt flag accordingly. When the virtual interrupt flag is cleared by the client's execution of CLI or call to DPMI function Int 31H 0900H, the program will not receive any hardware interrupts until it sets the flag again with STI or calls Function 0901H. DPMI clients should not use the PUSHF instruction to examine their interrupt status. This is because PUSHF pushes the real processor flags onto the stack, which do not reflect the state of the client's virtual interrupt flag. Similarly, clients cannot use IRET(D) or POPF to alter the interrupt flag, because these instructions access the physical interrupt flag and are ignored by the CPU due to the client's privilege level.

Example: The following source code demonstrates how a client would disable virtual interrupts prior to entry to an interrupt-critical section of code, then restore the virtual interrupt flag to its previous state at the end of the critical section:


	mov	ax,0900h		; get previous virtual interrupt
	int	31h			; flag and disable interrupts
	push	ax			; save value 0900H or 0901H
	.
	.				; interrupt-critical code goes here
	.
	pop	ax
	int	31h			; restore previous interrupt flag

If the client already knows (or does not care about) the previous state of the virtual interrupt flag, it can use CLI and STI instead of DPMI functions 0900H and 0901H. The programmer should assume that the execution of either of these instructions will be slow.