CBBS(R) 4.0.3b 09/22/90 00:18:08 Y/N: want CBBS "1st time user" info?^U ?^U ?^U ?n;ward;christensen;odraw;;fullc;piss Logging name to disk... You are caller 217053; next msg =43964; 378 active msgs. Prev. call 09/20/90 @ 22:45, next msg was 43960 Recording logon for next time... Use FULL? to check assignments ?^U ?xxxxx "Mine" command checking for msgs TO you, ^ >Function:?dir c:log;dir c:killed;dir summary;type-20 log,ward c;or;*;short LOG. 11 KILLED. 11 SUMMARY. 25 09/20/90,22:45:37,217039,2,WARD CHRISTENSEN,, E#43960,6 09/20/90,22:57:13,217040,2,JAMES SCHMIDT,,0 09/20/90,23:03:44,217041,9,JIM POLOUS,, E#43961,9 09/20/90,23:38:49,217042,2,ARLYNN EFTEFIELD,DES PLAINES/ IL,10 09/21/90,02:12:00,217043,2,ERIC BOHLMAN,, E#43962,17 09/21/90,05:34:13,217044,2,PETE JONES,,1 09/21/90,06:19:42,217045,1,MICHAEL MCDANIEL,,2 09/21/90,08:18:59,217046,1,KEN STOX,, E#43963,6 09/21/90,08:48:23,217047,2,MARTY LINGG,,1 09/21/90,09:00:22,217048,2,CLIFF SHARP,,2 09/21/90,14:51:56,217049,1,G G,, 09/21/90,17:38:11,217050,2,DAVID SPECTOR,chicago/ illinois, 09/21/90,18:48:21,217051,3,JIM COLLING,,1 09/21/90,19:24:38,217052,2,CHARLIE KESTNER,,3 09/22/90,00:18:12,217053,2,WARD CHRISTENSEN,, 43960 09/20/90 WARD CHRISTENSEN => ALL: "DOS MEM ALLOCATION?" 43961 09/20/90 JIM POLOUS => ANDREW DECKOWITZ/ALL: "NETWARE 3.0 DRIVERS" 43962 09/21/90 ERIC BOHLMAN => WARD CHRISTENSEN: "R/DOS MEM ALLOCATION?" 43963 09/21/90 KEN STOX => JAIME COBB: "GREETINGS" ---- End of summary ---- Retrieving flagged msgs: C skips, K aborts. Msg 43960 is 08 line(s) on 09/20/90 from WARD CHRISTENSEN to ALL re: DOS MEM ALLOCATION? I saw a strange situation today: >300K free, yet a 256K program wouldn't load! Turned out via PMAP memory mapper, that there was a "hole". Turns out a menuing program of sorts, loaded a TSR, then exited. The hole is where it was, yet there was no large-enough chunk. Does DOS memory have a "bit" saying whether memory is free or something? I didn't know it could have "holes". Will DOS prevent things from clobbering the TSR? Thanks! Msg 43961 is 10 line(s) on 09/20/90 from JIM POLOUS to ANDREW DECKOWITZ/ALL re: NETWARE 3.0 DRIVERS The Netware 3.01 drivers are available for "free" from Netwire on CompuServe. These work with Windows 3.0.... Note that while Windows claimes compatibility with Netware, there is a small incompatibility: Running too many things in Windows somehow causes the file server to use up more memory for tracking purposes. Since the three dynamic memory pools are fixed and automatically configured depending on the amount of memory in the system when it was NETGEN'd. Multiple programs run through windows can cause the server to lock up. Netware 386 is immune to this problem because of it's ability to dynamically allocate and deallocate memory at will Msg 43962 is 25 line(s) on 09/21/90 from ERIC BOHLMAN to WARD CHRISTENSEN re: R/DOS MEM ALLOCATION? The problem you ran into is known as "memory fragmentation." When you unload a TSR, DOS can't just move everything in memory to fill up the hole because that would invalidate any pointers in the stuff that's being moved (no way to do segment fixups after a program has been loaded). If the TSR were the last thing in memory (i.e. you unloaded it from a "virgin" command prompt), there would be no hole because the memory being freed up would be immediately adjacent to the main free space and DOS is smart enough to combine them into one big block. The other major way to cause fragmentation is to load a TSR from within something else (an application with a "shell to DOS" command). In this case the TSR will load after the application. When you leave the application, the space it took will be freed but the TSR will still be sitting at the end of that space, leaving you with non-contiguous free blocks on either side of it. About the only way an operating system can solve this problem (other than by limiting you to COM files) is to use hardware page-mode memory management to do the allocation--just twiddle the page registers and the non-contiguous blocks suddenly become contiguous. That could be done on a 386, but it wouldn't be DOS-compatible--Hmmm, there just might be a way to do it transparently, though there might be some memory loss because the 386 has a 4K page granularity, whereas DOS memory blocks have a 16-byte granularity. On second thought, it wouldn't work--though you could create contiguous blocks of PHYSICAL memory, you wouldn't be able to change the situation with regards to LOGICAL memory, which is what DOS wants to see. Msg 43963 is 04 line(s) on 09/21/90 from KEN STOX to JAIME COBB re: GREETINGS Jaime, Good to see you out and about the BBS community. I hope you find it as interesting pursuit as I have the last ten years. Best of luck in your pursuits! No dup. chars. >Function:?