HDTenEightyP/NetNews huggingface dataset:
From: marke@dev1.csg.ssd.fsi.com (Mark Easter)
Subject: Re: "BYTE" review of DV/X
Date: Thu, 23 Jul 1992 04:43:11 GMT
Distribution: us
Organization: FlightSafety Simulation Systems Division - Tulsa

In article <614@ceylon.gte.com> sc05@newshost.gte.com (Shih-Chio Chang) writes:

> Surprise! You need another piece of software, which was either ignored
> or down played in all their ads, from Quarterdeck to fill in the gap
> between DV/X and "other" TCP/IP products that opens the door for DV/X
> to the wide world of existing X applications.  Also, rumor has it that
> an additional window manager might be needed.

Yeah, I was shocked myself, especially after specifically stating my
requirements in two separate phone calls and mentioning to tech support
in the third call that even the manual referred to a "Network Manager
for Other X" when the installation said I was missing this piece but
he insisted that everything I needed was on disc 6!  And, yes, if you
want anything but the DVX window manager (like motif or openlook) you
get to pay another $250.  I hope they enjoy this period when they are
the only ones to have X over dos.  A whole lot of us likely to jump
ship the instant there is an alternative.

> I turned arround and bought eXceed/W, which cost me $381 and gave me
> only an X server and nothing else.  But it did come with all the
> necessary parts for connecting to many "other" TCP/IP transport
> protocols. I just do not see how in the world could Quarterdeck not
> actively pursuing all those existing X users out there.  Wake up,
> Quarterdeck!  Package the product the way it should be packaged.  

Right on!

----------------------------------------------------------------    /|  -
Mark W. Easter            FlightSafety International               / | /|
Staff Engineer            Simulation Systems Division         -----------
Computer Systems Group    Broken Arrow, Oklahoma 74012    Flight   \ |   
marke@fsi.com             918-251-0500 x596                  Safety \|SSD
                   "You wreck 'em - we'll rack 'em"                       
----------------------------------------------------------------------------

--
From: sc05@newshost.gte.com (Shih-Chio Chang)
Newsgroups: comp.os.msdos.desqview
Subject: Re: "BYTE" review of DV/X
Date: 22 Jul 92 15:30:23 GMT
Organization: GTE Laboratories, Waltham, MA

In article <Jul21.231709.61662@yuma.ACNS.ColoState.EDU>, kk881595@longs.LANCE.ColoState.EDU (kevin knappmiller) writes:
|> 
|> Somebody at Quarterdeck seems to be listening, so I wonder if they can give
|> us the low down.  What bright marketing person decided that pissing off your
|> loyal customer base was the best way to make your new product succeed?
|> 

I think they not only pissed off loyal customers but also ignored potential new
customers.  In fact, I just returned my copy of DV/X to make my point.

I have heard of the product for two years. And I have waited for it for two years.
To me, its promise of being both an X server AND client on a MS-DOS box makes it
unique and desirable.  Being a satisfied customer of QEMM, I ordered DV/X at the
first sight of an ad from PC Connection.  There was no mention of anything else
that I would need on the ad.  (I have to admit, after reading the ad again,
there was a faint hint for it.)  Also, I was already a user of other X server
products for DOS, and was on the look out for better ones.  I was aware of
the fact that I do need additional transport software, of which I have several
already.  But I do expect any X server product to come with all the other
necessary parts.  

When I open the DV/X package, to my surprise, I found out that it can only talk
to other X applications on Novell LAN or some PC LAN, which I do not think
existed other than DV/X applications.  What about all those existing X 
applications?  Surprise! You need another piece of software, which was either
ignored or down played in all their ads, from Quarterdeck to fill in the gap
between DV/X and "other" TCP/IP products that opens the door for DV/X to the
wide world of existing X applications.  Also, rumor has it that an additional
window manager might be needed.

I turned arround and bought eXceed/W, which cost me $381 and gave me only an X
server and nothing else.  But it did come with all the necessary parts for 
connecting to many "other" TCP/IP transport protocols.

I just do not see how in the world could Quarterdeck not actively pursuing all
those existing X users out there.  Wake up, Quarterdeck!  Package the product the
way it should be packaged.  

S.C. Chang
GTE Labs
schang@gte.com
Newsgroups: comp.os.msdos.desqview
From: markg@pdx077 (Mark Gonzales)
Subject: DV/X and Win 3.1 Apps as X clients
Organization: Intel Corp., Hillsboro, Oregon
Distribution: usa
Date: Thu, 23 Jul 1992 01:29:34 GMT

We would like to run Windows 3.1 applications in X-Windows displayed on
RS6000 or Sparc workstations. Windows applications we want to use
include Powerpoint, Excel 4.0, and Word-for-Windows.

Has anyone out there succeeded in doing this? Did you get acceptable
performance, as seen by the user at the workstation?  

Obviously we can buy as macho a PC as necessary to get client
performance, but I am not convinced that X is fast enough to do all the
snazzy window manipulations that apps like excel perform.

Also is it possible to have more than one workstation "logged on" to the
PC, running Windows 3.1 apps?

Please reply by email, and I will summarize.

Thanks

Mark - markg@ichips.intel.com
Newsgroups: comp.os.msdos.desqview
From: knipe@mksol.dseg.ti.com (richard l knipe)
Subject: Turning off DV/X windows 3 support
Organization: University of Texas, Arlington
Date: Mon, 27 Jul 1992 16:09:05 GMT


If manifest is run from inside of dv/x, it shows a 560K memory
block allocated as "DVX.WIN3".  Is this memory region setup
exclusively for windows 3?  If so, how is it turned off?  I
don't use window 3 and would like the 1/2 meg back.

Richard Knipe.
knipe@me.uta.edu
From: trevor@trevan.uucp
Newsgroups: comp.os.msdos.desqview
Subject: Re: DV/X and NCSA Telnet WORKS!
Date: 24 Jul 92 20:30:35 GMT
Organization: Trevan

silano@newton.cs.jhu.edu (Mike Silano) writes:


>The solution to this is pktmux - the packet driver multiplexor.
>I FTP'd this from omnigate.clakrson.edu, in the 
>/pub/gw/pktmux directory.  There were no docs.  Apparently, pktmux
>implements a protocol stack or at least a buffer around the 
>drivers.  Bottom line - CUTCP/NCSA telnet works from DV/X.  

Do you still need the TCP manager sold as an extra by Deskview.
-- 
				regards trevor
------------------------------------------------------------------------------
Trevor Harris				UUCP: trevor@trevan.uucp
Trevan Designs Limited
From: swf@teradata.com (Stanley Friesen)
Newsgroups: comp.os.msdos.desqview
Subject: Re: Game program hangs DesqView
Date: 27 Jul 92 22:48:48 GMT
Reply-To: swf@tdat.teradata.com (Stanley Friesen)
Organization: NCR Teradata Database Business Unit

In article <1992Jul22.215824.1051@qdeck.com> docw@qdeck.com (Doc Williamson) writes:
|In article <682@tdat.teradata.COM> swf@tdat.teradata.com (Stanley Friesen) writes:
|>Hi, I have found an odd problem with a new game I bought.
|>When I run it under DesqView (version 2.31, under QEMM 5.11) it hangs
|>my computer (completely, I have to RESET to get it back).
|>
|>The game is Strike Eagle II from MicroProse, ...
|
|>Any idea what is going on?  And what can be done about it?
|>
|Most game programmers assume that their program will be the only software
|running on a DOS machine (other then the OS), and tend to take a liberal
|attitude towards any shortcuts they can devise.

Silly assumption.

|DESQview tends to rely
|on programs following some of the "rules" of "polite" programming .
| In particular the things these programs tend to do that are "rude" include
|directly accessing ROMs (especially the video ROM) instead of using the
|appropriate interrupt or BIOS call.

O.K.  Now are there any config. options I can set to at least localize this
to the window in which the game is running?

|Another particular problem with game software under DESQview is that DV has a 
|maximum "supported" resolution of 640x480x16colors .  Most games try to give
|you the highest available resolution, and especially if this is 1024x?x? or
|most hi-res modes in 256 colors, which will tend to lock up DV, especially
|when you try to rbing up the DV menu.

Well, this is annoying, and could even be the problem, except for one thing:

The program locks up *immediately*, before it has displayed *anything*,
and before I make any attempt to *do* any thing.  Could just switching
to a hi-res mode and attempting to draw do this?  (Hmm, I seem to remember
having problems with GIF viewers as well, but nothing quite like this).

|If you set up the game for 640x480x16 it MAY run, but many game routines are
|timer 
|sensitive, and since it is only seeing its own window's timer ticks, the
|response is poor at best.

This game is supposed to adapt itself to the available timer.

Ah well, I will try to use command line options to tell it to use medium-res.
(annoying, since the main attraction of Strike Eagle II is its realism,
due to its using VGA properly).


Another thing that has sometimes caused problems is games (or other software)
trying to do fancy sound stuff (my new Compton's Encyclopedia scrambled
itself when it tried to play a sound bite, but that only locked the one
window, I could still call up my DV menu and get rid of it).
-- 
sarima@teradata.com			(formerly tdatirv!sarima)
  or
Stanley.Friesen@ElSegundoCA.ncr.com
From: nickw@syma.sussex.ac.uk (Nick Watkins)
Newsgroups: comp.os.msdos.desqview
Subject: PgUp & PgDown - was Re: DV/X bugs
Date: 21 Jul 92 11:22:28 GMT
Organization: University of Sussex

From article <1992Jul14.022831.284352@cs.cmu.edu>, by ralf+@cs.cmu.edu (Ralf Brown):
> In article <4x#m#+_.tunxis@netcom.com> tunxis@netcom.com (Gary A. Gorgen) writes:
> }I still can't get either "~" or "`" to work on "xterm", on the UN*x box.
I am wondering if I can get an HP9000 to recognise the PC page up and
page down keys under micro emacs in an xterm. This requires microemacs
to think that the PC is sending FNV and FNU on these keys, at present it
thinks it is seeing ^[~3 and ^[~5, any clues ?

Nick
-- 
Dr Nick Watkins, Space Plasma Physics, Univ. of Sussex, Brighton BN1 9QH, UK
JANET: nickw@uk.ac.sussex.syma        BITNET: nickw%syma.sussex.ac.uk@uk.ac
From: duperval@ERE.UMontreal.CA (Duperval Laurent)
Newsgroups: comp.os.msdos.desqview
Subject: How to make Desqview recognize mouse clicks
Date: 27 Jul 92 13:36:44 GMT
Organization: Universite de Montreal

Hello all,

I have Desqview running with screen blanking on.  I use it becausea lot af the
time the computer is running with noone at the console.  But sometimes, whiule
I'm downloading large files, I play games simultaneously.  The games I play
usually make extensive use of the mouse but not the keyboard.  So every 3
minutes, I have to hit the shift key to get my screen back because DV doesn't
recognize mouse clicks as key presses.  Is there anyway to make DV recognize
the mouse as it does the keyboard?  If not, can I turn off screen blanking on
the fly, without having to reconfigure DV everytime?

Thank you for your help.
-- 
Laurent Duperval
duperval@ere.umontreal.ca
duperval@jsp.umontreal.ca
"If you gotta go, you might as well go happy... or suprised"   -Me
From: SCC@nervm.nerdc.ufl.edu (Scott C. Crumpton)
Newsgroups: comp.os.msdos.desqview
Subject: For Sale: Desqview 386
Date: 28 Jul 92 01:29:46 GMT
Organization: University of Florida, NERDC

I've moved on to OS/2.  Is anyone interested in my copy of Desqview 386?
It's version 2.42 and QEMM is at 6.02.  I'm looking for $70.
Please email if interested.
 
---Scott.                scc@nervm.nerdc.ufl.edu
Newsgroups: comp.os.msdos.desqview
From: hoesel@igc.ethz.ch (Frans van Hoesel)
Subject: dv/x redraw detection
Organization: University of Groningen, the Netherlands
Date: Sat, 25 Jul 1992 10:27:13 GMT

I'm using dv/x just as a multitasker (I'm one of the people strucked by
the fact that Qdeck suplies only the x-protocol, not the communication
it self).

Using bgi-driver in 800*600*256 in my program (with a etseng compatable
graphics card (colorimage 6)) dv/x refuses to redraw the screen, even
when backing store is enable. Note that it redraws fine on many other
programs, not using the 800*600*256 graphics mode, but my program needs
that mode.

So given the fact that dv/x fails to redraw the screen, is there an easy way
to detect that my programs needs redrawing?
Until now I didn't use any dv/x specific commands in my program.
I'll think i'll need two calls at least: one to detect if my program is running
within dv/x and if so then another call to detect if my program needs
redrawing.

I don't have any dv/x programmers documentation (and not the money to buy
their development stuff), so any help would be appriciated.

-- frans
From: kk881595@longs.LANCE.ColoState.EDU (kevin knappmiller)
Newsgroups: comp.os.msdos.desqview
Subject: Re: DVX and DOS Graphic apps (was Re: DV/X and Tame?)
Date: 29 Jul 92 19:59:43 GMT
Reply-To: kk881595@longs.LANCE.ColoState.Edu
Organization: Engineering College, Colorado State University


 
> What I am proposing is not a change to the X standard, but a layer on
> top of it, specifically for DV/X.  A layer of code that translates
> BGI (or whatever) requests to X requests and X events back to BGI
> events.  Later on in my post, I proposed a similar layer, maybe
> we could call it "Trivial X", which is a simplified interface
> specifically for DOS graphics apps so manufacturers could write
> installable video drivers for their software to run under DV/X.
> [This is similar to Window's video drivers...]
> -- 
> Dan Bodoh                      

Good idea, but rather than another layer wouldn't it make more sense
for Borland to add an option to their products so that the compiler generates
code for an X display, rather than DOS graphics, from the BGI calls.

This would put the burden on Borland and any other compiler seller,
but it seems that would be the best way to get the job done right.

I know that this would be a good way to get me to buy a compiler
upgrade.

Kevin Knappmiller
Solar Lab
Colorado State University
Fort Collins, CO  80523
(303)491-8215
kk881595@longs.lance.colostate.edu
Newsgroups: comp.os.msdos.desqview
From: jrd@cc.usu.edu
Newsgroups: comp.os.msdos.desqview
Subject: Re: Bug in DV screen shadowing?
Date: 28 Jul 92 11:33:40 MDT
Organization: Utah State University

In article <1992Jul28.133417.6240@donau.et.tudelft.nl>, cornet@zen.et.tudelft.nl (Jan-Pieter Cornet) writes:
> 
> I have encountered a strange phenomenon regarding the shadow screen
> buffer in DV. When I set "Writes text directly to screen" to Y, then the
> (hardware) cursor won't move in that window as soon as some DV- aware
> program has started shadowing via the AX=2B02/INT 21h call, unless via
> a DV-specific cursor motion (ie. sending a window stream with opcode C0
> in it). Note that the setting of "Virtualize text" makes no difference
> at all, because I'm using a 286.
> 
> I mentioned this "hanging cursor" problem before in this group, but
> nobody knew an answer at that time. To cure the problem while on the
> command line, I've written a small program that does nothing more than
> issuing a "stop shadowing" call (ie. AX=2B05h, CXDX="DESQ", INT 21h,
> see Ralf's interrupt list for more info), but this of course is not a
> decent solution. (In case anyone is interested in this 16 byte program
> I could easily mail it or post it or ftp it or /dcc it, whatever...)
	<parts omitted> 
> Thanks,
> 
> -- Jan-Pieter
> cornet@duteca.et.tudelft.nl
-------------
	The way I handle this successfully is to inform DV of screen updates
each time they occur. I test for, and use, the shadow buffer, and then tell
DV the buffer locations which have been changed. See MS-DOS Kermit file 
MSYIBM.ASM for details on the matter. 
        Joe D.
Newsgroups: comp.os.msdos.desqview
From: garyrich@qdeck.com (Gary Rich)
Subject: Re: dv/x redraw detection
Organization: Quarterdeck Office Systems, Santa Monica CA
Date: Tue, 28 Jul 1992 16:29:34 GMT

In article <1992Jul25.102713.29092@bernina.ethz.ch> hoesel@igc.ethz.ch (Frans van Hoesel) writes:
>
>Using bgi-driver in 800*600*256 in my program (with a etseng compatable
>graphics card (colorimage 6)) dv/x refuses to redraw the screen, even
>when backing store is enable. Note that it redraws fine on many other
>programs, not using the 800*600*256 graphics mode, but my program needs
>that mode.
>
>So given the fact that dv/x fails to redraw the screen, is there an easy way
>to detect that my programs needs redrawing?
>Until now I didn't use any dv/x specific commands in my program.
>I'll think i'll need two calls at least: one to detect if my program is running
>within dv/x and if so then another call to detect if my program needs
>redrawing.
>
>I don't have any dv/x programmers documentation (and not the money to buy
>their development stuff), so any help would be appriciated.
>
1)  Dos graphics work only in a "DIRECT WINDOW". They do not run VIRTUALIZED
    in the server.
2)  Backing Store only applies to the server.
3)  Direct windows will only save and restore 640x480x16 (VGA mode 12)

garyrich <support@qdeck.com>
From: bodoh@xraylith.wisc.edu (Daniel J. Bodoh)
Newsgroups: comp.os.msdos.desqview
Subject: Re: DVX and DOS Graphic apps (was Re: DV/X and Tame?)
Date: 29 Jul 92 13:29:27 GMT
Organization: Center for X-ray Lithography, UW-Madison

In article <1992Jul29.014210.12629@NCoast.ORG> allbery@ncoast.org (Brandon S. Allbery KF8NH) writes:
>As quoted from <1992Jul28.013909.26770@xraylith.wisc.edu> by bodoh@xraylith.wisc.edu (Daniel J. Bodoh):
>+---------------
>| Here's a partial solution to the problem:  Has QOS considered it?
>| 
>| There are a variety of graphics display standards available,
>| one that I can think of off the top of my head is Borland's BGI.
>+---------------
>
>I think *you* need to consider that the features of the X server are
>determined by GSS, not QOS.  Now, if you can convince *them* to provide BGI
>and Windows APIs, etc., then you've got something.  (I would suggest that,
>with the PC market the way it is at present, a Windows API should have a much
>higher priority than a BGI driver.)

What I am proposing is not a change to the X standard, but a layer on
top of it, specifically for DV/X.  A layer of code that translates
BGI (or whatever) requests to X requests and X events back to BGI
events.  Later on in my post, I proposed a similar layer, maybe
we could call it "Trivial X", which is a simplified interface
specifically for DOS graphics apps so manufacturers could write
installable video drivers for their software to run under DV/X.
[This is similar to Window's video drivers...]
-- 
Dan Bodoh                       | U.S. Citizens: For less gov't and more 
Grad Student                    | freedom, vote Libertarian.  FTP think.com 
University of Wisconsin-Madison | pub/libernet for more info.
From: ralf+@cs.cmu.edu (Ralf Brown)
Newsgroups: comp.os.msdos.desqview
Subject: Re: Scaled DOS Window
Date: 28 Jul 92 02:29:38 GMT
Organization: School of Computer Science, Carnegie Mellon

In article <mike02070920626135716@batpad.lgb.ca.us> mike@batpad.lgb.ca.us (mike batchelor) writes:
}tjmeyer@acsu.buffalo.edu (Thomas J. Meyer) writes:
}> Every time I open a scaled DOS window, the background and text colors are
}> ridiculous.  Is there a way to control this? e.g., have a white background
}> with black text?
}
}Page 130 of the User Guide, Chapter 8: Using DVP Manager.

Yeah, "Uses own colors = Y" will set the window to white on black, but some
of us would like to have different instances of the same window with different
colors.  Under DV Classic, you can define four different color schemes which
DV cycles among (windows 1,5,9,etc. get the first scheme, etc.) for windows
which are set to "Uses own colors = N".  Unfortunately, even though DV/X
does the same cycling among four different color schemes, I have not found
any way to customize those color schemes.  Blue on cyan, Blue on Green, Blue
on Brown, and White on Red are rather poor choices IMHO....

-- 
Internet: RALF+@CS.CMU.EDU   |The University would disclaim this if it knew...
FIDO: Ralf Brown 1:129/26.1  |"Wisdom is the quality that keeps you from
BIT: RALF%CS.CMU.EDU@CARNEGIE| getting into situations where you need it."
AT&Tnet: (412)268-3053 school|		-- Doug Larson
From: docw@qdeck.com (Doc Williamson)
Newsgroups: comp.os.msdos.desqview
Subject: Re: Game program hangs DesqView
Date: 22 Jul 92 21:58:24 GMT
Organization: Quarterdeck Office Systems, Santa Monica CA

In article <682@tdat.teradata.COM> swf@tdat.teradata.com (Stanley Friesen) writes:
>Hi, I have found an odd problem with a new game I bought.
>
>When I run it under DesqView (version 2.31, under QEMM 5.11) it hangs
>my computer (completely, I have to RESET to get it back).
>
>The game is Strike Eagle II from MicroProse, and it claims to only need
>384K of memory, and my game window has about 600K, so memory should not
>be a problem.
>The only odd thing about the game is that it uses a key disk based
>copy protection scheme.
>
>Any idea what is going on?  And what can be done about it?
>
>-- 
>sarima@teradata.com			(formerly tdatirv!sarima)
>  or
>Stanley.Friesen@ElSegundoCA.ncr.com

Most game programmers assume that their program will be the only software running on a DOS machine (other then the OS), and tend to take a liberal attitude towards any shortcuts they can devise.  DESQview tends to rely on programs following some of the "rules" of "polite" programming .  In particular the things these programs tend to do that are "rude" include directly accessing ROMs (especially
the video ROM) instead of using the appropriate interrupt or BIOS call.

Another particular problem with game software under DESQview is that DV has a 
maximum "supported" resolution of 640x480x16colors .  Most games try to give you 
the highest available resolution, and especially if this is 1024x?x? or most 
hi-res modes in 256 colors, which will tend to lock up DV, especially when you try to rbing up the DV menu.
If you set up the game for 640x480x16 it MAY run, but many game routines are timer 
sensitive, and since it is only seeing its own window's timer ticks, the response is poor at best.

 -- Doc Williamson  <supportq @deck.com>
Newsgroups: comp.os.msdos.desqview
From: silano@newton.cs.jhu.edu (Mike Silano)
Subject: DV/X and NCSA Telnet WORKS!
Organization: Johns Hopkins Computer Science Department, Baltimore, MD
X-Newsreader: Tin 1.1 PL4
Date: Thu, 23 Jul 1992 17:55:26 GMT

My company just received DV/X last week.  A few problems here and
there, but overall, very stable.  One problem though was that
none of my TCP/IP software would run.  This is the same problem I have
seen using any telnet program and a task swapper.  

The reasons for this are clear - when the task is swapped out, 
the ISR(Interrupt Service Routine) is swapped as well.  All I/O 
with the packet drivers is interrupt driven.  Hence, the task is
swapped and the machine goes boom..  (Please correct me if I'm off
on this...)

The solution to this is pktmux - the packet driver multiplexor.
I FTP'd this from omnigate.clakrson.edu, in the 
/pub/gw/pktmux directory.  There were no docs.  Apparently, pktmux
implements a protocol stack or at least a buffer around the 
drivers.  Bottom line - CUTCP/NCSA telnet works from DV/X.  

One note - NCSA, ver 2.3.05 (the latest, I think) fails to properly 
reset the multiplexed packet driver.  After exiting NCSA, the command
pktdrv <int num> /r must be used to reset the driver.  

Enjoy.

-Mike Silano


Replies, comments, flames, or other to silano@cs.jhu.edu.
Newsgroups: comp.os.msdos.desqview