mshiels@tmsoft.uucp (Michael A. Shiels) (08/06/90)
Do any of the TCP/IPs out there for the PC/AT work in multiple windows of Desqview or Windows? What type of an interface is there between the main TSR core and each program running in a seperate machine? I am trying to work on a Netbios which will be Desqview compatible but as soon as you bring in async notifications it makes things 10 times more complex. As far as I could tell there was no way the Netbios could tell Desqview to please swap in process x. Thanx.
PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) (08/07/90)
On Mon, 6 Aug 90 01:45:06 GMT you said: >Do any of the TCP/IPs out there for the PC/AT work in multiple windows >of Desqview or Windows? What type of an interface is there between the >main TSR core and each program running in a seperate machine? I am trying >to work on a Netbios which will be Desqview compatible but as soon as you >bring in async notifications it makes things 10 times more complex. As >far as I could tell there was no way the Netbios could tell Desqview to please >swap in process x. Thanx. I think you won't succeed in having a program tell DV to swap in another, but I may be wrong. In any case, I don't find it desirable. That's user only control and if it's a communication program (even in loose terms, TCP/IP client) the user should make it non-swappable or expect it to loose data. On the other hand, DV is most useful with a 386 with enough memory to hold several applications in different memory banks. Then, you must really care to *switch* in a memory bank to schedule some code there. Some theoretical ideas from a previous message below. In theory, the best would be driver, TCP and UDP in one small DV process and TCP/IP applications interfacing at the socket level via a stub loaded in common memory (e. g. before DESQview). The problem is that socket level interface is not popular on an originally non-multitasking PC and that most of the public domain software would have to be rewritten to use it. TCP Inc have a socket API and told me they have tried but failed to make it DV compatible, but I don't know how hard they tried. I guess they did try hard however, because this would have made a *tremendously useful* standard. Or are they plugged on OS/2? I also find it a pity to see the multitasking-in-DOS discussion shift to Windows. I really like DESQview and the problems are similar enough to try to solve them for both at the same time. Date: Tue, 12 Jun 90 16:12:40 +0200 From: Andr'e PIRARD <PIRARD@BLIULG11> Subject: Re: idea for packet driver/desqview/telnet combo (idea number 2) To: Steve Wallace <usc!ucselx!sol.ctr.columbia.edu!cica!ssw@UCSD.EDU>, pcip@udel.edu cc: James Van Bokkelen <jbvb@VAX.FTP.COM>, nelson@clutx.clarkson.edu On Mon, 11 Jun 90 16:29:39 GMT Steve Wallace said: >My goal is to get the packet driver/NetWare/telnet combo to work with >Desqview/windows/WP office DESQview is a tremendous multitasking tool indeed. An enhancement of the packet drivers would be most welcome. Now that we have promiscuous mode, it's regrettable that demultiplexing at the link level can only be afforded with TSR (e.g. why not NETWATCH in an other DV window?). More, could not a simple cooperative strategy demultiplex at the socket level? >I'd like to propose an enhancement to the packet driver spec. Those of >us who use multi-taskers (Desqview, Windows, etc) are not able to >cleanly use Novell netware and other network software at the same time. >The netware shell can't be loaded in a window, therefore the packet >driver must be loaded before the multi-tasker. Applications like telnet >will run in a window, but if there are other applications running in the >background, telnet will eventually hang. The packet driver is executing >the function pointed to by receiver, but the real receiver is paged out. >When the receiver function was called by the packet driver and >when the packet driver copies the packet to the buffer, the packet >driver checked the receiver's signature. If the signature is incorrect >the packet driver pauses, then checks again. No, this will not work. Simply because the receiver can be in another memory bank, because receive() -- and upcall() if I understand correctly -- occur at hardware interrupt time, when another application can be running. Application context switching must be done. The correct way should be to schedule a second level interrupt (with GETBIT/SETBIT) that finally does a PGMINT that will be forced to execute (asynchronously) in the correct environment (look in DESQview API manual, but also check this pure theory with Quarterdeck!). Only then can a packet driver be loaded before DESQview, outside an application, and shared. Under DESQview, communication programs should be non-swappable (to disk); I guess the previous scheme would work even then, if the driver is prepared to accept a (longer) delay of the final asynchronous interrupt. Now, multiple stacks for the *same* network protocol would be nice too. The correct solution would be a DESQview-aware socket interface, but would need extensive changes to packet-level TCP/IP applications. I am far from a TCP/IP guru, but I guess this could be solved in a simpler way if the packet driver had additional functions to help applications not allocate duplicate sockets and not send a reset in reply to a datagram sent to someone else's socket. 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 on EARN/BITNET 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 on EARN/BITNET