On Thu, Apr 01, 2004 at 02:58:20PM -0500, Richard Drummond wrote: > It's certainly the best solution we have at the moment. Winner by default? =) > I had a go fixing a couple of things. And I tried to remove the dependency on > pthreads (and use whatever thread layer UAE is using instead). That still > has problems, because I haven't done the signal handling - so aborting a > socket doesn't work for instance. IIRC the signal handling never worked right anyway. (And it only matters when an amiga-side signal is supposed to interrupt a call to bsdsocket.library, so it's seldom important. At least that's all I remember it doing..) > I have considered porting the windows version, but while that would be the > best solution for maintainability - I'm not convinced it would be technically > the best solution. The stack magic code that the win32 version relies on to > call Amiga code would cause all kinds of portability problems, IMHO. I call amiga code too somewhere. That is, uae_Signal() must be doing it. When I started that didn't work, and I really never called the amiga from the native side, but that meant the amiga side had to poll for signals.. (Fixed in 0.8.14 or something like that.) Actually I suppose something might be polling for uae_Signal(), I've never checked.. But last I looked at the windows-version it also called all these strange windows functions I'd never heard of.. > I think > it's a better idea to handle more of the work in the bsdsocket.library > wrapper itself as you have done in your version. (BTW, I've been meaning to > re-write that in C, since I don't have an E compiler, but haven't got around > to it yet). Why not just download the E compiler from aminet? Also, regarding requiring the library in the filesystem (I read some of the archives): There is no reason for my version to do that except convinience while developing. After that the (binary) library can just be included in the uae binary, and inserted during autoconfig or whereever.