getProtocolNumber garbage (was: Network on Win98: failed - socket - no error ??)

okay, after giving myself a day to recover from the frustration,
I've given it fresh try today, and can at last report the source 
of the problem and a workaround (thanks to Sigbjorn for helping
me to narrow down the source). I leave precise location of the 
bug and proper fix to the experts:-)

ghc's 'getProtocolNumber "tcp"' returns garbage on my win98 box
(ghc-5.04.2, perhaps a marshalling problem??).

    perl's version gives me: 6
    ghc's version gives me: 1398538246

Putting in the more sensible value explicitly makes the program
work as expected, so winsock was really quite right to report 

    WSAEAFNOSUPPORT 10047
    Address family not supported by protocol family,

just that I didn't expect the error to be with the parameters.. 
(and my hacked-up error-reporting didn't include the 
erroneous values themselves..). 


On the topic of libraries: although ghc doesn't value binary compatibility
as high as its user's do;-) I would expect the libraries to develop faster than
ghc's binary incompatibilities in the near future (or is this unreasonable?).

So it would really be useful to have regular binary snapshots of the libaries,
built to work with(*) the latest binary release of GHC, but distributed 
separately. 
When the current libraries can no longer be built for the latest GHC release, 
it's
a sure sign that a new one is needed..

(*) note that this might well be different from "built with", as long as the 
ghc 
    modifications needed do not compromise binary compatibility.

>A word of caution here.  Parts of the libraries, especially base/GHC/*,
>may be GHC-version-specific.  We do not put lots of ifdefs in the
>library sources to cope with different GHC versions, because they are
>expected to be built with the GHC from the same tree.  
>So, it may work, but it may not.

The usual cvs-rule is not to check in things that don't compile, so even
without lots of ifdefs, it would be useful to have a simple text file for
each package, stating the version of GHC/Hugc/nhc with which it was
compiled (and wether or not it compiles with the latest binary release?).

Btw, does the web interface to the cvs-tree give me an easy way to see 
the precise source versions wich make up the latest binary release? I find
it difficult to check whether there have been any changes relevant to my
problems. A good start would be to have the tag for the latest binary release
as the selected diff target by default?

Finally cheerful again,
Claus