marc@mercury.sybase.com (04/25/89)
I hope this hasn't been previously discussed but:
We're attempting to implement a Windows .DLL library for use
with Excelan's EXOS TCP/IP networking routines. These has been a lot
of speculation around here that in fact (with out modification)
Excelan can't be implemented under Windows. Our reasoning ? Well...
Windows grabs and controls all the timers right ? The network wants
to grab a timer for its own timing requirements and hence you have a
resource conflict. Are these assumption fact or fiction. Has anyone
else done work with Window running in a network environment
(other than
MS-NET or DOS Lan Man ??).
Thanx,
_Marc
------------------------------------------------------------------------------
"We don't guarantee, any work caused by or arising out of the failure
of the owner to comply with instructions or recommendations."
Marc E. Strohwig - "Oppinions ?? Mine, mine, mine!!"
Sybase, Inc. marc@sybase.com
Emeryville, CA {pacbell, lll-tis, pyramid,sun}!sybase!marcmjr@tigger.planet.bt.co.uk (Martyn Reason) (05/02/89)
From article <4005@sybase.sybase.com>, by marc@mercury.sybase.com: > I hope this hasn't been previously discussed but: > > We're attempting to implement a Windows .DLL library for use > with Excelan's EXOS TCP/IP networking routines. These has been a lot > of speculation around here that in fact (with out modification) > Excelan can't be implemented under Windows. Our reasoning ? Well... > Windows grabs and controls all the timers right ? The network wants > to grab a timer for its own timing requirements and hence you have a > resource conflict. Are these assumption fact or fiction. Has anyone > else done work with Window running in a network environment > (other than > MS-NET or DOS Lan Man ??). > > Thanx, > _Marc > Some time ago I attempted to write a Windows 2.03 application which contacted a server process running on a VAX host using Sun's PC-NFS. I ran into the same timing problems with Windows taking the timers calls. A call to the NFS callrpc () function caused to machine to hang. Having contatcted the Sun support people here in England, they told me that there was nothing that could be done - it is up to the guys at Microsoft to fix the problem. +----------------------------------------+ | Martyn Reason | | | | British Telecom Research Labs. | | RT5111 | | Martlesham Heath, IPSWICH | | Suffolk, IP5 7RE. | | ENGLAND | | | | National: Ipswich (0473) 646779 | | International: +44 473 646779 | | email: mjr@planet.bt.co.uk | +----------------------------------------+
richk@pogo.WV.TEK.COM (Richard G. Knowles) (05/06/89)
In article <218@tigger.planet.bt.co.uk> mjr@tigger.planet.bt.co.uk (Martyn Reason) writes: >From article <4005@sybase.sybase.com>, by marc@mercury.sybase.com: >> We're attempting to implement a Windows .DLL library for use >> with Excelan's EXOS TCP/IP networking routines. These has been a lot >> of speculation around here that in fact (with out modification) >> Excelan can't be implemented under Windows. Our reasoning ? Well... >> Windows grabs and controls all the timers right ? The network wants >> to grab a timer for its own timing requirements and hence you have a >> resource conflict. Are these assumption fact or fiction. Has anyone >> else done work with Window running in a network environment >> (other than >> MS-NET or DOS Lan Man ??). > > Some time ago I attempted to write a Windows 2.03 application which >contacted a server process running on a VAX host using Sun's PC-NFS. I >ran into the same timing problems with Windows taking the timers calls. >A call to the NFS callrpc () function caused to machine to hang. Having >contatcted the Sun support people here in England, they told me that >there was nothing that could be done - it is up to the guys at Microsoft >to fix the problem. I don't know for sure about the Windows environment but I have found that Excelan has a timer bug in their soselect call, such that the application may hang in an infinite loop waiting for a timeout. You might be able to avoid timer use if you avoid that call. (BTW, If Excelan is reading, that bug exists in the last lines of the routine "giveup" which is called from "soselect". It is in a while loop waiting for two variables/memory-locations to become equal in value. I always found the first to be zero and the second to be one, never the twain to meet. Library version 3.2.3). Now if the TSR driver code is using the timer I doubt there is any recourse. In my application (rlogin, which Excelan does not provide to DOS users) I needed to be able to perform non-blocking I/O on the socket connection as well as the PC keyboard, so I was forced to use the asynchronous interface to the socket. But that made the application non-swappable to Windows (since the Excelan driver notified the application of data availability via an interrupt thread). What I eventually discovered was a way to force the synchronous socket interface to become non-blocking also. To do that I just forced non-blocking I/O mode by setting the FIOBIO soioctl parameter to 0. Then I performed a normal soread on the socket I was interested in. If the character count returned was -1 then nothing was available. Note that a return value of -1 from soread is *not* documented. Give it a try and see if it works. I have been thinking about rewriting rlogin as a Windows application so I would like to know if it is even possible before I go and *waste* all that effort. It is at least Windows compatible now, and although it requires full screen access, you can cut-and-paste to other applications. -------- Whatever I say is my fault and no one elses! ----------- Richard G. Knowles richk@pogo.WV.TEK.COM Graphics Printing and Imaging (503) 685-3860 Tektronix, Inc; D/S 63-356 Wilsonville, Or 97070 or just yell "Hey, Rich!"