Re: cygwin use report: vexec, UML, off-topic X rave

Re: cygwin use report: vexec, UML, off-topic X rave

[lhall]

Original Message:
-----------------
From: Christopher Faylor cgf@redhat.com
Date: Mon, 21 Oct 2002 15:26:34 -0400
To: cygwin@cygwin.com
Subject: Re: cygwin use report: vexec, UML, off-topic X rave


On Mon, Oct 21, 2002 at 12:55:04PM -0400, lhall@pop.ma.ultranet.com wrote:
>Hi David,
>
>I just wanted to make two comments based on your observations below.
>
>  1. File extensions are already optional on NT-based platforms. 
>Originally,
>     Cygwin didn't enforce ".exe" for exectuables.  This was added for
9x/Me
>     support and will likely remain until these systems fall into disuse.

Cygwin doesn't enforce .exe for executables on any platform, AFAIK.  Trying
to
run an executable without a .exe on Windows 9x just doesn't work, AFAIK.

<snip>

Right.  Poor choice of wording.  ".exe" was added to executables generated
by
gcc for Cygwin to permit them to run on 9x/Me platforms.  Individuals that 
don't run on 9x/Me and that want to remove the ".exe"s from their utilities 
are free to, assuming they don't mind always running those utilities from
the
Cygwin shells.

Also, it's worthwhile to point out that Cygwin didn't need to do anything
special to get executables without an extension to run as executables in 
Cygwin shells.  This is an NT/W2K/XP feature.  It's just not one that is 
generally used by Windows (i.e. it isn't available to cmd.exe, etc).

Larry

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin use report: vexec, UML, off-topic X rave

[lhall]

Hi David,

I just wanted to make two comments based on your observations below.

  1. File extensions are already optional on NT-based platforms. 
Originally,
     Cygwin didn't enforce ".exe" for exectuables.  This was added for 9x/Me
     support and will likely remain until these systems fall into disuse.

  2. Based on the above, it's not clear that there's a big win to "adding
     resources" to address this limitation for 9x/Me.  However, since this 
     is an open-source project, if volunteers appeared that wanted to pursue
     this, I expect the list would consider their patches.  That's generally
     the way the Cygwin project "adds resources".  I know, it's a little 
     different than at work. ;-)

Glad Cygwin is working for you. :-)

Larry

Original Message:
-----------------
From: David Nicol shipnow@davidnicol.com
Date: Mon, 21 Oct 2002 09:43:30 -0500
To: cygwin@sources.redhat.com
Subject: cygwin use report: vexec, UML, off-topic X rave





I have been using the cygwin environment for a month now and have these
things to report and recommend.

All in all, it has worked surprisingly well.  I have been developing
CLI and socket-based C applications for a unix target system with no
bumps at all.

SKIP DOWN A BIT TO AVOID DISCUSSION OF X

The demonstration of KDE appearing but then being impossible to use
is impressive -- but only as a demonstration.

A better X server for the windows platform would, in my opinion, throw
up a new windows window for each X client, rather than being a nested
server like Xnest or the old standby, Micro-images MIX.  Does cygwin
KDE work against Microimages MIX?  that is an interesting question I
have not explored.  I wonder how much glue is required to provide
a transparent x-client-as-windows-window translation.  I know I
used a Novell product for windows 3.11 in 1995 that did that trick,
although not as robustly as could be desired; and I suspect that 
window-as-window might be a mode that WeirdX can run in.  WeirdX, being
a java application, is resource-intensive, but it can run on the
vendor-provided JIT Java compiler instead of casting Xfree86 into a 
windows window.

I see that patching xfree to put each client in its own win32 window
is on the cygwin/X to-do list.  Good.

END XFREE SECTION

BEGIN RANT ABOUT FILE NAME EXTENSIONS AND POSIX

The whole thing with the filename extensions seems surprising that there
cannot be a workaround.  So what if a program I compile into myprog
cannot be invoked from the cmd shell because it doesn't have a .exe
extension; we have control over Cygwin BASH, can we not make Cygwin BASH
  respect permission bits and magic numbers and hash-bangs instead of
passing things to cmd.exe?  At that point, DJB install scripts and so on
  might start working without as much porting.

Maybe this could be done by using a cygwin vexec rather than a native
exec of some kind for launching new pids, that would fix the cause
instead of the symptom, and less porting would be required in idividual
packages.


Another direction is OS compatibility drivers.  Could cygwin absorb a 
project such as LINE that is designed to allow linux executables to run
under windows?

I guess I'm suggesting that the cygwin shell gets extended to absorb the
execution method selection function that unix users are used to getting
from the kernel, instead of using the windows kernel's mechanism, which
is based on filename extensions instead of permission bits, magic
numbers, and hashbangs.

This would means the cygwin bash, instead of executing with a simple 
fork and vexec (or whatever it does) would have to do a lot of the work
of the vexec itself:

it would launch a dispatcher program that would examine the target
filename and determine what to do with it, such as loading and executing
  it, or respecting the hashbang and loading and executing a shell
program, etc.

Then all the .exe extensions on the cygwin toolkit could be dropped, or
made optional if the tools are invoked from the cygwin shell.


This extending of the cygwin shell is in my opinion a high priority
item, since it will eliminate most of the porting issues currently open
if you want to port something like DJBDNS to cygwin.  I want to port
DJBDNS to cygwin so I can use the utilities in it, and currently doing
that means unwrapping several layers of DJB script abstraction and
compiling pieces directly instead of running an install script.  If
cygwin BASH were extended to treat non-extended filenames the way a
POSIX developer expects the files to get treated -- magic numbers and
hashbangs instead of extensions -- I expect that the install script in a
DJB package might start working just fine, at least until it tries to
edit the /etc/inittab file.


END VEXEC RANT


How about dedicating some resources to getting user-mode linux to
compile and run under cygwin?  That might solve a lot of problems.
Or maybe it wouldn't.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin use report: vexec, UML, off-topic X rave

[Christopher Faylor]

On Mon, Oct 21, 2002 at 12:55:04PM -0400, lhall@pop.ma.ultranet.com wrote:
>Hi David,
>
>I just wanted to make two comments based on your observations below.
>
>  1. File extensions are already optional on NT-based platforms. 
>Originally,
>     Cygwin didn't enforce ".exe" for exectuables.  This was added for 9x/Me
>     support and will likely remain until these systems fall into disuse.

Cygwin doesn't enforce .exe for executables on any platform, AFAIK.  Trying to
run an executable without a .exe on Windows 9x just doesn't work, AFAIK.

Also, Cygwin does handle '#!' shell scripts and it does look at magic numbers
to determine if something is executable, when ntsec is not active.

>  2. Based on the above, it's not clear that there's a big win to "adding
>     resources" to address this limitation for 9x/Me.  However, since this 
>     is an open-source project, if volunteers appeared that wanted to pursue
>     this, I expect the list would consider their patches.  That's generally
>     the way the Cygwin project "adds resources".  I know, it's a little 
>     different than at work. ;-)

Additional comments:  The Cygwin/XFree86 mailing list is cygwin-xfree@cygwin.com.
If David had scanned the archives for this mailing list or even just looked at
the last week worth of traffic, he could have spared himself a rant or at least
he could have ranted in the correct forum.

cgf
--
Please do not send me personal email with cygwin questions.
Use the resources at http://cygwin.com/ .

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

cygwin use report: vexec, UML, off-topic X rave

[David Nicol]

I have been using the cygwin environment for a month now and have these
things to report and recommend.

All in all, it has worked surprisingly well.  I have been developing
CLI and socket-based C applications for a unix target system with no
bumps at all.

SKIP DOWN A BIT TO AVOID DISCUSSION OF X

The demonstration of KDE appearing but then being impossible to use
is impressive -- but only as a demonstration.

A better X server for the windows platform would, in my opinion, throw
up a new windows window for each X client, rather than being a nested
server like Xnest or the old standby, Micro-images MIX.  Does cygwin
KDE work against Microimages MIX?  that is an interesting question I
have not explored.  I wonder how much glue is required to provide
a transparent x-client-as-windows-window translation.  I know I
used a Novell product for windows 3.11 in 1995 that did that trick,
although not as robustly as could be desired; and I suspect that 
window-as-window might be a mode that WeirdX can run in.  WeirdX, being
a java application, is resource-intensive, but it can run on the
vendor-provided JIT Java compiler instead of casting Xfree86 into a 
windows window.

I see that patching xfree to put each client in its own win32 window
is on the cygwin/X to-do list.  Good.

END XFREE SECTION

BEGIN RANT ABOUT FILE NAME EXTENSIONS AND POSIX

The whole thing with the filename extensions seems surprising that there
cannot be a workaround.  So what if a program I compile into myprog
cannot be invoked from the cmd shell because it doesn't have a .exe
extension; we have control over Cygwin BASH, can we not make Cygwin BASH
  respect permission bits and magic numbers and hash-bangs instead of
passing things to cmd.exe?  At that point, DJB install scripts and so on
  might start working without as much porting.

Maybe this could be done by using a cygwin vexec rather than a native
exec of some kind for launching new pids, that would fix the cause
instead of the symptom, and less porting would be required in idividual
packages.


Another direction is OS compatibility drivers.  Could cygwin absorb a 
project such as LINE that is designed to allow linux executables to run
under windows?

I guess I'm suggesting that the cygwin shell gets extended to absorb the
execution method selection function that unix users are used to getting
from the kernel, instead of using the windows kernel's mechanism, which
is based on filename extensions instead of permission bits, magic
numbers, and hashbangs.

This would means the cygwin bash, instead of executing with a simple 
fork and vexec (or whatever it does) would have to do a lot of the work
of the vexec itself:

it would launch a dispatcher program that would examine the target
filename and determine what to do with it, such as loading and executing
  it, or respecting the hashbang and loading and executing a shell
program, etc.

Then all the .exe extensions on the cygwin toolkit could be dropped, or
made optional if the tools are invoked from the cygwin shell.


This extending of the cygwin shell is in my opinion a high priority
item, since it will eliminate most of the porting issues currently open
if you want to port something like DJBDNS to cygwin.  I want to port
DJBDNS to cygwin so I can use the utilities in it, and currently doing
that means unwrapping several layers of DJB script abstraction and
compiling pieces directly instead of running an install script.  If
cygwin BASH were extended to treat non-extended filenames the way a
POSIX developer expects the files to get treated -- magic numbers and
hashbangs instead of extensions -- I expect that the install script in a
DJB package might start working just fine, at least until it tries to
edit the /etc/inittab file.


END VEXEC RANT


How about dedicating some resources to getting user-mode linux to
compile and run under cygwin?  That might solve a lot of problems.
Or maybe it wouldn't.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/