michiel@idca.tds.PHILIPS.nl (Michiel Fierst van Wijnandsbergen) (02/14/90)
Is there any one who has a TCP communication program working under MS-Windows? We tried to use TCP of FTP Software and WIN/TCP of Wollongong, but with both versions we are having problems with the first 'socket' call. TCP of FTP is crashing and WIN/TCP of Wollongong gives the error(19) "no such device". We use in combination with TCP of FTP a NI5210 ethernet card and in combination with WIN/TCP a 3com Ethernet link II. We only have these problems under MS-Windows. The MS-Dos equivalent of our programs is running with both TCP versions. If you have a TCP version running under MS-Window, please tell us some details about your TCP version, configuration of your PC (hardware and software) and maybe some c program how to open a connection. -- # Michiel Fierst van Wijnandsbergen Internet fierst@idca.tds.philips.nl # # Philips Telecomm. and Data Systems UUCP ...!mcvax!philapd!fierst #
paul@cscnj.UUCP (Paul Moody) (02/21/90)
In article <972@ssp18.idca.tds.philips.nl>, michiel@idca.tds.PHILIPS.nl (Michiel Fierst van Wijnandsbergen) writes: > Is there any one who has a TCP communication program working under MS-Windows? ...deleted... After several frustating months we managed to get our app running using Excelans Lan Workplace for DOS and windows, including Windows/386. The problem is that most TCP/IP implementations for DOS rely on 'post back' routines. They expect that if you have passed a function/buffer pair during a connection api call(OPEN), those pointers remain valid for the life of the app. This is known as asychronous non blocking api. In general this api is always used, its effects are masked by blocking until the post back takes place. Blocking until a response is recieved is unacceptable in a windows environment. Windows, especially windows/386, wants to move things around with abandon. Windows/386 will even move(swap out) fixed segments. Our solution was two fold. First we divided the application into a tcp/ip interface and the main app. The tcp/ip window is small model with fixed data and code segments. It communicates with the main app via DDE. Next we used a synchronous non-blocking api and poll the socket. This means using up a timer but this way tcp/ip wont try to put something into a buffer that windows has moved to the hinterlands of extended memory. We have been told that with care, dll's can be used under windows/286 with the more effcient asynchronous-non blocking interface. This would not help us very much since we want to use windows/386. The ultimate solution is for the various vendors of DOS tcp/ip products to provide a windows device driver for their socket interface. The device driver would live as part of dos space and would never be moved by windows. It could use the asychronous non-blocking interface to the actual tcp/ip drivers while doing SendMessage calls to give you data. Lets hope. -- Paul Moody UUCP: rutgers!cscnj!paul Computer Sciences Corporation # the opinions expressed are entirely imaginary #
leemc@csri.toronto.edu (Matthew Lee) (02/21/90)
In article <972@ssp18.idca.tds.philips.nl>, michiel@idca.tds.PHILIPS.nl (Michiel Fierst van Wijnandsbergen) writes: > Is there any one who has a TCP communication program working under MS-Windows? ...deleted... I missed the original post and perhaps followups so I hope this is not redundant information. We haven't used it but Wollongong's most recent version (4.1) of "WIN/TCP for DOS" claims Windows compatibility and comes complete with PIF files. For more info: Wollongong Canada 30 Dupont Street East. Waterloo, Ontario N2J 2G7 (519) 747-9900 This is by no means an endorsement of their product. Matthew Lee leemc@csri.toronto.edu