bob@rancor.UUCP (Bob Willcox) (05/14/91)
I have Desqview 2.32 (and QEMM-386 5.12) running on a 386sx with 8MB of
memory that is giving me the error message "Insufficient room for
shared memory" whenever I attempt to open the third window that
specifies Ralf Brown's DVKPOLL.SHR in the shared program pathname
field. I have been unable to locate any reference to either this error
message or how one might go about increasing the ammount of shared
memory that is available.
Any help/ideas on this would be greatly appreciated. Post or email.
Thanks,
--
Bob Willcox ...!{rutgers|ames}!cs.utexas.edu!romp!rancor!bob
Phone: 512 258-4224Ralf.Brown@B.GP.CS.CMU.EDU (05/14/91)
In article <308@rancor.UUCP>, bob@rancor.UUCP (Bob Willcox) wrote: }I have Desqview 2.32 (and QEMM-386 5.12) running on a 386sx with 8MB of }memory that is giving me the error message "Insufficient room for }shared memory" whenever I attempt to open the third window that }specifies Ralf Brown's DVKPOLL.SHR in the shared program pathname }field. I have been unable to locate any reference to either this error }message or how one might go about increasing the ammount of shared }memory that is available. Shared memory, as its name implies, is visible by all loaded programs, even if those programs were loaded in backfilled EMS memory such that only some of the programs are mapped into memory at any given time. In order for shared memory to be shared, DV must "tack down" that memory, which reduces the maximum window size. If you've already loaded a program whose window size is set to the maximum possible, DV won't be able to steal any memory to tack down, resulting in the above error message. There are a number of ways to circumvent the message: 1. run a smaller first window 2. with DV 2.26+, specify /MS:n on the DV commandline to reserve n K for shared memory 3. don't use DVKPOLL. DV already has the same capability built in, but Quarterdeck doesn't let you get at it with Change a Program. How to curb keyboard polling without additional programs: The word at offset 175h in the .DVP file specifies how many times the program is allowed to poll the keyboard in one clock tick before DV will suspend it and switch to the next task. This value is normally zero, meaning DV will never switch early, no matter how often the program polls. If you patch the two bytes to 01 00, you get the same result as with DVKPOLL. Most programs seem to work best with values between 4 and 9. If you use DEBUG to patch the file, remember that it loads the file starting at offset 100h, so you want to patch the two bytes at 275h and 276h. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/53 BITnet: RALF%CS.CMU.EDU@CARNEGIE AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers
Andrew Deckowitz <U09368@uicvm.uic.edu> (05/14/91)
In article <308@rancor.UUCP>, bob@rancor.UUCP (Bob Willcox) says: >... >specifies Ralf Brown's DVKPOLL.SHR in the shared program pathname >... >Thanks, >-- >Bob Willcox ...!{rutgers|ames}!cs.utexas.edu!romp!rancor!bob >Phone: 512 258-4224 Please tell us more about this utility. What does it do? Where can we get it? Andrew Deckowitz, U09368@uicvm The Crystal Wind is the Storm, and the Storm is Data, and the Data is Life -- The Player's Litany from _The Long Run_ by D.K. Moran
bob@rancor.UUCP (Bob Willcox) (05/15/91)
In article <91134.162236U09368@uicvm.uic.edu> U09368@uicvm.uic.edu (Andrew Deckowitz) writes: >In article <308@rancor.UUCP>, bob@rancor.UUCP (Bob Willcox) says: >>... >>specifies Ralf Brown's DVKPOLL.SHR in the shared program pathname >>... >Please tell us more about this utility. What does it do? Where can we get it? > I got it from wuarchive.wustl.edu (./mirrors/msdos/desqview/dvkpoll.arc). As for what it does...here is its dvkpoll.doc file: ---------------------------- cut here ----------------------------- This is a shared program which reduces the amount of CPU time used by programs which poll the keyboard when waiting for input. Simply add DVKPOLL.SHR to the "Shared Program Pathname" entry on the "Change Program" advanced options screen, and your other programs will speed up. You will probably also want to make sure that INT 16 is in the range of interrupts indicated on the advanced options screen, though the nature of shared programs may make this unnecessary. How it works: The shared program installs a small TSR when the window is opened, and deinstalls the TSR when the window is closed. This TSR intercepts the polling call, and if no keystroke is available, gives up the rest of the current timeslice to other programs. DVKPOLL is hereby released to the public domain. Ralf Brown FIDO: 1:129/31 ARPA: ralf@cs.cmu.edu ---------------------------- cut here ----------------------------- I really don't know any more about it. It does seem to make a significant difference in overall performance and feel of the system when using it though. Unfortunately, I have run into this insufficient shared memory error which limits how many windows I can run that use it, and I have noticed problems with two different programs when using it (Pathminder+ and ArcMaster). -- Bob Willcox ...!{rutgers|ames}!cs.utexas.edu!romp!rancor!bob Phone: 512 258-4224
valley@gsbsun.uchicago.edu (Doug Dougherty) (05/19/91)
Ralf.Brown@B.GP.CS.CMU.EDU writes: >How to curb keyboard polling without additional programs: >The word at offset 175h in the .DVP file specifies how many times the >program is allowed to poll the keyboard in one clock tick before DV will >suspend it and switch to the next task. This value is normally zero, >meaning DV will never switch early, no matter how often the program polls. >If you patch the two bytes to 01 00, you get the same result as with >DVKPOLL. Most programs seem to work best with values between 4 and 9. >If you use DEBUG to patch the file, remember that it loads the file >starting at offset 100h, so you want to patch the two bytes at 275h and >276h. How does patching that word (which, I assume, is equivalent to using DVKPOLL) compare to using TAME? -- (Another fine mess brought to you by valley@gsbsun.uchicago.edu)
ralf+@cs.cmu.edu (Ralf Brown) (05/19/91)
In article <1991May18.170538.14139@midway.uchicago.edu> valley@gsbsun.uchicago.edu (Doug Dougherty) writes: }How does patching that word (which, I assume, is equivalent to using }DVKPOLL) compare to using TAME? Setting that word to N is essentially the same as TAME /Freq:N,N /boost:0,0 plus whatever switches turn off everything else in TAME (INT 28, serial, parallel checking, etc). -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/53 BITnet: RALF%CS.CMU.EDU@CARNEGIE AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers
bob@rancor.UUCP (Bob Willcox) (05/19/91)
In article <13102@pt.cs.cmu.edu> ralf+@cs.cmu.edu (Ralf Brown) writes: >Setting that word to N is essentially the same as TAME /Freq:N,N /boost:0,0 >plus whatever switches turn off everything else in TAME (INT 28, serial, >parallel checking, etc). Okay, now you've piqued my curosity. What is TAME and where would one find it? -- Bob Willcox ...!{rutgers|ames}!cs.utexas.edu!romp!rancor!bob Phone: 512 258-4224
w8sdz@rigel.acs.oakland.edu (Keith Petersen) (05/21/91)
In article <310@rancor.UUCP> bob@rancor.UUCP (Bob Willcox) writes: >In article <13102@pt.cs.cmu.edu> ralf+@cs.cmu.edu (Ralf Brown) writes: >>Setting that word to N is essentially the same as TAME /Freq:N,N /boost:0,0 >>plus whatever switches turn off everything else in TAME (INT 28, serial, >>parallel checking, etc). > >Okay, now you've piqued my curosity. What is TAME and where >would one find it? WSMR-SIMTEL20.ARMY.MIL [192.88.110.20] Directory PD1:<MSDOS.DESQVIEW> Filename Type Length Date Description ============================================== TAME261.ZIP B 75649 910407 Speed up pgm execution in DesqView/VM386/other Excerpt from the docs: Tame works by monitoring what a program does. When the program is not doing anything except polling the keyboard, Tame notices. After enough polls, Tame can see that the program is wasting time and tells the multi-tasker to move on to the next task. Eventually, the multi-tasker will come back to this task. At this point, Tame will be less patient than before, and switch tasks as soon as the program starts polling again. When the program does something active, like processing keyboard input, performing disk I/O or changing the video screen, Tame takes note that it is active, and boosts its priority for about a tenth of a second. This will prevent Tame from causing a task switch during that period of time. Keith -- Keith Petersen Maintainer of the MSDOS, MISC and CP/M archives at SIMTEL20 [192.88.110.20] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil or w8sdz@vela.acs.oakland.edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND
ralf+@cs.cmu.edu (Ralf Brown) (05/21/91)
In article <310@rancor.UUCP> bob@rancor.UUCP (Bob Willcox) writes: }Okay, now you've piqued my curosity. What is TAME and where }would one find it? It's a shareware TSR which gives up a program's time slices when it detects that the program is merely polling (keyboard/time/serial/parallel) rather than doing any useful work. You can find it on SIMTEL20 in PD1:<MSDOS.DESQVIEW>, on any Fidonet BBS belonging to the DVnet distribution system, and elsewhere. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/53 BITnet: RALF%CS.CMU.EDU@CARNEGIE AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers