sac90286@uxa.cso.uiuc.edu (Kubla Khan) (08/05/89)
In article <8989@cs.Buffalo.EDU> ugbell@sunybcs.UUCP (William Bell) writes: > > Does anyone use DeskView 1.0 with or without QEMM 4.2?? > > I was wondering: >1) How much memory would you say is adaquate? I'd recommend a MINIMUM of 2Mb of RAM. DESQview has many features, and thus uses up a lot of memory. My system has 2Mb and I haven't run into any memory problems so far (of course, I don't usually run any mongo-sized programs under DESQview, either!) >2) Is it true that you can run 2 programs simulataneous? A friend of mine > said I could run a BBS in the background and play a game in the forground. > Is this true? Is anyone using DeskView to do this exact thing? How about > running a BBS in the background throught COM1: and using procomm > through COM2:? I run a BBS, but not under DESQview. My machine at home runs DoubleDOS with one partition for the BBS and the other for whatever I want. Under DDOS I am able to run the BBS on one COM port while simultaneously using the other for something else. I think it's safe to assume that DESQview can do anything that DDOS can. I do know of at least one BBS that does run under DESQview. If you have a '386 and at least 2Mb RAM, DESQview can't be beat! >3) Is there a way to use memory from 640K to 1 Meg for resident programs? > Or is this just used for BIOS and MOS 4.01?? Depending on your machine, QEMM can remap that 384K chunk so that it's usable for your programs, but you're much better off using it as shadow RAM for your system and video BIOS. The performance improvement is quite dramatic and well worth the loss of that "extra" 384K. Good Luck!
rich@sli.com (Rich K. Braun) (08/07/89)
I just purchased DESQview 2.2 for my new 386, and have had positive experiences so far. It can run any number (well, up to 256) of simultaneous tasks, and seems to handle I/O contention between various tasks quite well (e.g. you can run a C compiler, a BBS, or a database application which performs disk I/O in the background while accessing the same disk in your active window). One comment I have on their windows (are any DESQview developers reading this?) is that they don't provide a way to query the user for a command line when invoking an application from the top-level menu. You have to run things which need command lines (such as editors) under the PC-DOS shell, which eats up memory. While I'm on this subject, I wonder if anyone out there knows of a C compiler which runs under DESQview in native mode, producing code which will run in native (386) mode? I'd love to see GNU C capable of doing this. On memory allocation: the DESQview manual contains several pages of text on how to set things up such that it doesn't consume 145K of "conventional" memory when firing up an application. Since some of my applications really want to have 640K or more, I'd like to set this up. But I must confess that my first pass through the DESQview manual didn't make things obvious, and I'm also confused on the difference between the various extended and expanded memory standards on the PC. (Why did Intel do this to us? Life's so simple on the 68020, where you just have a 4G linear address space...) On disk I/O performance: apparently DESQview robs the foreground process of enough CPU cycles to hurt disk I/O dramatically. I'm running an RLL disk with 1:1 interleaving, and it appears that although I can read an entire track full of sectors in a single revolution from PC-DOS, if I do the same thing under DESQview with certain applications (XCOPY is the simplest example), it's clear that the disk has to spin several times before a track is read in. Any clues on how to prevent this from happening? -rich
simcha@kurz-ai.UUCP (Simcha Lerner) (08/07/89)
In article <1989Aug7.053410.12364@sli.com> rich%sli@uunet.uu.net (Rich K. Braun) writes: >...... >On disk I/O performance: apparently DESQview robs the foreground process of >enough CPU cycles to hurt disk I/O dramatically. I'm running an RLL disk >with 1:1 interleaving, and it appears that although I can read an entire >track full of sectors in a single revolution from PC-DOS, if I do the same >thing under DESQview w/ certain applications (XCOPY is the simplest example), >it's clear that the disk has to spin several times before a track is read in. >Any clues on how to prevent this from happening? > >-rich While I haven't used DESQview 2.2, under version 1.x you had the option to set how many ticks were spent in forground, and how many were spend on each background task. If you aren't getting enough tics __on_average__ to allow reading a full track uninterrupted, you can increase the number of ticks to allocate to the foreground task. If you wish to keep the same ratio of foreground to background ticks, you can increase both. What this will accomplish is to increase the "graininess" of the task swapping - which should give the forground enough time to completely read a full track. The problem of xcopy is that it will keep reading data until it is interrupted. Since it is impossible to guarantee that the ticks will always fall out between track reads, your choise is either: 1. Increase the clock ticks as above, and maximize the number of tracks read before an interrupt. 2. Buy a caching disk controller. Since the reading of a full track takes place independent of the program running, task swapping doesn't bother this type of controller so much. 3. Reduce your interleave to 2:1 (and cry :-) ) [or undocumented alternative 4: get a real operating system instead...] Good luck, -- Simcha Lerner Kurzweil Applied Intelligence PLEASE NOTE ADDRESS: NO RETURN MAIL VIA bbn PLEASE UUCP address: kurz-ai!simcha@talcott.harvard.edu or: ...{uunet,rutgers,ames}!harvard!talcott!kurz-ai!simcha
davidr@hplsla.HP.COM (David M. Reed) (08/08/89)
If you use a question mark "?" as the last character in the Program Parameters field, DESQview will prompt the user for information before starting the application. This way you, for example, when DESQview starts your editor it will allow you to enter the name of the file you want to edit. As for memory allocation. If your program really DEMANDS more than 550K of conventional memory you will probably never be able to run it under DESQview. As for disc access. I do not know the answer, but I have some ideas as to why such poor performance. I suspect that for optimum disc performance under DESQview you will want to have your disc interleave set at 2 (or 3), unless you have really good buffering or cache (such as on the hard disc controller). Since DESQview is giving time slices to programs (either foreground or background), then a process that is reading from disc is not really able to read continuously (particularly if it is doing its own disc accessing instead of utilizing DOS or the BIOS), and therefore would need to "go around again" to get what it was interrupted at doing the "first time around". Now one must realize that any program running in a multi-tasking environment will NOT run as fast as it would in a single-tasking environment. There will be some performance penalty. It is not as noticeable on a interactive program (like an editor) as on something like a program accessing a disc. But I generally care very little if something that used to take 5 minutes now takes 6 (or 7 or 10) if I can be doing something else at the same time. Yes, I still get caught up in the idea of wanting programs to run faster, but that, I began to realize, was because I did not like to wait. If I can be doing something else instead of simply waiting, then speed is not quite so critical to me.
reeves@dvinci.USask.CA (Malcolm Reeves) (08/10/89)
>2) Is it true that you can run 2 programs simulataneous? A friend of mine > said I could run a BBS in the background and play a game in the forground. > Is this true? Is anyone using DeskView to do this exact thing? How about > running a BBS in the background throught COM1: and using procomm > through COM2:? > I run a BBS under DESQview on com2 and can run almost anything on com1. For example, I have used procomm, telix and several other communications packages to check out the BBS (I have 2 modems and 2 phone lines). I can also upload from a remote BBS while my own BBS is running. The only thing I can't do with DESQview is run a BBS and a 3Com 3plus network session at the same time - I don't really want to but if I did I couldn't. DESQview is a very neat program which will take a large amount of abuse before it "breaks". Good Luck!