Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <232810-220021012116554995@M2W063.mail2web.com>
Reply-To: lhall AT rfk DOT com
From: "lhall AT pop DOT ma DOT ultranet DOT com" <lhall AT pop DOT ma DOT ultranet DOT com>
To: shipnow AT davidnicol DOT com, cygwin AT sources DOT redhat DOT com
Subject: RE: cygwin use report: vexec, UML, off-topic X rave
Date: Mon, 21 Oct 2002 12:55:04 -0400
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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 AT davidnicol DOT com
Date: Mon, 21 Oct 2002 09:43:30 -0500
To: cygwin AT sources DOT redhat DOT 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/