Ranjit Mathew wrote:
> Earnie Boyd wrote:
> > Ranjit Mathew wrote:
> >>BTW, I think that the heap_chunk_in_mb registry entry has no effect
> >>in MSYS, right?
> > Yes, I think not. The heap_chunk_in_mb is a default starting size,
> > which for the current snapshot is 2MB while in 1.0.7 it's 4MB. I'll
> > have to see what I can dream up to control this besides the registry
> > entry. Thanks for the report.
> Out of curiosity, I was browsing through the MSYS source code
> on SF and noticed these things:
> 1. The current Cygwin DLL is 1.3.12-2 while MSYS seems to have
> incorporated changes only up to version 1.3.3. Are there
> any plans to merge with the "mainstream" Cygwin any time
I've thought about it, there may be bit's a pieces I look at but, in
> BTW, I also noticed that Chris Faylor ("Mr Cygwin") is the
> current maintainer of Cygwin - he wasn't too happy with
> the MSYS fork, as seen in one of his mails forwarded to
> this list. I don't think we'll see a unified MSYS/Cygwin
> source tree any time soon, will we? :-(
I had to use an external fork because the changes I wanted to make were
to invasive to the source. As I said to Chris, MSYS is more than just a
fork of Cygwin and the purposes of msys-1.0.dll are different than
cygwin1.dll in the sense that I only distribute the msys-1.0.dll for the
purpose of providing hard to port utilities a POSIX runtime. My desire
will be to eventually remove that layer.
> 2. "cygwin/version.h" defines these constants -
> #define CYGWIN_INFO_CYGNUS_REGISTRY_NAME "msys"
> #define CYGWIN_INFO_CYGWIN_REGISTRY_NAME "1.0"
> This should mean that settings like heap_chunk_in_mb
> should be put in "HKEY_CURRENT_USER\Software\msys\1.0"
> (ref. registry.cc), right?
Not used by MSYS since alpha stages. They could be removed without harm
as long as the source doesn't use them any longer.
> 3. "shared.cc" seems to read "heap_chunk_in_mb" from
> the registry in the "shared_info::heap_chunk_size"
> method - the default seems to be 256 MB if not
> specified and a minimum of 2MB - but I think one
> can also specify a larger value - nothing seems to
> be stopping it. Right?
I need to trace that read, removing it breaks MSYS.
Feel free to submit patches to MinGW-patches for consideration.