HDTenEightyP/NetNews huggingface dataset:
From: garyrich@qdeck.com (Gary Rich)
Subject: Re: ST:P and DJGCC ?
Organization: Quarterdeck Office Systems, Santa Monica CA
Date: Tue, 06 Oct 1992 18:45:53 GMT

In article <1992Oct5.184845.7073@syma.sussex.ac.uk> nickw@syma.sussex.ac.uk (Nick Watkins) writes:
>From article <1992Oct2.183837.16382@syma.sussex.ac.uk>, by nickw@syma.sussex.ac.uk (Nick Watkins):
>>> ST:P is MR:C as described in Forney's book. I assume it was pulled at
>>> last moment because of incompatibilty with Windows 
>
>Meanwhile, I have also gathered that you may not need a page frame if
>you use it, and have tried this on my system. 
>
>What is not so clear is what it is/isn't compatible with.
>

What it's not really compatible with is DVX.  Frame=none, that is.  DVX
will be much less stable, and will acually use more conventional memory since
it can't use the page frame.

>DJGCC complained on being run in a DOS window under it that 
>CPU was in V386 mode and so DJGCC wouldn't run.
>
>Is this unavoidable ?

No.  This is just a consequence of the way DJ is determining if VCPI
memory is available.  If EMS calls fail, the program assumes (usually correctly) 
that VCPI is not available.  It then finds that the machine is currently in 
V8086 mode with no VCPI and no EMS available and terminates.

Gary Rich		<support@qdeck.com>
From: livigni@bldrdoc.gov (David livigni 303-497-5898)
Newsgroups: comp.os.msdos.desqview
Subject: Re: DV: a preemptive multitasker (was Re: Don't Compare with Amiga!)
Summary: comments
Date: 13 Oct 92 17:34:00 GMT

In article <1992Oct12.132904.5770@gw.wmich.edu>, x90wardell@gw.wmich.edu writes:
> In article <7545@lib.tmc.edu>, jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard) writes:

<stuff deleted>

> 
> 	I think we are looking at thigns differently.  OS/2 multitasks
> by having the OS decide when another task gets processor time.  For
> example, if an OS/2 program is just sitting there idle, it gets no
> processor time.  With Desqview, it cycles thru the programs over and
> over.  

<stuff deleted>

> 
> 						-Brad
> 
> =================================
> Brad Wardell  **Happy OS/2 2.0 User**
> Project Director
> Stardock Systems (SDS)
> Western Michigan University
> Western Michigan Universit

OK, you say under OS/2 idle tasks get no processor time.  Then, HOW
DOES OS/2 KNOW ITS IDLE IF IT GETS NO PROCESSOR TIME?  And more
importantly HOW DOES IT KNOW WHEN IT IS NO LONGER IDLE? (such as
when a word processor does a timed backup)?  If it's an OS/2 specific
application, this communication can occur but if its a normal DOS program
I am afraid even OS/2 is going to have to periodically run the application
to see what its doing.  And in that case, a Desqview specific program can
do the same thing as an OS/2 specific program with very little overhead.
In my humble opinion, Desqview is still the best multitasker for DOS
applications.  What good would OS/2 do me if I have no OS/2 applications?
Seems to me that it would just consume resources and slow me down.

ALso going back along the thread, IMHO the Amiga's OS was when it was
released light-years ahead of EVERYONE else, and everyone else is still
trying to play catch up.  Too bad no one, including Commodore, took it
seriously.

David Livigni

-- 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@   Anything stated here is my opinion only    @
@   livigni@bldrdoc.gov                        @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
From: jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard)
Newsgroups: comp.os.msdos.desqview
Subject: Re: DV: a preemptive multitasker (was Re: Don't Compare with Amiga!)
Date: 12 Oct 1992 19:43:05 GMT
Organization: UT Health Science Center Houston

In article <1992Oct12.132904.5770@gw.wmich.edu> x90wardell@gw.wmich.edu writes:
>	I think we are looking at thigns differently.  OS/2 multitasks
>by having the OS decide when another task gets processor time.  For
>example, if an OS/2 program is just sitting there idle, it gets no
>processor time.  With Desqview, it cycles thru the programs over and
>over.  

This is true (though, as another poster has pointed out, DV will short-circuit
programs that are just polling for keyboard input); that doesn't make it
non-preemptive, though. That's merely the sign of a less sophisticated
scheduler. DV still can preempt a runing program to switch away from it.

I agree that OS/2's scheduler is more sophisticated than DV's, but that
difference is hard for a user to detect short of a blatant abuse of good
programming practices. (That is one reason I run OS/2 by choice, though, on my
main PC at home; my other 386 can't run it, or it'd be using it, too. DV does
very well on PCs that can't handle OS/2.)
-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmaynard@oac.hsc.uth.tmc.edu      | adequately be explained by stupidity.
    Vote for a REAL change on 3 November: Throw out the check-bouncing,
  tax-and-spend Democrat Congress! (obviously, not an opinion of UTHSCH)
From: dave@monitor.larc.nasa.gov (Dave A. Hinde)
Newsgroups: comp.os.msdos.desqview
Subject: Postscript viewers
Date: 14 Oct 1992 22:53:20 GMT
Organization: NASA Langley Research Center, Hampton, VA  USA
Distribution: world
NNTP-Posting-Host: monitor.larc.nasa.gov
Keywords: ps & dvx

I need a good postscript "viewer" that is compatible with DV/X.  It doesn't have
to run on the PC, only display the output there.  The files I will be viewing are
plots and graphs that are postscript output files.  

Has anyone "ported" such a program, and if so is it available?  If not does anyone
have any reccomendations?  

					Thanks,
                                            
                                          ___/,@___  Dave Hinde
                                         /_o_____o_| dave@monitor.larc.nasa.gov




Newsgroups: comp.os.msdos.desqview
From: "quarterdeck canada" <quarterdeck.canada@canrem.com>
Subject: problems using rs232
Reply-To: "quarterdeck canada" <quarterdeck.canada@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 11 Oct 92 16:08:36 EST

GF>I am having trouble using comm programs with DV. Kermit, Psion 3 Link,
GF>The Smart label printer (RS232 label printer) and talamate have prolems
GF>using their RS232 ports under DV. Optimize communication is set to Yes,
GF>and the programs that use com port 1 and 2 have those flags set in the DVP
GF>files. Is there anywhere else I should look.

1) Kermit is in the FAQ; I believe the version you are looking for is
3.12.

2) The "Smart Label Printer" is the Seiko device, correct?  If so, try
loading SLP.EXE (not the TSR in a DESQview window).  This is the
non-resident mode of the program, but who cares?  Under DESQview, all
programs are like memory resident popups.  You can also use DESQview's
Mark and Transfer feature to transfer label information from other
windows into the SLP window.

3) I presume that the other two programs you refer to above are
communications programs.  Get the file COMMPROG.TEC and have a look at
it; it's available on the Quarterdeck BBS at (310) 314-3227, Compuserve
(!GO QUARTERDECK), or large local BBS systems, and also via our Q/FAX
fax retrieval service; from the handset of your fax machine, call (310)
314-3214, or in Canada, (416) 665-5070.

GF>I have run Checkit outside DV and each interrupt has QEMM386 assigned to it.
GF>could it be that QEMM is the problem, hideing the interrupts?

No.  QEMM doesn't hide interrupts, and things wouldn't work if it did.
QEMM does handle interrupts, but no reasonable application should care
about this.

Regards,

Michael Bolton
Tech Support
Quarterdeck Canada  (416) 360-5758  quarterdeck.canada@canrem.com
---
  DeLuxe 1.25 #6922  Exception 13? QEMM Manual, "Troubleshooting"
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.os.msdos.desqview
From: books@fsunuc.physics.fsu.edu (Roger Books)
Subject: QEMM memory conflicts
Organization: FSU nuclear physics
Date: Fri, 9 Oct 92 00:45:13 GMT

My 3c507 board just decided it wasn't going to work with QEMM.  I had it
set to adx d0000 and it worked fine for a while.  If I unload QEMM it works
fine with NCSA telnet and FTP.  I seem to have a memory conflict.  I would 
just disable QEMM but then I couldn't run DV/X.  I tried the following.

1. Disabled Stealth

2. With stealth disabled tried both ARAM=D000-D800 and X=D000-D800, not
   at the same time of course.

Neither seemed to have any affect on the problem.

If anyone has any idea what I can do to fix this please let me know.

Roger
books@fsunuc.physics.fsu.edu
Newsgroups: comp.os.msdos.desqview
From: mcastle@mcs213d.cs.umr.edu (Michael R Castle)
Subject: Re: any special way?
Date: Fri, 16 Oct 1992 18:19:30 GMT
Organization: University of Missouri - Rolla

In article <Bw668o.9zF@world.std.com> aml@world.std.com (Andrew M Langmead) writes:
>Quarterdeck's DESQview API development tools (available through Quarterdeck
>or software retailers. The API Reference Manual is $25.00. The API Toolkit
>(available in C, Pascal, BASIC, Clipper, and dBase flavors) costs $100, and
>includes the API Reference Manual, language library and manual, the Panel 
>Design Tool (screen painter,) API debugger (break or trace at API calls,
>understands multiple tasks per process) and DESQview.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Does this mean that a DV-specific app can do multithreading???  If so, I may
have to really look into this....
mrc
Newsgroups: comp.os.msdos.desqview
From: hshlswe1@w222zrz.zrz.tu-berlin.de (Hilmar Schlegel)
Subject: Re: Latest version of QEMM386
Keywords: QEMM386 Updates
Reply-To: hshlswe1@w222zrz.zrz.tu-berlin.de (Hilmar Schlegel)
Organization: ZRZ/TU-Berlin
Date: Fri, 9 Oct 1992 16:41:40 GMT

In article <1992Oct9.010611.16851@massey.ac.nz>, D.Burns@massey.ac.nz
(David Burns) writes:
> What is the latest version of QEMM386?  As a registered of user of several
> versions of QEMM, I'm displeased that I don't receive update notices.  Is
> this lack of notification common?
> -- 
> /-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-\
> /     David Burns, Massey University, Palmerston North, New Zealand     \
> /`We can never truly know the path we have not walked.' (G.G.Kay,Tigana)\
> /-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-\
Yes it is common. We are ignored with respect to support and notification too.
Hilmar Schlegel (hshlswe1@w250zrz.zrz.tu-berlin.de)
###
From: x90wardell@gw.wmich.edu
Newsgroups: comp.os.msdos.desqview
Subject: Re: DV: a preemptive multitasker (was Re: Don't Compare with Amiga!)
Date: 12 Oct 92 13:29:04 EST
Followup-To: comp.os.msdos.desqview
Organization: Western Michigan University

In article <7545@lib.tmc.edu>, jmaynard@oac.hsc.uth.tmc.edu (Jay Maynard) writes:
> In article <1992Oct10.223900.5743@gw.wmich.edu> x90wardell@gw.wmich.edu writes:
> [about DV, being preemptive or non-preemptive]
>>	This is incorrect, Desqview aware programs alone are capable of
>>telling DV that it doesn't need time but the processor still switches
>>to it and has to be told this.  DV is cooperative not preemptive, it
>>is just a lot better at it than Windows and has the ability of acting
>>almost preemptive which windows programs parently do not do.
> 
> Sorry. DV will multitask programs that know nothing about DV. I know, because
> I do it all day. Under a cooperative multitasker (such as Windows), the
> applications program must explicitly tell the multitasker to switch processes
> while the program isn't doing I/O if it wants to give up control of the
> processor and let something else run for a bit. DV will switch away from such
> a task, whether or not the task has told it to...this is called "preemption".
> This is what makes preemptive multitasking such a Good Thing: even poorly
> written programs will still be multitasked, and this can be achieved
> transparently.
> 
> (This is straying from comp.os.os2.advocacy; DV-only posts should go to
> comp.os.msdos.desqview. Please pay attention to the Newsgroups: line if
> following up.)
> -- 
> Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can


	I think we are looking at thigns differently.  OS/2 multitasks
by having the OS decide when another task gets processor time.  For
example, if an OS/2 program is just sitting there idle, it gets no
processor time.  With Desqview, it cycles thru the programs over and
over.  

	For example, if you have 3 programs, 2 of which are actually
doing something and one of them is a word processor that is currently
doing nothing here are how the two enviornments handle it:
 We have 15 clock cycles available:

Terminal program: Gets enough of the processor to keep it going well
Virus Scanner:	Gets just enough processor to keep it going well
Word Processor: doesn't get anything.
In numbers, we could say that teh Terminal program gets say 9 clock
cycles, the virus scanner 6 cycles and the word processor 0.

Under Desqview, each app would get 5 clock cycles.
(These are back ground tasks by the way).

DV handls multitasking of DOS in the SAME mannger os Windows 3.1 (except
that Windows gives them a bit more protection).  

Windows programs themselves must explicitly give up the processor.

						-Brad

=================================
Brad Wardell  **Happy OS/2 2.0 User**
Project Director
Stardock Systems (SDS)
Western Michigan University
Western Michigan Universit
From: rvuori@klaava.Helsinki.FI (Rasmus Vuori)
Newsgroups: comp.os.msdos.desqview
Subject: DV/X on Lantastic 4.1 network
Date: 16 Oct 92 08:47:41 GMT
Organization: University of Helsinki


I'm about to build a system based upon a Lantastic 4.1 network
(ethernet) and a few dos sessions on each workstations. They can be
pretty heavy on networked disk-access, so I'd like to know if anybody
out there has experience in this kind of setup?

I have used Lantastic 4.1 and Windows 3.1 successfully, but would really
like to use DV/X instead of Win, and according to the adverts DV/X
should support Lantastic as it is a NetBios network, but not having seen
anywhere that Lantastic is one of the supported networks made me wonder.

Thanx!
-- 
	Rasmus Vuori
	Rasmus.Vuori@Helsinki.fi
From: dwgordon@matt.ksu.ksu.edu (Dwight W. Gordon)
Newsgroups: comp.os.msdos.desqview
Subject: Re: DV: a preemptive multitasker (was Re: Don't Compare with Amiga!)
Date: 12 Oct 1992 13:01:26 -0500
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

x90wardell@gw.wmich.edu writes:

>	I think we are looking at thigns differently.  OS/2 multitasks
>by having the OS decide when another task gets processor time.  For
>example, if an OS/2 program is just sitting there idle, it gets no
>processor time.  With Desqview, it cycles thru the programs over and
>over.  

>	For example, if you have 3 programs, 2 of which are actually
>doing something and one of them is a word processor that is currently
>doing nothing here are how the two enviornments handle it:
> We have 15 clock cycles available:

>Terminal program: Gets enough of the processor to keep it going well
>Virus Scanner:	Gets just enough processor to keep it going well
>Word Processor: doesn't get anything.
>In numbers, we could say that teh Terminal program gets say 9 clock
>cycles, the virus scanner 6 cycles and the word processor 0.

>Under Desqview, each app would get 5 clock cycles.
>(These are back ground tasks by the way).

>DV handls multitasking of DOS in the SAME manner as Windows 3.1 (except
>that Windows gives them a bit more protection).  

  WRONG!  I just wrote a "nop loop" program (an infinite loop
that processes a couple of nop instructions).  Under Windows, the
control program (Windows) was hung by my little program.  Running
the same program under DV only hangs that particular window.  I
was able to tap the Desq-key and close that particular task without
rebooting the computer.

  Task switches in both OS2 (I assume) and DV occur on the clock
tick.  The clock tick is not necessarily used for Windows multitasking.

  As for the protection issue, under DV the user has control over
the level of program protection.  In the default (virtually no
protection mode), it is easy to have a single task crash the
entire system.  In the full protection mode, I've only ever seen
one package on my computer that crashed the system.
Unfortunately, this high level of protection is one that
prohibits the running of certain programs that do things such as
access the system resources outside of the control of the
operating system.

>Windows programs themselves must explicitly give up the processor.

  My understanding is that it may also be _implicitly_ (as in
certain actions such as keyboard polls).  My experience with
running a performance analyzer under DV is that DV has a tendency
to interpret certain actions as "idle" activities, and preempt
the task if they are doing them.

- Dwight -





-- 
Dwight W. Gordon, Ph.D.                     Kansas State University
dwgordon@matt.ksu.ksu.edu             Electrical and Computer Engineering
dwgordon@ksuvm.bitnet                             Durland Hall
Phone 913-532-5600; FAX 913-532-7810        Manhattan, KS 66506-5105
Newsgroups: comp.os.msdos.desqview
From: "quarterdeck canada" <quarterdeck.canada@canrem.com>
Subject: upgrading???
Reply-To: "quarterdeck canada" <quarterdeck.canada@canrem.com>
Organization: Canada Remote Systems
Distribution: comp
Date: 11 Oct 92 16:08:37 EST

AR> Just curious here, not having been a long time Quarterdeck
AR>customer, but what will the upgrade policy be with the next release of
AR>DV/X?

AR> I guess the point I'm trying to get at is 'how much' will it
AR>cost to obtain the next release?

That would depend on how much stuff is in the new release, whether it's
a massive rewrite with gobs of new features, or just a minor
compatibility update.  So until there are details on the new release, or
until one is announced, or even hinted at, the question is pretty much
moot.

However, it has long been company policy that, regardless of the
product, the latter types of upgrades range from free to patchable to
a nominal fee, and that the former are quite reasonably priced.  We
advise users of the new features, most upgrade, a few don't, and we
rarely get complaints from either group.

Regards,

Michael Bolton
Tech Support
Quarterdeck Canada  (416) 360-5758  quarterdeck.canada@canrem.com
---
  DeLuxe 1.25 #6922  DESQview/X : Raising DOS to the power of X!
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
Newsgroups: comp.os.msdos.desqview
From: ulrick@mp.cs.niu.edu (David Ulrick)
Subject: Backups under DV-386
Organization: Northern Illinois University
Date: Wed, 7 Oct 1992 14:11:41 GMT

I've finally bitten the bullet and gotten myself a 386SX-25 machine for home
use.  It came with Windows 3.1, but after seeing how well Windows performed I
went out and bought DESQview-386 v2.40.  It seems to run most software OK--even
Windows 3.1, once you get used to the long delay after pressing the DESQ 
key--with the exceptions of MS-Kermit 3.11 and DOS BACKUP.  The problems with
Kermit are documented, among other places, in the FAQ, so I won't belabor that
issue here.  However, I would like to be able to find a good way to back up     
that big 107 Mb hard drive without having to bring down DESQview.  The DOS
BACKUP command seems to back up several disks without any problem, and then 
the whole system hangs for no apparent reason.  Admittedly, I *did* have a
bunch of other windows open at the time BACKUP was running, but the DV Files
Monitor showed that I didn't have any files open that BACKUP needed.  

Can BACKUP be trusted within DESQview?  Would XCOPY work any better, or 
should I look into another backup program?  I may have to look into something 
else, since I already have 40 Mb in use on my hard drive; once I start to 
fill it up some more I'll probably consider tape backup.  In the meantime, 
I'll do my backups outside DESQview. :-(

Thanks,
Dave

Newsgroups: comp.os.msdos.desqview
From: joet@dcatlas.dot.gov (Joe Trott)
Subject: Re: maximum memory in each window , background colors?
Organization: U.S Dept. of Transportation
Date: Thu, 8 Oct 1992 18:06:28 GMT

goodrich@qdeck.com (Steve Goodrich) writes:

>In article <1992Sep25.144446.178@wam.umd.edu> qian@wam.umd.edu (Yong Qian) writes:
>>I tried to run Norton's SA to get a background color under DV/X's DOS
>>window. But there is just no color change. Are there other softwares
>>for doing that which works under DV/X?
>>

>I just tried using Norton's BE to change the color (BE CLS BLACK GREEN) and it
>worked just fine.

You may need to load ANSI.SYS (or DVANSI) in order to get a color change
to stick.

-JTT
Newsgroups: comp.os.msdos.desqview
From: gunars@spss.com (Gunars V Lucans)
Subject: Re: DV/X and blotchy graphics and characters, etc.
Keywords: quattro pro 4.0, windows 3.1, disk formatting, etc.
Organization: SPSS Inc.
Date: Fri, 16 Oct 1992 20:46:18 GMT

garyrich@qdeck.com (Gary Rich) writes:

>In article <1992Oct12.185153.11845@magnus.acs.ohio-state.edu> jjwu@magnus.acs.ohio-state.edu (James J Wu) writes:
>>
>>     my questions concern garbled characters in graphics mode.  to explain, 
>>i'll use examples.  when i run the bgidemo in turbo pascal 5.0 some characters 
>>display fine while others on the same screen display as blotches.  this also 
>>happens when i use quattro pro 4.0. 

>> the opening screen comes up with 50% ok 
>>and 50% blotchy characters.  in  wysiwyg  mode, the movement arrows blotch out.
>>this effect goes on after exit DV/X and run another program that uses graphics.
>>windows 3.1 runs ok but the graphics programs under it get blotchy characters.
>>when i reboot the problems go away.  i'm assuming that the problem is stemming 
>>from how DV/X handles graphics.

>Not if it happens even after you quit DVX.  That makes it sound more like
>some kind of memory conflict.  You might try adding X=A000-C7FF to your
>QEMM line in CONFIG.SYS 

>Gary Rich  	<support@qdeck.com>


Yes, I get this problem as well with TeXcad (add-on drawing package
for TeX) which is written in Turbo Pascal v5 and also uses BGI drivers
(egavga.bgi).  Some characters come out fine and others are garbled.
This has nothing to do with DV/X ... I get this in DV386 and plain DOS
as well.  In particular, I get this when running ST:M or ST:P. The
problem goes away with ST:F or no stealth.  The problem also goes
away with ST:M if I exclude a small area at X=f000-f0ff.  My qemm line
is:

   c:\qemm\qemm386.sys ram rom x=f000-f0ff x=c800-c9ff xst=c000 ST:M

Gunars

--
Gunars V. Lucans  --  gunars@spss.com  --  SPSS Inc, Chicago, USA
Newsgroups: comp.os.msdos.desqview
From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
Subject: Re: automatic reboot
Organization: Queen's University
Date: Thu, 8 Oct 1992 13:08:15 GMT

In article <moorerr.192.718498601@msu.edu> moorerr@msu.edu (richard r. moore) writes:
>I am running desqview 2.4 & QEMM 6.01.  I recently added paradox 4.0   
>(replacing paradox 3.5).  Now, frequently when i switch to paradox, i see a "
>swapping..." message and then my micro reboots itself.  Obviously, this is 
>not a desireable situation!  This did not happen with paradox 3.5.  Any 
>ideas what might be going on?  What more information should i collect to 
>help figure out this problem?

I get the same problem with SPlus 1.1, a statistical package.  It was 
written using the Phar Lap extender, and is supposed to be VCPI compatible, 
but can't tolerate being swapped out.  I've just set "Can be swapped out" 
to "N", to avoid the problem.  


Duncan Murdoch
dmurdoch@mast.queensu.ca
Newsgroups: comp.os.msdos.desqview
From: joet@dcatlas.dot.gov (Joe Trott)
Subject: Re: Latest version of QEMM386
Keywords: QEMM386 Updates
Organization: U.S Dept. of Transportation
Date: Fri, 9 Oct 1992 15:17:27 GMT

D.Burns@massey.ac.nz (David Burns) writes:

>What is the latest version of QEMM386?  As a registered of user of several
>versions of QEMM, I'm displeased that I don't receive update notices.  Is
>this lack of notification common?

I've never gotten an update notice from Qdeck either!

-JTT