Re: Cygwin built DLL invoked from MSC app doesn't seem to be all there.

[jon@bigbang.com.au (Jon Wells)]

>
> Earnie Boyd wrote:
> --- Ian Zimmerman <itz@lbin.com> wrote:
> > Earnie Boyd wrote:
> > > 
> > > --- Jon Wells <jon@bigbang.com.au> wrote:
> > > > It's seems that only some bits of the cygwin API work inside a dll
> > > > invoked from a none cygwin applications.
> > > -8<-
> > > > Anyone got any thoughts? I getting really close to having to use
> > > > micromush tools and yucky ugly stuff like that..
> > > 
> > > To communicate properly between cygwin and non-cygwin processes you must
> > have
> > > set notty in the CYGWIN variable before starting bash.
> > 
> > Why?  I thought (after reading the documents) that CYGWIN=tty just
> > enabled termios calls.  What harm does it do when cooperating with
> > non-cygwin programs?
> 
> I don't know the why?  I just live with it.  The harm that it does is that the
> cygwin process cannot communicate properly with the non-cygwin process.
>

Ummm I'm talking about previously functional code, compiled with the
cygwin tools, not being able to call its own runtime iff it's loaded
by an MSC app. Stdio between processes isn't involved... although that
bit does seem to work... it's just the rest of the runtime which is
stuffed up... well mostly things to do with a process waiting in some
way.. sleep(), select(), wait() etc. Sleep not sleeping is minor
compared to the SEGV's from select 'n wait.

I've looked through all Mumit's DLL helpers and bits of doc. and as
far as I can tell I am doing the right thing..


 (yes I tried CYGWIN=tty, no it didn't help, thanks for the
thought)

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com