rsh problem

[Asim]

Hi All,
I installed cygwin 1.88 on my Windows XP.
I have a sun solaris server from which I want to execute some commands on
the Windows PC remotely.

i.e. rsh -l amohanty  "ls"

But it is not working, it simply returns nothing.

[EMAIL PROTECTED] /export/home/amohanty $ rsh -l amohanty
 "ls"
[EMAIL PROTECTED] /export/home/amohanty $

Whereas rsh -l amohanty  is working and I am able
to login to my Windows PC from Sun solaris server.

[EMAIL PROTECTED] /export/home/amohanty $ rsh -l amohanty

Fanfare!!!
You are successfully logged in to this server!!!

[EMAIL PROTECTED] ~

Please help me.

Thanks.
Asim
--
View this message in context: 
http://www.nabble.com/rsh-problem-t1423516.html#a3837458
Sent from the Cygwin Users forum at Nabble.com.


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

cygrunsrv.exe with csrss.exe cause 100% system load with API-Call

[Patrick Lichtner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

we are an antivirus vendor and customers can't update our software with
OpenSSH for Windows (cygwin1.dll v 1005.10.0.0) running:

The cygwin process "cygrunsrv.exe" together with the Microsoft
Client/Server Runtime Server Subsystem ("csrss.exe") cause the load as
soon as our "update.exe" is triggered.

We do NOT touch any of these processes with updater or scanner. So
there's NO chance to exclude anything here. WHAT we do is to browse all
processes for explorer to find the current users desktop before starting
our apps. This is done only on NT/W2K. We perform a
FindFirstProcess()/FindNextProcess(). So we simply created a testapp
which caused the same effect: If this tool is started, cygwin or csrss
needs 100% of the CPU. The tool use only windows API calls and so the
described behaviour is a bug in CYGWIN.
Examples can be also taken from the MSDN help (ProcessList). As soon as
the API Call "Process32First" is called and the process "csrss" is
attached, the CPU gets 100%. The process list is required by us for
different tasks.

So what can we do? Thanks in advance for your feedback.

Kind Regards,
Patrick Lichtner
Avira GmbH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEOh7gDQV5FAFpBBMRAsrFAKClcfO744yc+lka+758sSIOjTHPzgCfTDss
tNSKo1xCj94p0u7lZB0lmPA=
=yW5e
-END PGP SIGNATURE-


--
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: cygrunsrv.exe with csrss.exe cause 100% system load with API-Call

[Alexander Herrmann]

On 4/10/06, Patrick Lichtner <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi All,
>
> we are an antivirus vendor and customers can't update our software with
> OpenSSH for Windows (cygwin1.dll v 1005.10.0.0) running:
>
> The cygwin process "cygrunsrv.exe" together with the Microsoft
> Client/Server Runtime Server Subsystem ("csrss.exe") cause the load as
> soon as our "update.exe" is triggered.
>
> We do NOT touch any of these processes with updater or scanner. So
> there's NO chance to exclude anything here. WHAT we do is to browse all
> processes for explorer to find the current users desktop before starting
> our apps. This is done only on NT/W2K. We perform a
> FindFirstProcess()/FindNextProcess(). So we simply created a testapp
> which caused the same effect: If this tool is started, cygwin or csrss
> needs 100% of the CPU. The tool use only windows API calls and so the
> described behaviour is a bug in CYGWIN.
> Examples can be also taken from the MSDN help (ProcessList). As soon as
> the API Call "Process32First" is called and the process "csrss" is
> attached, the CPU gets 100%. The process list is required by us for
> different tasks.
>
> So what can we do? Thanks in advance for your feedback.
Attach the testprogram so we can figure out what's going on. Dont
expect anybody really looks into MSDN help (ProcessList). There not
many M$ Lovers here -imo - otherwise cygwin wouldn't extist.
Alex


--
Take a look - not only for computer people ;) http://www.seabreeze.co.th

--
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: cygrunsrv.exe with csrss.exe cause 100% system load with API-Call

[Patrick Lichtner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Alex,

first of all thanks for your help.

>> Attach the testprogram so we can figure out what's going on.
Sorry, how? It doesn't seem to work..
Neither with cygwin at cygwin dot com
nor with ping2weltall at gmail dot com
What am i doing wrong?

Thanks,
Patrick
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEOk3MDQV5FAFpBBMRAj0+AKC2ca0hCqbeC3yRRR5aaOZJNuYgjwCg1Dly
8wslBaCB49kDNZZuS2PzAys=
=4a2F
-END PGP SIGNATURE-


--
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: cygrunsrv.exe with csrss.exe cause 100% system load with API-Call

[Dave Korn]

On 10 April 2006 13:22, Patrick Lichtner wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Alex,
> 
> first of all thanks for your help.
> 
>>> Attach the testprogram so we can figure out what's going on.
> Sorry, how? It doesn't seem to work..
> Neither with cygwin at cygwin dot com
> nor with ping2weltall at gmail dot com
> What am i doing wrong?

  Probably the main thing is that you're not reading the bounce messages to
see why the post was rejected.  Are they getting dumped by your spamfilter
before you see them?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: find and /cygdrive/c

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Easton on 4/9/2006 1:44 AM:
> 
> Anyway, find 4.2.27:
> I must have installed 4.3.0 several times :-( I really didn't have a
> good handle on using setup).  oldfind claims he is version 4.3.0 too :-(.
> Funny thing though, they are different sizes, find.exe is 142336 and
> oldfind.exe is 139776 - they both work right.  Different compilers?

No, different versions.  oldfind really is version 4.3.0, but uses the
same hand-rolled traversal algorithm as 4.2.27.  find 4.3.0 introduces a
new algorithm, based on gnulib fts().  The difference in algorithms can be
seen with strace, where a different sequence of syscalls is made between
the two.

> 
> Hope this helps.  :-)  If you like send me the source I would 
> be happy to try it (ie. open vs. opendir) on my machine.

The source for findutils, including the cygwin-specific patches, is
available via setup.exe.  There are checkboxes next to each package in the
chooser screen so that you can download the source of that package to
/usr/src and reproduce how the maintainer built the binary.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEOk/P84KuGfSFAYARAhT1AJ9Glvpz1BkEAhO1bXb9MMNg1qrCvQCfdIYs
P18WNaZk9gzUN2D9+yL7jsw=
=kXad
-END PGP SIGNATURE-

--
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: V5.94 ptx -i ignore-file doesn't appear to work

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Graig McHendrie on 4/8/2006 6:55 AM:
> On receiving this message, Paul Eggert of the coreutils group suggested
> I send this information to the cygwin mailing list, since he is using
> the Linux version.
> 
> The message at the bottom shows my original report to Paul along with
> his demonstration of ptx working as expected.
> 
> The message above that (immediately below), shows where I duplicated his
> files and command line to produce output that is not as expected.

Thanks for the heads up.  I will look into this; I suspect a line ending
condition is causing the grief.  It is on my list of things to fix for
coreutils-5.94-5.

However, since I suspect line endings (even though all your directories
are mounted binmode, which is good), copying and pasting from your email
did not give me the same files that you were testing with (I was only able
to reproduce Paul's output).  Please send the actual (short) problem files
as an attachment, with line-endings preserved, so that I can more easily
reproduce your situation.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
volunteer cygwin coreutils maintainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEOlHW84KuGfSFAYARAuFOAJ9rARM49RHoe275j81U6OfpIN+A3ACeNkLL
IwnR10ci1/Q5AgNdMK3DV8o=
=10tr
-END PGP SIGNATURE-

--
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: when is using cygserver recommended? (thx)

[J. David Boyd]

Christopher Faylor <[EMAIL PROTECTED]> writes:

>
> Just to state the obvious again: cygserver has nothing to do with fork
> -- superstitious assertions to the contrary not withstanding.
>
> cgf


>From the CYGSERVER Readme:
--
What is Cygserver?

  Cygserver is a program which is designed to run as a background service.
  It provides Cygwin applications with services which require security
  arbitration or which need to persist while no other cygwin application
  is running.

  The implemented services so far are:

  - Control slave tty/pty handle dispersal from tty owner to other
processes without compromising the owner processes' security.
--

To me, this sounds like it controls the 'fork'ing of items, but I can't argue
(too much), as I don't know for certain.

Or, could it be that something we (us that have had the problem) call from our
.bashrc or .profile might be calling something that bounces off the cygserver
controlling mechanism?

Dave




--
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: when is using cygserver recommended? (thx)

[Dave Korn]

On 10 April 2006 13:47, J. David Boyd wrote:

> Christopher Faylor  writes:

> To me, this sounds like it controls the 'fork'ing of items, but I can't
> argue (too much), as I don't know for certain.

  Then it's damn silly to argue (any at all) with someone who does know for
certain!


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


--
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: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...)

[Igor Peshansky]

On Sun, 9 Apr 2006, Christopher Faylor wrote:

> On Tue, Apr 04, 2006 at 11:44:47AM -0700, David Rothenberger wrote:
> >WinMain() in a program compiled with cygwin1.dll is no longer
> >getting passed the command-line from bash correctly with the
> >20060403 snapshot. It works fine with the 20060329 snapshot.
> >
> >This is the same problem mentioned in
> >.
> >
> >The same test case is attached here again (winCmdLine.c). I compile
> >it with "gcc -o winCmdLine winCmdLine.c" (note no -mno-cygwin).
>
> This is due to recent changes which cause cygwin to stop filling out the
> command-line for cygwin1.dll using programs.  We did this to fix the
> "long command line" problem.
>
> There is a crude workaround for the problem which reinstates the
> previous cygwin behavior but I really would rather not go that way.  It
> would be nice if, just this once, we could make cygwin a little faster
> at the expense of programs which are using a non-linux-like interface.
>
> So, I'm thinking that if you want your WinMain or GetCommandLine using
> program to work with Cygwin 1.5.20 then you'll have to relink it.  I
> realize that this is a major departure from previous stated goal of
> maintaining backwards compatibility but we've already broken that once
> in recent memory with the case of pure Windows environment variables so
> I think we probably will just take the logical next step and break
> things for WinMain and GetCommandLine as well.
>
> If there are a lot of programs out there which are using WinMain or
> GetCommandLine then I guess we'll hear about it.  Otherwise, unless
> someone can convince me that this is a bad idea, Cygwin will start
> carrying a GetCommandLine substitute which regenerates the command line
> from the argv list.  I have something ready to go in my sandbox now
> but I thought I'd hold off doing this in case someone had a valid
> objection to this approach.

One argument against doing this is that people will now have to build and
distribute 2 versions of each such program -- one that works on 1.5.20,
and one that works on all previous versions of Cygwin.  However, I think
there *is* a way of writing the program so that it will work on both
versions, by using something like the following (untested) function:

typedef LPTSTR WINAPI (*GCL_PTR)(void);
LPTSTR WINAPI cygwinGetCommandLine(void) {
   HMODULE cygDLL, winDLL;
   GCL_PTR cygGCL, winGCL;
   cygDLL = GetModuleHandle(TEXT("cygwin1.dll"));
   cygGCL = (GCL_PTR) GetProcAddress(cygDLL, TEXT("GetCommandLine"));
   if (cygGCL != NULL) return cygGCL();
   winDLL = GetModuleHandle(TEXT("kernel32.dll"));
   winGCL = (GCL_PTR) GetProcAddress(winDLL, TEXT("GetCommandLine"));
   if (winGCL != NULL) return winGCL();
   return NULL;
}

and prefacing the rest of the program by:

#define GetCommandLine cygwinGetCommandLine

Barring some typos in the above, it should work.
WinMain would be a bit harder to emulate, but still possible using the
same techniques as above.

David, could you try this with your testcase and see if my claim is
correct?
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

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

Linking Windows dll with GCC application on cygwin

[Jie Xu]

Hi,

I have a dll, for which I don't have the source code, compiled in Visual 
Studio .NET 2003. How can I link this dll with my C++ codes compiled in GCC 
on cygwin?

Please help me.

Thanks!

-Jie




--
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: Linking Windows dll with GCC application on cygwin

[Igor Peshansky]

On Mon, 10 Apr 2006, Jie Xu wrote:

> I have a dll, for which I don't have the source code, compiled in Visual
> Studio .NET 2003. How can I link this dll with my C++ codes compiled in
> GCC on cygwin?

The short answer is: you can't (in general).  C++ name mangling is
different in GCC and MSVC, so you won't be able to link C++ calls
properly.

If the functionality exported is all 'extern "C"', you can link to the DLL
by simply specifying it on the command line.  One thing to keep in mind is
that the MSVC DLL is going to use the MSVC runtime, and your Cygwin code
will use the Cygwin runtime, and mixing runtimes is usually not a good
idea.  Unless you're sure that the functionality you use from the MSVC DLL
is going to behave properly, be prepared to track down some nasty bugs.
HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...)

[Christopher Faylor]

On Mon, Apr 10, 2006 at 09:48:10AM -0400, Igor Peshansky wrote:
>On Sun, 9 Apr 2006, Christopher Faylor wrote:
>
>> On Tue, Apr 04, 2006 at 11:44:47AM -0700, David Rothenberger wrote:
>> >WinMain() in a program compiled with cygwin1.dll is no longer
>> >getting passed the command-line from bash correctly with the
>> >20060403 snapshot. It works fine with the 20060329 snapshot.
>> >
>> >This is the same problem mentioned in
>> >.
>> >
>> >The same test case is attached here again (winCmdLine.c). I compile
>> >it with "gcc -o winCmdLine winCmdLine.c" (note no -mno-cygwin).
>>
>> This is due to recent changes which cause cygwin to stop filling out the
>> command-line for cygwin1.dll using programs.  We did this to fix the
>> "long command line" problem.
>>
>> There is a crude workaround for the problem which reinstates the
>> previous cygwin behavior but I really would rather not go that way.  It
>> would be nice if, just this once, we could make cygwin a little faster
>> at the expense of programs which are using a non-linux-like interface.
>>
>> So, I'm thinking that if you want your WinMain or GetCommandLine using
>> program to work with Cygwin 1.5.20 then you'll have to relink it.  I
>> realize that this is a major departure from previous stated goal of
>> maintaining backwards compatibility but we've already broken that once
>> in recent memory with the case of pure Windows environment variables so
>> I think we probably will just take the logical next step and break
>> things for WinMain and GetCommandLine as well.
>>
>> If there are a lot of programs out there which are using WinMain or
>> GetCommandLine then I guess we'll hear about it.  Otherwise, unless
>> someone can convince me that this is a bad idea, Cygwin will start
>> carrying a GetCommandLine substitute which regenerates the command line
>> from the argv list.  I have something ready to go in my sandbox now
>> but I thought I'd hold off doing this in case someone had a valid
>> objection to this approach.
>
>One argument against doing this is that people will now have to build and
>distribute 2 versions of each such program -- one that works on 1.5.20,
>and one that works on all previous versions of Cygwin.  However, I think
>there *is* a way of writing the program so that it will work on both
>versions, by using something like the following (untested) function:

This is not a problem.  GetCommandLine won't live in cygwin1.dll.  It
will live in libcygwin.a.  So, once linked, the binary will work with
any version of cygwin.

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/

Re: Linking Windows dll with GCC application on cygwin

[Jie Xu]

Thanks a lot!

-Jie

- Original Message - 
From: "Igor Peshansky" <[EMAIL PROTECTED]>

To: "Jie Xu" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, April 10, 2006 12:38 PM
Subject: Re: Linking Windows dll with GCC application on cygwin



On Mon, 10 Apr 2006, Jie Xu wrote:


I have a dll, for which I don't have the source code, compiled in Visual
Studio .NET 2003. How can I link this dll with my C++ codes compiled in
GCC on cygwin?


The short answer is: you can't (in general).  C++ name mangling is
different in GCC and MSVC, so you won't be able to link C++ calls
properly.

If the functionality exported is all 'extern "C"', you can link to the DLL
by simply specifying it on the command line.  One thing to keep in mind is
that the MSVC DLL is going to use the MSVC runtime, and your Cygwin code
will use the Cygwin runtime, and mixing runtimes is usually not a good
idea.  Unless you're sure that the functionality you use from the MSVC DLL
is going to behave properly, be prepared to track down some nasty bugs.
HTH,
Igor
--
http://cs.nyu.edu/~pechtcha/
 |\  _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
   '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends 
compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough 
in

that!" -- Rostand, "Cyrano de Bergerac"





--
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: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...)

[Igor Peshansky]

On Mon, 10 Apr 2006, Christopher Faylor wrote:

> On Mon, Apr 10, 2006 at 09:48:10AM -0400, Igor Peshansky wrote:
> >On Sun, 9 Apr 2006, Christopher Faylor wrote:
> >
> >> On Tue, Apr 04, 2006 at 11:44:47AM -0700, David Rothenberger wrote:
> >> >WinMain() in a program compiled with cygwin1.dll is no longer
> >> >getting passed the command-line from bash correctly with the
> >> >20060403 snapshot. It works fine with the 20060329 snapshot.
> >> >
> >> >This is the same problem mentioned in
> >> >.
> >> >
> >> >The same test case is attached here again (winCmdLine.c). I compile
> >> >it with "gcc -o winCmdLine winCmdLine.c" (note no -mno-cygwin).
> >>
> >> This is due to recent changes which cause cygwin to stop filling out the
> >> command-line for cygwin1.dll using programs.  We did this to fix the
> >> "long command line" problem.
> >>
> >> There is a crude workaround for the problem which reinstates the
> >> previous cygwin behavior but I really would rather not go that way.  It
> >> would be nice if, just this once, we could make cygwin a little faster
> >> at the expense of programs which are using a non-linux-like interface.
> >>
> >> So, I'm thinking that if you want your WinMain or GetCommandLine using
> >> program to work with Cygwin 1.5.20 then you'll have to relink it.  I
> >> realize that this is a major departure from previous stated goal of
> >> maintaining backwards compatibility but we've already broken that once
> >> in recent memory with the case of pure Windows environment variables so
> >> I think we probably will just take the logical next step and break
> >> things for WinMain and GetCommandLine as well.
> >>
> >> If there are a lot of programs out there which are using WinMain or
> >> GetCommandLine then I guess we'll hear about it.  Otherwise, unless
> >> someone can convince me that this is a bad idea, Cygwin will start
> >> carrying a GetCommandLine substitute which regenerates the command line
> >> from the argv list.  I have something ready to go in my sandbox now
> >> but I thought I'd hold off doing this in case someone had a valid
> >> objection to this approach.
> >
> >One argument against doing this is that people will now have to build and
> >distribute 2 versions of each such program -- one that works on 1.5.20,
> >and one that works on all previous versions of Cygwin.  However, I think
> >there *is* a way of writing the program so that it will work on both
> >versions, by using something like the following (untested) function:
>
> This is not a problem.  GetCommandLine won't live in cygwin1.dll.  It
> will live in libcygwin.a.  So, once linked, the binary will work with
> any version of cygwin.

If GetCommandLine lives in libcygwin.a, then programs linked on older
versions of Cygwin will not link that function in, and thus won't work
with the new DLL.  Programs linking with the new version of Cygwin will
have that function, but due to API changes, may not work with older DLLs.
Or am I missing something?
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...)

[Brian Dessent]

Igor Peshansky wrote:

> If GetCommandLine lives in libcygwin.a, then programs linked on older
> versions of Cygwin will not link that function in, and thus won't work
> with the new DLL.  Programs linking with the new version of Cygwin will
> have that function, but due to API changes, may not work with older DLLs.
> Or am I missing something?

It should work out like this:

Linked against  <1.5.20, Run against >=1.5.19:
 calls kernel32's GCL() and won't work

Linked against  <1.5.20, Run against  <1.5.19:
 calls kernel32's GCL() but the win environment exists, success
 
Linked against >=1.5.20, Run against any version:
 calls libcygwin's static GCL(), which works in any circumstance

Brian

--
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: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...)

[Igor Peshansky]

On Mon, 10 Apr 2006, Brian Dessent wrote:

> Igor Peshansky wrote:
>
> > If GetCommandLine lives in libcygwin.a, then programs linked on older
> > versions of Cygwin will not link that function in, and thus won't work
> > with the new DLL.  Programs linking with the new version of Cygwin will
> > have that function, but due to API changes, may not work with older DLLs.
> > Or am I missing something?
>
> It should work out like this:
>
> Linked against  <1.5.20, Run against >=1.5.19:
>  calls kernel32's GCL() and won't work
>
> Linked against  <1.5.20, Run against  <1.5.19:
>  calls kernel32's GCL() but the win environment exists, success
>
> Linked against >=1.5.20, Run against any version:
>  calls libcygwin's static GCL(), which works in any circumstance

I'm worried about the case

Linked against >=1.5.20, Run against <=1.5.19:
 calls libcygwin's static GCL, which works, but fails because 1.5.20
 (or 1.5.21, etc) has an extra API function that now gets invoked by
 the code, but is missing from 1.5.19 and earlier -- BOOM.

IOW, the infamous "Procedure entry point ... couldn't be found" popup.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...)

[Christopher Faylor]

On Mon, Apr 10, 2006 at 02:52:04PM -0400, Igor Peshansky wrote:
>On Mon, 10 Apr 2006, Brian Dessent wrote:
>> Igor Peshansky wrote:
>>>If GetCommandLine lives in libcygwin.a, then programs linked on older
>>>versions of Cygwin will not link that function in, and thus won't work
>>>with the new DLL.  Programs linking with the new version of Cygwin will
>>>have that function, but due to API changes, may not work with older
>>>DLLs.  Or am I missing something?
>>
>>It should work out like this:
>>
>>Linked against <1.5.20, Run against >=1.5.19: calls kernel32's GCL()
>>and won't work
>>
>>Linked against <1.5.20, Run against <1.5.19: calls kernel32's GCL() but
>>the win environment exists, success
>>
>>Linked against >=1.5.20, Run against any version: calls libcygwin's
>>static GCL(), which works in any circumstance
>
>I'm worried about the case
>
>Linked against >=1.5.20, Run against <=1.5.19: calls libcygwin's static
>GCL, which works, but fails because 1.5.20 (or 1.5.21, etc) has an
>extra API function that now gets invoked by the code, but is missing
>from 1.5.19 and earlier -- BOOM.
>
>IOW, the infamous "Procedure entry point ...  couldn't be found" popup.

So you're thinking that a program which has had no other changes, and
hasn't been recompiled, is going to somehow pull in newer functions from
cygwin1.dll?

Please provide examples of how that could happen.

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/

Re: when is using cygserver recommended? (thx)

[J. David Boyd]

"Dave Korn" <[EMAIL PROTECTED]> writes:

> On 10 April 2006 13:47, J. David Boyd wrote:
>
>> Christopher Faylor  writes:
>
>> To me, this sounds like it controls the 'fork'ing of items, but I can't
>> argue (too much), as I don't know for certain.
>
>   Then it's damn silly to argue (any at all) with someone who does know for
> certain!
>
>

Hmm, too true.  I guess I'll stop!  Have a great day...

Dave


--
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: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...)

[Igor Peshansky]

On Tue, 11 Apr 2006, Christopher Faylor wrote:

> On Mon, Apr 10, 2006 at 02:52:04PM -0400, Igor Peshansky wrote:
> >On Mon, 10 Apr 2006, Brian Dessent wrote:
> >> Igor Peshansky wrote:
> >>>If GetCommandLine lives in libcygwin.a, then programs linked on older
> >>>versions of Cygwin will not link that function in, and thus won't work
> >>>with the new DLL.  Programs linking with the new version of Cygwin will
> >>>have that function, but due to API changes, may not work with older
> >>>DLLs.  Or am I missing something?
> >>
> >>It should work out like this:
> >>
> >>Linked against <1.5.20, Run against >=1.5.19: calls kernel32's GCL()
> >>and won't work
> >>
> >>Linked against <1.5.20, Run against <1.5.19: calls kernel32's GCL() but
> >>the win environment exists, success
> >>
> >>Linked against >=1.5.20, Run against any version: calls libcygwin's
> >>static GCL(), which works in any circumstance
> >
> >I'm worried about the case
> >
> >Linked against >=1.5.20, Run against <=1.5.19: calls libcygwin's static
> >GCL, which works, but fails because 1.5.20 (or 1.5.21, etc) has an
> >extra API function that now gets invoked by the code, but is missing
> >from 1.5.19 and earlier -- BOOM.
> >
> >IOW, the infamous "Procedure entry point ...  couldn't be found" popup.
>
> So you're thinking that a program which has had no other changes, and
> hasn't been recompiled, is going to somehow pull in newer functions from
> cygwin1.dll?

Huh?  That's the point -- it *has* to be recompiled to get the new
GetCommandLine implementation from cygwin.a...

> Please provide examples of how that could happen.

I compile program A (which uses GCL) under 1.5.18 and release it.  It
doesn't work properly on 1.5.20+ (because it calls the kernel's GCL).  I
then recompile it under 1.5.20 to pull in the new libcygwin.a.  However,
this also pulls in whatever new functions are in cygwin1.dll, so that
program A now doesn't work with <1.5.20.  Am I missing something?
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_Igor Peshansky, Ph.D. (name changed!)
 |,4-  ) )-,_. ,\ (  `'-'   old name: Igor Pechtchanski
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
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: Cygwin backwards compatibility break with WinMain and GetCommandLine (was Re: WinMain() not getting cl...)

[Christopher Faylor]

On Mon, Apr 10, 2006 at 03:55:02PM -0400, Igor Peshansky wrote:
>On Tue, 11 Apr 2006, Christopher Faylor wrote:
>
>> On Mon, Apr 10, 2006 at 02:52:04PM -0400, Igor Peshansky wrote:
>> >On Mon, 10 Apr 2006, Brian Dessent wrote:
>> >> Igor Peshansky wrote:
>> >>>If GetCommandLine lives in libcygwin.a, then programs linked on older
>> >>>versions of Cygwin will not link that function in, and thus won't work
>> >>>with the new DLL.  Programs linking with the new version of Cygwin will
>> >>>have that function, but due to API changes, may not work with older
>> >>>DLLs.  Or am I missing something?
>> >>
>> >>It should work out like this:
>> >>
>> >>Linked against <1.5.20, Run against >=1.5.19: calls kernel32's GCL()
>> >>and won't work
>> >>
>> >>Linked against <1.5.20, Run against <1.5.19: calls kernel32's GCL() but
>> >>the win environment exists, success
>> >>
>> >>Linked against >=1.5.20, Run against any version: calls libcygwin's
>> >>static GCL(), which works in any circumstance
>> >
>> >I'm worried about the case
>> >
>> >Linked against >=1.5.20, Run against <=1.5.19: calls libcygwin's static
>> >GCL, which works, but fails because 1.5.20 (or 1.5.21, etc) has an
>> >extra API function that now gets invoked by the code, but is missing
>> >from 1.5.19 and earlier -- BOOM.
>> >
>> >IOW, the infamous "Procedure entry point ...  couldn't be found" popup.
>>
>> So you're thinking that a program which has had no other changes, and
>> hasn't been recompiled, is going to somehow pull in newer functions from
>> cygwin1.dll?
>
>Huh?  That's the point -- it *has* to be recompiled

See all of the uses of the word "linked" above?  It has to be relinked,
not recompiled.

>> Please provide examples of how that could happen.
>
>I compile program A (which uses GCL) under 1.5.18 and release it.  It
>doesn't work properly on 1.5.20+ (because it calls the kernel's GCL).  I
>then recompile it under 1.5.20 to pull in the new libcygwin.a.  However,
>this also pulls in whatever new functions are in cygwin1.dll, so that
>program A now doesn't work with <1.5.20.  Am I missing something?

I was only talking about the simple act of relinking a program, not
recompiling everything.  However, it's unlikely that a program which has
had no other changes is going to pull in a new function from the cygwin
DLL even after recompiling.  The only way I can think of that that could
happen is if a macro in a header file changed or we introduced a
backwards compatibility redirect in libcygwin.a.

A program which is using "WinMain()" or GetCommandLine is not likely to
be using linux functionality very heavily.  It's likely not going to be
using configure to detect the existence of new functions which will
cause the program to use new the functions.

So I think this scenario is pretty unlikely even if you do recompile.

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/

install_driver(Oracle) failed

[Jessie Chen]

Dear Sir:

I try to use perl script to connect to a oracle database in cygwin, and I am 
getting this error msg:
install_driver(Oracle) failed: cann't locate DBD/Oracle.pm in @INC (@INC 
contains: /usr/lib/perl5/5.8/cygwin ..)

Perphase the DBD::Oracle perl module hasn't been fully installed

Perl5.8 came with cygwin package, but I cann't find DBI and DBD-Oracle there 
in the package, so I dowlloaded both from CPAN and installed them in cygwin. 
Everything seems all right.


I can see that there is an Oracle.pm in C:\DBD-Oracle-1.16\blib\lib\DBD, but 
obviously, this dir is not included in @INC. What should I do to let @INC 
find it?


Thanks very much!

Jessie



--
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: Printer configuration problem

[Matthew Persico]

On 4/10/06, Rockefeller, Harry <[EMAIL PROTECTED]> wrote:
> lpq works to see the queue but printing doesn't.
>
> [EMAIL PROTECTED] /cygdrive/e
> $ lpq -SNTSERVER1 -Psw-txt1 -l
>
>  Windows 2000 LPD Server
>   Printer \\192.83.227.33\sw-txt1
>
> Owner   Status Jobname  Job-IdSize   Pages
> Priority
> 
> 
>
>
>
> [EMAIL PROTECTED] /cygdrive/e
> $ lpr poetry
> lpr: printer error: can't open '\\NTSERVER1\sw-txt1.lnk' for writing:
> The printer name is invalid.
>
>
> [EMAIL PROTECTED] /cygdrive/e
> $ lpr -d '\\192.83.227.33\sw-txt1' poetry
> lpr: printer error: can't open '\\192.83.227.33\sw-txt1.lnk' for
> writing: The printer name is invalid.

You have an Internet Explorer shortcut (the .lnk file) gumming up the works.

>
> I ran lprsetup.sh and followed instructions.
>
>
> --
> 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/
>
>
>


--
Matthew O. Persico

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

xv on cygwin?

[steven woody]

hi,

is there a solution of getting and installing xv on cygwin ? i got the
3.10a of the program but failed when compile.

thanks.

--
woody

--
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: xv on cygwin?

[René Berber]

steven woody wrote:

> is there a solution of getting and installing xv on cygwin ? i got the
> 3.10a of the program but failed when compile.

Should compile if you have the xorg-x11-devel package installed.

And better ask in the cygwin.xfree list; also include what error messages you
received when the compilation failed (do you have all the prerequisites?).
-- 
René Berber


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