A01DGU1@MVS.CSO.NIU.EDU (Dave Ulrick) (03/24/91)
I have recently installed PC/TCP v2.07 on my 80386 PC. I'm trying to run it in a DESQview window under DESQview v2.26 and MS-DOS v4.01. Additionally, I'm trying to run a 3270 emulation program (Attachmate Extra! v1.41) in another window. Doing this seems to work for a while, but sometimes things in the PC/TCP window just die. It seems to happen most often when I'm using FTP. My PC doesn't freeze--pressing <alt> will still give me the DESQview window--but I am essentially locked out from doing anything in the PC/TCP window. I can close the window and reopen it, but my next TN3270, PING, FTP, etc., will be greeted with a message complaining about the TCP/IP kernel being reentered. The only solution (such as it is) that I've been able to find is to shut down all of my DESQview windows, quit DESQview, and press CTRL-ALT-DEL. I've tried entering INET UNLOAD and then reloading the kernel--the former says that it works, but when I try to load the latter it says that it's already been loaded. I'm loading the kernet (ETHDRV.EXE) in my AUTOEXEC.BAT before I enter DESQview. I'd be interested in hearing about anything that you folks have found successful in coaxing PC/TCP to run properly under DESQview. As it is, it looks like I'm not going to be able to run it there. Thank you for any advice/hints that you are able to offer! Dave =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dave Ulrick Bitnet: A01DGU1@NIU (MVS/XA) Northern Illinois University A01DGU1@NIUCS (VM/SP) DeKalb, IL, USA Internet: a01dgu1@vm.niu.edu
fks@FTP.COM (Frances Selkirk) (03/26/91)
We know of no problems between PC/TCP and DESQview. Unless the 3270 emulator you mention, however, is using our stack, you are trying to run two TCP/IP stacks! That will cause problems such as the hang you describe. The second IP takes the network interface, and the first one starves. Since closing the window does not actually terminate the application, the next attempt to run one of our applications finds the kernel already in use. The same problem will occur with other combinations of TCP/IP packages that do not share a stack. The current release, for those of you who were wondering, is 2.05. Frances Kirk Selkirk info@ftp.com (617) 246-0900 FTP Software, Inc. 26 Princess Street, Wakefield, MA 01880
ian@unipalm.uucp (Ian Phillipps) (03/27/91)
A01DGU1@MVS.CSO.NIU.EDU (Dave Ulrick) writes: >I have recently installed PC/TCP v2.07 on my 80386 PC. I'm trying >to run it in a DESQview window under DESQview v2.26 and MS-DOS v4.01. >Additionally, I'm trying to run a 3270 emulation program (Attachmate >Extra! v1.41) in another window. Doing this seems to work for a >while, but sometimes things in the PC/TCP window just die. >I'd be interested in hearing about >anything that you folks have found successful in coaxing PC/TCP >to run properly under DESQview. As it is, it looks like I'm not >going to be able to run it there. I use DESQview and PC/TCP most of the time. It's not ideal, but survives most of the time. An application in one DESQview window which calls the Kernel concurrently with another will get an error decodeable as "kernel re-entered". Some applications (the latest TN, Interdrive) treat this as a recoverable error, and retry. The result is that things work slowly (presumably there's some serious busy-looping going on in there). Other applications, e.g. FTP's own domain-name-service lookups in TN; Century Software's Tiny Term, treat this as a hard error. TN's DNS reports the "kernel re-entered"; Tiny Term exits. I'm not sure what happens if an application sets up a call-back. If someone at FTP can tell me one of theirs that does, I'll try it and see if I can break the combination. Presumably all will be well when Desqview X arrives.
PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) (03/28/91)
On Sat, 23 Mar 91 20:54:00 CST Dave Ulrick said: >I have recently installed PC/TCP v2.07 on my 80386 PC. I'm trying >to run it in a DESQview window under DESQview v2.26 and MS-DOS v4.01. A module in common memory won't do an upcall correctly if it isn't DESQview aware and switches in the application memory before the call. Consequently, all of the drivers up to the kernel must be loaded *within* the application. DESQview *will* dispatch the hardware interrupt correctly. Alternatively, Quarterdeck have written a front end called DVFTP to the kernal. With it, multiple PC/TCP applications run multitasked. But it doesn't work quite well with regard to performance. Quarterdeck wish the kernel to be made reentrant, but FTP Software never replied my question whether they want to do that. Sigh, it would be super. Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
jbvb@FTP.COM ("James B. Van Bokkelen") (04/02/91)
Quarterdeck wish the kernel to be made reentrant, but FTP Software never
replied my question whether they want to do that. Sigh, it would be super.
As a concept, we like DesqView/X, but we've tried to talk to Quarterdeck about
it with little success. No Quarterdeck person with engineering responsibility
has ever called or sent e-mail to me. We don't have a copy of DVFTP in-house
(the last I heard was a Quarterdeck support person saying he couldn't send it
because it wasn't in production yet). "Re-entrancy" is a very broad set of
issues, and won't get resolved until the relevant architects discuss it.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901