Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #394664 > unrolled thread
| Started by | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| First post | 2025-10-22 14:39 -0700 |
| Last post | 2025-10-27 11:51 -0700 |
| Articles | 20 on this page of 196 — 19 participants |
Back to article view | Back to comp.lang.c
New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-22 14:39 -0700
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 22:19 -0300
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 02:42 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 03:04 +0000
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-23 15:05 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-23 11:36 +0100
Re: New and improved version of cdecl Thiago Adams <thiago.adams@gmail.com> - 2025-10-23 07:59 -0300
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 16:04 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 01:44 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-23 19:00 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 14:27 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-24 19:35 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 19:50 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-24 18:59 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:20 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-24 23:18 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:25 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 11:26 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 13:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:07 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 17:03 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-26 16:04 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 16:58 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 17:27 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 22:49 +0200
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 23:07 +0200
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 18:01 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-29 20:33 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:29 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:07 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 03:08 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:50 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 12:58 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:45 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:48 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:23 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 22:39 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 15:59 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 16:05 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:00 +0200
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 18:28 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 20:49 +0200
Re: New and improved version of cdecl Ben Bacarisse <ben@bsb.me.uk> - 2025-10-29 21:30 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:32 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 20:14 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 16:36 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 17:24 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-27 14:39 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 15:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 03:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 11:16 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 14:59 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 23:14 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-28 18:48 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 19:24 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 15:10 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 23:19 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 18:03 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 09:02 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 08:06 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 11:20 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-29 17:12 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 21:21 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 00:04 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 16:47 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 00:36 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 03:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-29 21:24 -0700
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 04:52 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-30 05:38 +0000
Re: New and improved version of cdecl Richard Heathfield <rjh@cpax.org.uk> - 2025-10-30 07:45 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 16:41 +0200
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 16:26 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 17:30 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-30 18:29 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 18:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:21 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:44 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 07:49 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 12:50 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 00:27 +0000
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-30 17:35 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 14:13 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 14:32 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-30 16:22 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:40 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 12:39 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 14:55 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 17:18 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 17:52 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-30 05:00 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 11:15 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:07 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 16:04 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-30 18:30 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 17:49 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-30 18:59 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:23 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 16:44 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 00:15 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 18:16 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:36 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 19:13 -0700
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:43 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:10 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 16:34 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:01 +0100
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 00:28 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 01:22 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 10:29 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-31 13:15 +0200
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 21:39 +0000
Re: New and improved version of cdecl richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-10-31 11:43 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 22:47 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-31 13:16 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 23:40 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-31 17:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-31 09:31 +0100
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 23:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 23:49 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-31 02:14 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 22:01 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 11:57 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-11-01 14:56 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-30 13:37 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-30 23:37 +0100
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-31 11:52 +0100
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-31 13:48 +0000
Re: New and improved version of cdecl vallor <vallor@vallor.earth> - 2025-10-29 23:11 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-29 06:57 +0100
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-29 14:17 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 14:40 +0000
Re: New and improved version of cdecl tTh <tth@none.invalid> - 2025-10-29 16:09 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-29 16:47 +0000
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-30 05:11 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-30 12:56 +0000
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-28 17:34 -0400
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-31 04:37 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:31 -0700
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-27 20:52 +0000
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 17:30 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 19:11 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 19:59 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:45 -0700
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 10:27 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 01:22 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-28 17:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 22:26 +0000
Re: New and improved version of cdecl Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-29 00:04 +0000
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-26 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 14:56 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 00:34 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:45 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-27 01:12 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 16:15 -0700
Re: New and improved version of cdecl Michael S <already5chosen@yahoo.com> - 2025-10-28 14:56 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 13:18 +0000
Re: New and improved version of cdecl scott@slp53.sl.home (Scott Lurndal) - 2025-10-28 15:03 +0000
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-28 16:16 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:04 +0200
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 13:51 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 17:18 +0200
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 07:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-26 15:12 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 10:44 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 11:22 +0000
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-27 17:35 +0100
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-27 17:44 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:10 +0100
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 23:47 -0700
Re: New and improved version of cdecl antispam@fricas.org (Waldek Hebisch) - 2025-10-27 22:33 +0000
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:23 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-28 16:20 +0100
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-27 13:48 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-28 04:41 +0100
Re: New and improved version of cdecl James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-10-25 11:40 -0400
Re: New and improved version of cdecl bart <bc@freeuk.com> - 2025-10-25 16:48 +0100
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 19:14 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-25 15:14 -0700
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-26 08:07 +0100
Re: New and improved version of cdecl Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-24 21:36 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:07 -0700
Re: New and improved version of cdecl David Brown <david.brown@hesbynett.no> - 2025-10-25 13:15 +0200
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-24 13:01 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-24 15:01 -0700
Re: New and improved version of cdecl Andrey Tarasevich <noone@noone.net> - 2025-10-26 12:09 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:36 -0700
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 07:31 -0800
Re: New and improved version of cdecl Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-09 20:38 +0000
Re: New and improved version of cdecl "Paul J. Lucas" <paul@lucasmail.org> - 2025-12-09 16:46 -0800
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-09 17:51 -0800
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 14:44 -0700
Re: New and improved version of cdecl Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-26 15:38 -0700
Re: New and improved version of cdecl "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-27 11:51 -0700
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-27 13:31 -0700 |
| Message-ID | <87h5vk13yq.fsf@example.invalid> |
| In reply to | #394784 |
bart <bc@freeuk.com> writes:
[...]
> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX.
>
> So they are utterly dependent on them. So much so that it is pretty
> much impossible to build this stuff on any non-UNIX environment,
> unless that environment is emulated. That is what happens with WSL,
> MSYS2, CYGWIN.
[...]
**Yes, you're right**.
The GNU autotools typically work smoothly when used on Unix-like
systems. They can be made to work nearly as smoothly under Windows
by using an emulation layer such as WSL, MSYS2, or Cygwin. It's very
difficult to use them on pure Windows.
Yes, that sucks for Windows users who want to build cdecl or
coreutils from source without using an emulation layer.
(A large part of the reason for this is that the folks who
implemented the GNU autotools, for ideological reasons, do not
care about supporting Windows. I won't go into their reasoning,
and I will not express an opinion about it here. I am simply
explaining it. Discuss it elsewhere if you like.)
I don't believe that anyone reading your articles is a GNU autotools
maintainer, so your incessant whining about them is futile.
The fact that I can't easily build cdecl from source on pure Windows
does not bother me. I am not motivated to do anything about it.
If it were a problem for me, I might take a look at the GNU autotools
and try to think of ways to make them work with MS Windows. I would
consider doing so if someone paid me for the work. If the existing
maintainers were not interested in any such changes, they could be
maintained in a separate fork.
Now I've acknowleged your concerns, explained that nobody here is
likely to be able to do anything to address them, and suggested
ways you might address them yourself.
What now, bart?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-27 20:52 +0000 |
| Message-ID | <20251027134847.610@kylheku.com> |
| In reply to | #394818 |
On 2025-10-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > bart <bc@freeuk.com> writes: > [...] >> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX. >> >> So they are utterly dependent on them. So much so that it is pretty >> much impossible to build this stuff on any non-UNIX environment, >> unless that environment is emulated. That is what happens with WSL, >> MSYS2, CYGWIN. > [...] > > **Yes, you're right**. > > The GNU autotools typically work smoothly when used on Unix-like > systems. They can be made to work nearly as smoothly under Windows > by using an emulation layer such as WSL, MSYS2, or Cygwin. It's very > difficult to use them on pure Windows. The way I see the status quo in this matter is this: cross-platform programs originating or mainly focusing on Unix-likes require effort /from their actual authors/ to have a native Windows port. Whereas when such programs are ported to Unix-like which their authors do not use, it is often possible for the users to get it working without needing help from the authors. There may be some patch to upstream, and that's about it. Also, a proper Windows port isn't just a way to build on Windows. Nobody does that. Windows doens't have tools out of the box. When you seriously commit to a Windows port, you provide a binary build with a proper installer. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-27 17:30 -0700 |
| Message-ID | <878qgv27gt.fsf@example.invalid> |
| In reply to | #394823 |
Kaz Kylheku <643-408-1753@kylheku.com> writes:
> On 2025-10-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX.
>>>
>>> So they are utterly dependent on them. So much so that it is pretty
>>> much impossible to build this stuff on any non-UNIX environment,
>>> unless that environment is emulated. That is what happens with WSL,
>>> MSYS2, CYGWIN.
>> [...]
>>
>> **Yes, you're right**.
>>
>> The GNU autotools typically work smoothly when used on Unix-like
>> systems. They can be made to work nearly as smoothly under Windows
>> by using an emulation layer such as WSL, MSYS2, or Cygwin. It's very
>> difficult to use them on pure Windows.
>
> The way I see the status quo in this matter is this: cross-platform
> programs originating or mainly focusing on Unix-likes require effort
> /from their actual authors/ to have a native Windows port.
>
> Whereas when such programs are ported to Unix-like which their
> authors do not use, it is often possible for the users to get it
> working without needing help from the authors. There may be some
> patch to upstream, and that's about it.
>
> Also, a proper Windows port isn't just a way to build on Windows.
> Nobody does that. Windows doens't have tools out of the box.
>
> When you seriously commit to a Windows port, you provide a binary build
> with a proper installer.
I agree that that's the status quo.
I can imagine either an enhanced version of the GNU autotools,
or a new set of tools similar to it, that could support building
software from source on Windows. It wouldn't work on Windows out
of the box, which doesn't provide much in the way of development
tools, but it could detect the presence of Visual Studio and/or
other development systems and use them automatically.
Ideally it would be a drop-in replacement for the GNU autotools,
so that someone could take, say, a copy of cdecl-18.5.tar.gz,
feed it to the tool, and it would build and install cdecl.exe in
the right place without depending on a Unix-like emulation layer.
It would probably have to work with the configure.ac file (which
is fed to autoconf) rather than with the generated configure script
(which requires a Bourne-like shell).
I don't know the details of how this could be done, and I certainly
don't have the motivation to implement it unless someone pays
me a lot of money to do so. And if nobody does this, I won't be
particularly inconvenienced. It's entirely possible that there
isn't enough demand to justify the effort.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-27 19:11 -0700 |
| Message-ID | <10dp8pd$1fd7u$4@dont-email.me> |
| In reply to | #394833 |
On 10/27/2025 5:30 PM, Keith Thompson wrote: [...] > I can imagine either an enhanced version of the GNU autotools, > or a new set of tools similar to it, that could support building > software from source on Windows. https://vcpkg.io/en/packages?query= Not bad, well for me, for now. Builds like a charm, so far. [...]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-27 19:59 -0700 |
| Message-ID | <874irj20lk.fsf@example.invalid> |
| In reply to | #394849 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 10/27/2025 5:30 PM, Keith Thompson wrote:
> [...]
>
>> I can imagine either an enhanced version of the GNU autotools,
>> or a new set of tools similar to it, that could support building
>> software from source on Windows.
>
> https://vcpkg.io/en/packages?query=
>
> Not bad, well for me, for now. Builds like a charm, so far.
>
> [...]
Looks interesting, but I don't think it's quite what I was talking about
(based on about 5 minutes browsing the website).
It seems to emphasize C and C++ *libraries* rather than applications.
And I don't see that it can be used to build an existing autotools-based
package (like, say, cdecl) on Windows.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-27 23:45 -0700 |
| Message-ID | <10dpopv$1n1q8$1@dont-email.me> |
| In reply to | #394852 |
On 10/27/2025 7:59 PM, Keith Thompson wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> On 10/27/2025 5:30 PM, Keith Thompson wrote: >> [...] >> >>> I can imagine either an enhanced version of the GNU autotools, >>> or a new set of tools similar to it, that could support building >>> software from source on Windows. >> >> https://vcpkg.io/en/packages?query= >> >> Not bad, well for me, for now. Builds like a charm, so far. >> >> [...] > > Looks interesting, but I don't think it's quite what I was talking about > (based on about 5 minutes browsing the website). So far, it can be used to cure some "headaches" over in Windows land... ;^) > > It seems to emphasize C and C++ *libraries* rather than applications. > And I don't see that it can be used to build an existing autotools-based > package (like, say, cdecl) on Windows. > Well, if what you want is not in that list, you are shit out of luck. ;^) It sure seems to build packages from source. For instance, I got Cairo compiled and up and fully integrated into MSVC. Pretty nice. At least its there. Although if it took a while to build everything, Bart would be pulling his hair out. But, beats manually building something that is not meant to be built on windows, uggg, sometimes, double uggg. Ming, cygwin, ect... vcpkg, has all of them, and used them to build certain things... I have built Cairo on Windows, and vcpkg is just oh so easy. Well, keep in mind, windows... ;^o
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-28 10:27 +0000 |
| Message-ID | <10dq5pq$1s6oa$1@dont-email.me> |
| In reply to | #394876 |
On 28/10/2025 06:45, Chris M. Thomasson wrote: > On 10/27/2025 7:59 PM, Keith Thompson wrote: >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>> On 10/27/2025 5:30 PM, Keith Thompson wrote: >>> [...] >>> >>>> I can imagine either an enhanced version of the GNU autotools, >>>> or a new set of tools similar to it, that could support building >>>> software from source on Windows. >>> >>> https://vcpkg.io/en/packages?query= >>> >>> Not bad, well for me, for now. Builds like a charm, so far. >>> >>> [...] >> >> Looks interesting, but I don't think it's quite what I was talking about >> (based on about 5 minutes browsing the website). > > So far, it can be used to cure some "headaches" over in Windows land... ;^) > >> >> It seems to emphasize C and C++ *libraries* rather than applications. >> And I don't see that it can be used to build an existing autotools-based >> package (like, say, cdecl) on Windows. >> > > Well, if what you want is not in that list, you are shit out of > luck. ;^) It sure seems to build packages from source. For instance, I > got Cairo compiled and up and fully integrated into MSVC. Pretty nice. > > At least its there. Although if it took a while to build everything, > Bart would be pulling his hair out. But, beats manually building > something that is not meant to be built on windows, uggg, sometimes, > double uggg. Ming, cygwin, ect... vcpkg, has all of them, and used them > to build certain things... > > I have built Cairo on Windows, and vcpkg is just oh so easy. Well, keep > in mind, windows... ;^o > PART I In the early days of testing my C compiler, I tried to build a hello-type test program using GTK2. GTK2 (I expect GTK4 is a lot worse!) was a complex library: * There were some 700 include files, spread over a dozen or two nested directories * Compiling my test involved over 1000 nested #include statements, 550 unique header files, a dozen include search paths, and 330,000 lines of declarations to process * To link the result, GTK2 comes with 50 DLL files, totalling 50MB, although not all will be needed. All have version names, so it's not just a case of suppying a particular file name, it needs to have the correct version suffix. I managed this by trial and error. The input to the compiler needs to be: * A set of search paths to the needed include files * The exact names of the needed DLL files (their location is not needed, provided the location is part of the Windows 'Path' variable) Note we are not building anything from source; it is the simpler task of using a ready-built library! The test program might be two dozen lines of C. So, how does it all work normally? Apparently it's done with a program called 'PKG-CONFIG' which performs some magic based on some 'metadata' somewhere. However this was of no interest to me: I wanted a bare-compiler solution with minimal meta-dependencies PART II At a different point, I wanted to try GTK2 from my own language. Here the sticking point is creating bindings, in my syntax, for the 10,000 functions, types, structs, enums, and macros exported by the library. My C compiler has an extension which could do some of that automatically: it processes the library headers (via the method in Part I), and generated a single, flattened interface file containing all the necessary information. For GTK2, this was a single 25Kloc file, which I called gtk2.m. In my language, I would compile the library by having 'import gtk2' in one place in the program. However, 4000 of those 25000 lines were C macros; simple #defines could be converted, but the rest needed manual translation: a big task. (The method has worked however for smaller libraries like OpenGL and SDL2.) But here's the interesting thing: if, instead of generating bindings in my syntax, suppose I generated them as C? Then, instead of 700 headers, 1/3 million lines and dozens of folders, the GTK2 API could be expressed in a single 25Kloc header file. Why isn't such a process done anyway by the suppliers of the library? (SDL2 would also reduce from 80 headers of 50Kloc, to one header of 3Kloc.) PART III This was an idea I had for my language, but it never got implemented. At this point, a simple external library involves one or more DLL files, and an interface file needed by the compiler, which gives the API info. My idea was, why not put that interface file inside the DLL? Then you submit that DLL name to the compiler, and it can extract the necessary info, either via some special function, or an exported set of variables. Where the DLL structure is complex, like GTK2, there could be an accompanying small DLL that replaces those 700 files of headers. One with an obvious name, like 'gtk2.dll'. (In my language, such input gets specified once inside the lead module. Building any app is always 'mm prog'.) However, one remaining problem is finding where the DLL is located. Again, the idea could work in C too.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-28 01:22 +0000 |
| Message-ID | <10dp5sb$1d8ic$1@dont-email.me> |
| In reply to | #394823 |
On 27/10/2025 20:52, Kaz Kylheku wrote: > On 2025-10-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> bart <bc@freeuk.com> writes: >> [...] >>> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX. >>> >>> So they are utterly dependent on them. So much so that it is pretty >>> much impossible to build this stuff on any non-UNIX environment, >>> unless that environment is emulated. That is what happens with WSL, >>> MSYS2, CYGWIN. >> [...] >> >> **Yes, you're right**. >> >> The GNU autotools typically work smoothly when used on Unix-like >> systems. They can be made to work nearly as smoothly under Windows >> by using an emulation layer such as WSL, MSYS2, or Cygwin. It's very >> difficult to use them on pure Windows. > > The way I see the status quo in this matter is this: cross-platform > programs originating or mainly focusing on Unix-likes require effort > /from their actual authors/ to have a native Windows port. > > Whereas when such programs are ported to Unix-like which their > authors do not use, it is often possible for the users to get it > working without needing help from the authors. There may be some > patch to upstream, and that's about it. > > Also, a proper Windows port isn't just a way to build on Windows. > Nobody does that. Windows doens't have tools out of the box. > > When you seriously commit to a Windows port, you provide a binary build > with a proper installer. The problem with a binary distribution is AV software on the user's machine which can block it. That's if the machine has been unlocked (something to do with 's-mode'), otherwise it can only run software from the Microsoft Store, and won't even run some of MS's own programs such as the command prompt. To get around that AV, you either need to have some clout, be 'white-listed', or somehow know some tricks. In my case, rather than supply a monolithic executable (EXE file, which either the app itself, or some sort of installer), I've played around with several alternatives, all of which are also single monolithic files, and are a step or two back from full binaries: * Provide a ASM file in AT&T format, which can be assembled and linked locally. This requires the user to be a programmer, who will already know how to bypass AV for their own programs * Provide a headerless C source file, which these days is very low level C. * Provide a binary but in my private format, which seems to evade AV. But this needs a launcher (an 800-line true-C program built-locally). * If the user has managed to obtain a working version of my compiler via the above means, then further apps could be downloaded in original source code (not C), but again, this will be a single amalgamated file. In all cases, there is one file to be assembled, compiled etc. Not dozens of source files, headers, makefiles etc. The approach used here can also work for Linux, but there only the C format would be viable ATM since I don't directly support the SYS V ABI needed by the other formats, assuming an x64 target, or the Linux may run on some other target anyway.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-28 17:03 +0000 |
| Message-ID | <20251028095213.518@kylheku.com> |
| In reply to | #394842 |
On 2025-10-28, bart <bc@freeuk.com> wrote: > On 27/10/2025 20:52, Kaz Kylheku wrote: >> On 2025-10-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> bart <bc@freeuk.com> writes: >>> [...] >>>> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX. >>>> >>>> So they are utterly dependent on them. So much so that it is pretty >>>> much impossible to build this stuff on any non-UNIX environment, >>>> unless that environment is emulated. That is what happens with WSL, >>>> MSYS2, CYGWIN. >>> [...] >>> >>> **Yes, you're right**. >>> >>> The GNU autotools typically work smoothly when used on Unix-like >>> systems. They can be made to work nearly as smoothly under Windows >>> by using an emulation layer such as WSL, MSYS2, or Cygwin. It's very >>> difficult to use them on pure Windows. >> >> The way I see the status quo in this matter is this: cross-platform >> programs originating or mainly focusing on Unix-likes require effort >> /from their actual authors/ to have a native Windows port. >> >> Whereas when such programs are ported to Unix-like which their >> authors do not use, it is often possible for the users to get it >> working without needing help from the authors. There may be some >> patch to upstream, and that's about it. >> >> Also, a proper Windows port isn't just a way to build on Windows. >> Nobody does that. Windows doens't have tools out of the box. >> >> When you seriously commit to a Windows port, you provide a binary build >> with a proper installer. > > The problem with a binary distribution is AV software on the user's > machine which can block it. Well, then you're fucked. (Which, anyway, is a good general adjective for someone still depending on Microsoft Windows.) The problem with source distribution is that users on Windows don't have any tooling. To get tooling, they would need to install binaries. > To get around that AV, you either need to have some clout, be The way you do that is by developing a compelling program that helps users get their work done and becomes popular, so users (and their managers) can they convince their IT that they need it. > In my case, rather than supply a monolithic executable (EXE file, which > either the app itself, or some sort of installer), I've played around You are perhaps too hastily skipping over the idea of "some sort of installer". Yes, use an installer for Windows if you're doing something serious that is offered to the public, rather than just to a handful of friends or customers. I use NSIS myself. Creating an installer is a PITA, but once you close the iteration loop on that, you hardly have to touch it, if the structure of your deliverables stays the same from release to release. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-28 22:26 +0000 |
| Message-ID | <10drfuj$2fnud$1@dont-email.me> |
| In reply to | #394894 |
On 28/10/2025 17:03, Kaz Kylheku wrote: > On 2025-10-28, bart <bc@freeuk.com> wrote: >> On 27/10/2025 20:52, Kaz Kylheku wrote: >>> On 2025-10-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>> bart <bc@freeuk.com> writes: >>>> [...] >>>>> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX. >>>>> >>>>> So they are utterly dependent on them. So much so that it is pretty >>>>> much impossible to build this stuff on any non-UNIX environment, >>>>> unless that environment is emulated. That is what happens with WSL, >>>>> MSYS2, CYGWIN. >>>> [...] >>>> >>>> **Yes, you're right**. >>>> >>>> The GNU autotools typically work smoothly when used on Unix-like >>>> systems. They can be made to work nearly as smoothly under Windows >>>> by using an emulation layer such as WSL, MSYS2, or Cygwin. It's very >>>> difficult to use them on pure Windows. >>> >>> The way I see the status quo in this matter is this: cross-platform >>> programs originating or mainly focusing on Unix-likes require effort >>> /from their actual authors/ to have a native Windows port. >>> >>> Whereas when such programs are ported to Unix-like which their >>> authors do not use, it is often possible for the users to get it >>> working without needing help from the authors. There may be some >>> patch to upstream, and that's about it. >>> >>> Also, a proper Windows port isn't just a way to build on Windows. >>> Nobody does that. Windows doens't have tools out of the box. >>> >>> When you seriously commit to a Windows port, you provide a binary build >>> with a proper installer. >> >> The problem with a binary distribution is AV software on the user's >> machine which can block it. > > Well, then you're fucked. (Which, anyway, is a good general adjective > for someone still depending on Microsoft Windows.) > > The problem with source distribution is that users on Windows don't > have any tooling. To get tooling, they would need to install binaries. There seems little problem with installing well-known compilers. Windows' AV seems to use AI methods to detect viruses which can give false positives (there is an 'ai' tag on the report code shown). So I guess 'gcc' etc must pass. Anyway these days I don't deal with non-technical endusers. People should know how to build programs. Or I had assumed they did. Although I'd gone to a lot of trouble to ensure my single-file C distributions are as easy to build as hello.c (on Windows, that is the case), I found out something interesting: Some people don't actually know how to compile hello.c! They know only how to type 'make', and some argue that is actually simpler in that you only type one thing instead of two or three. I was rather surprised: I'd reduced the job of installing a kitchen to hammering in just one nail so that you can trivially DIY it, but some people don't know how to use a hammer. >> To get around that AV, you either need to have some clout, be > > The way you do that is by developing a compelling program that helps > users get their work done and becomes popular, so users (and their > managers) can they convince their IT that they need it. > >> In my case, rather than supply a monolithic executable (EXE file, which >> either the app itself, or some sort of installer), I've played around > > You are perhaps too hastily skipping over the idea of "some sort of > installer". > > Yes, use an installer for Windows if you're doing something > serious that is offered to the public, rather than just to a handful of > friends or customers. An installer is just an executable like any other, at least if it as a .EXE extension. If you supply a one-file, self-contained ready-to-run application, then it doesn't really need installing. Wherever it happens to reside after downloading, it can happily be run from there! The only thing that's needed is to make it so that it can be run from anywhere without needing to type its path. But I can't remember any apps I've installed recently that seem to get that right, even with a long-winded installer: It might go through a long process of perhaps several minutes. It says it's installed, you type (what you assume to be) its name on the command line, and you get: File not found. It doesn't even tell where it installed it, or its actual EXE name. So my stuff is no worse. I just don't think anybody cares anymore; most poeple use GUI apps launched via Windows menus.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-29 00:04 +0000 |
| Message-ID | <20251028165333.690@kylheku.com> |
| In reply to | #394922 |
On 2025-10-28, bart <bc@freeuk.com> wrote:
> On 28/10/2025 17:03, Kaz Kylheku wrote:
>> On 2025-10-28, bart <bc@freeuk.com> wrote:
>>> On 27/10/2025 20:52, Kaz Kylheku wrote:
>>>> On 2025-10-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> bart <bc@freeuk.com> writes:
>>>>> [...]
>>>>>> Yes, but: the development and build procedures HAVE BEEN BUILT AROUND UNIX.
>>>>>>
>>>>>> So they are utterly dependent on them. So much so that it is pretty
>>>>>> much impossible to build this stuff on any non-UNIX environment,
>>>>>> unless that environment is emulated. That is what happens with WSL,
>>>>>> MSYS2, CYGWIN.
>>>>> [...]
>>>>>
>>>>> **Yes, you're right**.
>>>>>
>>>>> The GNU autotools typically work smoothly when used on Unix-like
>>>>> systems. They can be made to work nearly as smoothly under Windows
>>>>> by using an emulation layer such as WSL, MSYS2, or Cygwin. It's very
>>>>> difficult to use them on pure Windows.
>>>>
>>>> The way I see the status quo in this matter is this: cross-platform
>>>> programs originating or mainly focusing on Unix-likes require effort
>>>> /from their actual authors/ to have a native Windows port.
>>>>
>>>> Whereas when such programs are ported to Unix-like which their
>>>> authors do not use, it is often possible for the users to get it
>>>> working without needing help from the authors. There may be some
>>>> patch to upstream, and that's about it.
>>>>
>>>> Also, a proper Windows port isn't just a way to build on Windows.
>>>> Nobody does that. Windows doens't have tools out of the box.
>>>>
>>>> When you seriously commit to a Windows port, you provide a binary build
>>>> with a proper installer.
>>>
>>> The problem with a binary distribution is AV software on the user's
>>> machine which can block it.
>>
>> Well, then you're fucked. (Which, anyway, is a good general adjective
>> for someone still depending on Microsoft Windows.)
>>
>> The problem with source distribution is that users on Windows don't
>> have any tooling. To get tooling, they would need to install binaries.
>
> There seems little problem with installing well-known compilers.
If you think that is the case, then you can make an installer which
bundles some know compiler, and your source code ... and so it goes.
At install time, it builds the program.
The user doesn't care how the program came to be there.
(But even programs you build on the Windows machine itself can trigger
antivirus ...)
> An installer is just an executable like any other, at least if it as a
> .EXE extension.
Yes and, similarly, "there seems little problem with installing
well-known" installers.
> If you supply a one-file, self-contained ready-to-run application, then
> it doesn't really need installing. Wherever it happens to reside after
> downloading, it can happily be run from there!
Yes; that would be nice. Many people get PuTTY.exe that way, for
instance.
> The only thing that's needed is to make it so that it can be run from
> anywhere without needing to type its path. But I can't remember any apps
> I've installed recently that seem to get that right, even with a
> long-winded installer:
I did that for the Windows port of the TXR language. The installer
updates PATH and sends the Windows message to running apps about the
environment change. IIRC, existing cmd.exe instances pick that up.
The generated uninstall.exe will take it right out.
I've not looked at this in ages. I seem to recall there is a check
against inserting the same PATH entry multiple times.
Anyway, once you have that working, it works.
In my inst.nsi, in Section "TXR" it looks like this;
${If} $AccountType == "Admin"
${EnvVarUpdate} $0 "PATH" "A" "HKLM" "$INSTDIR\txr\bin"
${Else}
${EnvVarUpdate} $0 "PATH" "A" "HKCU" "$INSTDIR\txr\bin"
${Endif}
And in Section "Uninstall" the removal looks like this:
${If} $AccountType == "Admin"
${un.EnvVarUpdate} $0 "PATH" "R" "HKLM" "$INSTDIR\bin"
${Else}
${un.EnvVarUpdate} $0 "PATH" "R" "HKCU" "$INSTDIR\bin"
${Endif}
Thus everything is done by this EnvVarUpdate, and its un.EnvVarUpdate
These two environment update functions come from an "env.nsh" file that
is not part of NSIS; it is a utility developed by multiple authors: Cal
Turney, Amir Szekely, Diego Pedroso, Kevin English, Hendri Adriaens and
others.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-26 13:15 +0200 |
| Message-ID | <20251026131515.000036b6@yahoo.com> |
| In reply to | #394718 |
On Fri, 24 Oct 2025 13:20:45 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > bart <bc@freeuk.com> writes: > > On 24/10/2025 18:35, David Brown wrote: > >> On 24/10/2025 15:27, bart wrote: > >>> On 24/10/2025 03:00, Keith Thompson wrote: > >>>> bart <bc@freeuk.com> writes: > >>>>> On 24/10/2025 00:04, Keith Thompson wrote: > >>>>>> bart <bc@freeuk.com> writes: > >>>> [...] > >>>> > >>>> I note that you've ignored the vast majority of my previous > >>>> article. > >>> > >>> I've noted it, but chose not to reply. You have a point of view > >>> and attitude which I don't share. > >>> > >>> Mainly that you don't care how complicated a program for even a > >>> simple task is, and how laborious and OS-dependent its build > >>> process is, so long as it (eventually) works. > >>> > >>> That it favours your own OS, leaving users of other to have to > >>> jump through extra hoops, doesn't appear to bother you. > >>> > >> Why would someone care what how someone else writes their code, or > >> what it does, or what systems it runs on? They guy who wrote cdecl > >> gets to choose exactly how he wants to write it, and what systems > >> it supports. We others get it for free - we can use it if we like > >> and it if it suits our needs. But neither Keith nor anyone else > >> paid that guy to do the work, or contributed anything to the task, > >> and we have no right to judge what he choose to do, or how he > >> choose to do it. > > > > This a curious argument: it's free software so you don't care in the > > slightest how efficient it is or how user-friendly it might be to > > build? > > Its efficiency is not a great concern. I've seen no perceptible delay > between issuing a command to cdecl and seeing the result. No, I don't > much care what it does behind the scenes. If I did care, I might look > through the sources and try to think of ways to improve it. But the > effort to do so would vastly exceed any time I might save running it. > > The build and installation process for cdecl is very user-friendly. > It matches the process for thousands of other software packages that > are distributed in source. I can see that the process might be > confusing if you're not accustomed to it. If you *asked* rather than > just complaining, you might learn something. > > The stripped executable occupies about 0.000008% of my hard drive. > > > This is a program that reads lines of text from the terminal and > > translates them into another line of text. THAT needs thirty > > thousand lines of configure script?! And that's even before you > > start compiling the program itself. > > The configure script is automatically generated from "configure.ac", > which is 343 lines, 241 lines if comments and blank lines are > deleted. I've never written a configure.ac file myself, but most > of it looks like boilerplate. It would probably be fairly easy > (with some experience) to create one by modifying an existing one > from another project. > > > I'm thinking of making available some software that does even less, > > but wrap enough extra and POINTLESS levels complexity around that > > you'd need to lease time on a super-computer to build it. But the > > software is free so that makes it alright? > > Free software still has to be usable. cdecl is usable for most of us. > > [...] > I'd say that it is not sufficiently usable for most of us to actually use it. > > I was talking about all the stuff scrolling endlessly up to the > > screen for a minute and a half while running the configure script > > and then compiling the modules. > > Why is that a problem? If you like, you can redirect the output of > "./configure" and "make" to a file, and take a look at the output > later if you need to (you probably won't). > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-26 14:56 -0700 |
| Message-ID | <875xc11g47.fsf@example.invalid> |
| In reply to | #394735 |
Michael S <already5chosen@yahoo.com> writes:
> On Fri, 24 Oct 2025 13:20:45 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> Free software still has to be usable. cdecl is usable for most of us.
>>
>> [...]
>>
>
> I'd say that it is not sufficiently usable for most of us to actually
> use it.
Why do you say that?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-27 00:34 +0200 |
| Message-ID | <20251027003414.0000407b@yahoo.com> |
| In reply to | #394750 |
On Sun, 26 Oct 2025 14:56:56 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > On Fri, 24 Oct 2025 13:20:45 -0700 > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > [...] > >> Free software still has to be usable. cdecl is usable for most of > >> us. > >> > >> [...] > >> > > > > I'd say that it is not sufficiently usable for most of us to > > actually use it. > > Why do you say that? > I would guess that less than 1 per cent of C programmers ever used it and less than 5% of those who used it once continued to use it regularly. All numbers pulled out of thin air...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-26 15:45 -0700 |
| Message-ID | <87ms5dz3ht.fsf@example.invalid> |
| In reply to | #394751 |
Michael S <already5chosen@yahoo.com> writes:
> On Sun, 26 Oct 2025 14:56:56 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Michael S <already5chosen@yahoo.com> writes:
>> > On Fri, 24 Oct 2025 13:20:45 -0700
>> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> [...]
>> >> Free software still has to be usable. cdecl is usable for most of
>> >> us.
>> >>
>> >> [...]
>> >>
>> >
>> > I'd say that it is not sufficiently usable for most of us to
>> > actually use it.
>>
>> Why do you say that?
>
> I would guess that less than 1 per cent of C programmers ever used it
> and less than 5% of those who used it once continued to use it
> regularly.
> All numbers pulled out of thin air...
So it's about usefulness, not usability. You're not saying that
it works incorrectly or that it's difficult to use (which would be
usability issues), but that the job it performs is not useful for
most C programmers.
(One data point: I use it occasionally.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-27 01:12 +0200 |
| Message-ID | <20251027011239.000065eb@yahoo.com> |
| In reply to | #394754 |
On Sun, 26 Oct 2025 15:45:34 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > On Sun, 26 Oct 2025 14:56:56 -0700 > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: > >> > On Fri, 24 Oct 2025 13:20:45 -0700 > >> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> [...] > >> >> Free software still has to be usable. cdecl is usable for most > >> >> of us. > >> >> > >> >> [...] > >> >> > >> > > >> > I'd say that it is not sufficiently usable for most of us to > >> > actually use it. > >> > >> Why do you say that? > > > > I would guess that less than 1 per cent of C programmers ever used > > it and less than 5% of those who used it once continued to use it > > regularly. > > All numbers pulled out of thin air... > > So it's about usefulness, not usability. You're not saying that > it works incorrectly or that it's difficult to use (which would be > usability issues), but that the job it performs is not useful for > most C programmers. > No, it's about usability. I'd imagine that in order to be closer to usable tools like that would better be integrated into programmer's text editor/IDE. > (One data point: I use it occasionally.) > How about your co-workers?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-26 16:15 -0700 |
| Message-ID | <87ecqpz24a.fsf@example.invalid> |
| In reply to | #394756 |
Michael S <already5chosen@yahoo.com> writes:
> On Sun, 26 Oct 2025 15:45:34 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>> > On Sun, 26 Oct 2025 14:56:56 -0700
>> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> >> Michael S <already5chosen@yahoo.com> writes:
>> >> > On Fri, 24 Oct 2025 13:20:45 -0700
>> >> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> >> [...]
>> >> >> Free software still has to be usable. cdecl is usable for most
>> >> >> of us.
>> >> >>
>> >> >> [...]
>> >> >>
>> >> >
>> >> > I'd say that it is not sufficiently usable for most of us to
>> >> > actually use it.
>> >>
>> >> Why do you say that?
>> >
>> > I would guess that less than 1 per cent of C programmers ever used
>> > it and less than 5% of those who used it once continued to use it
>> > regularly.
>> > All numbers pulled out of thin air...
>>
>> So it's about usefulness, not usability. You're not saying that
>> it works incorrectly or that it's difficult to use (which would be
>> usability issues), but that the job it performs is not useful for
>> most C programmers.
>
> No, it's about usability.
> I'd imagine that in order to be closer to usable tools like that would
> better be integrated into programmer's text editor/IDE.
Personally, integration into a text editor or IDE would not be useful
for me. Of course I accept that it would be useful for you.
>> (One data point: I use it occasionally.)
>
> How about your co-workers?
I don't have any at the moment.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-10-28 14:56 +0200 |
| Message-ID | <20251028145639.00001900@yahoo.com> |
| In reply to | #394754 |
On Sun, 26 Oct 2025 15:45:34 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > On Sun, 26 Oct 2025 14:56:56 -0700 > > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: > >> > On Fri, 24 Oct 2025 13:20:45 -0700 > >> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> [...] > >> >> Free software still has to be usable. cdecl is usable for most > >> >> of us. > >> >> > >> >> [...] > >> >> > >> > > >> > I'd say that it is not sufficiently usable for most of us to > >> > actually use it. > >> > >> Why do you say that? > > > > I would guess that less than 1 per cent of C programmers ever used > > it and less than 5% of those who used it once continued to use it > > regularly. > > All numbers pulled out of thin air... > > So it's about usefulness, not usability. You're not saying that > it works incorrectly or that it's difficult to use (which would be > usability issues), but that the job it performs is not useful for > most C programmers. > > (One data point: I use it occasionally.) > Few minutes ago I typed 'pacman -S cdecl' at my msys2 command prompt. Then I hit Y at suggestion to proceed with installation. After another second or three I got it installed. Then tried it and even managed to get couple of declarations properly explained. So, now I also belong to less than 1 per cent :-) In the process I finally understand why the build process is none-trivial. It's mostly because of interactivity. It's very hard to build decent interactive program in portable subset of C. Or, may be, even impossible rather than hard. Personally, I consider interactivity of cdecl as UI mistake. For me, as a user, it's a minor mistake, because I can easily ignore interactivity and to use it as a normal command line utility: $ cdecl -e "FILE* uu" declare uu as pointer to FILE But if I were tasked with porting of cdecl to non-unixy environment then interactivity would be the biggest obstacle.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-10-28 13:18 +0000 |
| Message-ID | <10dqfru$2034r$1@dont-email.me> |
| In reply to | #394882 |
On 28/10/2025 12:56, Michael S wrote:
> On Sun, 26 Oct 2025 15:45:34 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>> On Sun, 26 Oct 2025 14:56:56 -0700
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>> On Fri, 24 Oct 2025 13:20:45 -0700
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> [...]
>>>>>> Free software still has to be usable. cdecl is usable for most
>>>>>> of us.
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>
>>>>> I'd say that it is not sufficiently usable for most of us to
>>>>> actually use it.
>>>>
>>>> Why do you say that?
>>>
>>> I would guess that less than 1 per cent of C programmers ever used
>>> it and less than 5% of those who used it once continued to use it
>>> regularly.
>>> All numbers pulled out of thin air...
>>
>> So it's about usefulness, not usability. You're not saying that
>> it works incorrectly or that it's difficult to use (which would be
>> usability issues), but that the job it performs is not useful for
>> most C programmers.
>>
>> (One data point: I use it occasionally.)
>>
>
> Few minutes ago I typed 'pacman -S cdecl' at my msys2 command prompt.
> Then I hit Y at suggestion to proceed with installation. After another
> second or three I got it installed. Then tried it and even managed to
> get couple of declarations properly explained.
> So, now I also belong to less than 1 per cent :-)
>
> In the process I finally understand why the build process is none-trivial.
> It's mostly because of interactivity.
> It's very hard to build decent interactive program in portable subset
> of C. Or, may be, even impossible rather than hard.
I don't understand. What's hard about interactive programs?
The problem below, which is in standard C and runs on both Windows and
Linux, should give you all the interativity needed for a program like CDECL.
It reads a line of input, and prints something based on that. In between
would go all the non-interactive processing that it needs to do (parse
the line and so on).
So what's missing that could render this task impossible?
(Obviously, it will need a keyboard and display!)
----------------------------------------
#include <stdio.h>
#include <string.h>
int main() {
char buffer[1000];
puts("Type q to quit:");
while (1) {
printf("Cdecl> ");
fgets(buffer, sizeof(buffer), stdin);
if (buffer[0] == 'q') break;
printf("Input was: %s\n", buffer);
}
}
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-10-28 15:03 +0000 |
| Message-ID | <hX4MQ.1394415$ctz9.474828@fx16.iad> |
| In reply to | #394883 |
bart <bc@freeuk.com> writes:
>On 28/10/2025 12:56, Michael S wrote:
>> On Sun, 26 Oct 2025 15:45:34 -0700
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>>>> On Sun, 26 Oct 2025 14:56:56 -0700
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>>> On Fri, 24 Oct 2025 13:20:45 -0700
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> [...]
>>>>>>> Free software still has to be usable. cdecl is usable for most
>>>>>>> of us.
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>
>>>>>> I'd say that it is not sufficiently usable for most of us to
>>>>>> actually use it.
>>>>>
>>>>> Why do you say that?
>>>>
>>>> I would guess that less than 1 per cent of C programmers ever used
>>>> it and less than 5% of those who used it once continued to use it
>>>> regularly.
>>>> All numbers pulled out of thin air...
>>>
>>> So it's about usefulness, not usability. You're not saying that
>>> it works incorrectly or that it's difficult to use (which would be
>>> usability issues), but that the job it performs is not useful for
>>> most C programmers.
>>>
>>> (One data point: I use it occasionally.)
>>>
>>
>> Few minutes ago I typed 'pacman -S cdecl' at my msys2 command prompt.
>> Then I hit Y at suggestion to proceed with installation. After another
>> second or three I got it installed. Then tried it and even managed to
>> get couple of declarations properly explained.
>> So, now I also belong to less than 1 per cent :-)
>>
>> In the process I finally understand why the build process is none-trivial.
>> It's mostly because of interactivity.
>> It's very hard to build decent interactive program in portable subset
>> of C. Or, may be, even impossible rather than hard.
>
>
>I don't understand. What's hard about interactive programs?
>
>The problem below, which is in standard C and runs on both Windows and
>Linux, should give you all the interativity needed for a program like CDECL.
>
>It reads a line of input, and prints something based on that. In between
>would go all the non-interactive processing that it needs to do (parse
>the line and so on).
>
>So what's missing that could render this task impossible?
>
>(Obviously, it will need a keyboard and display!)
>
>----------------------------------------
>#include <stdio.h>
>#include <string.h>
>
>int main() {
> char buffer[1000];
>
> puts("Type q to quit:");
>
> while (1) {
> printf("Cdecl> ");
> fgets(buffer, sizeof(buffer), stdin);
> if (buffer[0] == 'q') break;
>
> printf("Input was: %s\n", buffer);
> }
>}
Where is the command line editing and history support
in this trivial application?
Use libreadline or libedit and you'll get command line
history and editing; compatable with the standard
unix/linux shells (useful shells, unlike the DOS
command line or soi disant powershell).
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web