> On Thu, Nov 22, 2007 at 04:15:50AM -0500, Robert Kiesling wrote:
> >ISTM it would be easier to add event notifiers to the shell or the
> >app, although the implementation of that would almost certainly require
> >a code fork. And the memory management and the practice of loading Windows
> >apps
On Thu, Nov 22, 2007 at 04:15:50AM -0500, Robert Kiesling wrote:
>ISTM it would be easier to add event notifiers to the shell or the
>app, although the implementation of that would almost certainly require
>a code fork. And the memory management and the practice of loading Windows
>apps with Unix
> Christopher Faylor wrote:
>
> > > Not an unreasonable idea, but very hard to make work when we really want
> > >cygwin apps to basically be windows apps; I can't see how cygwin could
> > >support
> > >e.g. an ELF loader and yet still be able to launch cygwin apps from cmd.exe
> > >rather than
On Wed, Nov 21, 2007 at 06:30:06PM -0800, Brian Dessent wrote:
>Christopher Faylor wrote:
>>somebody else wrote:
>>>Not an unreasonable idea, but very hard to make work when we really
>>>want cygwin apps to basically be windows apps; I can't see how cygwin
>>>could support e.g. an ELF loader and y
Christopher Faylor wrote:
> > Not an unreasonable idea, but very hard to make work when we really want
> >cygwin apps to basically be windows apps; I can't see how cygwin could
> >support
> >e.g. an ELF loader and yet still be able to launch cygwin apps from cmd.exe
> >rather than having to fire
On Wed, Nov 21, 2007 at 04:25:31PM -, Dave Korn wrote:
>On 21 November 2007 16:07, Alain Frisch wrote:
>
>> (Altough at this point, one
>> could also imagine that Cygwin supports another binary format for
>> dynamic libraries, e.g. ELF, which can deal with unresolved symbols
>> natively.)
>
>
On 21 November 2007 16:07, Alain Frisch wrote:
> (Altough at this point, one
> could also imagine that Cygwin supports another binary format for
> dynamic libraries, e.g. ELF, which can deal with unresolved symbols
> natively.)
Not an unreasonable idea, but very hard to make work when we rea
Dave Korn wrote:
This looks very interesting indeed.
Thanks! It's great to see some interest from people on this list.
Of course, implementing a similar feature directly in the linker and in
the runtime library makes sense, and I'll be happy to see some of the
ideas developed in FlexDLL ap
On Tue, Nov 20, 2007 at 06:44:43PM -, Dave Korn wrote:
>On 20 November 2007 18:39, Reini Urban wrote:
>
>> 2007/11/20, Christopher Faylor:
>> ...
>>> Indeed, this is very interesting. It sounds a little like the
>>> autoload.cc code in Cygwin which handles optional linking from dlls but it
>>>
On 20 November 2007 18:39, Reini Urban wrote:
> 2007/11/20, Christopher Faylor:
> ...
>> Indeed, this is very interesting. It sounds a little like the
>> autoload.cc code in Cygwin which handles optional linking from dlls but it
>> is obviously much more advanced.
>
> Where should it go to?
> Pu
2007/11/20, Christopher Faylor:
...
> Indeed, this is very interesting. It sounds a little like the
> autoload.cc code in Cygwin which handles optional linking from dlls but it
> is obviously much more advanced.
Where should it go to?
Puttin it into libtool sounds nearest to me, to work around -n
On Tue, Nov 20, 2007 at 02:49:48PM -, Dave Korn wrote:
>On 20 November 2007 13:58, Alain Frisch wrote:
>
>> Dear Cygwin and MinGW mailing lists,
>>
>> I'd like to announce the availability of FlexDLL, a new tool that should
>> greatly help porting some Unix applications under Windows. FlexDLL
On 20 November 2007 13:58, Alain Frisch wrote:
> Dear Cygwin and MinGW mailing lists,
>
> I'd like to announce the availability of FlexDLL, a new tool that should
> greatly help porting some Unix applications under Windows. FlexDLL
> implements the classical POSIX dlopen API. In short, it lets yo
13 matches
Mail list logo