Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #45602 > unrolled thread
| Started by | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| First post | 2024-08-18 13:46 +0000 |
| Last post | 2024-08-27 07:13 +0200 |
| Articles | 20 on this page of 850 — 36 participants |
Back to article view | Back to de.alt.folklore.computer
Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-18 13:46 +0000
Re: Epische Computer-Fails Marco Moock <mm+solani@dorfdsl.de> - 2024-08-18 16:25 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-18 14:46 +0000
Re: Epische Computer-Fails Marco Moock <mm+solani@dorfdsl.de> - 2024-08-18 17:09 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-08-18 19:43 +0200
Re: Epische Computer-Fails Marco Moock <mm+solani@dorfdsl.de> - 2024-08-18 20:52 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-18 21:52 +0200
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-08-19 10:51 +0200
Re: Epische Computer-Fails Marco Moock <mm+solani@dorfdsl.de> - 2024-08-19 15:40 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-19 18:01 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-08-19 09:36 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-02 17:47 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-02 22:15 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-07 15:08 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-07 18:57 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-07 20:58 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-08 13:09 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 20:37 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-08 20:57 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 22:44 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 00:22 +0200
Re: Epische Computer-Fails Martin Τrautmann <t-usenet@gmx.net> - 2024-09-10 18:26 +0200
Re: Epische Computer-Fails michaelnoeusenet@mac.com (Michael Noe) - 2024-09-10 18:43 +0200
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-09-08 10:13 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 10:59 +0200
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-09-08 12:04 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-08 12:16 +0200
Re: Epische Computer-Fails Clemens Schüller <cs.usenet@mailbox.org> - 2024-09-08 12:36 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 09:32 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 11:46 +0200
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-09-09 14:42 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 15:43 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 20:55 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 09:54 +0200
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-09-09 14:46 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 15:44 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-10 16:42 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-08 09:34 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-08 13:00 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 21:07 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-08 21:53 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 22:47 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 00:49 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 11:52 +0200
Re: Epische Computer-Fails Martin Τrautmann <t-usenet@gmx.net> - 2024-09-10 18:48 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-14 17:05 +0200
Re: Epische Computer-Fails Martin Τrautmann <t-usenet@gmx.net> - 2024-09-24 23:23 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 06:41 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 08:56 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 09:14 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 14:02 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 14:34 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 14:47 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-09-09 08:13 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 09:12 +0200
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-09-09 14:58 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-09-09 16:16 +0200
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-09-10 16:09 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-10 17:53 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-09 19:11 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 23:28 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-10 07:25 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-10 09:18 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-10 13:50 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-10 15:14 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-10 17:50 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 21:00 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-08 12:10 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 21:10 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-08 21:33 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 00:59 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 06:46 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 09:07 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 09:19 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 11:33 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 12:00 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 14:19 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 14:42 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 14:48 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-10 16:44 +0200
Re: Epische Computer-Fails "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-09-10 14:49 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-10 17:54 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-10 17:54 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 14:10 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 14:27 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 17:38 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 18:17 +0200
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-09-10 06:39 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 11:31 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 11:57 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 14:22 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 11:26 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 12:03 +0200
Re: Epische Computer-Fails Martin Τrautmann <t-usenet@gmx.net> - 2024-09-10 18:51 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 11:16 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-09-09 19:24 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 20:41 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-09-10 21:32 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-11 14:10 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-09-18 16:22 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-08 10:04 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 23:25 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 23:54 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-10 15:12 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-10 16:37 +0200
Re: Epische Computer-Fails "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-09-10 14:46 +0000
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-10 15:33 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-11 14:50 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-18 08:57 +0200
Re: Epische Computer-Fails Martin Τrautmann <t-usenet@gmx.net> - 2024-09-10 18:25 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-07 15:54 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-07 18:37 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-07 22:19 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-08 07:44 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 11:01 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-08 11:44 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-08 09:40 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-08 10:13 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-09 09:13 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 14:20 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-07 19:00 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-07 22:10 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-07 22:34 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-20 14:33 +0200
Re: Epische Computer-Fails Andreas Eder <a_eder_muc@web.de> - 2024-08-24 18:22 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-08-25 08:10 +0200
Re: Epische Computer-Fails Andreas Eder <a_eder_muc@web.de> - 2024-08-25 10:06 +0200
Re: Epische Computer-Fails Wolf gang P u f f e <remail@gmx.com> - 2024-08-25 08:33 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-25 08:37 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-18 16:42 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-18 16:55 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-18 20:17 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-18 21:36 +0200
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-08-19 10:46 +0200
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-19 09:04 +0000
Re: Epische Computer-Fails Joerg Walther <joerg.walther@magenta.de> - 2024-08-19 11:54 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-19 13:43 +0200
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-19 11:57 +0000
Re: Epische Computer-Fails ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-19 17:50 +0200
Re: Epische Computer-Fails ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-19 18:23 +0200
Re: Epische Computer-Fails ;-) Kay Martinen <usenet@martinen.de> - 2024-08-19 19:15 +0200
Re: Epische Computer-Fails ;-) Markus Elsken <markus.elsken@ewetel.net> - 2024-08-20 14:23 +0200
Re: Epische Computer-Fails ;-) Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-20 12:32 +0000
Re: Epische Computer-Fails ;-) Kay Martinen <usenet@martinen.de> - 2024-08-20 19:55 +0200
Re: Epische Computer-Fails ;-) Arno Welzel <usenet@arnowelzel.de> - 2024-08-19 22:15 +0200
Re: Epische Computer-Fails ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-20 00:21 +0200
Re: Epische Computer-Fails ;-) Başar Alabay <alabay@gmx.net> - 2024-08-20 20:32 +0000
Re: Epische Computer-Fails ;-) Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-20 06:15 +0000
Re: Epische Computer-Fails ;-) Kay Martinen <usenet@martinen.de> - 2024-08-19 18:24 +0200
Re: Epische Computer-Fails ;-) Kay Martinen <usenet@martinen.de> - 2024-08-19 19:10 +0200
Re: Epische Computer-Fails ;-) Thomas Koenig <tkoenig@netcologne.de> - 2024-08-19 18:31 +0000
Re: Epische Computer-Fails ;-) Arno Welzel <usenet@arnowelzel.de> - 2024-08-19 22:18 +0200
Re: Epische Computer-Fails ;-) Thomas Klix <wotokl@web.de> - 2024-08-19 22:51 +0200
Re: Epische Computer-Fails ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-20 07:00 +0200
Re: Epische Computer-Fails ;-) Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-20 06:17 +0000
Re: Epische Computer-Fails ;-) Markus Elsken <markus.elsken@ewetel.net> - 2024-08-20 14:24 +0200
Re: Epische Computer-Fails ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-20 17:17 +0200
Re: Epische Computer-Fails ;-) Thomas Koenig <tkoenig@netcologne.de> - 2024-08-20 17:32 +0000
Re: Epische Computer-Fails ;-) Joerg Walther <joerg.walther@magenta.de> - 2024-08-21 08:54 +0200
Re: Epische Computer-Fails ;-) Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-21 07:25 +0000
Re: Epische Computer-Fails ;-) Kay Martinen <usenet@martinen.de> - 2024-08-21 13:41 +0200
Re: Epische Computer-Fails ;-) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-21 14:38 +0200
Re: Epische Computer-Fails ;-) Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-21 13:09 +0000
Re: Epische Computer-Fails ;-) Kay Martinen <usenet@martinen.de> - 2024-08-20 19:57 +0200
Re: Epische Computer-Fails ;-) Arno Welzel <usenet@arnowelzel.de> - 2024-08-21 17:54 +0200
Re: Epische Computer-Fails ;-) Kay Martinen <usenet@martinen.de> - 2024-08-21 18:13 +0200
Re: Epische Computer-Fails ;-) Markus Elsken <markus.elsken@ewetel.net> - 2024-08-21 20:09 +0200
Re: Epische Computer-Fails ;-) Arno Welzel <usenet@arnowelzel.de> - 2024-08-24 12:11 +0200
Re: Epische Computer-Fails ;-) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-24 15:54 +0200
Re: Epische Computer-Fails ;-) "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-08-20 07:22 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-19 22:17 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-20 14:22 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-20 19:58 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-20 23:21 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-21 19:41 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-08-19 12:25 +0000
Re: Epische Computer-Fails Marco Moock <mm+solani@dorfdsl.de> - 2024-08-19 15:38 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-08-19 14:08 +0000
Re: Epische Computer-Fails Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-08-19 16:21 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-20 14:28 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-20 20:07 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-20 23:26 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-08-20 15:14 +0000
Re: Epische Computer-Fails Marco Moock <mm+solani@dorfdsl.de> - 2024-08-18 17:02 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-18 19:34 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-18 20:18 +0200
Re: Epische Computer-Fails Andreas Bockelmann <xotzil@gmx.de> - 2024-08-19 11:56 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-19 13:57 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-23 14:02 +0000
Basiseinheit mit 8 Bit (was: Epische Computer-Fails) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2024-08-23 16:38 +0200
Re: Basiseinheit mit 8 Bit Thomas Koenig <tkoenig@netcologne.de> - 2024-08-23 19:23 +0000
Re: Epische Computer-Fails Marco Moock <mm+solani@dorfdsl.de> - 2024-08-23 16:48 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-08-23 18:34 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-24 01:39 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-24 07:39 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-24 14:37 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-24 14:22 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-24 19:54 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 12:43 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-08-31 18:29 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-08-25 10:07 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-25 13:31 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-08-26 18:52 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-26 19:06 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-26 20:07 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-27 00:17 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-08-27 13:44 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-08-27 18:36 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 12:54 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 12:49 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-31 14:57 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-31 14:27 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 18:23 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 14:15 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-01 17:01 +0200
Programm[ierer] (was: Epische Computer-Fails) Kay Martinen <usenet@martinen.de> - 2024-09-01 22:51 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 11:36 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-11 12:54 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-11 14:05 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-11 17:51 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-11 18:38 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-11 21:14 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-12 09:35 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-12 21:48 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-13 06:07 +0000
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-15 23:09 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-16 07:59 +0000
Re: Epische Computer-Fails Michael Kraemer <m.kraemer@gsi.de> - 2024-09-16 18:24 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-16 19:47 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-16 21:37 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-16 21:49 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-17 21:20 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-17 19:50 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-18 00:39 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-18 05:46 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-18 16:57 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-18 16:10 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-19 00:07 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-19 05:36 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-19 13:54 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-28 14:04 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-28 17:31 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-28 17:58 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-28 20:26 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-29 10:07 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-29 11:40 +0000
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-29 10:54 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-29 16:32 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-29 15:46 +0000
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-29 17:25 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-29 18:36 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-29 21:19 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-30 17:59 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-28 20:16 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-28 18:24 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-19 09:50 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-19 10:17 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-19 11:52 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-19 14:40 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-28 14:13 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-28 18:30 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-29 21:17 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-29 21:58 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-29 22:18 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-30 01:42 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-30 16:58 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-28 20:04 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-29 21:18 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-29 22:25 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-30 10:48 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-30 17:01 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-30 10:45 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-30 12:58 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-30 17:03 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-30 18:25 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-30 17:02 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-01 05:11 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-10-04 15:42 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-04 18:43 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-10-06 11:35 +0000
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-10-07 20:08 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-07 19:05 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-07 19:25 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-10-07 17:30 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-10-07 20:58 +0200
Re: Epische Computer-Fails Andreas Eder <a_eder_muc@web.de> - 2024-11-01 16:12 +0100
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-11-01 18:56 +0100
Re: Epische Computer-Fails Andreas Eder <a_eder_muc@web.de> - 2024-11-01 22:24 +0100
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-11-02 09:30 +0100
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-11-02 09:21 +0000
Re: Epische Computer-Fails Andreas Eder <a_eder_muc@web.de> - 2024-11-02 10:50 +0100
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-11-02 11:17 +0100
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-11-02 03:27 +0100
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-10-05 20:16 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-10-06 12:12 +0000
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-10-07 07:17 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-10-07 19:23 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-07 19:02 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-10-07 20:48 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-08 04:23 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-09 14:26 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-10-10 00:07 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-10 19:37 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-10-10 21:58 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-11 06:18 +0000
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-10-11 06:44 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-10-11 10:08 +0200
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-10-12 12:42 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-10-12 15:07 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-12 15:16 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-10-12 15:55 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-10-13 16:58 +0000
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-10-13 17:09 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-10-13 19:50 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-11 13:51 +0200
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-10-13 07:17 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-10-12 14:19 +0200
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-10-12 13:19 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-10-12 16:00 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-10-12 14:29 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-10-12 19:51 +0200
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-10-12 15:05 +0000
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-10-13 07:13 +0000
Re: Epische Computer-Fails Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-10-12 19:49 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-10-10 10:27 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-10-01 20:35 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-30 14:24 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-30 17:04 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-30 18:32 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-10-04 15:44 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-30 23:30 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-10-04 15:45 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-30 18:27 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-19 14:01 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-20 09:03 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-28 14:11 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-28 20:40 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-28 19:43 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-29 21:21 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-29 19:40 +0000
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-30 10:14 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-30 09:33 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-30 18:04 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-30 17:07 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-30 15:20 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-30 18:07 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-30 10:09 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-30 10:07 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-30 08:13 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-28 23:28 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-30 10:15 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-20 09:40 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-20 14:17 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-20 20:37 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-20 22:51 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-22 17:02 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-22 19:50 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-23 12:39 +0000
Re: Epische Computer-Fails mlelstv@serpens.de (Michael van Elst) - 2024-09-22 17:14 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-22 21:03 +0000
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-23 08:54 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-23 18:43 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-23 21:00 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-24 23:06 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-24 21:09 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-25 00:15 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-28 15:46 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-28 14:07 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-29 21:25 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-29 22:03 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-30 17:10 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-28 20:42 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-23 18:04 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-23 20:35 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-24 22:53 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-25 17:30 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-25 16:26 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-26 19:10 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-26 21:55 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-26 20:45 +0000
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-27 11:04 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-27 17:27 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-28 13:54 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-28 18:32 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-28 17:14 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-27 19:30 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-28 17:23 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-29 09:57 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-29 12:38 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-29 18:52 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-29 20:53 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-30 11:20 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-27 17:23 +0200
Re: Moderne Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-28 20:37 +0200
Re: Moderne Programmiersprachen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-30 10:56 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-27 15:24 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-27 19:24 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-28 20:44 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-20 17:38 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-20 23:24 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-23 09:16 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-23 10:17 +0000
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-23 18:18 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-23 20:17 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-24 22:57 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-28 15:16 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-24 19:40 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-25 13:49 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-25 17:33 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-25 18:35 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-25 20:11 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-25 21:22 +0200
Re: Prozedurale Sprachen (was: Epische Computer-Fails) "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-25 22:05 +0200
Re: Prozedurale Sprachen Christian Weisgerber <naddy@mips.inka.de> - 2024-09-26 14:16 +0000
Re: Prozedurale Sprachen Kay Martinen <usenet@martinen.de> - 2024-09-26 18:54 +0200
Re: Prozedurale Sprachen "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-26 21:49 +0200
Re: Prozedurale Sprachen Thomas Koenig <tkoenig@netcologne.de> - 2024-09-27 05:54 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-26 19:13 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-21 09:47 +0200
Re: Epische Computer-Fails mlelstv@serpens.de (Michael van Elst) - 2024-09-21 08:00 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-21 12:28 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-23 10:06 +0000
Re: Epische Computer-Fails mlelstv@serpens.de (Michael van Elst) - 2024-09-21 09:42 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-22 15:56 +0200
Re: Epische Computer-Fails mlelstv@serpens.de (Michael van Elst) - 2024-09-22 15:56 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-22 22:54 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-23 17:49 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-24 09:05 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-24 19:35 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-23 09:29 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-23 10:08 +0000
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-09-23 18:02 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-23 09:26 +0200
Re: Undefiniertes Verhalten Christian Corti <use@reply.to> - 2024-09-23 18:20 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-23 09:23 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-23 09:22 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-28 15:40 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-20 09:26 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-20 10:55 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-18 15:06 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-18 16:12 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-19 00:25 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-18 14:28 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-17 22:31 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-18 14:19 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-18 05:41 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-16 20:13 +0000
Re: Epische Computer-Fails Michael Kraemer <m.kraemer@gsi.de> - 2024-09-18 09:29 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-13 12:41 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-13 14:22 +0200
Re: Epische Computer-Fails Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-09-12 16:03 +0200
Re: Epische Computer-Fails Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-09-12 17:49 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-12 19:24 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-12 09:35 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-12 11:55 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-12 13:05 +0200
Re: Epische Computer-Fails "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-09-12 12:25 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-12 16:52 +0200
Re: Epische Computer-Fails mlelstv@serpens.de (Michael van Elst) - 2024-09-12 15:32 +0000
Re: Epische Computer-Fails mlelstv@serpens.de (Michael van Elst) - 2024-09-12 11:31 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-12 21:41 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-13 06:49 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-13 08:43 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-14 17:02 +0200
Re: Epische Computer-Fails mlelstv@serpens.de (Michael van Elst) - 2024-09-14 17:18 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-14 21:42 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-16 12:30 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-16 13:39 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-16 15:31 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-11 19:48 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-18 08:59 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-18 13:18 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-18 13:47 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-09-18 15:03 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-18 16:40 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-11 13:36 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-11 17:53 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-11 21:02 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-12 09:41 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-11 19:52 +0000
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-11 21:52 +0000
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-13 18:46 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-14 11:37 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-14 13:24 +0000
Re: Epische Computer-Fails michaelnoeusenet@mac.com (Michael Noe) - 2024-09-14 16:19 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-14 21:39 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-15 23:50 +0000
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-16 20:09 +0000
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-16 21:43 +0000
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-16 22:35 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-14 17:09 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-14 22:03 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-14 20:20 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-14 23:22 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-15 00:41 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-15 12:39 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-16 00:33 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-16 16:17 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-16 19:51 +0000
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-16 00:10 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-17 05:25 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-17 14:19 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-17 14:54 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-17 17:18 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-09-17 20:05 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-18 05:26 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-18 13:51 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-17 17:30 +0000
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-17 20:21 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-18 05:32 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-18 13:28 +0000
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-16 19:53 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-17 10:23 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-15 00:26 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-15 12:43 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-26 09:40 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 12:55 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 09:56 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 11:38 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-24 20:00 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-24 23:50 +0200
Re: Epische Computer-Fails Michael Bäuerle <michael.baeuerle@gmx.net> - 2024-08-25 10:58 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-25 14:54 +0200
Re: Epische Computer-Fails Michael Bäuerle <michael.baeuerle@gmx.net> - 2024-08-25 18:02 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-25 16:11 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-25 16:16 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-25 21:24 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-25 20:50 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-26 23:06 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-27 00:45 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-27 15:35 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-27 19:00 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-27 19:41 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-28 13:15 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-28 17:24 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-28 21:51 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-29 06:42 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-28 15:20 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-28 17:32 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-28 20:17 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-28 22:00 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-28 21:53 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-28 19:55 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-29 23:56 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 18:34 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-08-29 00:25 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-29 13:41 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-08-29 14:29 +0200
Re: Epische Computer-Fails Ulf_Kutzner <Ulf.Kutzner@web.de> - 2024-08-29 12:53 +0000
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-08-29 20:50 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-29 23:59 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-08-30 00:30 +0200
Re: Epische Computer-Fails Guido Grohmann <guido.grohmann@gmx.de> - 2024-08-29 20:31 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 18:25 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-31 19:02 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-01 13:56 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 15:54 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 11:40 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-28 15:11 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-28 18:30 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-28 22:10 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-29 13:53 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-30 00:02 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-30 08:16 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-30 14:34 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 18:56 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 18:50 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 00:32 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-01 13:57 +0200
Re: Epische Computer-Fails mlelstv@serpens.de (Michael van Elst) - 2024-09-01 12:18 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 16:35 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 23:05 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-08-28 22:07 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-29 05:47 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-29 14:10 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-29 18:15 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-29 19:54 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-30 00:10 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 18:49 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-31 19:04 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-01 13:57 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-08-31 18:55 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 00:34 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-01 07:53 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-01 14:03 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-28 20:53 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-29 12:00 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-30 00:15 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-30 06:41 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-30 14:46 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-30 13:34 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-08-30 17:12 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-30 23:31 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-30 19:53 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-30 23:38 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-31 08:41 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-31 12:09 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-31 13:11 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-31 15:46 +0200
Re: Epische Computer-Fails Andreas Eder <a_eder_muc@web.de> - 2024-08-31 17:26 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-31 19:23 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 13:53 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 00:52 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-01 08:05 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 11:50 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 10:35 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-09-02 13:47 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-02 13:38 +0000
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-09-02 16:17 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-02 14:55 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 13:53 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 18:01 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 18:28 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 23:35 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 16:41 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-09-01 17:36 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 18:00 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 18:10 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 18:45 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 19:33 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 22:33 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 23:17 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 23:37 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-02 00:13 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 23:28 +0200
Re: Epische Computer-Fails Clemens Schüller <cs.usenet@mailbox.org> - 2024-09-01 23:46 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 13:49 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-02 15:00 +0200
Re: Epische Computer-Fails dont.spam.usenet@googlemail.com (Hauke Fath) - 2024-09-09 23:39 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-10 00:13 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-10 15:21 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-10 17:52 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-11 14:55 +0200
Re: Epische Computer-Fails Christian Corti <use@reply.to> - 2024-09-11 18:42 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-11 21:20 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-12 14:01 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-10 16:59 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-10 15:18 +0200
Re: Epische Computer-Fails Clemens Schüller <cs.usenet@mailbox.org> - 2024-09-03 21:00 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 11:09 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-02 15:37 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 20:02 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-03 04:46 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-03 13:48 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-03 14:30 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-03 14:39 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-03 15:24 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 14:27 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-03 20:32 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-03 23:58 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-04 06:38 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-04 17:09 +0000
Re: Epische Computer-Fails Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-09-04 22:19 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-04 21:09 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-05 09:55 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-04 13:55 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-04 14:18 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-04 22:08 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-05 02:49 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-05 05:42 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-05 08:48 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-05 08:47 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-05 10:50 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-05 13:48 +0200
Re: Epische Computer-Fails Andreas Karrer <ak-4a@gmx.ch> - 2024-09-05 10:14 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-04 10:02 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-04 13:51 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-07 23:35 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 11:03 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-08 12:49 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-08 21:14 +0200
PR (was: Epische Computer-Fails) Kay Martinen <usenet@martinen.de> - 2024-09-09 01:37 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 14:23 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-03 07:23 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 14:22 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 14:31 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 14:46 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-09 14:51 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 14:20 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 21:50 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 22:08 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 23:33 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 23:55 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-09-02 09:16 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 13:57 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-09-02 15:43 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-02 15:45 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 20:10 +0200
Re: Epische Computer-Fails Michael Bäuerle <michael.baeuerle@gmx.net> - 2024-09-02 20:40 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-03 01:14 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-09-03 07:55 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-03 14:33 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-03 17:32 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-03 18:13 +0200
Re: Epische Computer-Fails Marc Haber <mh+usenetspam1118@zugschl.us> - 2024-09-04 10:57 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-03 14:45 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-03 15:26 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-03 19:41 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-03 22:03 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-04 06:54 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-03 16:55 +0200
Re2: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 20:34 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 23:19 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 10:39 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 13:57 +0200
Re: Epische Computer-Fails Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-09-09 14:34 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-09 14:48 +0200
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-09 19:18 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-09 21:44 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-09 23:39 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-10 00:03 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-10 17:07 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-10 20:08 +0200
Re: Epische Computer-Fails Başar Alabay <alabay@gmx.net> - 2024-09-11 05:19 +0000
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-10 09:27 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-14 16:57 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-10 17:05 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-10 17:56 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-10 21:16 +0000
Re: Epische Computer-Fails Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-09-11 07:44 +0000
Re: Epische Computer-Fails Andreas Karrer <ak-4a@gmx.ch> - 2024-09-11 10:17 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-11 14:00 +0200
Re: Epische Computer-Fails Bernd Laengerich <Bernd.Laengerich@web.de> - 2024-09-10 09:55 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 10:32 +0200
Re: Epische Computer-Fails Andreas Eder <a_eder_muc@web.de> - 2024-09-03 15:36 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 17:58 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 23:34 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 12:40 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 13:07 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-01 11:37 +0000
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-09-01 13:12 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 16:00 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 17:00 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 21:48 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 22:06 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 23:12 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 23:51 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 23:25 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 13:38 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-02 15:42 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 20:44 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-03 07:29 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-02 18:53 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-03 01:21 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-03 04:49 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-03 07:35 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-03 07:33 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-03 09:36 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-03 13:09 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 18:24 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 23:38 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 21:41 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 21:51 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 23:41 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 18:17 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-09-01 17:14 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-01 23:26 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-09-02 15:21 +0000
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 23:45 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 10:25 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 13:43 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-02 15:44 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 18:24 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-02 19:11 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-09-02 20:47 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-03 04:52 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-03 07:31 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-03 10:21 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-02 15:07 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 00:47 +0200
Re: Epische Computer-Fails Michael Noe <michaelnoeusenet@mac.com> - 2024-09-01 03:46 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 10:22 +0200
Re: Epische Computer-Fails Markus Elsken <markus.elsken@ewetel.net> - 2024-09-01 00:42 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-28 18:16 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-28 20:57 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-29 05:49 +0200
Re: Epische Computer-Fails "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-08-29 07:12 +0000
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 19:01 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-29 11:38 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-29 18:20 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-29 16:30 +0000
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-29 19:36 +0000
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-30 06:50 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-30 13:09 +0000
Re: Epische Computer-Fails Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-08-28 20:26 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-27 19:20 +0200
Re: Epische Computer-Fails Christian Weisgerber <naddy@mips.inka.de> - 2024-08-25 19:17 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-26 09:57 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 19:04 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-31 19:15 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-31 19:48 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-31 20:11 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-09-01 14:06 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-09-01 15:56 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-09-02 11:15 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-09-01 14:02 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-24 12:26 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-24 20:19 +0000
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-24 21:25 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-25 00:14 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-25 07:01 +0000
Re: Epische Computer-Fails Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-08-25 09:48 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-25 12:01 +0000
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-25 14:47 +0200
Re: Epische Computer-Fails "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-08-25 14:42 +0200
Re: Epische Computer-Fails Thomas Koenig <tkoenig@netcologne.de> - 2024-08-25 13:53 +0000
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-26 10:21 +0200
Re: Epische Computer-Fails Wolf gang P u f f e <remail@gmx.com> - 2024-08-18 18:17 +0200
Re: Epische Computer-Fails Stefan Reuther <stefan.news@arcor.de> - 2024-08-19 07:44 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-19 11:00 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-08-22 19:04 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-22 19:13 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-08-24 21:44 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-22 19:12 +0200
Re: Epische Computer-Fails Guido Grohmann <guido.grohmann@gmx.de> - 2024-08-23 07:23 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-23 09:27 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-23 13:36 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-23 13:50 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-23 20:24 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-24 17:47 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-24 20:02 +0200
Re: Epische Computer-Fails Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2024-08-24 21:04 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-25 12:27 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-23 14:45 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-24 15:04 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-24 17:50 +0200
Re: Epische Computer-Fails Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2024-08-24 18:26 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-24 20:34 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-31 13:01 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-24 14:38 +0200
Re: Epische Computer-Fails Arno Welzel <usenet@arnowelzel.de> - 2024-08-24 14:41 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-08-24 21:46 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-25 12:41 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-08-26 19:57 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-08-26 20:26 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-27 01:00 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-08-27 15:04 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-27 18:55 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-27 19:14 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-28 04:29 +0200
Re: Epische Computer-Fails Thomas Klix <wotokl@web.de> - 2024-08-22 23:36 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-23 14:51 +0200
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-08-24 21:49 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-26 10:51 +0200
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-26 13:33 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-26 13:54 +0000
Re: Epische Computer-Fails Kay Martinen <usenet@martinen.de> - 2024-08-26 17:31 +0200
Re: Epische Computer-Fails Sebastian Barthel <naitsabes@freenet.de> - 2024-08-28 13:23 +0000
Re: Epische Computer-Fails "Chr. Maercker" <Zweistein@gmx-topmail.de> - 2024-08-26 19:52 +0200
Re: Epische Computer-Fails Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-08-27 07:13 +0200
Page 11 of 43 — ← Prev page 1 … 9 10 [11] 12 13 … 43 Next page →
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-08-25 10:07 +0200 |
| Message-ID | <vaevps.4rc.1@stefan.msgid.phost.de> |
| In reply to | #45701 |
Am 24.08.2024 um 14:22 schrieb Arno Welzel: > Christian Weisgerber, 2024-08-23 20:34: > [...] >> Ist eine Unterscheidung zwischen Daten und Programm theoretisch >> überhaupt möglich? Wenn Daten die Ausführung eines Programms >> beeinflussen, sind sie dann nicht auch Programm? Was sagt die >> theoretische Informatik dazu? > > Ich würde es so beschreiben: > > "Programm" ist alles, was zur Laufzeit nicht verändert werden muss, um > die Ausführung zu ermöglichen. Definiere "verändern". Zumindest bei on-topic'nen Systemen hat man auch mal selbstmodifizierenden Code benutzt. In meinem frühen Programmierleben war das: im Bresenham-Algorithmus für die Schritte entlang der Achsen die 'inc'- bzw. 'dec'-Instruktionen tauschen. Und bei aktuellen Systemen gibt es den dynamischen Lader, der beim Programmstart die Bibliotheksadressen patcht. Das ist einer der Gründe, warum auch heute noch Teile des Programmsegments modifizierbar sind. Die theoretische Informatik sagt also vermutlich: du hast eine von-Neumann-Maschine, die unterscheidet nicht zwischen Programm und Daten. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2024-08-25 13:31 +0200 |
| Message-ID | <jehrpk-7vc.ln1@news.martinen.de> |
| In reply to | #45730 |
Am 25.08.24 um 12:34 schrieb Stefan Ram: > Stefan Reuther <stefan.news@arcor.de> schrieb oder zitierte: >> Die theoretische Informatik sagt also vermutlich: du hast eine >> von-Neumann-Maschine, die unterscheidet nicht zwischen Programm und Daten. > > Begrifflich sind "Programm" und "Datum" Interpretationen, die wir > Zuständen auferlegen. Zum Beispiel? Zuständen wie: Ausführbar, Lesbar, schreibbar, Modifizierbar (Kombi aus Lesen, verarbeiten und Schreiben). > Man könnte durchaus einen Computer bauen, bei dem Programme und > Daten streng getrennt werden: Er hat zwei Speicher, der eine > enthält nur Anweisungen, die zwar ausgeführt, aber weder gelesen = Harvard-architektur!? Die CPU muß diese Anweisungen aber dennoch erst mal "Lesen" dieser Speicher muß also Lesbar sein - aber nicht beschreibbar. Wie ein ROM oder EPROM. Oder hast du einen externen Adressgenerator im Sinn der einer Speziellen CPU die Anweisungen anliefert - nur damit diese ihren Programmspeicher nicht lesen können dürfte? Das liefe auf Diskrete Logik hinaus, da kann man den Instruction Pointer dann auch so bauen wie man will - und auch festlegen ob und welche Befehle ihn manipulieren dürften (z.b. bei Sprüngen oder Schleifen). > noch geschrieben werden können. (Das Laden der Programme müßte > bei solch einem Computer dann vor Inbetriebnahme "von außen" > durch ein anderes System erfolgen.) Für einen EMUF, einen µC o.a. Fest programmierte Einheit üblich. Aber nicht für General Purpose Computer wie PCs u.a. > Etwas in diese Richtung geht ja Code in ROMs oder EPROMs, der > normalerweise vor Inbetriebnahme durch ein anderes System von > außen in den Speicher geschrieben wird. Wenn der Programmspeicher nicht verändert werden kann so kann der prinzipiell auch im normalen Adressbereich liegen. Man muß nur den Schreibzugriff verhindern. Z.b. Technisch (ROM) oder Elektrisch (SRAM mit Schreibschutz-schalter) Und beispielsweise bei SPS wie einer Simatic S-5 nimmst du ein Programmiertes Speichermodul, steckst es in die CPU und startest diese. Festprogramm läuft. ;) > Bei höheren Programmiersprachen kennt man auch solche, die - wie > Pascal - streng zwischen Programmen und Daten trennen. Bei anderen > wird durch etwas wie "eval" die Trennung aufgehoben. Herausragend > ist da LISP, wo die Aufhebung der Trennung in der Kultur WIMRE Ich hab früher bei PASCAL nie bemerkt das dieses eine Strenge Trennung zwischen Programm und Daten vollzöge. Aber das waren noch die Prozeduralen Varianten bevor mit TP6 u.a. die "Objektorientierung" einzug hielt. Und zu einem 'eval' oder Lisp hab ich da leider keine Praktischen Erfahrungen. Lisp ist "anders" und Forth noch mal mehr, das ist alles was ich erinnere. 'eval' i.s.v. 'evaluate' kann doch auch vieles bedeuten. Einen Strengen bezug auf Programm/Daten-trennung sehe ich darin noch nicht. Wie steht's mit BASIC 100 DATA 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 101 REM das sei nur ein Beispiel für eine numerische Reihe 103 READ DATA ...? in... was! Bye/ /Kay -- nix
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-08-26 18:52 +0200 |
| Message-ID | <vaiit2.6ts.1@stefan.msgid.phost.de> |
| In reply to | #45737 |
Am 25.08.2024 um 13:31 schrieb Kay Martinen:
> Am 25.08.24 um 12:34 schrieb Stefan Ram:
>> Man könnte durchaus einen Computer bauen, bei dem Programme und
>> Daten streng getrennt werden: Er hat zwei Speicher, der eine
>> enthält nur Anweisungen, die zwar ausgeführt, aber weder gelesen
>
> = Harvard-architektur!?
>
> Die CPU muß diese Anweisungen aber dennoch erst mal "Lesen" dieser
> Speicher muß also Lesbar sein - aber nicht beschreibbar. Wie ein ROM
> oder EPROM.
>
> Oder hast du einen externen Adressgenerator im Sinn der einer Speziellen
> CPU die Anweisungen anliefert - nur damit diese ihren Programmspeicher
> nicht lesen können dürfte?
Da geht's ja schon weiter: definiere Lesen :)
Harvard-Architektur macht man unter anderem, weil man dann zwei Busse
haben kann, einen für die Daten und einen für die Instruktionen. Dann
kann man Instruktionen und Daten gleichzeitig laden.
> Für einen EMUF, einen µC o.a. Fest programmierte Einheit üblich. Aber
> nicht für General Purpose Computer wie PCs u.a.
Allzweckcomputer haben gerne mal getrennte I- und D-Caches, genau dafür,
dass sie wie bei einer Harvard-Architektur beides gleichzeitig zugreifen
können.
Keine Ahnung, ob das bei aktuellen PC-Schlachtschiffen geht, aber bei
Embedded hatte ich da schon Prozessoren, wo man auch einfach sagen kann:
schalte die blöde Cache-Logik aus, ich adressiere die Caches jetzt
direkt. Spart Strom und führt zu vorhersehbarem Zeitverhalten. Die Daten
sind halt sofort da, ohne das Risiko eines Cache-Miss.
>> Etwas in diese Richtung geht ja Code in ROMs oder EPROMs, der
>> normalerweise vor Inbetriebnahme durch ein anderes System von
>> außen in den Speicher geschrieben wird.
>
> Wenn der Programmspeicher nicht verändert werden kann so kann der
> prinzipiell auch im normalen Adressbereich liegen. Man muß nur den
> Schreibzugriff verhindern. Z.b. Technisch (ROM) oder Elektrisch (SRAM
> mit Schreibschutz-schalter)
Es kann auch einfach die Adressierungslogik verhindern. Das ist ja heute
schon lange nicht mehr so, dass die Adresse, die intern im
Adressregister steht, einfach so auf den Bus gelegt wird und dann am
Speicherchip ankommt. Neben ein oder mehreren MMUs ist da ja auch noch
jede Menge Logik dazwischen, um Adressen an Funktionseinheiten zuzuordnen.
Der o.g. Chip hatte halt wenigstens drei solcher Adressierungseinheiten:
Daten (kommt an Daten- und Allzweck-Speicher ran), Code (kommt an
Instruktions- und Allzweck-Speicher ran) und DMA (kommt überall ran,
stellt sich aber immer hinten an). Demzufolge konnte man diese Speicher
also z.B. per Bootloader mit dem DMA befüllen.
>> Bei höheren Programmiersprachen kennt man auch solche, die - wie
>> Pascal - streng zwischen Programmen und Daten trennen. Bei anderen
>> wird durch etwas wie "eval" die Trennung aufgehoben. Herausragend
>> ist da LISP, wo die Aufhebung der Trennung in der Kultur WIMRE
>
> Ich hab früher bei PASCAL nie bemerkt das dieses eine Strenge Trennung
> zwischen Programm und Daten vollzöge.
In kaum einer Programmiersprache kann man "offiziell" den Programmcode
ändern. Klar, in Turbo Pascal (oder in C) kann ich einen Datenzeiger in
einen Funktionszeiger casten und andersrum, damit verlasse ich aber das,
was die Sprachspezifikation definiert.
OK, COBOL hat ein ALTER-Kommando.
https://www.ibm.com/docs/en/cobol-zos/6.3?topic=statements-alter-statement
> 'eval' i.s.v. 'evaluate' kann doch auch vieles bedeuten. Einen Strengen
> bezug auf Programm/Daten-trennung sehe ich darin noch nicht.
In Lisp ist eben
(print "hello")
entweder Daten (eine Liste mit zwei Elemente, wenn man es z.B. an die
Funktion length verfüttert), oder Code (wenn man es an die Funktion eval
verfüttert).
Der Unterschied zu anderen Programmiersprachen mit 'eval' ist, dass der
zusätzliche Parse-Schritt entfällt.
> Wie steht's mit BASIC
>
> 100 DATA 1, 2, 3, 4, 5, 6, 7, 8, 9, 0
> 101 REM das sei nur ein Beispiel für eine numerische Reihe
> 103 READ DATA ...? in... was!
Das ist nix anderes als
const int data[] = { 1,2,3,4,5,6,7,8,9,0 }
anderswo.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-08-26 19:06 +0000 |
| Message-ID | <vaijo2$2j08h$1@dont-email.me> |
| In reply to | #45757 |
Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 25.08.2024 um 13:31 schrieb Kay Martinen:
>> Wie steht's mit BASIC
>>
>> 100 DATA 1, 2, 3, 4, 5, 6, 7, 8, 9, 0
>> 101 REM das sei nur ein Beispiel für eine numerische Reihe
>> 103 READ DATA ...? in... was!
>
> Das ist nix anderes als
> const int data[] = { 1,2,3,4,5,6,7,8,9,0 }
> anderswo.
Nicht ganz. const int data[] ist eine Initialisierung, was im DATA
steht, muss eingelesen werden, mit dem READ - Befehl.
Und ausserdem gibt es noch RESTORE, zum nochmal Einlesen.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-08-26 20:07 +0000 |
| Message-ID | <vainal$2jfts$1@dont-email.me> |
| In reply to | #45757 |
Stefan Reuther <stefan.news@arcor.de> schrieb: > Allzweckcomputer haben gerne mal getrennte I- und D-Caches, genau dafür, > dass sie wie bei einer Harvard-Architektur beides gleichzeitig zugreifen > können. Wurde von der IBM 801 eingeführt, IIRC. > Keine Ahnung, ob das bei aktuellen PC-Schlachtschiffen geht, aber bei > Embedded hatte ich da schon Prozessoren, wo man auch einfach sagen kann: > schalte die blöde Cache-Logik aus, ich adressiere die Caches jetzt > direkt. Spart Strom und führt zu vorhersehbarem Zeitverhalten. Die Daten > sind halt sofort da, ohne das Risiko eines Cache-Miss. POWER hat icbt, "Instruction Cache Block Touch", das eine Cache Line in einen Cache pre-loaden kann. Im Allgemeinen sind aber Programme (und Programmier) relativ schlecht darin, Speichermuster vorherzusagen. Und ein Hauptspeicherzugriff dauert heute gerne mal 150 Zyklen, wenn nichts im Cache ist...
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2024-08-27 00:17 +0200 |
| Message-ID | <flbvpk-cqv.ln1@news.martinen.de> |
| In reply to | #45757 |
Am 26.08.24 um 18:52 schrieb Stefan Reuther:
> Am 25.08.2024 um 13:31 schrieb Kay Martinen:
>> Am 25.08.24 um 12:34 schrieb Stefan Ram:
>>> Man könnte durchaus einen Computer bauen, bei dem Programme und
>>> Daten streng getrennt werden: Er hat zwei Speicher, der eine
>>> enthält nur Anweisungen, die zwar ausgeführt, aber weder gelesen
>> Die CPU muß diese Anweisungen aber dennoch erst mal "Lesen" dieser
>> Speicher muß also Lesbar sein -
>> CPU die Anweisungen anliefert - nur damit diese ihren Programmspeicher
>> nicht lesen können dürfte?
>
> Da geht's ja schon weiter: definiere Lesen :)
Das war dein Statement oben, in dem du behauptest die Anweisungen im
Instruktionsspeicher sollten ausgeführt aber nicht gelesen werden - was
so überhaupt nicht möglich ist.
Und grundsätzlich ist; aus sicht irgend einer CPU; "Lesen" der
Kopiervorgang eines Datums (Bit, Nibble, Byte, Word Dword, QWord, ???)
von einer Externen Speicheradresse - üblicherweise in ein CPU-Internes
Register. Und das "Ein Datum lesen" ist die Reaktion auf die ausgabe
einer Speicheradresse verbunden mit Steuerleitungen (R/W, IO o.a.) um
ggf. spezialitäten ab zu bilden. Und es passiert bei allen CPUs die mir
bekannt sind eigentlich immer intern und automatisch, ebenso das dabei
der Adresszähler/Instruction-Pointer passend gesetzt wird um das nächste
Datum auf den Adressbus zu legen.
Kurz: Was du beschriebst ist ein WOM, ein Write-Only Memory - wenn
Schreiben möglich wäre, lesen aber nicht. Da du schreiben auch
ausschließen wolltest kann es nur eines sein: Ein STEIN! :-)
> Harvard-Architektur macht man unter anderem, weil man dann zwei Busse
> haben kann, einen für die Daten und einen für die Instruktionen. Dann
> kann man Instruktionen und Daten gleichzeitig laden.
Wenn die restlichen Externen Pfade ebenso redundant sind ja. Denn du
brauchst ja auch zwei Adressbusse damit Daten- und Programm-speicher ja
eben... adressiert werden können.
Bei allem was mehr als 8 Bit Breite hat wird der Maikäfer immer noch
mehr Beine bekommen. Aber x86 ist ja auch bei 1k Pincount und mehr - nur
eher weil man immer mehr in die CPU packte.
Mit einem DIl-40 Sockel kommt man dann aber nicht weit.
>> Für einen EMUF, einen µC o.a. Fest programmierte Einheit üblich. Aber
>> nicht für General Purpose Computer wie PCs u.a.
>
> Allzweckcomputer haben gerne mal getrennte I- und D-Caches, genau dafür,
> dass sie wie bei einer Harvard-Architektur beides gleichzeitig zugreifen
> können.
Das ist doch nicht viel mehr als ein weiterer interner Buffer der
lastausgleichend wirkt. Die müssen beide durch den EINEN Adress- und
Daten-bus erst mal befüllt werden damit es was bringt. Und wenn das
Programm entgegen der Logik darin und deren Optimierungen (typsische
Code o. Schleifengrößen?) wild mit Adressen hin und her hüpft (Basic:
GOTO-Wüste?) dann würde ich da sinkende Effizienz annehmen.
Und wieder liefert die Hardware eine Basis und die Software muß sich dem
anpassen damit es was bringen soll.
> Keine Ahnung, ob das bei aktuellen PC-Schlachtschiffen geht, aber bei
> Embedded hatte ich da schon Prozessoren, wo man auch einfach sagen kann:
> schalte die blöde Cache-Logik aus, ich adressiere die Caches jetzt
Ich bin da auch nicht sicher aber ich meine schon von Befehlspräfixen
gelesen zu haben die Cachesteuerung zu ließen. Und ansonsten gab's schon
früher BIOS-Optionen um Caches z.b. auf Write-thru oder Write-back zu
stellen.
> direkt. Spart Strom und führt zu vorhersehbarem Zeitverhalten. Die Daten
> sind halt sofort da, ohne das Risiko eines Cache-Miss.
Ja, Cache-Miss führt zum neuladen mindestens einer Cacheline oder? Das
was ich oben meinte, wenn dein I-Cache leer ist oder der Sprung weiter
geht was dann? Cache-miss, neu laden, read-penalty?
Vorhersagbare Zeitverhalten würde ich bei Realtime Anforderungen
erwarten und z.b. bei viel genutzten Kernel-routinen, IRQ/Int-handlern
o.ä. Das einzige was da rein grätschen darf sollte ein NMI sein oder?
>> Wenn der Programmspeicher nicht verändert werden kann so kann der
>> prinzipiell auch im normalen Adressbereich liegen. Man muß nur den
>> Schreibzugriff verhindern.
> Es kann auch einfach die Adressierungslogik verhindern. Das ist ja heute
Sicher, obiges waren nur beispiele.
> schon lange nicht mehr so, dass die Adresse, die intern im
> Adressregister steht, einfach so auf den Bus gelegt wird und dann am
> Speicherchip ankommt. Neben ein oder mehreren MMUs ist da ja auch noch
> jede Menge Logik dazwischen, um Adressen an Funktionseinheiten zuzuordnen.
Z.B. durch eine Steuerleitung die IO-Adressen ansprechen statt RAM/ROM?
Deswegen hatte ich im anderen Post von einer CPU im Protected Mode OHNE
Paging geschrieben. M.W. sollte dort die Externe Adresse gleich Internen
sein. Wobei du aber auch recht hast, denn intern ist es immer noch die
Kombination aus Segment und Offset bzw. Selektor(Inhalt) und Adresse.
Und Logik dazwischen gab es ja wohl auch vorher schon, seit PCs
Memory-remapping erlernt haben. Scheint mir wie ein C-128 auf Drogen.
Der konnte nur Bankswitching aber das auf viele verschiedene Arten.
Was beim PC z.b. CS und DS wäre das ist dort halt Bank 0 und vielleicht
Bank 1. Beide maximal 64kbyte groß (a 8 bit) = 128k(plus ROM's). Das war
doch beim 8086 anfangs auch die Maximale Segment-größe oder?
Ja, ich weiß das sind eigentlich Äpfel (Segment-register) mit Birnen
(Bank-register) verglichen.
>>> Bei höheren Programmiersprachen kennt man auch solche, die - wie
>>> Pascal - streng zwischen Programmen und Daten trennen. Bei anderen
>> Ich hab früher bei PASCAL nie bemerkt das dieses eine Strenge Trennung
>> zwischen Programm und Daten vollzöge.
>
> In kaum einer Programmiersprache kann man "offiziell" den Programmcode
> ändern.
Ach so, du meintest Selbstmodifizierenden Code damit. Da hab ich nicht
"geschaltet".
War FORTH nicht eine Sprache die da gewisse Möglichkeiten für bot?
>> Wie steht's mit BASIC
>>
>> 100 DATA 1, 2, 3, 4, 5, 6, 7, 8, 9, 0
>> 101 REM das sei nur ein Beispiel für eine numerische Reihe
>> 103 READ DATA ...? in... was!
>
> Das ist nix anderes als
> const int data[] = { 1,2,3,4,5,6,7,8,9,0 }
> anderswo.
Naja. Einerseits kannst du entweder die 'const' reihe ändern oder die
DATA-Zeile. Je nach Dialekt, Möglichkeiten (CBM-Basic 7.0) könnten die
DATA-Zeilen auch in einem extern nach zu ladendem Programm liegen. Sind
es dann Daten, Programm oder ???
Und dann *kannst* du die DATA Elemente natürlich in Variablen speichern,
in ein Array legen für berechnungen - aber ebenso gut auch mit READ &
POKE in einer Schleife in den Speicher schreiben und mit einem SYS
hinein springen. Schon sind aus Daten-elementen die im Programm
gespeichert waren ein weiteres Programm geworden (in diesem Fall eher
Assembler-codes). Es könnten allerdings auch datenmuster sein die
vielleicht ein weiteres Programm (aus DATA-Zeilen) braucht um seine
Arbeit zu machen...
Ein Harvard-style Computer mit einem BASIC müßte also das Programm
laden, und die Datenelemente müßten "natürlich" im Daten-RAM landen - wo
sie dann aber nicht gestartet werden könnten. Oder vielleicht kann er es
doch weil sein BASIC diese Auswahl böte - was dann wieder eine
Aufweichung der Trennung wäre.
Bye/
/Kay
--
nix
[toc] | [prev] | [next] | [standalone]
| From | Christian Weisgerber <naddy@mips.inka.de> |
|---|---|
| Date | 2024-08-27 13:44 +0000 |
| Message-ID | <slrnvcrm2i.110l.naddy@lorvorc.mips.inka.de> |
| In reply to | #45765 |
On 2024-08-26, Kay Martinen <usenet@martinen.de> wrote: > Das war dein Statement oben, in dem du behauptest die Anweisungen im > Instruktionsspeicher sollten ausgeführt aber nicht gelesen werden - was > so überhaupt nicht möglich ist. Man kann Instruction Fetch und Data Fetch architektonisch trennen, egal ob dahinter derselbe physische oder virtuelle Speicher steht, und tut das auch. Siehe z.B. getrennte I/D-Caches. Manche Betriebssysteme (iOS, OpenBSD) bilden den direkt ausführbaren Code auch ausschließlich als ausführbar, aber nicht als lesbar im Adressraum ab. Ob die MMU das direkt umsetzen kann, hängt von der Architektur ab, z.B. - AArch64: ja - x86-64: nein (aber man kann ggfs. mit PKU tricksen) -- Christian "naddy" Weisgerber naddy@mips.inka.de
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-08-27 18:36 +0200 |
| Message-ID | <val6an.408.1@stefan.msgid.phost.de> |
| In reply to | #45765 |
Am 27.08.2024 um 00:17 schrieb Kay Martinen:
> Am 26.08.24 um 18:52 schrieb Stefan Reuther:
>> Am 25.08.2024 um 13:31 schrieb Kay Martinen:
>>> Am 25.08.24 um 12:34 schrieb Stefan Ram:
>>>> Man könnte durchaus einen Computer bauen, bei dem Programme und
>>>> Daten streng getrennt werden: Er hat zwei Speicher, der eine
>>>> enthält nur Anweisungen, die zwar ausgeführt, aber weder gelesen
>
>>> Die CPU muß diese Anweisungen aber dennoch erst mal "Lesen" dieser
>>> Speicher muß also Lesbar sein -
>
>>> CPU die Anweisungen anliefert - nur damit diese ihren Programmspeicher
>>> nicht lesen können dürfte?
>>
>> Da geht's ja schon weiter: definiere Lesen :)
>
> Das war dein Statement oben,
War es nicht (Hamming-Abstand der From-Zeile prüfen).
>> Harvard-Architektur macht man unter anderem, weil man dann zwei Busse
>> haben kann, einen für die Daten und einen für die Instruktionen. Dann
>> kann man Instruktionen und Daten gleichzeitig laden.
>
> Wenn die restlichen Externen Pfade ebenso redundant sind ja. Denn du
> brauchst ja auch zwei Adressbusse damit Daten- und Programm-speicher ja
> eben... adressiert werden können.
>
> Bei allem was mehr als 8 Bit Breite hat wird der Maikäfer immer noch
> mehr Beine bekommen. Aber x86 ist ja auch bei 1k Pincount und mehr - nur
> eher weil man immer mehr in die CPU packte.
Die Busse müssen ja nicht direkt rausgeführt werden.
Der Instruction-Bus führt zum Instruction-Cache und anderen
Instruktionsspeichern, und von dort dann unter Umständen zum
SDRAM-Controller, der die entsprechenden externen Pins bedient.
Der Daten-Bus führt zum Daten-Cache, anderen Daten-Speichern,
Memory-Mapped-Registers, usw., und unter Umständen zum gleichen
SDRAM-Controller.
Die Bus-Landkarte eines modernen SoC füllt ein Plakat...
> Mit einem DIl-40 Sockel kommt man dann aber nicht weit.
...und der SoC *deutlich* mehr als einen DIL-40-Sockel.
>>> Für einen EMUF, einen µC o.a. Fest programmierte Einheit üblich. Aber
>>> nicht für General Purpose Computer wie PCs u.a.
>>
>> Allzweckcomputer haben gerne mal getrennte I- und D-Caches, genau dafür,
>> dass sie wie bei einer Harvard-Architektur beides gleichzeitig zugreifen
>> können.
>
> Das ist doch nicht viel mehr als ein weiterer interner Buffer der
> lastausgleichend wirkt. Die müssen beide durch den EINEN Adress- und
> Daten-bus erst mal befüllt werden damit es was bringt. Und wenn das
> Programm entgegen der Logik darin und deren Optimierungen (typsische
> Code o. Schleifengrößen?) wild mit Adressen hin und her hüpft (Basic:
> GOTO-Wüste?) dann würde ich da sinkende Effizienz annehmen.
Richtig. Und der Prozessor muss jederzeit damit rechnen, dass er ein
Datum nicht bekommt, dann die Instruktion schlafen legen, ggf.
Pagetabellen auflösen und Interrupts verarbeiten. Das ist alles
Komplexität. Deswegen ergibt es auch im 21. Jahrhundert noch Sinn, für
bestimmte Workloads den ganzen Quatsch abzuschalten und manuell zu
managen (oder gleich wegzulassen).
Ich hab z.B. in einem Bootloader ~10% Geschwindigkeit rausgeholt, indem
ich den L1-Speicher manuell bedient habe, und das nicht den
Cachecontroller hab machen lassen.
Mit der armen Sau, die auf einem 56000 mit 24-Bit-Wortbreite ein
CD-Laufwerk angesteuert hat, das die Daten in 16-Bit-Worten anbringt,
und das ganze in einem externen Speicher ablegt, der 8-bit-weise über
"schreibe Adressregister, schreibe Datenregister, setze 'write' Bit"
angesteuert wird, will ich dann aber doch nicht tauschen :)
> Vorhersagbare Zeitverhalten würde ich bei Realtime Anforderungen
> erwarten und z.b. bei viel genutzten Kernel-routinen, IRQ/Int-handlern
> o.ä. Das einzige was da rein grätschen darf sollte ein NMI sein oder?
Vorhersehbares Zeitverhalten ist auch für Dinge wie DSP-Code schön. Wenn
ich mir meine SIMD-Instruktionen erstmal zurechtgelegt habe, ist's doch
schön, wenn die die Funktionseinheiten auch auslasten, und ich genau
sagen kann: lieber Sounddesigner, 15 Effekte hab ich jetzt hier schon
drin, 3 passen noch, dann ist die CPU voll.
>> schon lange nicht mehr so, dass die Adresse, die intern im
>> Adressregister steht, einfach so auf den Bus gelegt wird und dann am
>> Speicherchip ankommt. Neben ein oder mehreren MMUs ist da ja auch noch
>> jede Menge Logik dazwischen, um Adressen an Funktionseinheiten
>> zuzuordnen.
>
> Z.B. durch eine Steuerleitung die IO-Adressen ansprechen statt RAM/ROM?
>
> Deswegen hatte ich im anderen Post von einer CPU im Protected Mode OHNE
> Paging geschrieben. M.W. sollte dort die Externe Adresse gleich Internen
> sein. Wobei du aber auch recht hast, denn intern ist es immer noch die
> Kombination aus Segment und Offset bzw. Selektor(Inhalt) und Adresse.
>
> Und Logik dazwischen gab es ja wohl auch vorher schon, seit PCs
> Memory-remapping erlernt haben. Scheint mir wie ein C-128 auf Drogen.
> Der konnte nur Bankswitching aber das auf viele verschiedene Arten.
Inzwischen gibt's da halt auch noch so Dinge wie eine IOMMU, so dass der
Prozessor ein anderes Speicherlayout und andere Zugriffsrechte sehen
kann als z.B. ein PCIe-Gerät.
>>> Wie steht's mit BASIC
>>>
>>> 100 DATA 1, 2, 3, 4, 5, 6, 7, 8, 9, 0
>>> 101 REM das sei nur ein Beispiel für eine numerische Reihe
>>> 103 READ DATA ...? in... was!
>>
>> Das ist nix anderes als
>> const int data[] = { 1,2,3,4,5,6,7,8,9,0 }
>> anderswo.
>
> Naja. Einerseits kannst du entweder die 'const' reihe ändern oder die
> DATA-Zeile. Je nach Dialekt, Möglichkeiten (CBM-Basic 7.0) könnten die
> DATA-Zeilen auch in einem extern nach zu ladendem Programm liegen. Sind
> es dann Daten, Programm oder ???
>
> Und dann *kannst* du die DATA Elemente natürlich in Variablen speichern,
> in ein Array legen für berechnungen - aber ebenso gut auch mit READ &
> POKE in einer Schleife in den Speicher schreiben und mit einem SYS
> hinein springen. Schon sind aus Daten-elementen die im Programm
> gespeichert waren ein weiteres Programm geworden (in diesem Fall eher
> Assembler-codes).
Da brauchst du aber kein READ dafür, POKE und SYS geht auch ohne. Aber
SYS ist am Ende in BASIC das, was in C der int-nach-Funktionspointer
Cast wäre. Da wird dir kein ISO-Sprachstandard eine Aussage darüber geben.
> Ein Harvard-style Computer mit einem BASIC müßte also das Programm
> laden, und die Datenelemente müßten "natürlich" im Daten-RAM landen - wo
> sie dann aber nicht gestartet werden könnten. Oder vielleicht kann er es
> doch weil sein BASIC diese Auswahl böte - was dann wieder eine
> Aufweichung der Trennung wäre.
Die Microsoft-BASIC-Compiler packen DATA-Anweisungen jedenfalls
irgendwohin, wo sie nicht versehentlich ausgeführt werden können. Ich
meine, tatsächlich ins Datensegment.
BASIC ist an der Stelle insofern recht verrückt, als dass man die Zahlen
auch mit 'READ A$' als Zeichenkette lesen kann und dann die textuelle
Repräsentation bekommt. Deswegen liegen die als Text abgespeichert...
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-08-31 12:54 +0200 |
| Message-ID | <ljgb25F5g85U7@mid.individual.net> |
| In reply to | #45737 |
Kay Martinen, 2024-08-25 13:31:
[...]
> 'eval' i.s.v. 'evaluate' kann doch auch vieles bedeuten. Einen Strengen
> bezug auf Programm/Daten-trennung sehe ich darin noch nicht.
Beispiel aus der PHP-Dokumentation:
<?php
$string = 'Bierglas';
$name = 'Binding-Lager';
$str = 'Das ist mein $string, voll mit $name.';
echo $str . "\n";
eval ("\$str = \"$str\";");
echo $str . "\n";
Ausgabe:
Das ist mein $string, voll mit $name.
Das ist mein Bierglas, voll mit Binding-Lager.
--
Arno Welzel
https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-08-31 12:49 +0200 |
| Message-ID | <ljgapbF5g85U6@mid.individual.net> |
| In reply to | #45730 |
Stefan Reuther, 2024-08-25 10:07: > Am 24.08.2024 um 14:22 schrieb Arno Welzel: >> Christian Weisgerber, 2024-08-23 20:34: >> [...] >>> Ist eine Unterscheidung zwischen Daten und Programm theoretisch >>> überhaupt möglich? Wenn Daten die Ausführung eines Programms >>> beeinflussen, sind sie dann nicht auch Programm? Was sagt die >>> theoretische Informatik dazu? >> >> Ich würde es so beschreiben: >> >> "Programm" ist alles, was zur Laufzeit nicht verändert werden muss, um >> die Ausführung zu ermöglichen. > > Definiere "verändern". Den Inhalt des Speichers, in dem der Programmcode liegt, verändern, während das Programm ausgeführt wird. > Zumindest bei on-topic'nen Systemen hat man auch mal > selbstmodifizierenden Code benutzt. In meinem frühen Programmierleben > war das: im Bresenham-Algorithmus für die Schritte entlang der Achsen > die 'inc'- bzw. 'dec'-Instruktionen tauschen. Ich spreche nicht davon, dass man keinen selbstmodifzierenden Code erstellen *kann*, sondern davon, dass man das nicht tun *muss*, um Programme zu erstellen. Jeder Algorithmus, der seinen eigenen Code modifzieren muss, kann auch anders gelöst werden, um auf Modifikationen des Codes zu verzichten. Das mag im Einzelfall weniger effizient sein, aber nicht unmöglich. > Und bei aktuellen Systemen gibt es den dynamischen Lader, der beim > Programmstart die Bibliotheksadressen patcht. Das ist einer der Gründe, > warum auch heute noch Teile des Programmsegments modifizierbar sind. Korrekt. Dennoch muss *danach*, wenn das Programm dann *läuft*, nichts mehr am Code geändert werden. > Die theoretische Informatik sagt also vermutlich: du hast eine > von-Neumann-Maschine, die unterscheidet nicht zwischen Programm und Daten. Korrekt. Es gibt aber auch die Harvard-Architektur, die das durchaus tut und auch immer noch eingesetzt wird - z.B. bei Microcontrollern wie ATmega. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2024-08-31 14:57 +0200 |
| Message-ID | <uogbqk-31d.ln1@news.martinen.de> |
| In reply to | #45837 |
Am 31.08.24 um 12:49 schrieb Arno Welzel: > Stefan Reuther, 2024-08-25 10:07: > >> Am 24.08.2024 um 14:22 schrieb Arno Welzel: >>> Christian Weisgerber, 2024-08-23 20:34: >>> [...] >>>> Ist eine Unterscheidung zwischen Daten und Programm theoretisch >>>> überhaupt möglich? Wenn Daten die Ausführung eines Programms >>>> beeinflussen, sind sie dann nicht auch Programm? Was sagt die >>>> theoretische Informatik dazu? >>> >>> Ich würde es so beschreiben: >>> >>> "Programm" ist alles, was zur Laufzeit nicht verändert werden muss, um >>> die Ausführung zu ermöglichen. >> >> Definiere "verändern". > > Den Inhalt des Speichers, in dem der Programmcode liegt, verändern, > während das Programm ausgeführt wird. Hierbei sollte man unterscheiden wer den verändern wollte, Das Programm das dort liegt und läuft (=Selbstmodifizierend) oder ein "fremdes" Programm (= zweiter "Thread" oder ein Angreifer) Ein Schreibschutz für den Programmspeicher verhindert die Ausführung der Ersten Variante (= Abbruch mit Fehler) und den Angriff. >> Zumindest bei on-topic'nen Systemen hat man auch mal >> selbstmodifizierenden Code benutzt. Hieße: Heute kein Problem mehr??? > Ich spreche nicht davon, dass man keinen selbstmodifzierenden Code > erstellen *kann*, sondern davon, dass man das nicht tun *muss*, um > Programme zu erstellen. >> Und bei aktuellen Systemen gibt es den dynamischen Lader, der beim >> Programmstart die Bibliotheksadressen patcht. Das ist einer der Gründe, >> warum auch heute noch Teile des Programmsegments modifizierbar sind. > > Korrekt. Dennoch muss *danach*, wenn das Programm dann *läuft*, nichts > mehr am Code geändert werden. Sehe ich auch so und logisch wäre den Code im Speicher dann als nur lesbar zu markieren. Ein Problem könnte ich mir vorstellen wenn das Ladeprogramm; das erhöhte Rechte braucht für den Job; nicht richtig arbeitet oder sonstwie mißbraucht werden könnte um auf dem Weg das geladene Programm nachträglich zu modifizieren. Z.b. indem es einen Beschreibbaren Segment-Selektor für den Speicherbereich nicht entfernt und dieser neben einem Nur-Lesbaren Selektor für den gleichen Bereich (des Programms) weiter existiert. Das Dürfte wohl die Stelle im System sein an der sich Schlangenöl einklinkt um zu ladende Programme auf Schädliches zu scannen. Wenn aber diese "Tool" dann auch wieder (wg. der "Sicherheit") etwas modifizieren könnte und einen (ausnutzbaren) Fehler hat... ... hat man damit die Angriffsoberfläche erfolgreich erhöht. ;) Bye/ /Kay -- nix
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2024-08-31 14:27 +0000 |
| Message-ID | <vav97m$11o88$1@dont-email.me> |
| In reply to | #45841 |
Kay Martinen <usenet@martinen.de> schrieb: > Am 31.08.24 um 12:49 schrieb Arno Welzel: >> Stefan Reuther, 2024-08-25 10:07: >> >>> Am 24.08.2024 um 14:22 schrieb Arno Welzel: >>>> Christian Weisgerber, 2024-08-23 20:34: >>>> [...] >>>>> Ist eine Unterscheidung zwischen Daten und Programm theoretisch >>>>> überhaupt möglich? Wenn Daten die Ausführung eines Programms >>>>> beeinflussen, sind sie dann nicht auch Programm? Was sagt die >>>>> theoretische Informatik dazu? >>>> >>>> Ich würde es so beschreiben: >>>> >>>> "Programm" ist alles, was zur Laufzeit nicht verändert werden muss, um >>>> die Ausführung zu ermöglichen. >>> >>> Definiere "verändern". >> >> Den Inhalt des Speichers, in dem der Programmcode liegt, verändern, >> während das Programm ausgeführt wird. > > Hierbei sollte man unterscheiden wer den verändern wollte, Das Programm > das dort liegt und läuft (=Selbstmodifizierend) oder ein "fremdes" > Programm (= zweiter "Thread" oder ein Angreifer) > > Ein Schreibschutz für den Programmspeicher verhindert die Ausführung der > Ersten Variante (= Abbruch mit Fehler) und den Angriff. > >>> Zumindest bei on-topic'nen Systemen hat man auch mal >>> selbstmodifizierenden Code benutzt. > Hieße: Heute kein Problem mehr??? > >> Ich spreche nicht davon, dass man keinen selbstmodifzierenden Code >> erstellen *kann*, sondern davon, dass man das nicht tun *muss*, um >> Programme zu erstellen. > >>> Und bei aktuellen Systemen gibt es den dynamischen Lader, der beim >>> Programmstart die Bibliotheksadressen patcht. Das ist einer der Gründe, >>> warum auch heute noch Teile des Programmsegments modifizierbar sind. >> >> Korrekt. Dennoch muss *danach*, wenn das Programm dann *läuft*, nichts >> mehr am Code geändert werden. > Sehe ich auch so und logisch wäre den Code im Speicher dann als nur > lesbar zu markieren. > > Ein Problem könnte ich mir vorstellen wenn das Ladeprogramm; das erhöhte > Rechte braucht für den Job; nicht richtig arbeitet oder sonstwie > mißbraucht werden könnte um auf dem Weg das geladene Programm > nachträglich zu modifizieren. Z.b. indem es einen Beschreibbaren > Segment-Selektor für den Speicherbereich nicht entfernt und dieser neben > einem Nur-Lesbaren Selektor für den gleichen Bereich (des Programms) > weiter existiert. > > Das Dürfte wohl die Stelle im System sein an der sich Schlangenöl > einklinkt um zu ladende Programme auf Schädliches zu scannen. > > Wenn aber diese "Tool" dann auch wieder (wg. der "Sicherheit") etwas > modifizieren könnte und einen (ausnutzbaren) Fehler hat... > > ... hat man damit die Angriffsoberfläche erfolgreich erhöht. ;) > > Bye/ > /Kay >
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-08-31 18:23 +0200 |
| Message-ID | <ljgub9F8k8mU1@mid.individual.net> |
| In reply to | #45841 |
Kay Martinen, 2024-08-31 14:57: > Am 31.08.24 um 12:49 schrieb Arno Welzel: >> Stefan Reuther, 2024-08-25 10:07: >> >>> Am 24.08.2024 um 14:22 schrieb Arno Welzel: >>>> Christian Weisgerber, 2024-08-23 20:34: >>>> [...] >>>>> Ist eine Unterscheidung zwischen Daten und Programm theoretisch >>>>> überhaupt möglich? Wenn Daten die Ausführung eines Programms >>>>> beeinflussen, sind sie dann nicht auch Programm? Was sagt die >>>>> theoretische Informatik dazu? >>>> >>>> Ich würde es so beschreiben: >>>> >>>> "Programm" ist alles, was zur Laufzeit nicht verändert werden muss, um >>>> die Ausführung zu ermöglichen. >>> >>> Definiere "verändern". >> >> Den Inhalt des Speichers, in dem der Programmcode liegt, verändern, >> während das Programm ausgeführt wird. > > Hierbei sollte man unterscheiden wer den verändern wollte, Das Programm > das dort liegt und läuft (=Selbstmodifizierend) oder ein "fremdes" > Programm (= zweiter "Thread" oder ein Angreifer) Gar nichts. Auch nicht selbstmodifizierend. Das Programm wird geladen und der Code bleibt danach exakt so, wie es ist. [...] >> Korrekt. Dennoch muss *danach*, wenn das Programm dann *läuft*, nichts >> mehr am Code geändert werden. > Sehe ich auch so und logisch wäre den Code im Speicher dann als nur > lesbar zu markieren. Das wäre sinnvoll. In der Praxis ist es eher umgekehrt: Speicherbereiche in denen kein ausführbarer Code liegen soll, werden als "nicht ausfühbar" gekennzeichnet (aka "NX"-Bit bei x86), so dass Angreifer eigenen Code, der erst zur Laufzeit in den Speicher geladen wird, nicht so einfach zur Ausführung bringen können. > Ein Problem könnte ich mir vorstellen wenn das Ladeprogramm; das erhöhte > Rechte braucht für den Job; nicht richtig arbeitet oder sonstwie > mißbraucht werden könnte um auf dem Weg das geladene Programm > nachträglich zu modifizieren. Z.b. indem es einen Beschreibbaren > Segment-Selektor für den Speicherbereich nicht entfernt und dieser neben > einem Nur-Lesbaren Selektor für den gleichen Bereich (des Programms) > weiter existiert. Ja, Probleme und fehlerhafte Implementierungen kann es immer geben. Siehe Meltdown und Heartbleet. Deswegen ist Rechtetrennung und Trennung von Programmcode und Daten dennoch nicht sinnfrei. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2024-09-01 14:15 +0200 |
| Message-ID | <slrnvd8mno.1e8q1.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #45846 |
On 2024-08-31 16:23, Arno Welzel <usenet@arnowelzel.de> wrote:
> Kay Martinen, 2024-08-31 14:57:
>> Sehe ich auch so und logisch wäre den Code im Speicher dann als nur
>> lesbar zu markieren.
>
> Das wäre sinnvoll.
>
> In der Praxis ist es eher umgekehrt: Speicherbereiche in denen kein
> ausführbarer Code liegen soll, werden als "nicht ausfühbar"
> gekennzeichnet (aka "NX"-Bit bei x86),
Beides.
Z.B.:
% cat /proc/$$/maps
630a04a8e000-630a04aa5000 r--p 00000000 08:03 2624587 /usr/bin/zsh
630a04aa5000-630a04b5e000 r-xp 00017000 08:03 2624587 /usr/bin/zsh
630a04b5e000-630a04b75000 r--p 000d0000 08:03 2624587 /usr/bin/zsh
630a04b75000-630a04b77000 r--p 000e6000 08:03 2624587 /usr/bin/zsh
630a04b77000-630a04b7d000 rw-p 000e8000 08:03 2624587 /usr/bin/zsh
630a04b7d000-630a04b91000 rw-p 00000000 00:00 0
630a053b5000-630a055b3000 rw-p 00000000 00:00 0 [heap]
...
7fffb6118000-7fffb615d000 rw-p 00000000 00:00 0 [stack]
7fffb6171000-7fffb6175000 r--p 00000000 00:00 0 [vvar]
7fffb6175000-7fffb6177000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
Wie man sieht, gibt es da Segmente, die lesbar, aber weder schreibbar
noch executable sind, solche die lesbar und executable, aber nicht
schreibar sind, solche, die les- und schreibbar, aber nicht executable
sind uns sogar eines, das nur executable, aber weder les- noch
schreibbar ist.
Bei modernen CPUs kann man wohl alle drei Permissions unabhängig
voneinander setzen. Historisch war die Möglichkeit, eine Page read-only
zu mappen, wohl die älteste (an die kann ich mich zumindest schon in den
80er-Jahren erinnern). W^X hingegen war dann irgendwann ein neues
Feature (Anfang der 2000er?). Wobei man gerade bei der x86-Architektur
dazusagen muss, dass da mit dem flachen 32-Bit-Adressraum etliches
Potential liegengelassen wurde. Die Segmente hätten ein paar
Security-Features mehr geboten. Aber die passten halt nicht gut in das
"all the world's a VAX" Paradigma.
hp
[toc] | [prev] | [next] | [standalone]
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Date | 2024-09-01 17:01 +0200 |
| Message-ID | <vb26l0.6fo.1@stefan.msgid.phost.de> |
| In reply to | #45837 |
Am 31.08.2024 um 12:49 schrieb Arno Welzel: > Stefan Reuther, 2024-08-25 10:07: >> Am 24.08.2024 um 14:22 schrieb Arno Welzel: >>> Christian Weisgerber, 2024-08-23 20:34: >>> "Programm" ist alles, was zur Laufzeit nicht verändert werden muss, um >>> die Ausführung zu ermöglichen. >> >> Definiere "verändern". > > Den Inhalt des Speichers, in dem der Programmcode liegt, verändern, > während das Programm ausgeführt wird. Definiere "Programm". Ein Prozess, der ein Binary ausführt? Aber was ist dann, wenn der irgendwelche Subprozesse ausführt, darf ich deren Binaries modifizieren, während sie nicht laufen? Und was ist mit dem dynamischen Loader? Was ist, wenn der Kernel mir irgendwelche Signal-Trampoline injiziert? >> Zumindest bei on-topic'nen Systemen hat man auch mal >> selbstmodifizierenden Code benutzt. In meinem frühen Programmierleben >> war das: im Bresenham-Algorithmus für die Schritte entlang der Achsen >> die 'inc'- bzw. 'dec'-Instruktionen tauschen. > > Ich spreche nicht davon, dass man keinen selbstmodifzierenden Code > erstellen *kann*, sondern davon, dass man das nicht tun *muss*, um > Programme zu erstellen. > > Jeder Algorithmus, der seinen eigenen Code modifzieren muss, kann auch > anders gelöst werden, um auf Modifikationen des Codes zu verzichten. Das > mag im Einzelfall weniger effizient sein, aber nicht unmöglich. ...nämlich im Zweifelsfall durch einen Emulator, der das ursprüngliche selbstmodifizierende Programm emuliert. >> Und bei aktuellen Systemen gibt es den dynamischen Lader, der beim >> Programmstart die Bibliotheksadressen patcht. Das ist einer der Gründe, >> warum auch heute noch Teile des Programmsegments modifizierbar sind. > > Korrekt. Dennoch muss *danach*, wenn das Programm dann *läuft*, nichts > mehr am Code geändert werden. Nur bei LD_BIND_NOW. Sonst müssen die PLTs bis zum Schluss modifizierbar bleiben. Am Ende will ich sagen: die Definition eines nicht veränderten Programms ist nicht einfach. Unveränderbarkeit ist gut, und aus Sicherheitsgründen sollten so viele Teile wie möglich unveränderbar sein. Nur lässt sich das nicht locker flockig an irgendwelchen Memory-Mappings festmachen. Selbst wenn der Basic-Interpreter statisch compiliert (=kein dynamischer Loader) und alles fein W^X gemapped ist, ist das Basic-Programm, das er ausführt, für ihn nur Daten. Stefan
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2024-09-01 22:51 +0200 |
| Subject | Programm[ierer] (was: Epische Computer-Fails) |
| Message-ID | <dt0fqk-pnj.ln1@news.martinen.de> |
| In reply to | #45890 |
Am 01.09.24 um 17:29 schrieb Stefan Ram: > Stefan Reuther <stefan.news@arcor.de> schrieb oder zitierte: >> Definiere "Programm". > > Ein /Programm/ ist das Artefakt einer Verfügung eines Programmierers > an einen Ausführer zur Durchführung eines Vorgangs. > Unterschrieben: Ihr OberZertifikatsChefInformatikProzessor ähh Professor. ;-) Uff! Das klingt echt Theoretisch, und für meinen Geschmack etwas zu sehr Abstrahiert. BTW "Programmierer" ist dann ein Artefaktausführungsvorbereitungsplaner. Mich erinnert obiges an https://youtu.be/BrcKzP4B6UE?feature=shared Aber, das soll keine Beschwerde sein da eingangs IMO gefragt würde was die "Theoretische Informatik" dazu sagen würde. :) An manchen Tagen vermißt man Anglizismen oder? Wettbewerb: Welche Umschreibenden Begriffskonglomerate mag es noch geben für "Programmierer"? Bye/ /Kay -- nix
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2024-09-09 11:36 +0200 |
| Message-ID | <lk7ttaFroqeU5@mid.individual.net> |
| In reply to | #45890 |
Stefan Reuther, 2024-09-01 17:01: > Am 31.08.2024 um 12:49 schrieb Arno Welzel: >> Stefan Reuther, 2024-08-25 10:07: >>> Am 24.08.2024 um 14:22 schrieb Arno Welzel: >>>> Christian Weisgerber, 2024-08-23 20:34: >>>> "Programm" ist alles, was zur Laufzeit nicht verändert werden muss, um >>>> die Ausführung zu ermöglichen. >>> >>> Definiere "verändern". >> >> Den Inhalt des Speichers, in dem der Programmcode liegt, verändern, >> während das Programm ausgeführt wird. > > Definiere "Programm". Maschinenbefehle für die CPU. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-09-11 12:54 +0200 |
| Message-ID | <lkdb77FmbkcU1@mid.individual.net> |
| In reply to | #46074 |
Am 09.09.24 um 11:36 schrieb Arno Welzel:
>> Definiere "Programm".
> Maschinenbefehle für die CPU.
Beispiel: print("hello world")
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2024-09-11 14:05 +0200 |
| Message-ID | <2ld8rk-3hr.ln1@news.martinen.de> |
| In reply to | #46165 |
Am 11.09.24 um 12:54 schrieb Hermann Riemann:
> Am 09.09.24 um 11:36 schrieb Arno Welzel:
>
>>> Definiere "Programm".
>
>> Maschinenbefehle für die CPU.
>
> Beispiel: print("hello world")
Nenne mir eine Echte (Nicht-Papier-) CPU die einen "Print" Befehl in
Maschinensprache mit bringt. Und damit die Daten "hello world" als
Argument auch direkt verwenden könnte.
Obiges ist wohl eher ein Basic-Token mit Argument das vom
Interpreter/Compiler in zig Maschinenbefehle übersetzt würde. Und von
denen wird keiner "PRINT" lauten.
"Programm" ist zutreffend. "CPU Maschinenbefehl" dann aber nicht.
Bye/
/Kay
--
nix
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2024-09-11 17:51 +0200 |
| Message-ID | <lkdsjdFotm4U1@mid.individual.net> |
| In reply to | #46167 |
Am 11.09.24 um 14:05 schrieb Kay Martinen:
> Am 11.09.24 um 12:54 schrieb Hermann Riemann:
>> Am 09.09.24 um 11:36 schrieb Arno Welzel:
>>
>>>> Definiere "Programm".
>>
>>> Maschinenbefehle für die CPU.
>>
>> Beispiel: print("hello world")
>
> Nenne mir eine Echte (Nicht-Papier-) CPU die einen "Print" Befehl in
> Maschinensprache mit bringt. Und damit die Daten "hello world" als
> Argument auch direkt verwenden könnte.
>
> Obiges ist wohl eher ein Basic-Token mit Argument das vom
> Interpreter/Compiler in zig Maschinenbefehle übersetzt würde. Und von
> denen wird keiner "PRINT" lauten.
Ganz so einfach ist es nicht.
Ich habe auf Z80 ein interrupt Befehl für print Register A missbraucht.
> "Programm" ist zutreffend. "CPU Maschinenbefehl" dann aber nicht.
Wobei da noch die Frage code oder microcode offen ist.
Manche CPUs sie interpreter für Maschinencode.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
Page 11 of 43 — ← Prev page 1 … 9 10 [11] 12 13 … 43 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web