RE: Writing to MVFS (clearcase) volumes from remote ssh

[Max Kaehn]

On Tue, 2007-02-06 at 17:31 -0600, Benedict, Michael wrote:
>  Please bear with me, I am not sure if I am on the same page as you.
> 
> 1) I can see the mount.  I can make it my working directory.  I can view
> files in it.  I can even remove some files from it.  This is all from
> the remote ssh session.
> 2) I downloaded WinObj, and am trying to use it.  I see no entries in
> \Sessions\0\DosDevices that link to my Clearcase volume (M:).
> \GLOBAL??\M: is a link to \Device\mvfs on my system.  In Cygwin, m: was
> mounted on /cygdrive/m.  All my tests are nested deeply in
> /cygdrive/m... Eg:

You'd see the link in Sessions if you have a view shortcut mounting
a drive letter.  Looks like you're using the MVFS drive, rather than
mapping a drive to a particular view, so that's not an issue.
(If there's a conflict, the drive letters in Sessions override those in
the global namespace.  Each logged in user gets their own session,
as does any service running as a user other than SYSTEM.)

Do you have the same user ID, group membership, etc. when logged
in via ssh as via the console?


--
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/

Re: Writing to MVFS (clearcase) volumes from remote ssh

[Max Kaehn]

On Tue, 2007-02-06 at 15:55 -0600, Benedict, Michael wrote:
> I have an ssh server running on a Windows XP Professional.  I also have
> a Clearcase Dynamic view mounted to the M:\ drive.  From a Cygwin X-term
> (local), I am able to interact with files mostly as expected(1).  If I
> ssh into Cygwin(2), I can list and read files fine.  If I have
> permission, I can even unlink them!  However, I am not able to open any
> files for writing, including creating new files.  Running with smbntsec
> or nosmbntsec in the CYGWIN environment variable seems to have no
> effect.  I am running with ntsec set in the CYGWIN environment variable.
> I have tried running with and without privilege separation for sshd.

ClearCase dynamic views are mounted in the console session, not in the
global namespace.  e.g. my view slothman_main is mounted on drive S:,
with my MVFS drive as V:, and drive S: only exists in the
\Sessions\0\DosDevices\-bff9 as symbolic link from
"S:" to "\??\V:\slothman_main".  (You can see this using WinObj:
http://www.microsoft.com/technet/sysinternals/SystemInformation/WinObj.mspx .)
With sshd running as a service, it's not in the same session as the
console, so it can't see the mount.

I notice that the MVFS drive itself is mounted in the global
namespace (e.g.: \GLOBAL??\V: is a link to \Device\mvfs on my system).
Try accessing your view via the view drive (e.g. using V:\slothman_main
instead of S:); that worked on my system (running 1.5.19).


--
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/

Re: Race condition spawning childs/pipe stuff?

[Max Kaehn]

In , Robert
Michelson wrote:
> I seem to encounter a race condition when running large recursive build
> processes (make).
> Occasionally, the build process hangs with a spawned child (sh.exe)
> eating with 100% user cpu.
> It seems the build command itself (spawned make) finished but
> child/parent? shell doesnt exit.
>
> When i kill sh.exe manually, the (recursive) build process continues and
> finishes.
> I suspect some kind of race condition somewhere in pipe stuff.

I've been getting the same thing with Cygwin 1.5.19-3, but it's
extremely hard to reproduce:  when doing endurance testing by repeatedly
building Mozilla, it only happened a single time on build #518 out of
570 (thus far).

Like Robert, I've found the problem to be in sync_proc_pipe(),
looping on low_priority_sleep().  This is the stack trace once
I munge $ebp and $eip to the highest-on-the-stack pair that
makes any sense:

#0  0x6106f0c7 in _pinfo::sync_proc_pipe () from /usr/bin/cygwin1.dll
#1  0x610972a9 in spawn_guts () from /usr/bin/cygwin1.dll
#2  0x61097655 in spawnve () from /usr/bin/cygwin1.dll
#3  0x61018c6b in execve () from /usr/bin/cygwin1.dll
#4  0x6108dd7f in _sigfe () from /usr/bin/cygwin1.dll
#5  0x004714c8 in ?? ()
#6  0x004715ec in ?? ()
#7  0xfffd in ?? ()
#8  0x0002 in ?? ()
#9  0x0022eb98 in ?? ()
#10 0x004035c1 in fhandler_pipe::get_guard ()
#11 0x004715ec in ?? ()
#12 0x00470a24 in ?? ()
#13 0x004714c8 in ?? ()
#14 0x0041007c in fhandler_pipe::get_guard ()
#15 0x0124 in ?? ()
#16 0x in ?? () from

Can anyone suggest other useful data to gather for the next time
this happens?

Thanks,
Max



--
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/

Re: testers needed prior to 1.5.19 release

[Max Kaehn]

cygwin1-20050912.dll:  Success.



--
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/

Re: How to add 4K of scratch space at the bottom of the stack using C instead of C++?

[Max Kaehn]

On Tue, 2005-07-12 at 11:02 -0700, Yu-Cheng Chou wrote:
> My program works in this way. However, after the cygwin1.dll was 
> initialized, the I/O seemed to be redirected. How can I get my I/O back?
> I listed my codes below for reference.

Does your CYGWIN environment variable include the string "tty"?



--
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/

Re: How to add 4K of scratch space at the bottom of the stack using C instead of C++?

[Max Kaehn]

On Mon, 2005-07-11 at 16:14 -0700, Yu-Cheng Chou wrote:
> I used "cl -c main.c" and "cl /o main.exe main.obj" to create main.exe.
> I used "gcc -shared -o module.dll module.c" to create module.dll.
> module.dll will be invoked in main.exe. However, when I run main.exe, the 
> program just hung there.

> So, my question is in an executable program that was created by MSVC, how 
> to dynamically load a library (module.dll) that was created by cygwin's 
> gcc?

If you don't need cygwin functionality, you can just use MinGW
http://www.mingw.org/ and "gcc -mno-cygwin".

> Some users suggested that I load cygwin1.dll before module.dll because 
> module.dll might be related to cygwin1.dll.

> module.dll will only be created by cygwin's gcc, but I'm not sure if I did 
> it in the correct way using "gcc -shared -o module.dll module.c".

You may need to arrange that the symbols are exported; do a "dumpbin
/exports module.dll" and make sure that those things are available.

If your module.dll expects cygwin1.dll to already be present and
initialized, you'll need to arrange for 4K at the bottom of your stack,
then load cygwin1.dll and call cygwin_dll_init(), then load module.dll.

To separate out problems with DLL creation from problems with loading
cygwin, create a cygwin loader application for your DLL first, then
once you have the bugs ironed out of that, create the non-cygwin
version of the loader.



--
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/

Re: How to add 4K of scratch space at the bottom of the stack using C instead of C++?

[Max Kaehn]

On Mon, 2005-07-11 at 14:46 -0700, Yu-Cheng Chou wrote:
> I have module.dll that was created by using command line "gcc -shared -o 
> module.dll module.c" in cygwin.
> When I run "msvc-cygload -v -cygwin module.dll" in cygwin, error messages 
> listed below occurred.

Why are you using cygload to load something that isn't cygwin1.dll?



--
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/

Re: How to add 4K of scratch space at the bottom of the stack using C instead of C++?

[Max Kaehn]

On Mon, 2005-07-11 at 11:55 -0700, Yu-Cheng Chou wrote:
> I downloaded the cygload package, set up the MSVCDir for my system, and 
> used c:\cygwin\bin\make to run the Makefile. The msvc-cygload.exe was 
> successfully created. However, when I run msvc-cygload.exe, error messages 
> listed below occurred.

1.  You're running cygwin 1.5.18?
2.  What version of Visual Studio are you using?
3.  Did you try "cygload -v" to see how far it got before it crashed?



--
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/

Re: How to add 4K of scratch space at the bottom of the stack using C instead of C++?

[Max Kaehn]

On Mon, 2005-07-11 at 12:12 -0400, Igor Pechtchanski wrote:
> > By the way, the Makefile shows that the MSVC compiler is in
> > C:/cygwin/usr/local/tools/i686_win32/vc7/Vc7.
> > Is it a package that is provided by cygwin? Or is it the MSVC software
> > that is installed in that directory?
> 
> Umm, no, Cygwin doesn't install MSVC (hopefully).  I believe this is an
> artifact of the system configuration of whoever submitted the Makefile.

Yes.  That's the effective MSVCDir I use; if you've got your environment
filled out from vcvars32.bat, it should provide the right MSVCDir for
your own system and the Makefile should pick it up.



--
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/

RE: How to make DLLs in cygwin for MSVC and BCB

[Max Kaehn]

On Thu, 2005-06-23 at 18:18 +0100, Dave Korn wrote:
>   Sorry, but why isn't that 4k at the *TOP* of the stack?  It sure looks
> that way to me, unless cygwin stacks grow upward!

You're mixing the metaphors. :-)  The top of a stack is where you push
something down onto the stack.  The bottom of the stack is at the 
other end.  There happens to be an implementation detail of stacks
growing downward in memory, so the bottom of the stack is at the top 
of the memory allocated to the stack.  I always found that puzzling,
too...




--
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/

Re: How to make DLLs in cygwin for MSVC and BCB

[Max Kaehn]

On Thu, 2005-06-23 at 14:05 +0200, Patrick Rotsaert wrote:
> Ok, but this was only a small test program to see if I manage to load 
> cygwin1.dll functions.
> The plan is to do this in a DLL, later on. I guess cygwin_dll_init will 
> then have to be called in DllMain, yes?
> But then, what happens when DllMain returns? The stack space will no 
> longer exist.

You'll need to find some way to arrange that the 4K is available at
the bottom of the stack of your main thread for as long as you have
cygwin1.dll loaded.  Any thread spawned once cygwin1.dll is loaded will
automatically have the 4K inserted, but for your main thread, you need
to do stunts like
---
extern "C" int mainCRTStartup ();

extern "C" int __stdcall
cygwinFriendlyCRTStartup ()
{
  char buf[4096];
  return mainCRTStartup ();
}
---
and link with cygwinFriendlyCRTStartup as your entry point.

If you spawn other threads before you load cygwin1.dll, you should
not call any cygwin functions from those threads.



--
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/

Re: How to make DLLs in cygwin for MSVC and BCB

[Max Kaehn]

On Wed, 2005-06-22 at 18:17 +0200, Patrick Rotsaert wrote:
> Loading the cygwin1.dll dynamically is certainly an option. I tried it, 
> although I'm not quite sure how to make sure I have "4K of scratch space 
> at the bottom of the stack", like the faq says.

> My test program crashes once cygwin_dll_init is called. :-((

You need cygwin 1.5.18, which hasn't been released yet, for this to
work.  Try the latest snapshot.  Your program looks fine, though
you should do all your argv processing before calling
cygwin_dll_init(), because it will trash your argv and argc.
If you look at the cygload utility (in cygwin CVS), it shows how
to add a new entry point to your program that will put the 4K
closer to the bottom of the stack.



--
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/

Re: Problem with using stripped cygwin1.dll built from CVS

[Max Kaehn]

On Wed, 2005-06-08 at 07:36, Christopher Faylor wrote:
> I understand the problem.  It's a binutils bug that I'm investigating.
> Either gas or ld is marking NOLOAD sections as "read only" and that is
> causing windows to actually load them into memory.

This may or may not be related, but I've noticed that my local
builds of cygwin1.dll don't wind up with version resources that
Windows can see.  It looks like the linker is leaving them out--
the .rsrc section is absent, even though winver.o is on the link line.

---
levinbolt-xp% objdump -h C:/cygwin/bin/old-cygwin1.dll

C:/cygwin/bin/old-cygwin1.dll: file format pei-i386

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 00108264  61001000  61001000  0600  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data ad40  6110a000  6110a000  00108a00  2**4
  CONTENTS, ALLOC, LOAD, DATA
  2 .advapi32_text 0b50  61115000  61115000  00113800  2**2
  CONTENTS, ALLOC, LOAD, CODE
  3 .netapi32_text 0120  61116000  61116000  00114400  2**2
  CONTENTS, ALLOC, LOAD, CODE
  4 .ntdll_text   02f8  61117000  61117000  00114600  2**2
  CONTENTS, ALLOC, LOAD, CODE
  5 .psapi_text   00e0  61118000  61118000  00114a00  2**2
  CONTENTS, ALLOC, LOAD, CODE
  6 .secur32_text 00e8  61119000  61119000  00114c00  2**2
  CONTENTS, ALLOC, LOAD, CODE
  7 .user32_text  0560  6111a000  6111a000  00114e00  2**2
  CONTENTS, ALLOC, LOAD, CODE
  8 .wsock32_text 04e0  6111b000  6111b000  00115400  2**2
  CONTENTS, ALLOC, LOAD, CODE
  9 .ws2_32_text  01f0  6111c000  6111c000  00115a00  2**2
  CONTENTS, ALLOC, LOAD, CODE
 10 .iphlpapi_text 0090  6111d000  6111d000  00115c00  2**2
  CONTENTS, ALLOC, LOAD, CODE
 11 .ole32_text   0028  6111e000  6111e000  00115e00  2**2
  CONTENTS, ALLOC, LOAD, CODE
 12 .kernel32_text 0348  6111f000  6111f000  00116000  2**2
  CONTENTS, ALLOC, LOAD, CODE
 13 .shell32_text 0028  6112  6112  00116400  2**2
  CONTENTS, ALLOC, LOAD, CODE
 14 .winmm_text   0330  61121000  61121000  00116600  2**2
  CONTENTS, ALLOC, LOAD, CODE
 15 .mpr_text 00d8  61122000  61122000  00116a00  2**2
  CONTENTS, ALLOC, LOAD, CODE
 16 .rpcrt4_text  0050  61123000  61123000  00116c00  2**2
  CONTENTS, ALLOC, LOAD, CODE
 17 cygwin_dll_common 0020  61124000  61124000  00116e00  2**2
  CONTENTS, ALLOC, LOAD, DATA, SHARED
 18 .rdata2990  61125000  61125000  00117000  2**4
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 19 .bss  9af0  61128000  61128000    2**4
  ALLOC
 20 .edata7961  61132000  61132000  00119a00  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 21 .idata18d8  6113a000  6113a000  00121400  2**2
  CONTENTS, ALLOC, LOAD, DATA
 22 .rsrc 0428  6113c000  6113c000  00122e00  2**2
  CONTENTS, ALLOC, LOAD, DATA
 23 .relocf45c  6113d000  6113d000  00123400  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA

levinbolt-xp% objdump -h C:/cygwin/bin/cygwin1.dll

C:/cygwin/bin/cygwin1.dll: file format pei-i386

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 000d8344  61001000  61001000  0400  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .autoload_text 25e0  610da000  610da000  000d8800  2**2
  CONTENTS, ALLOC, LOAD, CODE
  2 .data af48  610dd000  610dd000  000dae00  2**4
  CONTENTS, ALLOC, LOAD, DATA
  3 cygwin_dll_common 0020  610e8000  610e8000  000e5e00  2**2
  CONTENTS, ALLOC, LOAD, DATA, SHARED
  4 .rdata00038930  610e9000  610e9000  000e6000  2**4
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .bss  9d60  61122000  61122000    2**4
  ALLOC
  6 .edata7961  6112c000  6112c000  0011ea00  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .stab 001daea0  61134000  61134000  00126400  2**2
  CONTENTS, READONLY, DEBUGGING, NEVER_LOAD, EXCLUDE
  8 .stabstr  004dd334  6130f000  6130f000  00301400  2**0
  CONTENTS, READONLY, DEBUGGING, NEVER_LOAD, EXCLUDE
  9 .idata1900  617ed000  617ed000  007de800  2**2
  CONTENTS, ALLOC, LOAD, DATA
 10 .cygheap  00104000  617ef000  617ef000    2**2
  ALLOC



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http:/

Re: Questions on patching dcrt0.cc

[Max Kaehn]

On Wed, 2005-05-25 at 21:38, Igor Pechtchanski wrote:
> As I understand it, the same issues arise whether cygwin1.dll is
> dynamically loaded from an MSVC application or a MinGW application.
> There is a simple way to compile MinGW applications on Cygwin (namely,
> "gcc -mno-cygwin").  You could test your approach with a MinGW-compiled
> app, and if you see the same behavior as with MSVC, the MinGW app could be
> included in the testsuite.

Thanks for the pointer, Igor.  That was extremely helpful.

I just ported the test app to mingw.  The only thing I had to change was
to put an #ifdef in to use GCC-style inline assembly instead of
MSVC-style when it looks at the segment register.  I'm still
reeling in amazement at how easy that was.  Wow.

My hat's off to the mingw folks, and I'll be submitting the test
utility (as a new subdirectory for winsup/testsuite) as mingw 
code (under the cygwin license) with an option in the makefile to 
show that it works for MSVC.



--
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/

Re: Questions on patching dcrt0.cc

[Max Kaehn]

On Thu, 2005-05-26 at 11:00, Christopher Faylor wrote:
> Rather than talking about "MSVC code" being "acceptable", please just
> provide a specific indication of *what* you are trying to do.  Where do
> you want to put this code?  Look at the directories available in winsup
> and tell us where you want to put this.

I want to make it as easy as possible for cygwin developers who are
working with the cygwin initialization code that they don't break
this functionality.  It seems to me that a subdirectory of
winsup/testsuite would be good for this.  You remarked in
semi-private E-mail that "we won't be putting any MSVC source in the
winsup directory", and I want to respect the policies of the cygwin
project, so I'm asking where you would like a program of this nature.
A new subdirectory of "contrib" might also be appropriate.  Wherever
it goes, I want to put comments in the patches I will submit for
dcrt0.cc and how-programming.texinfo that refer the reader to this
test program.

> As I mentioned in semi-private email, the fact that you can get cygwin
> working by dynamic linking doesn't mean that it can necessarily be used
> by proprietary programs if by "proprietary" you mean "non open source".

As I understand it, this clause in the cygwin license:
---
Red Hat sells a special Cygwin License for customers who are unable to
provide their application in open source code form.  For more
information, please see: http://www.redhat.com/software/tools/cygwin/,
or call 866-2REDHAT ext.  3007
---
allows vendors of proprietary, non-open source software to pay for
the privilege of linking to the GPL.  As it states at
http://www.redhat.com/software/cygwin/ :
---
A Cygwin Contract provides customers with: 

  * The ability to distribute customer's applications without being
bound by the GPL. Therefore, customers are not required to
provide their applications in open source code form. 
---
If I'm missing something, please let me know:  it looks to me like
there's a very nice setup here of:
* If your program is proprietary, you must pay for the
  privilege of linking to cygwin1.dll.
* If your program is open source, you can link to cygwin1.dll
  for free.
To my eyes, this is a win-win proposition for the open source community.

> ?  Why wouldn't signal handling just work?  A program would have to call
> "GetProcAddress" to retrieve the address of any signal function that it
> wanted to use but it should just work if all of the appropriate stuff is
> initialized in cygwin.

As far as I can tell, the main thread needs to be running an
interruptible cygwin function in order to receive signals from cygwin. 
This works fine if your main routine is waiting on sleep() or
pthread_cond_timedwait(), but not if it's busy in the Microsoft
libraries.  Spawning an additional thread to call sigwait() will
minimize the cost of integration of this functionality into
existing programs.



--
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/

Re: Questions on patching dcrt0.cc

[Max Kaehn]

On Thu, 2005-05-26 at 07:58, Christopher Faylor wrote:
> I don't know what "submit it" means here.  If the submission is for inclusion
> somewhere in the cygwin-specific part of winsup then the code needs to be
> assigned to Red Hat.  Otherwise, why not just make it GPL?

If MSVC code is acceptable for the cygwin-specific part of winsup, it
definitely gets the cygwin license.  If it should go someplace else,
then I want people who have purchased a cygwin license from Red Hat
not to have to worry about the legalities of copying code from the test
program.  If I can use the cygwin license for code in "contrib"
(or wherever), then that's fine.

My intent here is to minimize the barrier to entry of creating
proprietary programs that interoperate well with cygwin.  If someone
makes a proprietary tool and has customers clamoring for it to work
better with cygwin (e.g. doing proper cleanup when getting a ^C while
running in an xterm), I want the business decision to be a matter
of "the integration code is already available; the only question
is whether the value added is greater than the cost of a cygwin
license from Red Hat".

I'm new to actually *selecting* open source licenses, so I'm grateful
for all feedback on selecting an appropriate one for the test
program.  http://www.opensource.org/licenses/bsd-license.php
looks good; is it appropriate for me to assign the copyright to
Red Hat?

I got signal handling working yesterday; it works by spawning
a thread that loops on sigwait().  I want to make another pass
over the program doing cleanup and documentation and it'll be
ready for submission, probably by the time the copyright assignment
forms make it through snail mail.  I'll also see if I can make a
mingw version for winsup/testsuite, as Igor suggested.

Thanks,
Max



--
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/

Questions on patching dcrt0.cc

[Max Kaehn]

I'm working on a patch to make it possible to load cygwin1.dll
via LoadLibrary() in MSVC.  The intent is to make it possible
for non-cygwin applications to be cooperative with cygwin paths
and signals.  (Such applications will need to either be open
source as specified in the cygwin license, GPLed, or under the
Cygwin Contract available at http://www.redhat.com/software/cygwin/ .)

Some questions:

1.  As far as I can determine, the current problem with loading
the cygwin DLL via LoadLibrary is that the cygtls per-thread
context needs 4K of the bottom of the stack to be available to
work with.  That normally gets initialized when the application
loads or a thread is spawned, but it's hard to deal with that
retroactively in the LoadLibrary case.  If you ensure that there's
4K of padding at the bottom of the stack, you can just add
main_environ = user_data->envptr;
*main_environ = NULL;
initialize_main_tls(&_my_tls);
to cygwin_dll_init() just before the call to dll_crt0_1(NULL),
but that's the sort of thing that should come with big warning
signs.  Is this manner of solution-- combined with a sample
program that demonstrates and tests this functionality, a
FAQ entry, and thorough commenting in the code explaining all
the caveats-- acceptable?  Or should I be looking for a
different way to solve the problem?

2.  I have an MSVC test program that demonstrates and tests this
functionality.  Where should I submit the source code and
Makefile -- a subdirectory of contrib?  of winsup/testsuite?
Since not everyone working on cygwin will have access to the
Microsoft compiler, should I submit a binary as well as source?
Where should I submit it?

3.  I want to spare anyone making use of the test program any
worries over legalities.  Should I submit it under the cygwin
license or put it in the public domain?

Thanks,
Max



--
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/