fireman@s.cs.uiuc.edu (12/29/89)
A while back I posted a question about Windows 386. My objective is to multitask DOS applications (Turbo Pascal, a word processor, and the student version of Golden Common Lisp). What's unique about my situation is that this student version of GCL requires 600K to run. In order to run it, I need to decrease the number of files and buffers to 10 each. While in GCL, I can't even use the DOS access function because there isn't enough memory to spawn COMMAND.COM. (I'm using DOS 3.3) From the response I got to my original query, I'm convinced that Desqview 386 is better than Windows 386 (any opinions to the contrary?). My question is, does anyone know if I'm going to be able to run this student version of GCL? Does Desqview (or Windows) require a little bit of overhead in each of it's windows? How much? I can't spare more than a few KB. Assume I have a 386 with 4MB. Also, what is the relationship between QEMM and Desqview 386? Do you use them together? FOR THOSE WHO WANT A CHALLENGE. Actually, this student edition of GCL is split into three separate programs. 1. The LISP interpreter without any editor. This only takes several hundred K, leaving a few hundred K available for running your code. 2. A version with an editor that takes up so much memory that you only have 30K or so to run your code with. 3. A tutorial which takes up a full 600K. Obviously, it's convenient to be able to edit but with only 30K available for running your programs, you often have to quit, load version number 1 and run your program. If you want to do extensive editing, you quit version 2 and go back to version 1. If you want to use the on-line tutorial, you have to quit whatever you're in and enter version 3. *SO*, my real objective is to run all three of these at once as well as my word processor (350K). Does anyone know if Desqview can do the job? Finally, does anyone know of a reference where DESQview 386 is evaluated? Specific dates or issues of magazines would be very much appreciated. Neil
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/29/89)
In article <213400081@s.cs.uiuc.edu> fireman@s.cs.uiuc.edu writes: | Assume I have a 386 with 4MB. | | Also, what is the relationship between QEMM and Desqview 386? Do you use them | together? QEMM uses extended memory as expanded memory, by uses of the 386 memory mapping features. Desqview uses this. When I was doing this QEMM gave you more space per process than real LIM memory, but that was LIM3.2 as I recall, and that statment should be taken as "true for the time in question," and no more. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon
fel@hpcuhb.HP.COM (Skip La Fetra) (12/29/89)
> What's unique about my situation is that this > student version of GCL requires 600K to run. Ouch! This is going to be difficult. I've been able to get better than 530K free (it depends on how many drivers and such you load. I load a lot.) > My question is, > does anyone know if I'm going to be able to run this student version of GCL? > Does Desqview (or Windows) require a little bit of overhead in each of it's > windows? How much? I can't spare more than a few KB. I'm not sure you can get to 600K. The documentation for my version claims that under the best possible situation you can have 610K of program memory (if you have a CGA), 600K (Mono/Hercules), or 535K (EGA/VGA). It's going to be tight. I'd try before you buy. My own configuration claims 531K free (VGA). > Assume I have a 386 with 4MB. I have. (This is also my own configuration) > Also, what is the relationship between QEMM and Desqview 386? Do you use them > together? Normal DesqView + QEMM/386 = DesqView 386 (it's a marketing bundle) > ..., you often have to quit, load version number 1 and run > your program. If you want to do extensive editing, you quit version 2 and go > back to version 1. If you want to use the on-line tutorial, you have to quit > whatever you're in and enter version 3. *SO*, my real objective is to run all > three of these at once as well as my word processor (350K). This is what I use DesqView for. I'd try to run two concurrent sessions of your program (with/without editor) and a third window with your word processor. You should have enough memory to do this with 4Meg. > Does anyone know if Desqview can do the job? I think so. Though I'm concerned about that 600K... > Finally, does anyone know of a reference where DESQview 386 is evaluated? Sorry. No. > Neil - Skip (your mileage may vary. I've already told you most of what I know about DesqView. I love it.)
KRW1%LEHIGH.BITNET@IBM1.CC.Lehigh.EDU (12/30/89)
QEMM-386 alone (about $50) should let you run 600K programs. It's pretty good about freeing up normally unused memory, and it will let you load buffers, and most drivers and resident programs in high memory. I understand there are other packages available with similar functions.
lampi@pnet02.gryphon.com (Michael Lampi) (12/30/89)
> pretty good about freeing up normally unused memory, and it will let
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now, that's what I like to see in an operating system!
Michael Lampi MDL Corporation 213/782-7888 fax 213/782-7927
UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!lampi
INET: lampi@pnet02.gryphon.com
"My opinions are that of my corporation!"frank@hpuamsa.UUCP (Frank Slootweg CRC) (01/03/90)
I only have used DESQview a little bit. I could get 562128 bytes free
in a (full screen) COMMAND.COM DESQview "window".
With Windows/386 I can get 578096 bytes free in a *full screen*
COMMAND.COM "window" ("Windows beats DESview by over 15K!" :-)).
To this you can add the resident size of COMMAND.COM (nearly 4K (I
think) see "map[mem]", "mi" etc.) if you start your application directly
from a PIF file (instead of *via* COMMAND.COM).
The Windows/386 test was done on a *2* MB HP Vectra QS/16 with :
- 636 K (*not* 640) of Base/Convential memory (our (HP) machines have a
4K extended BIOS)
- BUFFERS=8
- FILES=20
- *no* drivers
- *no* TSRs
- WIN.INI: windowmemsize=420 (or down to 385)
- WIN.INI: emmsize=0 (because windowmemsize!=640)
The DESQview test was done on the same system (perhaps with 640 K Base
Memory). I think that DESQview *claimed* that it could give more but it
did not. The numbers from the Memory Status command (*before* opening the
"window") were (last two rows) :
615 608 572
912 688 560
I only have the numbers here (not the system or manual). I think the
"572" is the important number. So DESQview only "lied" a "little" :-).
Hope this helps.
Frank "I like|hate *both*!" :-) Slootweg
Hewlett-Packard, HP-UX Support, Dutch Customer Response Center.
^^^^^--*not* MS-DOS :-)esulzner@cadev4.intel.com (Eric Sulzner ~) (01/03/90)
In article <7310002@hpuamsa.UUCP> frank@hpuamsa.UUCP (Frank Slootweg CRC) writes:
I only have used DESQview a little bit. I could get 562128 bytes free
in a (full screen) COMMAND.COM DESQview "window".
With Windows/386 I can get 578096 bytes free in a *full screen*
COMMAND.COM "window" ("Windows beats DESview by over 15K!" :-)).
To this you can add the resident size of COMMAND.COM (nearly 4K (I
think) see "map[mem]", "mi" etc.) if you start your application directly
from a PIF file (instead of *via* COMMAND.COM).
The Windows/386 test was done on a *2* MB HP Vectra QS/16 with :
- 636 K (*not* 640) of Base/Convential memory (our (HP) machines have a
4K extended BIOS)
- BUFFERS=8
- FILES=20
- *no* drivers
- *no* TSRs
- WIN.INI: windowmemsize=420 (or down to 385)
- WIN.INI: emmsize=0 (because windowmemsize!=640)
The DESQview test was done on the same system (perhaps with 640 K Base
Memory). I think that DESQview *claimed* that it could give more but it
did not. The numbers from the Memory Status command (*before* opening the
Mmph. I tried Windows 386 and Desqview 386 on 2M (total ram) Intel 386 boxes.
When running typical user applications I support (Wordperfect, Lotus 1-2-3,
kermit, some others) Desqview beat Windows cold. Windows 386 could barely get
Wordperfect 5.0 up in a full screen. Desqview 386 held all 3, plus GEM or
Harvard Graphics (though it got into disk [or designated ramdisk] swapping
after a point). Maybe I missed something in RTFM (Windows 386 M is lousy,
Desqview's better but not great).
Please tell me if you know I'm wrong.
Windows 386 did much better with applications written for Windows.
It wasn't clear from your post, but if you ran Desqview with *no* drivers, you
weren't running Desqview 386. Desqview 386 is Desqview 286 with QEMM.SYS.
I typically set BUFFERS and FILES = 20.
esulzner@cadev4.intel.com
--
Eric Sulzner esulzner@cadev4.UUCP esulzner@cadev4.intel.com 54177frank@hpuamsa.UUCP (Frank Slootweg CRC) (01/03/90)
After retesting last night I found that the test conditions for my DESQview test were a little different from those given for the Windows/386 test. Mea culpa :-). Under the *same* conditions DESQview gave 569968 bytes free (i.e. 7840 bytes better than reported earlier). The new Memory Status table was : Total Total Largest Memory Available Available Common Memory 17408 14226 14200 Conventional Memory 622 615 580 Expanded Memory 912 688 560 I think that Windows/386 has the advantage of being able to run a command without help from COMMAND.COM, so my remark '"Windows beats DESview by over 15K!" should have read '"Windows beats DESQview by 11.4K at best!"'. Other data not reported earlier : - The resident size of "our" COMMAND.COM is 3536 bytes (instead of "nearly 4K"). - The tests were done on MS-DOS 3.3. Disclaimers: I have not tuned DESQview in any way. I only tuned the system on which DESQview ran. I got my DESQview results after only a few hours. The Windows/386 were obtained after many months of (on and off) use and investigation. <sentence on documentation deleted by Net Police> :-) Perhaps we could get some responses from Quarterdeck and Microsoft? Frank Slootweg, Hewlett-Packard, HP-UX Support, Dutch Customer Response Center.
frank@hpuamsa.UUCP (Frank Slootweg CRC) (01/04/90)
Eric Sulzner writes : >Mmph. I tried Windows 386 and Desqview 386 on 2M (total ram) Intel 386 boxes. > >When running typical user applications I support (Wordperfect, Lotus 1-2-3, >kermit, some others) Desqview beat Windows cold. Windows 386 could barely get >Wordperfect 5.0 up in a full screen. Desqview 386 held all 3, plus GEM or >Harvard Graphics (though it got into disk [or designated ramdisk] swapping >after a point). Maybe I missed something in RTFM (Windows 386 M is lousy, >Desqview's better but not great). Eric, please see my second posting which contains some small corrections and additions. In my tests the *first* Windows/386 full screen window was bigger (more memory available) then that of DESQview 386. For the *second* window it was quite the reverse (315952 for Windows (if windowmemsize=385, less if windowmemsize is bigger) and 549120 for DESQview). Indeed on a 2 MB system there will be no third window possible in Windows THREE86, while DESQview will be happily swapping along. With regard to documentation: You can't have missed something in TFM of Windows/386 because there is no such thing. Perhaps you found some bound paper in the box, but a *manual*, I don't think so :-) | :-(. > Please tell me if you know I'm wrong. We are both "right" (see above and my postings) > It wasn't clear from your post, but if you ran Desqview with *no* drivers, you > weren't running Desqview 386. Desqview 386 is Desqview 286 with QEMM.SYS. I said : > The Windows/386 test was done on a *2* MB HP Vectra QS/16 with : ^^^^^^^^^^^ The DESQview test was done on the same system and with the same settings (see my second posting for corrections/additions). Of course QEMM.SYS was used, otherwise I could never have gotten the numbers I got. DESQview 286 (i.e. "DV" instead of "XDV") will give numbers in the 380 K range. *I* should have said "*no* OTHER drivers". *You* probably should have better RTFP ("P" for "posting") :-). No offense, you are right to try to clear up possible misunderstandings.. Even after this short while I like DESQview better for the reasons you stated. It still crashes a lot on me, but that is probably caused by my inexperience, wrong settings, lousy graphics "applications" (read "games"), etc. For well behaving applications there are no problems and it is easy to set up and use. I probably will follow Quarterdeck's advice and run Windows/TWO86 in a DESQview 386 window if I have to (for MS Windows applications). Frank Slootweg.
Ralf.Brown@B.GP.CS.CMU.EDU (01/04/90)
In article <7310003@hpuamsa.UUCP>, frank@hpuamsa.UUCP (Frank Slootweg CRC) wrote: } I think that Windows/386 has the advantage of being able to run a }command without help from COMMAND.COM, so my remark '"Windows beats }DESview by over 15K!" should have read '"Windows beats DESQview by 11.4K }at best!"'. No, DESQview can also run a program without help from COMMAND.COM, but you have to set up the .DVP correctly: a) the "program" field must include the .COM or .EXE extension, and b) "close on exit" must be set to Y. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? "How to Prove It" by Dana Angluin 17. proof by mutual reference: In reference A, Theorem 5 is said to follow from Theorem 3 in reference B, which is shown to follow from Corollary 6.2 in reference C, which is an easy consequence of Theorem 5 in reference A.
frank@hpuamsa.UUCP (Frank Slootweg CRC) (01/08/90)
More/better DESQview results/information ======================================== Uptill now other posters and "mailers" have only indicated what was, possibly, wrong with my DESQview setup and/or results. While this in itself is appreciated, it does not help the original poster very much (i.e. please don't (only) say what is wrong, but (also) say how to do it right (i.e. get 600K, or whatever other maximum)). I continued my DESQview tests and now have results which are better than those of Windows/386 and are (mainly) consistent which the "specifications" in the DESQview 386 manual. First some quotes from the DESQview 386 manual (page 3) : <start of quote> * Low DESQview memory overhead. DESQview 386's memory overhead in each virtual machine varies from PC to PC. The chart below shows our test results running DESQview 386 with DOS 3.3. (If you are running DOS4.00, the numbers will be about 15K smaller). As a point of reference, on PCs run- ning only DOS 3.3, (without DESQview 386), the largest conventional memory partition size is 590K. |----------------------------------------------------------------------| | DESQview 386 Memory Allocation | |----------------------------------------------------------------------| | Display adapter Mono/Herc CGA EGA/VGA | | Largest Convent'l Mem Partition 660K 670K 580K | | Largest Expanded Mem Partition 654K 654K 576K | |----------------------------------------------------------------------| <end of quote> Summary : ========= While *my* "point of reference" is only 587.25K, I can get : - 579.4K in VGA mode (i.e. nearly the quoted 580K). - 670 to 675.4K in CGA mode (i.e. equal to or better than the quoted 670K). - 643.4K in Hercules mode (i.e. *not* the quoted 660K). Note: I think the CGA and Mono/Herc numbers in the manual *should* be 676K and 644K (i.e. VGA value plus 96K c.q. 64K) because the size of the video RAM (address space) is 128/32/64K for VGA/CGA/Hercules. These results are much better than the Windows/386 results. "DESQview beats Windows/386 in second/third round!" :-) If the original poster meant "600 * 1000" when he said "600K", then with some more tuning he might be able to do it in VGA mode. If he meant "600 * 1024" then I think it can only, but easily, be done in CGA or Mono/Herc mode. I hope this helps. Frank Slootweg, Hewlett-Packard, HP-UX Support, Dutch Customer Response Center. Details : ========= If the information from my first posting and the corrections in my second posting are used the following "tuning" will realize the free space given in the "Summary" above. VGA mode : ---------- - 562128 bytes, see my first posting. - 569968 bytes, see my second posting. Delta: 7840 bytes. - 582256 bytes by setting "Text Pages: 1" and "Graphics Pages: 1" (was 4 and 2) in the "Advanced Options" menu of the "Change a Program" function. Delta: 12288 bytes (12K). - 583392 bytes by setting "Scipt Buffer Size: 0" (was 1000) in the same menu. Delta: 1136 bytes. - 585472 bytes by setting "DOS Buffer for EMS: 0" (was 2) as advised in the DESQview manual (page 23) for QEMM-386 version 4.10 or higher. Delta: 2080 bytes. - 589568 bytes by disabling the Extended BIOS (HP-specific, see my first posting. Non-HP systems will always have this "advantage".). Delta: 4096 bytes (4k). - 593328 bytes (579.4K) by specifying the full pathname and extension of the command to be executed (this was suggested by another poster in the new "DV vs. Win/386" string) *and* setting "Close on exit" (in the "Advanced Options" menu) to "Y" or " ". Delta: 3760 bytes (3536 bytes for resident portion of COMMAND.COM and two little "holes" (shown as "N/A" by "mapmem" (of TurboPower Software)) of 48 and 176 bytes). CGA and Hercules mode : ----------------------- For both these modes the HP-specific Extended BIOS *must* be disabled. Otherwise there will be a 4K "hole" in the address space and the results will be the same (i.e. not better) as given under "VGA mode :". CGA mode : ---------- - 691648 bytes (675.4K). *Best* result under same conditions as 593328 bytes VGA result. Note: The different "free memory utilities" started to fail or give inconsistent results for these high free memory values. The lowest number was 670K ("memchk"). The highest was 691648 bytes ("mapmem" Version 2.2). The utilities were : - "mapmem" 2.2/2.9 by TurboPower Software. - "ramfree" 2.9 by TurboPower Software. - "memchk" 5.1 from PCTools. Hercules mode : --------------- - 658880 bytes (643.4K). *Best* result under same conditions as 593328 bytes VGA result. "memchk" gave 642K. <end of posting>