On Mar 18 22:11, Jeremy Drake via Cygwin-patches wrote: > On Tue, 18 Mar 2025, Corinna Vinschen wrote: > > > Subdir of winsup/cygwin, probably. What I'm most curious about is the > > size it adds to the DLL. I wonder if, say, an extra 32K is really > > usefully spent, given it only checks a small part of ntdll.dll, and only > > once per process tree, too. > > I did this with msys-2.0.dll, but it shouldn't matter as a delta. > all are stripped msys-2.0.dll size > start: > 3,246,118 bytes > with udis86 vendored, but not called: > 3,247,142 bytes > with find_fast_cwd_pointer rewritten to use udis86: > 3,328,550 bytes > > (I know the second one isn't realistic, the linker could exclude unused > code, I was just kind of curious) > > This is with all the "translate to assembly text, intel or at&t syntax" > and "table of strings for opcodes" stuff removed to try to save space, > still a net increase of 82,432 bytes.
The DLL has currently a size of 3 Megs, optimzed, stripped. 82K are two more allocation granularity slots, 51 instead of 49, about 2%. So in reality you probably won't notice a difference in loading time or memory pressure. > /* Next we search for the locking mechanism and perform a sanity check. > On Pre- (or Post-) Windows 8 we basically look for the > RtlEnterCriticalSection call. Windows 8 does not call > RtlEnterCriticalSection. The code manipulates the FastPebLock manually, > probably because RtlEnterCriticalSection has been converted to an inline > function. Either way, we test if the code uses the FastPebLock. */ We can throw anything related to pre-8.1 out of the Window, if it helps to reduce the code. Corinna
