Regarding this issue I had a problem about MinGW + MSys, with respect to
(actually that is the reason I joined the list)
HP Compaq Laptop that logs onto a Windows Domain
Scenario 1: (No network connection to the domain)
-- MSys will take ages to start (around 15 seconds).
-- If I start xemacs inside MSys it will start fast
-- But executing any process (like compiling) within XEmacs yields =
-- Cygwin will behave as expected: No delays ...
Scenario 2: (Network connection to the domain)
-- Both Msys and Cygwin behave the same: All right
Any clues ?
Daniel J. Rodr=EDguez
[mailto:mingw-users-admin@...] En nombre de KC
Enviado el: lun, 27 de marzo de 2006 07:58
Asunto: Re: [Mingw-users] Fwd: cygwin + --no-cygwin =3D MinGW ??
Thanks for the info.
ORBit2 is an implementation of CORBA 2.4 which is similar to DCOM
and it's the only implemenation of C language mapping of CORBA, AFAIK.
On 3/27/06, Brian Dessent <brian@...> wrote:
> KC wrote:
> > get better performance. But I'm a little confused by cygwin and =
> The cygwin gcc packages include -mno-cygwin as a shortcut to compiling
> with the mingw toolchain. It's really two different compilers, or at
> the very least two completely different C runtimes.
> Porting a *nix-like package to windows using mingw can sometimes be
> easy, but often it is quite difficult without some manual labor =
> of the fact that MSVCRT provides very little of the posix API past =
> the C language requires. So if your app expects to do anything "unix
> like" such as fork/exec you either have to rewrite it using win32
> concepts or use an emulation library like Cygwin. If you use Cygwin =
> can compile a much wider array of posix software out of the box =
> modification, but there is some overhead.
> I don't know anything about Orbit2, but it looks like it's network-IO
> bound. If that is the case then I doubt that Cygwin has anything to =
> with the perceived latency, and I suggest that the difference is
> inherently a windows issue and won't change just because you avoid
> Cygwin. There was a recent thread on the cygwin ML regarding Windows'
> poor implementation of the TCP/IP nagle algorithm, and the need to set
> TCP_NODELAY. You might want to read that:
> On the other hand if the library is just doing network IO then it
> shouldn't be too hard to port to mingw, and it would seem that others
> have had success doing this with relatively few changes:
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> that extends applications into web and mobile media. Attend the live
> and join the prime developer group breaking into this new coding
> MinGW-users mailing list
> You may change your MinGW Account Options or unsubscribe at:
This SF.Net email is sponsored by xPML, a groundbreaking scripting =
that extends applications into web and mobile media. Attend the live =
and join the prime developer group breaking into this new coding =
MinGW-users mailing list
You may change your MinGW Account Options or unsubscribe at: