Cygwin built DLL invoked from MSC app doesn't seem to be all there.
Mon May 31 21:10:00 GMT 1999
> Earnie Boyd wrote:
> --- Ian Zimmerman <firstname.lastname@example.org> wrote:
> > Earnie Boyd wrote:
> > >
> > > --- Jon Wells <email@example.com> 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
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org
More information about the Cygwin