Discussion:
Cygnal: port programs to Windows with Cygwin
(too old to reply)
Kaz Kylheku
2020-09-27 18:29:16 UTC
Permalink
Hi all,

About four years ago (I think it was) I read the announcement on
Cygwin's mailing list that Cygwin was moving to LGPL licensing.

Immediately I realized that Cygwin could be used as a free run-time
library for porting POSIX programs to Windows, regardless of their
licensing: BSD-licensed programs, proprietary programs.

The only small problem: Windows users would be confused by some of the
the unusual conventions exhibited by those programs, such as path
handling.

I set to work on a fork of Cygwin which would incorporate a small
number of changes to make the Cygwin DLL into a native-like run-time.

I called it Cygnal (Cygwin Native Application Library);

http://www.kylheku.com

I use this as the basis for the Windows port of the TXR language.

If you want a reasonably high fidelity port of a program from the POSIX
world to Windows, it may be as easy as just building it on Cygwin with
its native compiler and then sliding the Cygwin library under it for
deployment.
Kenny McCormack
2020-09-30 15:45:49 UTC
Permalink
In article <***@kylheku.com>,
Kaz Kylheku <793-849-***@kylheku.com> wrote:
...
Post by Kaz Kylheku
The only small problem: Windows users would be confused by some of the
the unusual conventions exhibited by those programs, such as path
handling.
I set to work on a fork of Cygwin which would incorporate a small
number of changes to make the Cygwin DLL into a native-like run-time.
I called it Cygnal (Cygwin Native Application Library);
http://www.kylheku.com
I use this as the basis for the Windows port of the TXR language.
If you want a reasonably high fidelity port of a program from the POSIX
world to Windows, it may be as easy as just building it on Cygwin with
its native compiler and then sliding the Cygwin library under it for
deployment.
You need to say something about what it actually does.

So far, all I've seen (here and in comp.lang.awk) is what I would call
"Marketing Hype".

You need to appeal to people's (i.e., my) rational brain, not our lizard
brains.
--
Elect a clown, expect a circus.
Kaz Kylheku
2020-10-01 02:38:40 UTC
Permalink
Post by Kenny McCormack
...
Post by Kaz Kylheku
The only small problem: Windows users would be confused by some of the
the unusual conventions exhibited by those programs, such as path
handling.
I set to work on a fork of Cygwin which would incorporate a small
number of changes to make the Cygwin DLL into a native-like run-time.
I called it Cygnal (Cygwin Native Application Library);
http://www.kylheku.com
I use this as the basis for the Windows port of the TXR language.
If you want a reasonably high fidelity port of a program from the POSIX
world to Windows, it may be as easy as just building it on Cygwin with
its native compiler and then sliding the Cygwin library under it for
deployment.
You need to say something about what it actually does.
Well, it does the same things like the original Cygwin library, but
using native Windows conventions. Plus a few bugfixes thrown in.
Post by Kenny McCormack
You need to appeal to people's (i.e., my) rational brain, not our lizard
brains.
The rational brain is that you have some program from Unix or Linux
that you'd like to build on Windows and give to Windows users.
Cygwin looks like a possibility, but:

- The users don't know what the hell /cygdrive/c/Users/bob is.
Your program must produce, as well as understand a normal
path like C:\Users\bob.

- Users have text files in CR-LF format. You programs should read and
write those by default.

- Users have semicolon-separated PATH variable in this format:

C:\Program Files\Blah\foo.exe;C:\...

they don't want some weird layer rewriting it to another form.
Cygnal's path resolution works with that.

- Users want chdir("C:") to change the "logged drive" and go to
C:\Users\bob\Documents, which was last associated with C:

- Users want C:foo.txt to refer to C:\path\to\whatever\foo.txt
through the same logged drive mechanism.

- If you make a symbolic link with symlink(), it should produce a
Windows shortcut that Windows understand.

- Your program calls system(). That cannot be looking for /bin/sh.
It should instead use the interpreer specified by COMSPEC.

Does this ring a bell?

C:\Users\kaz>echo %COMSPEC%
C:\WINDOWS\system32\cmd.exe

Under Cygnal system("dir /w") will nicely run cmd.exe /c dir /w.

Not only system(). Cygnal will also notice any exec() activity
targeting /bin/sh and rewrite it to use cmd.exe. So any applications
that pass commands to the shell have a shot at working.

- Yet, we want these kinds of things without throwing out POSIX.
We want to be able to stat() a file, or use termios + ANSI escapes
for controlling the console, use normal sockets, and whatever else.

We don't want the Visual Studio run-time, in other words, with its
30-year-old garbage imitation of a tiny, barely working subset of
POSIX.
--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1
Jorgen Grahn
2020-10-01 06:00:28 UTC
Permalink
...
Post by Kenny McCormack
Post by Kaz Kylheku
If you want a reasonably high fidelity port of a program from the POSIX
world to Windows, it may be as easy as just building it on Cygwin with
its native compiler and then sliding the Cygwin library under it for
deployment.
You need to say something about what it actually does.
When Kaz posted the above, I remember thinking it was an unusually
good, brief product announcement.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Loading...