Message-Id: <200001301957.UAA13909@mail.nordwest.net> Date: Sun, 30 Jan 2000 20:54:55 +0100 From: Jens Luedicke To: djgpp AT delorie DOT com Subject: Returned mail: User unknown X-Mailer: Jens Luedicke's registered AK-Mail 3.1 publicbeta2 [ger] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com The original message was received at Sun, 30 Jan 2000 09:16:00 -0800 from spam-protect AT irs-net DOT com [XXX.XXX.XXX.XXX] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 550 ... User unknown On 30 Jan 2000, Martin Stromberg wrote: > But I wondered what would happen if the processor was in some DOZE > call, an interrupt comes along (I'm assuming that DOZE can be > interrupted) which some code (not necessarily DJGPP code) handles by > invalidating the CS selector and then returns to the DOZE call. What > would happen now (in the DOZE call)? The routines in any OS don't invalidate the CS. When Windows (or any 32-bit OS) is interrupted, the CS is filled from the IDT descriptor or from the value in the TSS. At no point of time can the CS contain garbage. If anything attempted to load garbage into CS, that would immediately cause a GP Fault (which could crash Windows ;-)). So, it is not possible for any program to invalidate CS. If Windows tries to get back to the original process, the retf or iret would itself cause GP Fault. So, there's no way any such thing can take place.