This is the mail archive of the cygwin-patches@cygwin.com 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]
Other format: [Raw text]

Re: Reorganizing internal_getlogin()


Hi!

Monday, 10 June, 2002 Christopher Faylor cgf@redhat.com wrote:

CF> On Mon, Jun 10, 2002 at 11:13:59AM +0200, Corinna Vinschen wrote:
>>On Sun, Jun 09, 2002 at 11:52:28PM -0400, Chris Faylor wrote:
>>> On Sun, Jun 09, 2002 at 11:12:53PM -0400, Pierre A. Humblet wrote:
>>> >2002-06-09  Pierre Humblet <pierre.humblet@ieee.org>
>>> >
>>> >    * environ.cc (addWinDefEnv): New.
>>> >    (inWinDefEnv): New.
>>> >    (writeWinDefEnv): New.
>>> >    * spawn.cc (spawn_guts): Call functions above to set
>>> >    traditional Windows environment variables when copying the
>>> >    environment to the cygheap, before CreateProcessAsUser().
>>> >    Define sec_attribs and call sec_user_nih() only once.
>>> >    * environ.h: Declare inWinDefEnv() and addWinDefEnv(), and 
>>> >    define WINDEFENVC.
>>> 
>>> I don't know about the sexec question.  Anyone know if there are (or
>>> were) any actual applications out there which use sexecve?  Isn't this
>>> just a cygwin invention?  I wonder if we should just nuke it from cygwin
>>> and see if anyone complains.  It would certainly simplify spawn.cc.
>>
>>AFAICS, there should only be old applications left using sexec,
>>perhaps the original SSH.com port from Sergey, years ago.  I'm
>>even not sure if it still works with current Cygwin.  login(1)
>>was originally ported by using sexec but neither login(1) nor
>>any other application in the distro are using any sexecXX call.
>>I'd guess it's existance is in limbo.  We *would* obviously 
>>break backward compatibility by removing that functionality
>>but it's a backward compatibility to applications build at least
>>two years ago.

CF> Ok.  I'm in favor of getting rid of sexec in 1.3.11, then.

CF> I'll do that sometime today.

Do you think it's better remove them from exports, or just make them
return ENOSYS? I'd prefer the latter, because windows has very nasty
habit f popping up gui dialog in case of absent dll entry point, and
if host is 1000 miles away and you're logged in remotely, there's no
way (or at lease i don't know one) to kill the application which
misses some entry in dll, other from reboot.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


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