Mail Archives: cygwin/2007/11/22/02:25:12
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/
- Raw text -