From neil_r@gradient.com Mon May 2 06:42:18 1994 Received: from indy.gradient.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA04065; Mon, 2 May 1994 10:42:37 -0400 Received: from donna (donna.gradient.com) by indy.gradient.com (5.0/Gradient-2) id AA13269; Mon, 2 May 1994 10:42:19 +0500 Message-Id: <9405021442.AA13269@indy.gradient.com> X-Sender: neil@gradient Date: Mon, 02 May 1994 10:42:18 -0400 To: paul@atlas.abccomp.oz.au, Multiple recipients of list From: neil_r@gradient.com (neil) Subject: Re: Local communications optimized? X-Mailer: Content-Length: 1986 At 11:08 AM 4/30/94 -0400, paul@atlas.abccomp.oz.au wrote: >Thus expounded Jim Greuel X2493 on Apr 26, 6:44pm: >/-------------------- >|Are there any winsock implementations which optimize local >|communications (i.e., communications in which the "remote" >|socket is actually on the local node) by using some local IPC >|mechanism rather than sending the data down the networking >|stack, ala Unix domain sockets? > >Jim, >What other IPC mechanism did you have in mind - sending a windows >message to yourself? :) Why go the long way round sending the data to >yourself when you can simply pass it down your own code chain and >back up again? Not to gainsay the point above, which is valid enough in some cases, but... Let's not forget, everybody, that a client may want to contact a server w/out knowing at compile-time where the server resides at all, not even whether or not it's on the same host as the client. Unix apps rely on loopback to do this in a transparent fashion. And lots of folks are required to port Unix code to Windows. Me, ferinstance. So, let's keep this functionality in the API, and just implement it in the DLL in an efficient way. And while I'm ranting... we really should have BSD-style loopback in the next Winsock spec. I hate it when implementors say "oh, we don't have loopback, and you've got no grounds for complaint because it's not spelled out in the spec." And don't forget, there are two styles of loopback in the BSD world - one where you give an IP address that happens to be that of your host, and another where you give an IP = 127.0.0.1. The first is much more important, IME, but thoroughness counts. ------------------------------------------------------------------------- neil_r@gradient.com (Neil Rowland) "A simple man believes anything, but a prudent man gives thought to his steps." Proverbs 14:15 ------------------------------------------------------------------------- From paul@atlas.dev.abccomp.oz.au Tue May 3 06:08:38 1994 Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA29967; Mon, 2 May 1994 20:56:13 -0400 Received: by usage.csd.unsw.OZ.AU id AA17687 (5.65c/IDA-1.4.4 for winsock-users%sunsite.unc.edu); Tue, 3 May 1994 10:55:27 +1000 Received: by atlas (4.1/1.35) id AA06987; Tue, 3 May 94 11:08:40 EST Message-Id: <9405030108.AA06987@atlas> From: paul@atlas.abccomp.oz.au Date: Tue, 3 May 1994 11:08:38 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: neil_r@gradient.com (neil), paul@atlas.abccomp.oz.au, Multiple recipients of list Subject: Re: Local communications optimized? Thus expounded neil on May 2,10:42am: /-------------------- |At 11:08 AM 4/30/94 -0400, paul@atlas.abccomp.oz.au wrote: |>Thus expounded Jim Greuel X2493 on Apr 26, 6:44pm: |>/-------------------- |>|Are there any winsock implementations which optimize local |>|communications (i.e., communications in which the "remote" |>|socket is actually on the local node) by using some local IPC |>|mechanism rather than sending the data down the networking |>|stack, ala Unix domain sockets? |> |>Jim, |>What other IPC mechanism did you have in mind - sending a windows |>message to yourself? :) Why go the long way round sending the data to |>yourself when you can simply pass it down your own code chain and |>back up again? | |Not to gainsay the point above, which is valid enough in some cases, but... | |Let's not forget, everybody, that a client may want to contact a server |w/out knowing at compile-time where the server resides at all, not even |whether or not it's on the same host as the client. | |Unix apps rely on loopback to do this in a transparent fashion. And lots of |folks are required to port Unix code to Windows. Me, ferinstance. Neil, I agree completely. In the message fragment above, I was referring (although its not too clear) to the packet path within the Winsock implementation, not the application. For loopback, which should be transparent to the application and just look like the remote end is responding very quickly, the application should send the packet to either 127.0.0.1, or the IP of the local machine. The _WINSOCK.DLL_ should then recognise the packet is actually for itself once the packet reaches down to the IP layer, and then pass it back up within the DLL for delivery. I took the original query to be referring to the internal implementation of loopback within a WINSOCK.DLL, not an application. |And while I'm ranting... we really should have BSD-style loopback in the |next Winsock spec. I hate it when implementors say "oh, we don't have |loopback, and you've got no grounds for complaint because it's not spelled |out in the spec." | |And don't forget, there are two styles of loopback in the BSD world - one |where you give an IP address that happens to be that of your host, and |another where you give an IP = 127.0.0.1. The first is much more important, |IME, but thoroughness counts. All WINSOCK.DLLs should automatically behave this way, and those that don't are broken and should be exposed to the world as deficient - which stacks have you used that don't properly loopback packets both to the local IP number and 127.0.0.1? name them, then stone them :) It _is_ spelled out in the spec - paragraph 1.2 "The Windows Sockets Specification has been built upon the Berkeley Sockets programming model..." - if BSD does it, then Winsock should too, without it needing to be spelled out in the spec, although for completeness sake it should be, for those of us unfamiliar with programmming Berkeley Sockets under Unix. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From neil_r@gradient.com Tue May 3 05:53:28 1994 Received: from indy.gradient.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AA19328; Tue, 3 May 1994 09:54:35 -0400 Received: from donna (donna.gradient.com) by indy.gradient.com (5.0/Gradient-2) id AA07044; Tue, 3 May 1994 09:53:30 +0500 Message-Id: <9405031353.AA07044@indy.gradient.com> X-Sender: neil@gradient Date: Tue, 03 May 1994 09:53:28 -0400 To: paul@atlas.abccomp.oz.au, paul@atlas.abccomp.oz.au, Multiple recipients of list From: neil_r@gradient.com (neil) Subject: BSD-style loopback (Re: Local communications optimized?) X-Mailer: Content-Length: 1819 >All WINSOCK.DLLs should automatically behave this way, and those that don't >are broken and should be exposed to the world as deficient - which stacks >have you used that don't properly loopback packets both to the local >IP number and 127.0.0.1? name them, then stone them :) Oooh... an excuse to blow off more steam! Let's see.. last time I tried PC-NFS (5.0, I think) it didn't support loopback by local host address. Not only didn't it work, but their tech support said it wasn't supposed to work. That got me very irate `coz the code I was porting was abjectly dependent on this functionality. I've also tried 127.0.0.1... PC/TCP 2.2 and Pathway 1.2.1.2 patch 129 couldn't handle it, but this is a quibble from my POV. I was able to work around with a localized patch to the source I was porting, that simply switched to the other style of loopback. Chameleon supports both styles. Hats off to them. >It _is_ spelled out in the spec - paragraph 1.2 "The Windows Sockets >Specification has been built upon the Berkeley Sockets programming model..." >- if BSD does it, then Winsock should too, without it needing to be >spelled out in the spec, although for completeness sake it should be, for >those of us unfamiliar with programmming Berkeley Sockets under Unix. Kudos to those who accept this inference as valid (I do). But sometimes you've gotta spell things out, to leave folks no excuse. Sort of make the spec sophist-proof. (Completeness' sake is also a good reason.) ------------------------------------------------------------------------- neil_r@gradient.com (Neil Rowland) "A simple man believes anything, but a prudent man gives thought to his steps." Proverbs 14:15 ------------------------------------------------------------------------- From perrier@onera.fr Thu May 5 18:01:52 1994 Received: from onera.onera.fr by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AC05046; Thu, 5 May 1994 10:02:10 -0400 Received: from minerve.noname (minerve) by onera.onera.fr (5.65c/1.34) id AA01517; Thu, 5 May 1994 16:01:58 +0200 Received: from bubulle by minerve.noname (4.1/SMI-4.1) id AA00812; Thu, 5 May 94 15:49:55 +0200 Message-Id: <9405051349.AA00812@minerve.noname> X-Sender: perrier@minerve Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 05 May 1994 16:01:52 +0200 To: winsock-users@sunsite.unc.edu From: perrier@onera.fr (Christian Perrier) Subject: X-Mailer: From dob@tis.inel.gov Mon May 9 14:48:12 1994 Received: from mica.inel.gov by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP id AB00964; Mon, 9 May 1994 22:47:51 -0400 Received: from dewey.inel.gov (dewey.tis.inel.gov) by mica.inel.gov (4.1/INEL-MH-10.0) id AA04512; Mon, 9 May 94 20:47:48 MDT Received: by dewey.inel.gov (5.65/INEL-WKS-2.0) id AA01095; Mon, 9 May 1994 20:48:12 -0600 Date: Mon, 9 May 1994 20:48:12 -0600 Message-Id: <9405100248.AA01095@dewey.inel.gov> From: gopher@tis.inel.gov To: winsock-users@sunsite.unc.edu Subject: WSGopher 1.0 is here! This announces the latest version of WSGopher, 1.0. You'll find the self extracting archive file 'wsg-10.exe' on boombox.micro.umn.edu in pub/gopher/Windows, and sunsite.unc.edu in pub/micro/pc-stuff/ms-windows/winsock/apps. -- Please note: WSGopher is copyrighted software. You may freely use any and all of the files in the WSGopher distribution, and you may freely distribute the file wsg-10.exe. However, you may not distribute for profit the WSGopher executable or the file wsg-10.exe without permission from EG&G Idaho, Inc. If you wish to do this, or if you wish to obtain a non-exclusive source license, please contact Steve Borror, email swb@inel.gov, phone (208) 526-3883, or mail me at gopher@tis.inel.gov. The file wsg-10.exe is a self extracting archive. Please consult the section below entitled "Installation". If you try to run wsg-10 from the Program Manager, you will probably get errors, and it certainly won't work. -- Will the "real" 1.0 please stand up? If you had a copy of 1.0 prior to this announcement, please upgrade. The *official* 1.0 has a date of May 9, 1994; check the "About" box if you have any questions. -- Important additions since the last public release (0.9g): * WSGopher now has a help file, which includes pretty much everything you need to know as well as a description of features, what's new, and bug fixes. The help file is also context sensitive, so you can easily get help with whatever you are currently doing. See the Help File for much more detail on the following items. * WSGopher now supports Gopher+, including Ask blocks (or "Ask forms" as I call them in the help file). * WSGopher supports print preview and printer fonts. * WSGopher supports text search within a directory, text or phone window using the "standard" Windows 'Find' dialog. * Changes to the Bookmark Editor include: It is now non-modal, meaning you can interact with other windows while the editor is up. You can minimize the bookmark editor (which beats scooting it out of the way) It supports multiple sets of bookmarks, called "categories". You can create, delete and rename categories via the category dialog. You can move bookmarks between categories. Because of the bookmark changes, the format of how bookmarks is stored is also changed. See the "Installation" section for more information on how this may affect you. Bookmark Titles and paths are now stored with URL style encoding. This will mostly affect bookmarks with binary characters or trailing blanks in the path, or possibly special servers that let you hop over firewalls. Also, titles with multiple languages are stored properly. You can select multiple items in the bookmark list. This means that you can Move, Delete and copy to the clipboard more than one bookmark at a time. You can paste multiple bookmarks *from* the clipboard to the current category; these bookmarks can be in canonical format, or URLs. Look out, Archie! * The "New Gopher" dialog now accepts Gopher URLs. You can copy a URL to the Windows clipboard, and when the dialog comes up, it will process the URL just like it processes "standard" bookmark formats. You can also type or paste a URL into the dialog. * WSGopher will strip trailing dots from hostnames, for those users having difficulty with their WinSock stack. * Both telnet and 3270 emulation is supported. In addition, WSGopher takes the experimental and radical step of supporting Gopher+ specification of terminal emulation. This way, Gopher servers can advertise new and exciting types of emulation without requiring that new Gopher types be added to the core protocol. WSGopher now supports host name and (optional) port numbers via command line substitution; this means you can easily make a correct command line for your favorite telnet program, and WSGopher will put in the host and port values at the right time. There are "Host" and "Port" buttons in the telnet setup dialog to facilitate this. * The bitmaps and icons have been extensively revised, thanks to Ken Blackney of Drexel University. Also, thanks to the University of Minnesota for their permission to use the "Happy Gopher" in the program icon. * You can get the 'root' of a bookmark now. This should be particularly useful in Veronica searches. It works for any active window, not just directory items. * The vast majority of times you need to enter a path name, you can now use a browser button. * Cleaned up the appearance of the Information dialog; the text inside is cleaner, and you can see Gopher+ information such as views, administrative info, abstract, etc. Just use the Escape key to remove the dialog, as with most Windows dialogs. You can also minimize this window. The dialog also shows the URL, and a line of text that says what the item type is in English (for those of us who don't memorize obscure codes :-). Also added one cool feature: not only does the info window track individual bookmarks in a directory, but any time a window is activated via the keyboard or mouse, it's bookmark is shown in the info window (if it is up). * Changed lookup of files from current/installed/windows to current/windows/installed/path (that is, the path environment variable). This was suggested by a user who administers a Novell network, and it made quite a bit of sense. The "What's New in WSGopher 1.0" topic in the help file lists the bug fixes. Thanks to all who helped me find them! -- Installation First, be sure to exit WSGopher if it is running on your system. Bad things happen when you overwrite a running program. Generally speaking, you will execute the file "wsg-10.exe" and unpack everything in it. Please note the following: * If you have existing bookmarks from previous versions of WSGopher that you want to keep: First, rename your WSGOPHER.INI file to something else, maybe WSGOPHER.OLD. Let's assume it is in your "wsgopher" directory. Execute the file "wsg-10.exe". Unpack everything in the distribution. Using your favorite DOS editor, copy the "Bookmarks" section from WSGOPHER.OLD to the new WSGOPHER.INI. Here is how you do that: 1) Find the text "[Bookmarks]" in WSGOPHER.OLD. Copy all this text, through the first blank line. It could be a very large chunk of text, depending on how many bookmarks you saved. 2) Open the file WSGOPHER.INI, go to the bottom of the file, and insert the text you copied from WSGOPHER.OLD. Make sure there is a blank line before "[Bookmarks]". 3) Close WSGOPHER.INI. Run WSGopher 1.0. When WSGopher sees bookmarks in the 'old' format it will create a category called "Default", translate all your old bookmarks into the new format, put them in the "Default" category, and delete the old bookmarks. * If you don't care about keeping your old bookmarks: Just overwrite your old WSGOPHER.INI file with the new one in the distribution. Are you *sure* you want to do this? * Other things you need to do to after installing WSGopher: See the Help Topic "Configuring WSGopher" for a list of suggestions. -- Vendor Info Known to work with: * SuperTCP (DLL and VxD beta) * Distinct (Lan and PPP). * PC/TCP; be sure to use version 1.10 of the DLL, NOT version 1.1 * Trumpet It's been reported to me that the following vendor stacks work: * Netmanage 3.12 and 4.0; some users have difficulty with 3.11 and previous. I have one report that a version of Netmanage 4.0 GPFs, but apparently the latest patch file (c4004.exe) resolves that. * Windows for Workgroups *IF* you use the new Microsoft VxD beta WinSock * Lanera * Persoft * Wollongong, PATHWAY RUNTIME version 2.0 * PC-NFS, IF you make sure you have the following patches: Go to ftp.york.ac.uk:/pub/pc/pc-nfs/Patches get winsock.dll 24576 25/10/93 wshelper.exe 51232 25/10/93 Thanks to Geoff Smethurst for this information. * Novell Lan Workplace 4.1; the following is from Mark Shapiro of Novell: Things to check. They should have downloaded LWP168.EXE from NetWire or ftp'd to sjf-lwp.novell.com for tcpip.exe, wlibsock.dll, winsock.dll and novasync.exe in the directory ftpguest/lwp4dos/WinSock. These files should be copied to the LAN WorkPlace bin directory, default is \net\bin. The lwpcon.* and snmp.exe files should also be copied there if they're running the LAN WorkPlace apps. The following stacks are believed NOT to work: Windows NT -- Important notes: * Occasionally I hear from users who are trying to run WSGopher with the WSGOPHER.INI file with the "read only" attribute, or perhaps in a read-only directory. This is absolutely impossible; it will not work. * The files "extviews.cnf" and "language.cnf" have been added to the WSGopher distribution. They need to be writable, and they should be placed wherever you decide to put WSGOPHER.INI. That can be in the same directory you've installed WSGopher, in your Windows directory, in the directory where you execute WSGopher (if differnt), or somewhere on your DOS path. -- Thanks I'd like to give particular thanks to the beta testers, who looked at several intervening versions. In addition to the folks already mentioned, thanks to Ashok Aiyar, Ken Blackney, Ray Born, Chris Sacksteder, Dale Evans, Ellisa Evans, Sam Ramirez, Alex Reijnierse, Lois Schoen, Mary Schonsberg and David Treadwell for working with these versions, reporting problems and making helpful suggestions. Thanks to John Cooper, Rob Peterson, Phil Simpson and Steve Simon for their support. Thanks also to many, many others who have written with advice and encouragement, problem reports and questions. -- If you have any questions, please email gopher@tis.inel.gov. Thanks, Dave Brooks