Re: Announce: FlexDLL, flexible DLLs under Windows
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 up bash or whatever. It could theoretically do that if it had it's own loader for ELF binaries. Yes, probably. But then you run into the situation where you're doing things behind the back of Windows, so to speak. The first thing that comes to mind is the prefetching that is present in XP and later, which reduces process startup time by recording the disk extents of all images involved in startup so that they can be loaded all at once sequentially the next time the process starts. The next thing is the memory manager, which I think treats DLLs differently than generic file mappings for the purpose of maintaining and trimming the working set. And I wonder if there are further things that would not be possible without specific kernel support -- unless maybe you had a real win32 stub image for each exe/dll. Anyway, I don't mean to discourage anyone from trying this crazy idea, but just pointing out why staying with PE-compliant DLLs and EXEs under the hood has its advantages. 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 is much better documented. AND although Cygwin is limited by its use of static libraries in that regard, the task would not be impossible. Just my 0.02. -- Ctalk Home Page: http://ctalk-lang.sourceforge.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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 is much better documented. AND although Cygwin is limited by its use of static libraries in that regard, the task would not be impossible. Just my 0.02. My $.02: I can't grok most of the above. Cygwin doesn't rely on a shell, adding event notifiers doesn't make a lot of sense in this context, and the mention of static libraries doesn't really seem pertinent to a disscussion of shared library loading. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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 is much better documented. AND although Cygwin is limited by its use of static libraries in that regard, the task would not be impossible. Just my 0.02. I can't grok most of the above. Cygwin doesn't rely on a shell, adding event notifiers doesn't make a lot of sense in this context, and the mention of static libraries doesn't really seem pertinent to a disscussion of shared library loading. The scenario is normal and expected - program that uses data for another program and its libraries to finish before another program can read the data written to disk, loaded and swapped in its memory and then make use of the data. The mechanisms of this scenario vary between operating system and version. Unfortunately, Cygwin apps do rely on shells, or in the case of services, the exec () and similar system calls that load the apps and libraries. ISTM the previous description obfuscates and in fact complicates the process. The APIs to accomplish those tasks already exist. Anybody that wants to accomplish the tasks has only to look them up for themselves. -- Ctalk Home Page: http://ctalk-lang.sourceforge.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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 appear in Cygwin. (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.) -- Alain -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Announce: FlexDLL, flexible DLLs under Windows
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 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 up bash or whatever. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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.) 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 up bash or whatever. It could theoretically do that if it had it's own loader for ELF binaries. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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 up bash or whatever. It could theoretically do that if it had it's own loader for ELF binaries. Yes, probably. But then you run into the situation where you're doing things behind the back of Windows, so to speak. The first thing that comes to mind is the prefetching that is present in XP and later, which reduces process startup time by recording the disk extents of all images involved in startup so that they can be loaded all at once sequentially the next time the process starts. The next thing is the memory manager, which I think treats DLLs differently than generic file mappings for the purpose of maintaining and trimming the working set. And I wonder if there are further things that would not be possible without specific kernel support -- unless maybe you had a real win32 stub image for each exe/dll. Anyway, I don't mean to discourage anyone from trying this crazy idea, but just pointing out why staying with PE-compliant DLLs and EXEs under the hood has its advantages. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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 yet still be able to launch cygwin apps from cmd.exe rather than having to fire up bash or whatever. It could theoretically do that if it had it's own loader for ELF binaries. Yes, probably. But then you run into the situation where you're doing things behind the back of Windows, so to speak. The first thing that comes to mind is the prefetching that is present in XP and later, which reduces process startup time by recording the disk extents of all images involved in startup so that they can be loaded all at once sequentially the next time the process starts. That wouldn't be a terrifically big problem for things like, e.g., libncurses.so and the majority of the shared libraries used by cygwin. The next thing is the memory manager, which I think treats DLLs differently than generic file mappings for the purpose of maintaining and trimming the working set. And I wonder if there are further things that would not be possible without specific kernel support -- unless maybe you had a real win32 stub image for each exe/dll. Of course you'd have a real win32 stub for the exe. I'm not talking about writing a kernel driver or a new subsystem and I'm not talking about an all-or-nothing scenario. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Announce: FlexDLL, flexible DLLs under Windows
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 you create DLLs with unresolved symbols. When a DLL is loaded, these symbols are matched against those found in the main program and in previously loaded DLLs. This should make the development of modular applications (plugins) much easier under Windows. Forget all the trouble about dllimport/dllexport directives, .def files and import libraries! FlexDLL also exposes a common command-line interface to the Cygwin and Microsoft linkers, which should simplify the life of developers that targets several tool chains. Homepage: http://alain.frisch.fr/flexdll.html FlexDLL is open-source (MIT-like license) and it supports three toolchains: Cygwin, MinGW, and native MSVC (x86 and x86_64). It acts as a wrapper around the linker (at compile-time) and as a wrapper around LoadLibrary (at runtime). I hope this announce is not too much off-topic for these mailing lists. Feedback and comments are very welcome! Alain Frisch -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Announce: FlexDLL, flexible DLLs under Windows
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 you create DLLs with unresolved symbols. Feedback and comments are very welcome! This looks very interesting indeed. The technique of turning unresolved imports into data items that can be fixed up at runtime thus letting the windows runtime loaded accept the dll is a clever trick, and it occurs to me that it might be worth adopting the same technique directly in the binutils toolchain itself. Thanks for your valuable contribution! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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 implements the classical POSIX dlopen API. In short, it lets you create DLLs with unresolved symbols. Feedback and comments are very welcome! This looks very interesting indeed. The technique of turning unresolved imports into data items that can be fixed up at runtime thus letting the windows runtime loaded accept the dll is a clever trick, and it occurs to me that it might be worth adopting the same technique directly in the binutils toolchain itself. Thanks for your valuable contribution! 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. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Announce: FlexDLL, flexible DLLs under Windows
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? Puttin it into libtool sounds nearest to me, to work around -no-undefined. (Without having actually specced out the implementation yet,) I don't see why we couldn't do this trick entirely in ld, with a support routine or two in libgcc. It can't go entirely into libtool, I would have thought; it requires some additional code at runtime. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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 -no-undefined. -- Reini -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Announce: FlexDLL, flexible DLLs under Windows
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 is obviously much more advanced. Where should it go to? Puttin it into libtool sounds nearest to me, to work around -no-undefined. (Without having actually specced out the implementation yet,) I don't see why we couldn't do this trick entirely in ld, with a support routine or two in libgcc. It can't go entirely into libtool, I would have thought; it requires some additional code at runtime. That sounds correct to me. It seems to require some startup runtime code. You could conceivably put that in crt*.o. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
