This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]



Friday, 27 July, 2001 Robert Collins wrote:

RC> On 27 Jul 2001 16:55:57 +0400, egor duda wrote:
>> Friday, 27 July, 2001 Robert Collins wrote:
>> RC> On 26 Jul 2001 17:49:50 -0700, Dario Alcocer wrote:
>> >> >>>>> "Robert" == Robert Collins <> writes:
>> >> 
>> >>     Robert> As Chuck has mentioned, that cygwin1.dll should have a
>> >>     Robert> different shared memory region identifier, to prevent
>> >>     Robert> crashes :}.
>> >> 
>> >> Just curious; can't we avoid a specially built version of cygwin1.dll
>> >> by making sure that cygwin1.dll isn't loaded when the installer runs?
>> >> Making a special verion of cygwin1.dll could add more confusion.
>> RC> What if:
>> RC> the irt cygwin1.dll is incompatible with the installed, running
>> RC> cygwin1.dll - so that any attempt to call cygwin1.dll functions (which
>> RC> the irt uses?) results in a crash.
>> RC> I covered ina different reply the mechanics of a different shared memory
>> RC> identifier.
>> if you run x:\some\temp\path\ash.exe and x:\some\temp\path\ contains
>> cygwin1.dll is _doesn't_ matter if any other program is running from
>> c:\cygwin\bin and using incompatible version of cygwin1.dll from
>> c:\cygwin\bin\, as long as you're taking care about shared memory
>> region name.

RC> Yes - precisely my point :]. (Dario asked about avoiding having a
RC> different shared memory region name).

No! he talked about custom-built dll. custom-built dll and different
shared region name are _different_ issues. You can make 2 normally
built dlls to have different shared area names. i use stock version
1.1.8 for debugging version 1.3.2. gdb uses 1.1.8, debugee uses 1.3.2.
they're running along nicely.

so, *If* you can guarantee that all applications during bootstrapping
are run from the single directory, you can make them not interfere
with other currently running cygwin applications.


>> this will remain as it is currently (if i understand things
>> correctly). RPM is good for tracking dependencies, checking
>> installation integrity, signature verification etc. -- the issues
>> current setup doesn't address or partially address.

RC> Hmmm.. yes. Although rpm is actually mediocre at dependencies (IIRC it
RC> uses filepath+name rather than a feature).

it can use file name/package name/feature (with versioning, btw).

RC> The point being that a  "rpmfind" database is then needed, rather
RC> than the current setup.exe (if this or a simialr tcl/tk+rpm
RC> installer is adopted).

??? why? setup remains donwloading/bootstrapping tool. it could,
eventually, utilize something like rpmfind-generated index to help you
through downloading process.
Or we can leave setup as GUI front-end while having rpm-based
back-end, i.e. just merge tcl/tk installer interface functions into

Egor.   ICQ 5165414 FidoNet 2:5020/496.19

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]