Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!lgc.com!mips.mitek.com!hp835!gtoye From: gtoye@hp835.mitek.com (Gene Toye) Newsgroups: comp.sys.ibm.pc.misc Subject: Re: Dos 5 - strange result from mem /c command Message-ID: Date: 20 Jun 91 13:52:08 GMT References: <3710@travis.csd.harris.com> Sender: news@mips.mitek.com (USENET Administrator) Distribution: na Organization: OpenConnect Systems Lines: 25 In <3710@travis.csd.harris.com> leoh@hardy.hdw.csd.harris.com (Leo Hinds) writes: >I was messing around with my recently installed dos5 and did a "mem /c" ... >interesting results ... a portion of my path statement is using 13.7k !! >===> p;c:\net 14016 ( 13.7K) 36C0 <== mouse-supposedly >Anyone seen this? ... any thoughts? ... looks like some kind of data >structure/array has been corrupted ... I wounder what else was/will be affected? I suspect you have a mouse driver that deallocates its environment memory block. Several guides on TSR development recommend this as a way to reduce TSR memory requirements, since most TSRs don't need an environment. For this, it works well (I've used the technique myself in some TSRs I wrote). It does have the side effect of rendering memory utilities unable to display the program name, since it is kept in the same memory block as the environment. Anybody have any other ideas? >leoh@hdw.csd.harris.com Leo Hinds (305)973-5229 >Gfx ... gfx ... :-) whfg orpnhfr V "ebg"grq zl fvtangher svyr lbh guvax V nz n >creireg ?!!!!!!? ... znlor arkg gvzr -- Gene Toye, Software Engineer gtoye@hp835.mitek.com OpenConnect Systems, 2033 Chennault Drive, Carrollton, TX 75006 214/308-0454 DISCLAIMER: My employer had no idea I was going to say that.