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/