Jan Nieuwenhuizen wrote:

> On Thursday, 23 March 2000, Alain CULOS writes:
>
> > Under bare bones DOS shell, lilypond.exe still tries to access cygwin1.dll
> > (missing) and the other one when renamed, sorry to say Jan, but both are
> > still required.
>
> That's really a step backwards.  I'll just link to the new cygwin1.dll again.

Yes, but it'll clash with bash :-(


> I really don't understand these suffix problems.  When I had to use
> Cygwin under windows, I remember that I didn't use any .exe .py or
> whatnot, just doing
>
>         bash
>         $ echo "echo bar" > /bin/foo
>         $ chmod 755 /bin/foo
>         $ /bin/foo
>         bar
>
> should work fine.  Same for scripts that start with '#!/bin/python'.

On one hand you are right : for some things suffixes do not matter in windows but
for others they do.
Windows definitely requires suffixes to be correct for all files that deserve
special treatment as far as windows is concerned :
exe, dll, lnk, pif, and more.
On the other hand whenever you want to use the double-click facility you'd better
have the extension right so it calls the right program. Or the right click for a
contextual menu (edit/run/...).
Also I personally find it much cleaner with extensions, at least you know what you
are talking about. And in the case where extensions are used by more than one
program (which does not happen often), at least you only have just a few choices to
run. Being a maniac of organisation I can tell you that even on a unix system I
would put extensions to files (probably except exe's) at least files that I work
with often (for edition/activation/...).


> > still/again that dll issue, sorry to nag you, but will you please tell me why
> > you really want it, why not forget about it ?
>
> Uhm, I don't understand, what do you mean, forget about it ?

Not use cygwin dll.


> Anything
> you compile with gcc under cygwin will be using the cygwin*.dll
> compatibility layer.

Not true.
The cygwin dll is only meant to support specific calls to POSIX layers. It is not
necessary nor desirable for a plain vanilla C/C++ program that does not call upon
the system.
Lots of programs actually do not use specific POSIX system calls and therefore do
not require the POSIX compatibility layer.

One of the POSIX layers relied upon has to do with file access. If you use cygwin,
then opening a file will match both DOS path conventions and cygnus's
implementation of the unix conventions. On the other hand if you just use
-mno-cygwin, you'll be left with only the DOS conventions which should always work
unless you have a complex setup that uses unix style pathnames and it is too much
of a bother to change.


> Tonight, I've at last got the mingw cross-development tools working.
> But mingw is still too minimalistic for compiling guile; it won't work
> any time soon.

So that's the reason : guile.
I'll be happy to wait till you get time for that and let me know when you need a
hand for testing installation.


> Greetings,

Many happy returns.
Regards,
Alain.

Reply via email to