From: "smile773" Newsgroups: comp.os.msdos.djgpp References: <200006181709 DOT UAA14112 AT mailgw1 DOT netvision DOT net DOT il> Subject: Re: __go32__dpmi ? Lines: 25 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: Date: Sun, 18 Jun 2000 18:25:27 GMT NNTP-Posting-Host: 12.72.4.223 X-Complaints-To: abuse AT worldnet DOT att DOT net X-Trace: bgtnsc06-news.ops.worldnet.att.net 961352727 12.72.4.223 (Sun, 18 Jun 2000 18:25:27 GMT) NNTP-Posting-Date: Sun, 18 Jun 2000 18:25:27 GMT Organization: AT&T Worldnet To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Since the "old handler " usually in bios is also relevant Is it possible to reflash the bios to include some gnu friendly exception. Eli Zaretskii wrote in message news:200006181709 DOT UAA14112 AT mailgw1 DOT netvision DOT net DOT il... > > From: "smile773" > > Newsgroups: comp.os.msdos.djgpp > > Date: Sun, 18 Jun 2000 15:15:39 GMT > > > > > > I should warn you up front that real-mode callbacks have some downsides; > > > for starters, they are non-reentrant. > > ********************************************************************* > > Does non-reentrant mean that the attributes bytes can be swapped only as > > they > > are caught and not after the application completes ? > > No, it means that if you are in the middle of handling an Int 10h > function call, and someone calls another function of Int 10h, the > second call will not end up in your handler, it will be routed to the > old handler (in the BIOS, usually).