mirror of
https://github.com/opsxcq/mirror-textfiles.com.git
synced 2025-08-21 08:51:27 +02:00
112 lines
4.9 KiB
Plaintext
112 lines
4.9 KiB
Plaintext
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:? |