Message-ID: <00ee01c128ee$8fa88cc0$d308e289@mpaul> From: "Matthias Paul" To: References: <2 DOT 07b7 DOT C71Q DOT GI8CSR AT belous DOT munic DOT msk DOT su> Subject: Re: MEM bug Date: Sun, 19 Aug 2001 01:44:52 +0200 Organization: University of Technology, RWTH Aachen, Germany MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id QAA09256 Reply-To: opendos AT delorie DOT com On 2001-08-17, Arkady V.Belousov wrote: > B001:0000 \MMXXXX0 0h, 0 DEVICE = installed device driver > B138:0000 B1380 E0h, 224 Data > B146:0000 B1460 15B0h, 5 552 Data > B147:0000 DOS FFF4FCB0h, 294 245 552 System > B147:0048 NUL DEVICE = installed device driver > B147:00CC DOS 10Fh, 271 HANDLES=, FCBS= 5 total blocks > _____________________________________________________________________ > O/~\ /~\O > > This result I get under MS-DOS with QEMM. To "gladden" you I may add: > MS-DOS MEM also mistakes. So much for compatibility... ;-) But what has happened with the output above B147h:00CCh? Does MEM /A skip this? And what happens when you use QEMM under DR-DOS? Which version of QEMM and MS-DOS? Is this dependent on a specific configuration or does it happen all the time? I would be particularly interested in the contents of the MCB at B147h:0000h In any way it seems something very strange has happened to the MCB chain, and possibly the next few hundred bytes. Can you send me a DEBUG memory dump of the following next kilobyte via private mail? Thanks. Greetings, Matthias -- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org