Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #74027 > unrolled thread
| Started by | Farley Flud <fflud@gnu.rocks> |
|---|---|
| First post | 2025-09-13 12:57 +0000 |
| Last post | 2025-09-14 13:18 +0000 |
| Articles | 20 on this page of 216 — 32 participants |
Back to article view | Back to comp.os.linux.misc
What Thinks Thou Of LO Donate Banner? Farley Flud <fflud@gnu.rocks> - 2025-09-13 12:57 +0000
Re: What Thinks Thou Of LO Donate Banner? Farley Flud <fflud@gnu.rocks> - 2025-09-13 13:23 +0000
Re: What Thinks Thou Of LO Donate Banner? Jacek Marcin Jaworski <jaworski1978@adres.pl> - 2025-09-13 15:28 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-13 22:00 +0000
Re: What Thinkest Thou Of LO Donate Banner? not@telling.you.invalid (Computer Nerd Kev) - 2025-09-14 08:26 +1000
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-13 23:04 +0000
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-09-14 09:01 +0100
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-14 21:17 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-15 02:13 +0200
Re: What Thinkest Thou Of LO Donate Banner? Tyrone <none@none.none> - 2025-09-15 00:50 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-15 12:38 +0200
Re: What Thinkest Thou Of LO Donate Banner? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-15 09:52 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-15 08:19 +0000
Re: What Thinkest Thou Of LO Donate Banner? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-15 10:49 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-15 09:03 +0000
Re: What Thinkest Thou Of LO Donate Banner? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-15 12:04 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-15 22:29 +0000
Re: What Thinkest Thou Of LO Donate Banner? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-16 08:23 +0200
Re: What Thinkest Thou Of LO Donate Banner? Richard Kettlewell <invalid@invalid.invalid> - 2025-09-16 08:53 +0100
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-16 12:54 +0200
Re: What Thinkest Thou Of LO Donate Banner? Richard Kettlewell <invalid@invalid.invalid> - 2025-09-16 20:07 +0100
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-16 21:42 +0200
Re: What Thinkest Thou Of LO Donate Banner? Richard Kettlewell <invalid@invalid.invalid> - 2025-09-16 22:12 +0100
Re: What Thinkest Thou Of LO Donate Banner? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-17 06:52 +0200
E-mail server-side attachment deduplication (was: Re: What Thinkest Thou Of LO Donate Banner?) Nuno Silva <nunojsilva@invalid.invalid> - 2025-09-17 12:02 +0100
Re: What Thinkest Thou Of LO Donate Banner? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-17 06:52 +0200
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-15 12:44 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-15 22:35 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-16 02:09 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-16 01:12 +0000
Re: What Thinkest Thou Of LO Donate Banner? 🇵🇱Jacek Marcin Jaworski🇵🇱 <jaworski1978@adres.pl> - 2025-09-16 05:47 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-16 05:48 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-16 12:57 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-17 05:56 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-17 11:15 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-17 09:31 +0000
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-09-15 10:01 +0100
Re: What Thinkest Thou Of LO Donate Banner? Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-09-15 12:06 +0200
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-15 13:13 +0200
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-11 23:38 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-12 02:59 +0100
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-11-12 03:23 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-14 14:18 +0100
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-11-14 19:43 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-14 22:20 +0100
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-12 05:11 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-12 06:29 +0000
Re: What Thinkest Thou Of LO Donate Banner? Nuno Silva <nunojsilva@invalid.invalid> - 2025-11-12 06:46 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-12 14:14 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-13 02:06 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-13 02:14 +0000
Re: What Thinkest Thou Of LO Donate Banner? Nuno Silva <nunojsilva@invalid.invalid> - 2025-11-13 11:01 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-13 13:39 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-14 14:20 +0100
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-15 20:50 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-15 22:08 +0100
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-16 05:40 +0000
Re: What Thinkest Thou Of LO Donate Banner? Nuno Silva <nunojsilva@invalid.invalid> - 2025-11-16 11:05 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-17 01:33 +0100
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-20 22:23 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-11-20 14:59 -0800
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-20 23:54 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-21 00:44 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-11-21 14:33 -0800
Re: What Thinkest Thou Of LO Donate Banner? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-11-22 00:16 +0000
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-22 00:20 +0000
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-11-22 03:20 +0000
Re: What Thinkest Thou Of LO Donate Banner? pothead <pothead@snakebite.com> - 2025-11-22 14:17 +0000
Re: What Thinkest Thou Of LO Donate Banner? Nuno Silva <nunojsilva@invalid.invalid> - 2025-11-22 14:39 +0000
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-11-22 20:08 +0000
Re: What Thinkest Thou Of LO Donate Banner? tom nossen <news@nossen.org> - 2025-11-26 22:07 +0100
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-26 21:50 +0000
Re: What Thinkest Thou Of LO Donate Banner? tom nossen <news@nossen.org> - 2025-11-27 12:18 +0100
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-27 21:26 +0000
Re: What Thinkest Thou Of LO Donate Banner? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-11-22 18:56 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-11-24 09:06 -0800
Re: What Thinkest Thou Of LO Donate Banner? "Joel W. Crump" <joelcrump@gmail.com> - 2025-11-24 12:10 -0500
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-11-24 09:29 -0800
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-24 23:15 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-11-24 15:35 -0800
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-11-25 00:21 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-23 03:19 +0000
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-23 05:20 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-11-24 09:26 -0800
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-24 18:27 +0000
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-24 23:23 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-02 20:13 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-12-03 08:39 -0800
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-12-03 19:42 +0100
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-03 22:03 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-12-03 22:36 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-04 03:05 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-12-04 14:24 +0000
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-04 14:35 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-12-04 08:21 -0800
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-04 18:05 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-12-04 10:09 -0800
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-04 19:09 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-12-04 11:11 -0800
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-04 19:55 +0000
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-19 01:22 +0000
Re: What Thinkest Thou Of LO Donate Banner? CrudeSausage <crude@sausa.ge> - 2025-12-18 20:45 -0500
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-19 10:54 +0000
Re: What Thinkest Thou Of LO Donate Banner? CrudeSausage <crude@sausa.ge> - 2025-12-19 09:11 -0500
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-19 15:02 +0000
Re: What Thinkest Thou Of LO Donate Banner? CrudeSausage <crude@sausa.ge> - 2025-12-19 10:38 -0500
Re: What Thinkest Thou Of LO Donate Banner? "Joel W. Crump" <joelcrump@gmail.com> - 2025-12-19 11:03 -0500
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-19 18:14 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-12-19 08:09 -0800
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-12-19 21:56 +0100
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-12-20 05:56 +0000
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-20 10:52 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-12-20 15:03 +0100
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-20 14:50 +0000
Ozempic (and Mounjaro, Zepbound, etc) Lars Poulsen <lars@beagle-ears.com> - 2025-12-20 15:04 +0000
Re: Ozempic (and Mounjaro, Zepbound, etc) chrisv <chrisv@nospam.invalid> - 2025-12-20 17:21 -0600
Re: What Thinkest Thou Of LO Donate Banner? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2025-12-20 20:45 +0000
Re: What Thinkest Thou Of LO Donate Banner? Sump <sumpusent@outlook.com> - 2025-12-20 22:02 +0000
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-21 01:56 +0000
Re: What Thinkest Thou Of LO Donate Banner? Sump <sumpusent@outlook.com> - 2025-12-21 02:10 +0000
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-21 02:13 +0000
Re: Big Pharma (was Re: What Thinkest Thou Of LO Donate Banner?) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-21 02:09 +0000
Re: Big Pharma (was Re: What Thinkest Thou Of LO Donate Banner?) Sump <sumpusent@outlook.com> - 2025-12-21 02:38 +0000
Re: Big Pharma (was Re: What Thinkest Thou Of LO Donate Banner?) rbowman <bowman@montana.com> - 2025-12-21 05:00 +0000
Re: Big Pharma (was Re: What Thinkest Thou Of LO Donate Banner?) The Natural Philosopher <tnp@invalid.invalid> - 2025-12-21 10:57 +0000
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-12-21 04:47 +0000
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-12-21 04:43 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-12-20 15:01 +0100
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-20 14:47 +0000
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-21 02:11 +0000
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) rbowman <bowman@montana.com> - 2025-12-21 04:34 +0000
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) Bob Tennent <rdtennent@tennent.ca> - 2025-12-22 02:17 +0000
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-22 04:43 +0000
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) Bob Tennent <rdtennent@tennent.ca> - 2025-12-22 15:53 +0000
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) c186282 <c186282@nnada.net> - 2025-12-22 01:54 -0500
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) Bob Tennent <rdtennent@tennent.ca> - 2025-12-22 15:57 +0000
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-12-22 08:49 -0800
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) The Natural Philosopher <tnp@invalid.invalid> - 2025-12-22 19:16 +0000
Re: Marxist Healthcare (was Re: What Thinkest Thou Of LO Donate Banner?) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-22 21:24 +0000
Re: Marxist Healthcare( was Re: What Thinkest Thou Of LO Donate Banner?) rbowman <bowman@montana.com> - 2025-12-22 19:47 +0000
Re: Marxist Healthcare Nuno Silva <nunojsilva@invalid.invalid> - 2025-12-23 11:02 +0000
Re: Marxist Healthcare Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2025-12-23 11:38 -0800
Re: Marxist Healthcare The Natural Philosopher <tnp@invalid.invalid> - 2025-12-23 20:23 +0000
Re: Marxist Healthcare Richard Kettlewell <invalid@invalid.invalid> - 2025-12-23 22:41 +0000
Re: Marxist Healthcare The Natural Philosopher <tnp@invalid.invalid> - 2025-12-24 12:23 +0000
Re: Marxist Healthcare rbowman <bowman@montana.com> - 2025-12-23 23:42 +0000
Re: What Thinkest Thou Of LO Donate Banner? CrudeSausage <crude@sausa.ge> - 2025-12-20 08:33 -0500
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-12-21 04:40 +0000
Re: What Thinkest Thou Of LO Donate Banner? CrudeSausage <crude@sausa.ge> - 2025-12-21 19:59 -0500
Ozempic... "Carlos E.R." <robin_listas@es.invalid> - 2025-12-26 22:24 +0100
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-04 22:47 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-12-05 00:15 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-04 22:48 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-12-05 00:14 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-04 22:47 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-12-05 00:16 +0000
Re: What Thinkest Thou Of LO Donate Banner? John Ames <commodorejohn@gmail.com> - 2025-12-03 14:41 -0800
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-04 03:05 +0000
Re: What Thinkest Thou Of LO Donate Banner? vallor <vallor@vallor.earth> - 2025-12-07 04:01 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-08 02:32 +0000
Re: What Thinkest Thou Of LO Donate Banner? vallor <vallor@vallor.earth> - 2025-12-08 04:36 +0000
Re: What Thinkest Thou Of LO Donate Banner? vallor <vallor@vallor.earth> - 2025-12-08 14:30 +0000
Re: What Thinkest Thou Of LO Donate Banner? pothead <pothead@snakebite.com> - 2025-12-08 23:21 +0000
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-09 10:01 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-10 01:37 +0000
Re: What Thinkest Thou Of LO Donate Banner? pothead <pothead@snakebite.com> - 2025-12-10 18:13 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-12-10 20:06 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-12 07:44 +0000
Re: What Thinkest Thou Of LO Donate Banner? Daniel70 <daniel47@nomail.afraid.org> - 2025-12-12 22:39 +1100
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-12-12 12:18 +0000
SYSCALL "Carlos E.R." <robin_listas@es.invalid> - 2025-12-10 14:01 +0100
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-12-10 01:37 +0000
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-20 23:01 +0000
Re: What Thinkest Thou Of LO Donate Banner? Nuno Silva <nunojsilva@invalid.invalid> - 2025-11-21 09:58 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-23 03:19 +0000
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-11-23 05:21 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-23 19:01 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-23 23:23 +0000
Re: What Thinkest Thou Of LO Donate Banner? Nuno Silva <nunojsilva@invalid.invalid> - 2025-11-23 23:41 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-24 00:39 +0000
Re: What Thinkest Thou Of LO Donate Banner? c186282 <c186282@nnada.net> - 2025-11-23 23:46 -0500
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-24 15:45 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-24 20:59 +0100
Re: What Thinkest Thou Of LO Donate Banner? ALB <alb@lupinedb.org> - 2025-11-25 19:38 -0500
Re: What Thinkest Thou Of LO Donate Banner? The Natural Philosopher <tnp@invalid.invalid> - 2025-11-26 13:35 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-26 15:12 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-26 15:10 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-16 15:14 +0100
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-16 02:56 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-16 05:40 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-16 15:13 +0100
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-20 22:23 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-21 13:05 +0100
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-21 15:35 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-23 03:19 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-23 05:16 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-23 23:23 +0000
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-24 00:33 +0000
Re: What Thinkest Thou Of LO Donate Banner? Gremlin <nobody@haph.org> - 2025-11-23 03:19 +0000
Re: What Thinkest Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-11-23 22:05 +0100
Re: What Thinkest Thou Of LO Donate Banner? Brock McNuggets <brock.mcnuggets@gmail.com> - 2025-11-24 02:24 +0000
Re: What Thinkest Thou Of LO Donate Banner? rbowman <bowman@montana.com> - 2025-09-14 00:04 +0000
Re: What Thinkest Thou Of LO Donate Banner? 🇵🇱Jacek Marcin Jaworski🇵🇱 <jaworski1978@adres.pl> - 2025-09-14 06:34 +0200
Re: What Thinkest Thou Of LO Donate Banner? 🇵🇱Jacek Marcin Jaworski🇵🇱 <jaworski1978@adres.pl> - 2025-09-14 06:48 +0200
Re: What Thinkest Thou Of LO Donate Banner? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-14 06:37 +0000
Re: What Thinkest Thou Of LO Donate Banner? chrisv <chrisv@nospam.invalid> - 2025-09-14 08:00 -0500
Re: What Thinks Thou Of LO Donate Banner? Farley Flud <ff@linux.rocks> - 2025-09-13 22:24 +0000
Re: What Thinks Thou Of LO Donate Banner? "Carlos E.R." <robin_listas@es.invalid> - 2025-09-14 13:38 +0200
Re: What Thinks Thou Of LO Donate Banner? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-09-14 12:53 +0000
Re: What Thinks Thou Of LO Donate Banner? "Joel W. Crump" <joelcrump@gmail.com> - 2025-09-13 11:02 -0400
Re: What Thinks Thou Of LO Donate Banner? vallor <vallor@cultnix.org> - 2025-09-13 17:02 +0000
Re: What Thinks Thou Of LO Donate Banner? Stéphane CARPENTIER <sc@fiat-linux.fr> - 2025-09-13 18:23 +0000
Re: What Thinks Thou Of LO Donate Banner? Tyrone <none@none.none> - 2025-09-14 00:12 +0000
Re: What Thinks Thou Of LO Donate Banner? Farley Flud <ff@linux.rocks> - 2025-09-14 08:45 +0000
Re: What Thinks Thou Of LO Donate Banner? "Joel W. Crump" <joelcrump@gmail.com> - 2025-09-14 05:01 -0400
Re: What Thinks Thou Of LO Donate Banner? Farley Flud <fflud@gnu.rocks> - 2025-09-14 13:18 +0000
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2025-11-25 00:21 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <mokb50FslmeU1@mid.individual.net> |
| In reply to | #77885 |
On Mon, 24 Nov 2025 23:15:52 -0000 (UTC), Lawrence D’Oliveiro wrote: > On Mon, 24 Nov 2025 09:06:28 -0800, John Ames wrote: > >> (It is a shame, though [about PowerShell]; with as much functionality >> as it exposes and how smooth it makes interoperation of various Windows >> components, it really *could* be tremendously useful. But it's such a >> pain in the ass to figure out that I practically never bother.) > > Could it be that, when it comes to command-line tools, even Microsoft > are no longer “eating their own dog food” when it comes to PowerShell? > Do their internal engineers prefer to adopt the much richer ecosystem > already available in Linux, instead of going to the trouble of trying to > build an entire parallel one from scratch for the Windows command line? https://learn.microsoft.com/en-us/powershell/scripting/install/install-powershell-on-linux?view=powershell-7.5
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <nobody@haph.org> |
|---|---|
| Date | 2025-11-23 03:19 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <XnsB39FE31DCFC2FHT1@cF04o3ON7k2lx05.lLC.9r5> |
| In reply to | #77763 |
John Ames <commodorejohn@gmail.com> news:20251120145948.00000987@gmail.com Thu, 20 Nov 2025 22:59:48 GMT in comp.os.linux.advocacy, wrote: > On Thu, 20 Nov 2025 22:23:47 -0000 (UTC) > Gremlin <nobody@haph.org> wrote: > >> I never thought macro support was a good idea. MS disagreed and many >> corporations and end users used the technology. > > It's a good idea *on paper* (as an expansion of office-productivity > features like mail-merge which have been around forever,) but the > extent to which MS enabled it to hook into damn near everything not > just in Office but the broader Win32 environment created a *plethora* > of security issues that should really have been obvious to anybody who > gave it fifteen minutes of consideration. Which is why I didn't think it was a good idea. I should have provided more details and included the context you provided. :) >> You can't depend on a files extension to actually be what the file is. > > Once upon a time you could, in MS-land, but Win95 and Windows Explorer > hopelessly muddied the waters on this in trying to make file-type > handling semi-transparent :/ Hmm. I don't remember a time in MS days from DOS to Windows that the file extension could absolutely be trusted. Even under the days of DOS, the extension didn't really matter if you did this: HITHERE.TXT for the example is really an .exe file. ; Assume a command string "HITHERE.TXT" is in memory ; and a valid parameter block is also set up. MOV AH, 4Bh ; EXEC - Execute Program MOV AL, 00h ; Load and execute MOV DX, OFFSET command_string ; DS:DX points to command string MOV BX, OFFSET param_block ; ES:BX points to parameter block INT 21h You couldn't type hithere.txt from a command prompt and it execute, sure. But, you could do something like the above in asm/another language of choice and it would, if it was an executable. Extension really didn't matter in that case. It could have been anything. a .dat file, a .jpg etc. It's what's actually inside the file if you make a direct OS call that matters. You can save time by examining some of the files actual content to determine if you will have to do a full scan on it. If it starts with MZ for example, you should be scanning it - because that's a well known marker for an executable file. Just as an example. .com files were a little trickier because they didn't officially have a header. Windows95 and above encouraged users to trust the file extension. That the extension was what the file really was. This resulted some in people being a little cheeky and having a bit of fun with it. such as openme.txt.exe. You'd see openme.txt and not the actual extension. So one double click for many users later and you might have had yourself a problem. In order to see the actual extension, you would have to turn hide extensions (the default setting) off. -- Liar, lawyer; mirror show me, what's the difference? Kangaroo done hung the guilty with the innocent Liar, lawyer; mirror for ya', what's the difference? Kangaroo be stoned. He's guilty as the government
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-11-23 05:20 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <10fu5ih$14jks$1@dont-email.me> |
| In reply to | #77834 |
On Sun, 23 Nov 2025 03:19:35 -0000 (UTC), Gremlin wrote: > You couldn't type hithere.txt from a command prompt and it execute, > sure. But, you could do something like the above in asm/another language > of choice and it would, if it was an executable. Extension really didn't > matter in that case. It could have been anything. a .dat file, a .jpg > etc. On *nix systems, the extension doesn’t matter at all, but the file must have execute permissions. > Windows95 and above encouraged users to trust the file extension. What’s worse is hiding it and then using it as the basis for indicating what the file type is, in the file manager.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-11-24 09:26 -0800 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <20251124092600.00001815@gmail.com> |
| In reply to | #77834 |
On Sun, 23 Nov 2025 03:19:35 -0000 (UTC) Gremlin <nobody@haph.org> wrote: > >> You can't depend on a files extension to actually be what the file > >> is. > > > > Once upon a time you could, in MS-land, but Win95 and Windows > > Explorer hopelessly muddied the waters on this in trying to make > > file-type handling semi-transparent :/ > > Hmm. I don't remember a time in MS days from DOS to Windows that the > file extension could absolutely be trusted. Even under the days of > DOS, the extension didn't really matter if you did this: > HITHERE.TXT for the example is really an .exe file. > > ; Assume a command string "HITHERE.TXT" is in memory > ; and a valid parameter block is also set up. > > MOV AH, 4Bh ; EXEC - Execute Program > MOV AL, 00h ; Load and execute > MOV DX, OFFSET command_string ; DS:DX points to command string > MOV BX, OFFSET param_block ; ES:BX points to parameter block > INT 21h > > You couldn't type hithere.txt from a command prompt and it execute, > sure. But, you could do something like the above in asm/another > language of choice and it would, if it was an executable. Interesting - I'm curious how common that actually was back in the day, though? I don't recall a lot of DOS applications that I used chaining from one EXE to another, unless you were really into launcher-menu type utilities; most of what I remember was single EXEs for the main program plus accessory EXEs for configuration (i.e. the inevitable SOUNDSET.EXE and its ilk,) and transfer of control was usually mediated by a *.BAT launcher script. (Although if COMMAND.COM invokes that mechanism itself in interpreting batch scripts, that'd certainly leave it vulnerable; no idea if that's the case or not.) > If it starts with MZ for example, you should be scanning it - because > that's a well known marker for an executable file. Just as an > example. .com files were a little trickier because they didn't > officially have a header. Yeah, it certainly doesn't hurt to sniff for a valid header if you're already looking at the file. > Windows95 and above encouraged users to trust the file extension. > That the extension was what the file really was. This resulted some > in people being a little cheeky and having a bit of fun with it. such > as openme.txt.exe. You'd see openme.txt and not the actual extension. > So one double click for many users later and you might have had > yourself a problem. In order to see the actual extension, you would > have to turn hide extensions (the default setting) off. Yes - this was an absolute misfeature in Win9x, and one that was pretty plainly a "look, we can *so* be MacOS!" on MS's part to boot. Caused no *end* of shenanigans over the years, it has... :/
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2025-11-24 18:27 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <6924a3a9$3$21$882e4bbb@reader.netnews.com> |
| In reply to | #77875 |
On Nov 24, 2025 at 10:26:00 AM MST, "John Ames" wrote <20251124092600.00001815@gmail.com>: >> Windows95 and above encouraged users to trust the file extension. >> That the extension was what the file really was. This resulted some >> in people being a little cheeky and having a bit of fun with it. such >> as openme.txt.exe. You'd see openme.txt and not the actual extension. >> So one double click for many users later and you might have had >> yourself a problem. In order to see the actual extension, you would >> have to turn hide extensions (the default setting) off. > > Yes - this was an absolute misfeature in Win9x, and one that was pretty > plainly a "look, we can *so* be MacOS!" on MS's part to boot. Caused no > *end* of shenanigans over the years, it has... :/ Agreed: the hidden extension default in Windows was an absurd misfeature, and likely trying to mimic Classic Mac OS's clean presentation. Before that, though, Classic Mac used Type and Creator Codes (metadata) to identify files. File extensions were not needed. When Apple moved Mac OS X, it switched to using filename extensions as the standard, universally accepted method for file identification as a way to be more compatible with Windows and make it easier to share files in a mixed environment. In short: Windows copied a Mac behavior, only later did Mac adopt the Windows/UNIX standard, largely for better sharing. -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-11-24 23:23 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <10g2pcs$2st2p$4@dont-email.me> |
| In reply to | #77875 |
On Mon, 24 Nov 2025 09:26:00 -0800, John Ames wrote: > (Although if COMMAND.COM invokes that mechanism itself in interpreting > batch scripts, that'd certainly leave it vulnerable; no idea if that's > the case or not.) COMMAND.COM has/had a special status in CP/M and related single-tasking systems (like MS-DOS), since it’s the executable you’re running when you’re not running an executable. I remember a description of how it worked in CP/M: to make more memory available for a program that the user wanted to run, the system would if necessary partially overwrite COMMAND.COM (all except a permanently- resident core). Then when the program exited, the resident part of the command interpreter would do a checksum over itself, and if that failed to verify, it knew it had to reload the overwritten part of itself. (I think it was a 16-bit checksum, so what are the odds that the overwriting data left the checksum unchanged, leading to COMMAND.COM believing it was still intact and promptly crashing? Me, I would have done something less clever and more reliable, like have a flag that the program loader could set to signal unambiguously to the command interpreter whether the overwriting had occurred or not.)
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <nobody@haph.org> |
|---|---|
| Date | 2025-12-02 20:13 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <XnsB3A99AD60239HT1@cF04o3ON7k2lx05.lLC.9r5> |
| In reply to | #77875 |
John Ames <commodorejohn@gmail.com> news:20251124092600.00001815@gmail.com Mon, 24 Nov 2025 17:26:00 GMT in comp.os.linux.advocacy, wrote: > On Sun, 23 Nov 2025 03:19:35 -0000 (UTC) > Gremlin <nobody@haph.org> wrote: > >> >> You can't depend on a files extension to actually be what the file >> >> is. >> > >> > Once upon a time you could, in MS-land, but Win95 and Windows >> > Explorer hopelessly muddied the waters on this in trying to make >> > file-type handling semi-transparent :/ >> >> Hmm. I don't remember a time in MS days from DOS to Windows that the >> file extension could absolutely be trusted. Even under the days of >> DOS, the extension didn't really matter if you did this: >> HITHERE.TXT for the example is really an .exe file. >> >> ; Assume a command string "HITHERE.TXT" is in memory >> ; and a valid parameter block is also set up. >> >> MOV AH, 4Bh ; EXEC - Execute Program >> MOV AL, 00h ; Load and execute >> MOV DX, OFFSET command_string ; DS:DX points to command string >> MOV BX, OFFSET param_block ; ES:BX points to parameter block >> INT 21h >> >> You couldn't type hithere.txt from a command prompt and it execute, >> sure. But, you could do something like the above in asm/another >> language of choice and it would, if it was an executable. > > Interesting - I'm curious how common that actually was back in the day, > though? I don't recall a lot of DOS applications that I used chaining > from one EXE to another, unless you were really into launcher-menu type > utilities; most of what I remember was single EXEs for the main program > plus accessory EXEs for configuration (i.e. the inevitable SOUNDSET.EXE > and its ilk,) and transfer of control was usually mediated by a *.BAT > launcher script. It was common enough to be known amongst every coder I knew. Some programmers too. Take some of the multi floppy install packages for example. Some decrypted the necessary materials as they built the primary file on your computer. The primary file wouldn't always have a proper executable extension, but, it was still actually an .EXE most of the time. > (Although if COMMAND.COM invokes that mechanism itself in interpreting > batch scripts, that'd certainly leave it vulnerable; no idea if that's > the case or not.) COMMAND.COM didn't invoke it. >> If it starts with MZ for example, you should be scanning it - because >> that's a well known marker for an executable file. Just as an >> example. .com files were a little trickier because they didn't >> officially have a header. > > Yeah, it certainly doesn't hurt to sniff for a valid header if you're > already looking at the file. When you have a file of any real length but don't want to waste time full scanning if it's not an EXE based executable, a quick check is faster than processing a shitload more bytes. Even on old relics of yesteryear. >> Windows95 and above encouraged users to trust the file extension. >> That the extension was what the file really was. This resulted some >> in people being a little cheeky and having a bit of fun with it. such >> as openme.txt.exe. You'd see openme.txt and not the actual extension. >> So one double click for many users later and you might have had >> yourself a problem. In order to see the actual extension, you would >> have to turn hide extensions (the default setting) off. > > Yes - this was an absolute misfeature in Win9x, and one that was pretty > plainly a "look, we can *so* be MacOS!" on MS's part to boot. Caused no > *end* of shenanigans over the years, it has... :/ Agreed. It wasn't one of their best decisions... -- Liar, lawyer; mirror show me, what's the difference? Kangaroo done hung the guilty with the innocent Liar, lawyer; mirror for ya', what's the difference? Kangaroo be stoned. He's guilty as the government
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-12-03 08:39 -0800 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <20251203083900.00002c04@gmail.com> |
| In reply to | #78200 |
On Tue, 2 Dec 2025 20:13:15 -0000 (UTC) Gremlin <nobody@haph.org> wrote: > > Interesting - I'm curious how common that actually was back in the > > day, though? I don't recall a lot of DOS applications that I used > > chaining from one EXE to another, unless you were really into > > launcher-menu type utilities; most of what I remember was single > > EXEs for the main program plus accessory EXEs for configuration > > (i.e. the inevitable SOUNDSET.EXE and its ilk,) and transfer of > > control was usually mediated by a *.BAT launcher script. > > It was common enough to be known amongst every coder I knew. Some > programmers too. Take some of the multi floppy install packages for > example. Some decrypted the necessary materials as they built the > primary file on your computer. The primary file wouldn't always have > a proper executable extension, but, it was still actually an .EXE > most of the time. Huh, I'm trying to model what an exploit would look like here - who & what would be vulnerable to this? Obviously you *can* create a disk file with a non-EXE extension & whatever contents you want, but under what circumstances is another program gonna call the load-and-execute routine on any arbitrary filename (other than, as mentioned, app-menu utilities or command-shell alternatives?) Or if the game is to replace one of an application suite's own I-can't-believe-it's-not-EXEs with a Trojan, which developers bothered to mask their secondary EXEs under a different extension, and why...? (I mean, yes, installers might well build a final EXE from smaller and/or compressed/encrypted chunks, but the *resulting* file would normally still have an EXE extension, and be invoked the usual way.) Not saying that it doesn't make sense to check files on a better-safe- than-sorry heuristic, just trying to figure out how you'd get to the point of pulling that kind of trick in the first place...
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-12-03 19:42 +0100 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <ltc60mxdr1.ln2@Telcontar.valinor> |
| In reply to | #78241 |
On 2025-12-03 17:39, John Ames wrote: > On Tue, 2 Dec 2025 20:13:15 -0000 (UTC) > Gremlin <nobody@haph.org> wrote: > >>> Interesting - I'm curious how common that actually was back in the >>> day, though? I don't recall a lot of DOS applications that I used >>> chaining from one EXE to another, unless you were really into >>> launcher-menu type utilities; most of what I remember was single >>> EXEs for the main program plus accessory EXEs for configuration >>> (i.e. the inevitable SOUNDSET.EXE and its ilk,) and transfer of >>> control was usually mediated by a *.BAT launcher script. >> >> It was common enough to be known amongst every coder I knew. Some >> programmers too. Take some of the multi floppy install packages for >> example. Some decrypted the necessary materials as they built the >> primary file on your computer. The primary file wouldn't always have >> a proper executable extension, but, it was still actually an .EXE >> most of the time. > > Huh, I'm trying to model what an exploit would look like here - who & > what would be vulnerable to this? Obviously you *can* create a disk > file with a non-EXE extension & whatever contents you want, but under > what circumstances is another program gonna call the load-and-execute > routine on any arbitrary filename (other than, as mentioned, app-menu > utilities or command-shell alternatives?) Or if the game is to replace > one of an application suite's own I-can't-believe-it's-not-EXEs with a > Trojan, which developers bothered to mask their secondary EXEs under a > different extension, and why...? > > (I mean, yes, installers might well build a final EXE from smaller > and/or compressed/encrypted chunks, but the *resulting* file would > normally still have an EXE extension, and be invoked the usual way.) > > Not saying that it doesn't make sense to check files on a better-safe- > than-sorry heuristic, just trying to figure out how you'd get to the > point of pulling that kind of trick in the first place... With mail software, it was common enough to try: beautiful postcard.jpg..................exe but this was a different trick. The other type I have not seen it. -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <nobody@haph.org> |
|---|---|
| Date | 2025-12-03 22:03 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5> |
| In reply to | #78241 |
John Ames <commodorejohn@gmail.com> news:20251203083900.00002c04@gmail.com Wed, 03 Dec 2025 16:39:00 GMT in comp.os.linux.advocacy, wrote: > On Tue, 2 Dec 2025 20:13:15 -0000 (UTC) > Gremlin <nobody@haph.org> wrote: > Huh, I'm trying to model what an exploit would look like here - who & > what would be vulnerable to this? Obviously you *can* create a disk > file with a non-EXE extension & whatever contents you want, but under > what circumstances is another program gonna call the load-and-execute > routine on any arbitrary filename (other than, as mentioned, app-menu > utilities or command-shell alternatives?) Or if the game is to replace > one of an application suite's own I-can't-believe-it's-not-EXEs with a > Trojan, which developers bothered to mask their secondary EXEs under a > different extension, and why...? I wasn't writing about trojans using this? A trojan obviously could, but, that isn't what I was describing... I was writing about some installers doing it. Just not using a .bat file to pass control but doing it themselves. They'd recombine pieces of the executable (a chunk on each floppy for example) and then pass control to the final resulting file which would be an .EXE, but not necessarily with that file extension. I suppose one could think of it as a very simple way to keep 'nosey' people out? If the program comes with an install.exe and some 1,2,3 etc files that turn into a .DAT file; you probably won't give it a second look. You assume that because it's a .DAT file that it cannot be directly executed- that the install.exe is doing all the work. And it's using the .DAT file for instructions/configuration/data, etc, not that the .DAT file is the next stage of the install process itself. As for the trojan aspect you bring up, I did once use a .DLL file as a marker so that the program wouldn't access your email client for the 2nd time and email anyone again. The file wasn't really a .DLL though, but you wouldn't have been the wiser if you didn't actually examine it. It had a legitimate Windows name with proper date/time stamps that would trick you into thinking the file was as old as the rest of the common .DLLs on your machine - You wouldn't have known it was created that morning for example. Using DOS interrupts... Here's a little code from the program I was writing about. It's primarily written in an ancient DOS based language called ASIC. v5 specifically. rem ***Get/Set Date/Time stamps get_fdt: if file_handle>4 then AX=&HEX5700 BX=FILE_HANDLE INT86(&HEX21,AX,BX,CX,DX,NA,NA,NA,NA,NA) NEWDATE=CX NEWTIME=DX endif RETURN set_fdt: if file_handle>4 then AX=&HEX5701 BX=FILE_HANDLE CX=NEWDATE DX=NEWTIME INT86(&HEX21,AX,BX,CX,DX,NA,NA,NA,NA,NA) endif RETURN And these are the interrupts to get the current attribute and null it and then put it back later... rem ***Attribute get/set interrupts get_attr: AX = &HEX4300 DX = VARPTR(Filename$) CX = NewAttr INT86(&HEX21,AX,NA,CX,DX,NA,NA,NA,NA,NA) return set_attr: AX = &HEX4301 DX = VARPTR(Filename$) CX = NewAttr INT86(&HEX21,AX,NA,CX,DX,NA,NA,NA,NA,NA) return You just set newattr=0 and make the call, tada; now it's a normal file suitable for read/write. Save it beforehand with the get attr call, save the variable, call the set routine again when you're finished phucking around with it. Which is what this subroutine did: pre_open: rem *** routine when called with getem=0 will rem obtain the current file attributes, retain this rem and reset the attribute to null for read/write. rem If called with getem=1 it will restore the attribute rem to what it was previously. if getem=0 then gosub get_attr: oldattr=newattr newattr=0 gosub set_attr: else newattr=oldattr gosub set_attr: endif return ASICs built in file I/O routines left much to be desired speed wise, and when you're moving 10k or more around, you want it done fast. You don't have time to phuck around going byte by byte. Nah, you allocate some memory and pull a chunk all at once with a single DOS interrupt call. Super fucking quick. Plus once it's in memory, you can do whatever needs to be done much faster than doing it with the file on disk. RAM is faster after all. then set the file pointer, dump the ram content right back - again super fucking quick. I was trying to explain this previously but it somehow got lost in translation I suppose. You'll have to ignore the comments, the 'engine' is c/p from a particular piece of self replicating code I wrote decades ago. rem open_file chart! rem ax=&hex3d00 rem read-only rem ax=&hex3d01 rem write only rem ax=&hex3d02 rem read/write open_file: rem See chart for access mode used. AX=&HEX3D02 DX = VARPTR(Filename$) INT86(&HEX21,AX,NA,na,DX,NA,NA,NA,NA,NA) file_handle=ax return write_file: rem this routine will write selected bytes at whatever current position rem from whatever buffer i choose into the file. rem if the routine did not write all data ax will not equal cx upon rem return from int call. rem define dx register before calling this routine to point to the rem memory address of the buffer area you want to write from. like so: rem dx=varptr(buffer(0)) rem cx is how many bytes to write :) if file_handle>4 then ax=&hex4000 bx=file_handle cx=bytesize int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) byteswritten=ax endif return read_file: rem as the name implies, it reads bytes into a buffer. :-) rem as with write_file, you need to predefine the dx register for the rem buffer where you want the info stored. Like so: dx=varptr(buffer(0)) rem if you don't, this routine will not work, or will overwrite some rem other section of memory. And for virus coding, this is very bad! :) rem cx register is how many bytes to read :) if file_handle>4 then ax=&hex3f00 bx=file_handle cx=bytesize int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) bytesread=ax endif return close_file: rem Close the file handle. If the file handle is less then 4, then rem this routine will simply exit. if file_handle>4 then ax=&hex3e00 bx=file_handle int86(&hex21,ax,bx,na,na,na,na,na,na,na) endif return Why muck around with byte for byte reads and writes when you can have the OS give you much bigger chunks at once right? It's assembler speed without actually doing it in asm. It's not slow. Which is why I said previously that you could save considerable time by doing a quick looksee at the file before you opted to scan the entire damn thing. The only limit to how many bytes that could be read/written in one go was the size of your allocated memory. Using straight up interrupt calls, just like you would have in pure assembly is going to be faster than whatever file i/o functions your HLL language of choice had available to you. Your completely bypassing the fluff. The drawback is that you are entirely on your own if you go this route. You could for example, screwup and ask to read more bytes than you allocated memory for. If you do this, you will overwrite some other region of memory with the extra bytes. which usually leads to a crash scenario. But, if you're creative and understand how your executable is built, you can take advantage of that and instead of a crash cause code execution instead - those extra bytes are executable machine code that you intended to load this way. That's a sneaky, but very old, method of getting around hueristics that might check to see what you're doing. They assume it's a standard interrupt call to read bytes, not considering that you're also using it to jmp to another location in memory with additional code it doesn't presently see because that special code isn't already in your main program. > Not saying that it doesn't make sense to check files on a better-safe- > than-sorry heuristic, just trying to figure out how you'd get to the > point of pulling that kind of trick in the first place... It's not really a trick though. It was just using a DOS interrupt as intended. As I wrote initially, file extensions really don't tell you what the file actually is. They never did. -- Liar, lawyer; mirror show me, what's the difference? Kangaroo done hung the guilty with the innocent Liar, lawyer; mirror for ya', what's the difference? Kangaroo be stoned. He's guilty as the government
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2025-12-03 22:36 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <6930bb75$7$26$882e4bbb@reader.netnews.com> |
| In reply to | #78254 |
On Dec 3, 2025 at 3:03:12 PM MST, "Gremlin" wrote <XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>: > John Ames <commodorejohn@gmail.com> news:20251203083900.00002c04@gmail.com > Wed, 03 Dec 2025 16:39:00 GMT in comp.os.linux.advocacy, wrote: > >> On Tue, 2 Dec 2025 20:13:15 -0000 (UTC) >> Gremlin <nobody@haph.org> wrote: >> Huh, I'm trying to model what an exploit would look like here - who & >> what would be vulnerable to this? Obviously you *can* create a disk >> file with a non-EXE extension & whatever contents you want, but under >> what circumstances is another program gonna call the load-and-execute >> routine on any arbitrary filename (other than, as mentioned, app-menu >> utilities or command-shell alternatives?) Or if the game is to replace >> one of an application suite's own I-can't-believe-it's-not-EXEs with a >> Trojan, which developers bothered to mask their secondary EXEs under a >> different extension, and why...? > > I wasn't writing about trojans using this? A trojan obviously could, but, > that isn't what I was describing... > > I was writing about some installers doing it. Just not using a .bat file > to pass control but doing it themselves. They'd recombine pieces of the > executable (a chunk on each floppy for example) and then pass control to > the final resulting file which would be an .EXE, but not necessarily with > that file extension. > > I suppose one could think of it as a very simple way to keep 'nosey' > people out? If the program comes with an install.exe and some 1,2,3 etc > files that turn into a .DAT file; you probably won't give it a second look. > You assume that because it's a .DAT file that it cannot be directly > executed- that the install.exe is doing all the work. And it's using the > .DAT file for instructions/configuration/data, etc, not that the .DAT file > is the next stage of the install process itself. > > As for the trojan aspect you bring up, I did once use a .DLL file as a > marker so that the program wouldn't access your email client for the 2nd > time and email anyone again. The file wasn't really a .DLL though, but you > wouldn't have been the wiser if you didn't actually examine it. It had a > legitimate Windows name with proper date/time stamps that would trick you > into thinking the file was as old as the rest of the common .DLLs on your > machine - You wouldn't have known it was created that morning for example. > Using DOS interrupts... > > Here's a little code from the program I was writing about. It's primarily > written in an ancient DOS based language called ASIC. v5 specifically. > > rem ***Get/Set Date/Time stamps > > get_fdt: > if file_handle>4 then > AX=&HEX5700 > BX=FILE_HANDLE > INT86(&HEX21,AX,BX,CX,DX,NA,NA,NA,NA,NA) > NEWDATE=CX > NEWTIME=DX > endif > RETURN > > set_fdt: > if file_handle>4 then > AX=&HEX5701 > BX=FILE_HANDLE > CX=NEWDATE > DX=NEWTIME > INT86(&HEX21,AX,BX,CX,DX,NA,NA,NA,NA,NA) > endif > RETURN > > And these are the interrupts to get the current attribute and null it and > then put it back later... > > rem ***Attribute get/set interrupts > > get_attr: > AX = &HEX4300 > DX = VARPTR(Filename$) > CX = NewAttr > INT86(&HEX21,AX,NA,CX,DX,NA,NA,NA,NA,NA) > return > > set_attr: > AX = &HEX4301 > DX = VARPTR(Filename$) > CX = NewAttr > INT86(&HEX21,AX,NA,CX,DX,NA,NA,NA,NA,NA) > return > > You just set newattr=0 and make the call, tada; now it's a normal file > suitable for read/write. > > Save it beforehand with the get attr call, save the variable, call the set > routine again when you're finished phucking around with it. > > Which is what this subroutine did: > > pre_open: > rem *** routine when called with getem=0 will > rem obtain the current file attributes, retain this > rem and reset the attribute to null for read/write. > rem If called with getem=1 it will restore the attribute > rem to what it was previously. > if getem=0 then > gosub get_attr: > oldattr=newattr > newattr=0 > gosub set_attr: > else > newattr=oldattr > gosub set_attr: > endif > return > > ASICs built in file I/O routines left much to be desired speed wise, and > when you're moving 10k or more around, you want it done fast. You don't > have time to phuck around going byte by byte. Nah, you allocate some > memory and pull a chunk all at once with a single DOS interrupt call. > Super fucking quick. Plus once it's in memory, you can do whatever needs > to be done much faster than doing it with the file on disk. RAM is faster > after all. then set the file pointer, dump the ram content right back - > again super fucking quick. I was trying to explain this previously but it > somehow got lost in translation I suppose. > > You'll have to ignore the comments, the 'engine' is c/p from a particular > piece of self replicating code I wrote decades ago. > > rem open_file chart! > rem ax=&hex3d00 > rem read-only > rem ax=&hex3d01 > rem write only > rem ax=&hex3d02 > rem read/write > > open_file: > rem See chart for access mode used. > AX=&HEX3D02 > DX = VARPTR(Filename$) > INT86(&HEX21,AX,NA,na,DX,NA,NA,NA,NA,NA) > file_handle=ax > return > > write_file: > rem this routine will write selected bytes at whatever current position > rem from whatever buffer i choose into the file. > rem if the routine did not write all data ax will not equal cx upon > rem return from int call. > rem define dx register before calling this routine to point to the > rem memory address of the buffer area you want to write from. like so: > rem dx=varptr(buffer(0)) > rem cx is how many bytes to write :) > if file_handle>4 then > ax=&hex4000 > bx=file_handle > cx=bytesize > int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) > byteswritten=ax > endif > return > > read_file: > rem as the name implies, it reads bytes into a buffer. :-) > rem as with write_file, you need to predefine the dx register for the > rem buffer where you want the info stored. Like so: dx=varptr(buffer(0)) > rem if you don't, this routine will not work, or will overwrite some > rem other section of memory. And for virus coding, this is very bad! :) > rem cx register is how many bytes to read :) > if file_handle>4 then > ax=&hex3f00 > bx=file_handle > cx=bytesize > int86(&hex21,ax,bx,cx,dx,na,na,na,na,na) > bytesread=ax > endif > return > > close_file: > rem Close the file handle. If the file handle is less then 4, then > rem this routine will simply exit. > if file_handle>4 then > ax=&hex3e00 > bx=file_handle > int86(&hex21,ax,bx,na,na,na,na,na,na,na) > endif > return > > Why muck around with byte for byte reads and writes when you can have the > OS give you much bigger chunks at once right? It's assembler speed without > actually doing it in asm. It's not slow. Which is why I said previously > that you could save considerable time by doing a quick looksee at the file > before you opted to scan the entire damn thing. > > The only limit to how many bytes that could be read/written in one go was > the size of your allocated memory. Using straight up interrupt calls, just > like you would have in pure assembly is going to be faster than whatever > file i/o functions your HLL language of choice had available to you. Your > completely bypassing the fluff. The drawback is that you are entirely on > your own if you go this route. You could for example, screwup and ask to > read more bytes than you allocated memory for. If you do this, you will > overwrite some other region of memory with the extra bytes. which usually > leads to a crash scenario. But, if you're creative and understand how your > executable is built, you can take advantage of that and instead of a crash > cause code execution instead - those extra bytes are executable machine > code that you intended to load this way. That's a sneaky, but very old, > method of getting around hueristics that might check to see what you're > doing. They assume it's a standard interrupt call to read bytes, not > considering that you're also using it to jmp to another location in memory > with additional code it doesn't presently see because that special code > isn't already in your main program. > > > >> Not saying that it doesn't make sense to check files on a better-safe- >> than-sorry heuristic, just trying to figure out how you'd get to the >> point of pulling that kind of trick in the first place... > > It's not really a trick though. It was just using a DOS interrupt as > intended. As I wrote initially, file extensions really don't tell you what > the file actually is. They never did. Most of what you're describing is technically possible under DOS, but the way you're framing it doesn’t match how real software of the era operated. Yes, DOS will EXEC a file regardless of extension if the caller specifies it. No, DOS installers were not commonly stitching together disguised EXE chunks under .DAT files. That's an edge case at best. Your interrupt calls seem legit, but "reading past a buffer to trigger execution" is more movie-hacker than real-world practice; DOS viruses mostly used explicit jumps, not accidental overreads. Extensions mattered to the command shell even if EXEC didn't care. Saying "extensions never meant anything" is just flat wrong. So your technical notes are mostly fine, but the narrative around them is the usual Gremlin embellishment —- stretching niche behavior into something widespread or sophisticated. -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <nobody@haph.org> |
|---|---|
| Date | 2025-12-04 03:05 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <XnsB3AAE0B49172CHT1@cF04o3ON7k2lx05.lLC.9r5> |
| In reply to | #78255 |
Brock McNuggets <brock.mcnuggets@gmail.com> news:6930bb75$7$26$882e4bbb@reader.netnews.com Wed, 03 Dec 2025 22:36:37 GMT in comp.os.linux.advocacy, wrote: > On Dec 3, 2025 at 3:03:12 PM MST, "Gremlin" wrote > <XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>: > Most of what you're describing is technically possible under DOS, but > the way you're framing it doesn’t match how real software of the era > operated. All of what I described (buffer overrun specifically) works under DOS, os/2warp, Windows, Linux and MacOS. And it doesn't match software you personally are aware of is what you should have written, if your intention was to have an actual honest discussion concerning this. We both know that's not your intention with your reply though. You are an end user. I am a coder. There is a huge difference between the two. ChatGPT and the like can only help you get by to a point, Snit. It's not going to be able to let you completely fake a technical discussion concerning low level code with me though. Anymore so than it was useful helping you and David Brooks gain entry into that encrypted .zip file. > Yes, DOS will EXEC a file regardless of extension if the caller > specifies it. No, DOS installers were not commonly stitching together > disguised EXE chunks under .DAT files. That's an edge case at best. I was using the .DAT extension as an example. It's not an edge case, either. I'm familiar with several packages from back in the day that used that 'trick' (which is not a trick of any kind). Some authors didn't want you snooping around too much with their programs, and little 'tricks' like that kept end users like you far away. You probably aren't familiar with the internals of how zip2exe actually worked, or the difference between the registered copy of pkwarez exe compressor vs the unregistered one. It was a single byte that if toggled provided you the 'protection' of the registered version. Protection in the sense that pklite wouldn't decompress a file compressed with it if you were using the registered version, OR, if you understood how it actually worked and used the shareware version and changed a single byte yourself. The registered version also offered *slightly* better compression, depending entirely on how your executable was constructed. Depending on the language and compiler used, this could only be a few bytes though. Hardly worth paying for. And, it wasn't worth paying for it to disable the decompress option when changing a single byte worked just fine for that purpose. Here's the source code to one of my first cracks. One byte changed, tada, pklite won't decompress your file anymore using the -x parameter. a$=command$ a$=ltrim$(a$) a$=rtrim$(a$) print"PKEX: Prevents PKLITE from expanding .EXE files!" print" " open "r",1,a$ if error>0 then print"Usage: PKEX <Filename.ext>" beep else a=filepos(1,29) a$=chr$(17) print #1,a$ NONULL close 1 print"File cannot be expanded by PKLITE" end endif That's just simple ASIC code above. I'd typically write the crack in an HLL, but the actual work to make the damn thing was done via disassembly. Ie: reverse engineering. > Your interrupt calls seem legit, but "reading past a buffer to trigger > execution" is more movie-hacker than real-world practice; DOS viruses > mostly used explicit jumps, not accidental overreads. Those calls are all legit. You can cross reference any of them with Ralph Browns interrupt list. You really shouldn't rely on ChatGPT or any other AI to participate in this discussion. It's piss easy to fool them. Especially now that I know you're using AI to participate in the first place. I've left a great example of that in this reply. Just to drive the point home. byebye: ax=&hexfa02 dx=&hex5945 bx=rofl int86(&hex16,ax,bx,cx,dx,na,na,na,na,na) code &hexb8,&hex02,&hexfe,&hexbe,&hex41,&hex4e,&hexbf,&hex55,&hex4e,&hexcd,&hex2f return code should be on the same line as the &hex material. My client wordwraps at 78 characters and I can't be arsed to change it. <G> Chatgpt can only let you fake knowledge you don't actually have upto a point. Without the original label and my comments, ChatGPT has no idea what that code does. I also took the time to feed it to googles gemini. Geminis results are more useful from a technical breakdown, but, it doesn't know what's going on either. When I fed it the original source code without any snipping of my comments and using the original label, They were both mostly able to tell me what the code was doing. These AIs are not as reliable as you seem to think they are, bud. They both relied on my label and my comments - neither of them were able to properly identify what the code is doing without them. These AI things do not actually 'think' Snit. https://en.wikipedia.org/wiki/Buffer_overflow If you actually comprehended what I wrote, you would have known that I was describing a buffer overflow exploit. Since you didn't have a clue, because you don't comprehend what you read well at all (sorry bud, but this is well documented going back decades with you) that's why you relied on AI and shared what it told you. Which isn't correct, btw. :) Since you assumed I was discussing viruses specifically though, I do know of several viruses and worms from the late 80s and 90s that did use the technique. The Morris worm (which is a subset of a computer virus) was the earliest one I remember doing it. There were others, though. Just not as popular due to them either being proof of concept or having other issues which prevented their long term survival in the wild. There was nothing 'accidental' about those over reads. As I wrote previously, it was intentional and required you to be very familiar with the final executable structure of your program as it would be processed internally - not necessarily on disk. .COM files execute as is on disk in memory; what you see is what you get. .EXE files do not by default, but, if properly crafted, they can as well. It's *very easy* due to the nature of the files internals and executable layout to convert a .COM into an .EXE; it only requires a small header. I actually demonstrated that little 'trick' years ago to Pooh who claimed he was something he wasn't and like you, tried to talk out of turn. https://en.wikipedia.org/wiki/Buffer_overflow It would benefit you greatly to read the contents of that URL. Specifically for *comprehension* so that you don't expose the severe lack of actual knowledge and understanding you have on the subject of writing low level code. You really *don't know* what the fuck you're talking about on this subject, Snit. > Extensions mattered to the command shell even if EXEC didn't care. > Saying "extensions never meant anything" is just flat wrong. It's not flat out wrong in the context I was explaining it, Snit. Extensions are for end users like you who don't understand what's actually going on with the machine sitting in front of you. Specifically, how and why it does what it does. You should never rely on a files extension to determine what that file actually is. Not if you take security seriously, anyhow. AV gives people like you a very false sense of security. You think you're safe and all is well because such and such AV scanned the file and said it was 'ok' when it wasn't. As I've already shown, the extension is for the end user - it really doesn't matter to a coder/decent programmer. Neither of which you are. You cannot trust the extension. Which was the entire point of my sharing *one* of the interrupts used to execute code. Btw, viruses did more than just jmp around; poly/oglymorphs for example. That's a subject well beyond your understanding though, for certain. -- Liar, lawyer; mirror show me, what's the difference? Kangaroo done hung the guilty with the innocent Liar, lawyer; mirror for ya', what's the difference? Kangaroo be stoned. He's guilty as the government
[toc] | [prev] | [next] | [standalone]
| From | Brock McNuggets <brock.mcnuggets@gmail.com> |
|---|---|
| Date | 2025-12-04 14:24 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <6931999a$6$21$882e4bbb@reader.netnews.com> |
| In reply to | #78263 |
On Dec 3, 2025 at 8:05:22 PM MST, "Gremlin" wrote <XnsB3AAE0B49172CHT1@cF04o3ON7k2lx05.lLC.9r5>: > Brock McNuggets <brock.mcnuggets@gmail.com> > news:6930bb75$7$26$882e4bbb@reader.netnews.com Wed, 03 Dec 2025 22:36:37 > GMT in comp.os.linux.advocacy, wrote: > >> On Dec 3, 2025 at 3:03:12 PM MST, "Gremlin" wrote >> <XnsB3AAAD7A1C510HT1@cF04o3ON7k2lx05.lLC.9r5>: >> Most of what you're describing is technically possible under DOS, but >> the way you're framing it doesn’t match how real software of the era >> operated. > > All of what I described (buffer overrun specifically) works under DOS, > os/2warp, Windows, Linux and MacOS. Nobody said otherwise. Seriously, not one person ever did. Certainly not me. Please try to read for comprehension and not just attack. It would help you a lot. You do this often -- argue against bizarre straw men you create. And you do so out of your own hatred and personal issues. Try to do better! -- It's impossible for someone who is at war with themselves to be at peace with you.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-04 14:35 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <10gs688$bvup$2@dont-email.me> |
| In reply to | #78285 |
On 04/12/2025 14:24, Brock McNuggets wrote: > You do this often -- argue against bizarre straw men you create. And you do so > out of your own hatred and personal issues. Try to do better! Clearly a Marxist. -- Civilization exists by geological consent, subject to change without notice. – Will Durant
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-12-04 08:21 -0800 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <20251204082129.000038cc@gmail.com> |
| In reply to | #78286 |
On Thu, 4 Dec 2025 14:35:52 +0000 The Natural Philosopher <tnp@invalid.invalid> wrote: > > You do this often -- argue against bizarre straw men you create. > > And you do so out of your own hatred and personal issues. Try to do > > better! > > Clearly a Marxist. The irony here is palpable.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-04 18:05 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <10gsigt$h31i$1@dont-email.me> |
| In reply to | #78288 |
On 04/12/2025 16:21, John Ames wrote: > On Thu, 4 Dec 2025 14:35:52 +0000 > The Natural Philosopher <tnp@invalid.invalid> wrote: > >>> You do this often -- argue against bizarre straw men you create. >>> And you do so out of your own hatred and personal issues. Try to do >>> better! >> >> Clearly a Marxist. > > The irony here is palpable. > I'm no Marxist chum But the guy referred to here looks like one... -- "And if the blind lead the blind, both shall fall into the ditch". Gospel of St. Mathew 15:14
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-12-04 10:09 -0800 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <20251204100958.00006bf4@gmail.com> |
| In reply to | #78289 |
On Thu, 4 Dec 2025 18:05:17 +0000 The Natural Philosopher <tnp@invalid.invalid> wrote: > >>> You do this often -- argue against bizarre straw men you create. > >>> And you do so out of your own hatred and personal issues. Try to > >>> do better! > >> > >> Clearly a Marxist. > > > > The irony here is palpable. > > > I'm no Marxist chum No, but you *do* seem to be in need of a refresher on elementary set theory, even if we take your opinion on Marxist rhetorical tendencies as gospel.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-04 19:09 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <10gsm9a$k22r$1@dont-email.me> |
| In reply to | #78290 |
On 04/12/2025 18:09, John Ames wrote: > On Thu, 4 Dec 2025 18:05:17 +0000 > The Natural Philosopher <tnp@invalid.invalid> wrote: > >>>>> You do this often -- argue against bizarre straw men you create. >>>>> And you do so out of your own hatred and personal issues. Try to >>>>> do better! >>>> >>>> Clearly a Marxist. >>> >>> The irony here is palpable. >>> >> I'm no Marxist chum > > No, but you *do* seem to be in need of a refresher on elementary set > theory, even if we take your opinion on Marxist rhetorical tendencies > as gospel. > I am afraid that one whooshed right over my head. -- New Socialism consists essentially in being seen to have your heart in the right place whilst your head is in the clouds and your hand is in someone else's pocket.
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2025-12-04 11:11 -0800 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <20251204111152.00006d1c@gmail.com> |
| In reply to | #78294 |
On Thu, 4 Dec 2025 19:09:30 +0000 The Natural Philosopher <tnp@invalid.invalid> wrote: > >>>>> You do this often -- argue against bizarre straw men you create. > >>>>> And you do so out of your own hatred and personal issues. Try to > >>>>> do better! > >>>> > >>>> Clearly a Marxist. > >>> > >>> The irony here is palpable. > >>> > >> I'm no Marxist chum > > > > No, but you *do* seem to be in need of a refresher on elementary set > > theory, even if we take your opinion on Marxist rhetorical > > tendencies as gospel. > > I am afraid that one whooshed right over my head. Even if we take "members of group A exhibit property B" as a given, that does not in itself mean that all entities exhibiting property B are members of group A.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-04 19:55 +0000 |
| Subject | Re: What Thinkest Thou Of LO Donate Banner? |
| Message-ID | <10gsovs$k22r$7@dont-email.me> |
| In reply to | #78295 |
On 04/12/2025 19:11, John Ames wrote: > On Thu, 4 Dec 2025 19:09:30 +0000 > The Natural Philosopher <tnp@invalid.invalid> wrote: > >>>>>>> You do this often -- argue against bizarre straw men you create. >>>>>>> And you do so out of your own hatred and personal issues. Try to >>>>>>> do better! >>>>>> >>>>>> Clearly a Marxist. >>>>> >>>>> The irony here is palpable. >>>>> >>>> I'm no Marxist chum >>> >>> No, but you *do* seem to be in need of a refresher on elementary set >>> theory, even if we take your opinion on Marxist rhetorical >>> tendencies as gospel. >> >> I am afraid that one whooshed right over my head. > > Even if we take "members of group A exhibit property B" as a given, > that does not in itself mean that all entities exhibiting property B > are members of group A. > In general no, in this case, almost certainly. Almost by definition -- “The urge to save humanity is almost always only a false face for the urge to rule it.” – H. L. Mencken
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web