Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #4691 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> |
|---|---|
| First post | 2011-05-29 12:48 +1200 |
| Last post | 2011-06-02 03:43 -0700 |
| Articles | 20 on this page of 213 — 21 participants |
Back to article view | Back to comp.lang.java.programmer
Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-29 12:48 +1200
Re: AndroidWhy Dalvik? Roedy Green <see_website@mindprod.com.invalid> - 2011-05-28 21:28 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-29 16:56 +1200
Re: Android—Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-05-28 23:17 -0700
Re: Android—Why Dalvik? Lew <noone@lewscanon.com> - 2011-05-29 09:32 -0400
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-29 09:55 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 12:45 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-29 19:49 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 16:21 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-29 22:37 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 19:12 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 01:03 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 22:13 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 03:58 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 23:20 +1200
Re: AndroidWhy Dalvik? Roedy Green <see_website@mindprod.com.invalid> - 2011-05-29 19:52 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 16:20 +1200
Re: Android—Why Dalvik? Lew <noone@lewscanon.com> - 2011-05-30 01:14 -0400
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-30 00:33 -0700
Re: Android?Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 19:54 +1200
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 03:26 -0700
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-30 11:24 -0700
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 13:09 -0700
Re: Android?Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-05-30 13:43 -0700
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 15:55 -0700
Re: Android?Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-05-30 16:32 -0700
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 18:10 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-31 13:56 +1200
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-31 11:10 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 07:13 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-31 12:43 -0700
Re: Android?Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 08:00 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-31 13:33 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 09:29 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-31 17:13 -0700
Re: Android?Why Dalvik? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-31 22:03 +0000
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-31 16:08 -0700
Re: Android—Why Dalvik? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-31 21:09 +0000
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 09:27 +1200
Re: Android—Why Dalvik? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-31 22:25 +0000
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-31 15:20 -0700
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-31 12:11 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 07:59 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-31 15:01 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 15:05 +1200
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-01 00:58 -0400
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-01 03:21 -0700
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 09:40 -0400
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-03 12:17 -0700
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 17:06 -0400
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-03 16:04 -0700
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-07 11:42 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-02 11:54 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-01 17:43 -0700
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-01 17:43 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-03 15:08 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-02 20:50 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-03 17:34 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-02 23:20 -0700
Re: Android?Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-03 18:43 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-03 08:27 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-04 16:02 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-03 22:24 -0700
Re: Android?Why Dalvik? Gene Wirchenko <genew@ocis.net> - 2011-06-06 13:29 -0700
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-06 14:15 -0700
Re: Android?Why Dalvik? Gene Wirchenko <genew@ocis.net> - 2011-06-07 13:59 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-08 12:55 +1200
Re: Android—Why Dalvik? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-08 06:18 -0300
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-08 07:06 -0700
Re: Android?Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 10:25 -0400
Re: Android?Why Dalvik? Gene Wirchenko <genew@ocis.net> - 2011-06-08 10:56 -0700
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-08 14:11 -0700
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-08 14:09 -0700
Re: Android?Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 09:46 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-04 16:08 +1200
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-04 02:40 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-05 15:46 +1200
Re: AndroidWhy Dalvik? Gene Wirchenko <genew@ocis.net> - 2011-06-06 13:26 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 10:23 +1200
Re: AndroidWhy Dalvik? Gene Wirchenko <genew@ocis.net> - 2011-06-07 13:55 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-08 12:55 +1200
Re: Android—Why Dalvik? "H.J. Sander Bruggink" <sander.bruggink@uni-due.de> - 2011-06-06 11:21 +0200
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 13:40 +1200
Re: Android—Why Dalvik? "H.J. Sander Bruggink" <sander.bruggink@uni-due.de> - 2011-06-07 10:16 +0200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-07 01:30 -0700
Re: AndroidWhy Dalvik? rossum <rossum48@coldmail.com> - 2011-06-02 10:35 +0100
Re: Android�Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-02 03:32 -0700
Re: Android�Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-02 11:07 -0400
Re: Android�Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-02 10:07 -0700
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 09:38 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-04 12:21 +1200
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-07 11:48 -0400
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 09:31 -0400
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-03 12:45 -0700
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 17:14 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-04 12:23 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-03 19:01 -0700
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-07 11:59 -0400
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-04 02:44 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-05 11:11 +1200
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 10:10 -0400
Re: Android—Why Dalvik? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-08 20:38 -0300
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-08 17:28 -0700
Re: Android—Why Dalvik? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-08 23:41 -0300
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-11 13:38 -0400
Re: Android—Why Dalvik? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-12 16:59 -0300
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-15 14:01 -0400
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-08 22:46 -0700
Re: Android---Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-11 13:39 -0400
Re: Android?Why Dalvik? David Lamb <dalamb@cs.queensu.ca> - 2011-06-03 22:38 -0400
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-03 22:12 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-31 13:54 +1200
Re: Android—Why Dalvik? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-31 14:25 +0000
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 08:02 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-31 14:26 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 11:33 +1200
Re: Android—Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-05-31 19:43 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-01 15:03 +1200
Re: Android—Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-05-31 20:15 -0700
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-01 01:04 -0400
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-01 03:30 -0700
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 10:05 -0400
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-03 11:16 -0400
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 17:36 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-04 12:14 +1200
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-04 02:47 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-05 15:40 +1200
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-07 12:09 -0400
Re: Android—Why Dalvik? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-09 07:55 -0300
Re: Swing versus Windows.Forms Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-12 17:11 -0300
Re: Android---Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-11 13:43 -0400
Re: Android---Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-11 14:57 -0700
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-03 13:05 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-04 12:13 +1200
Re: Android—Why Dalvik? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-03 21:52 -0300
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-04 02:52 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-05 15:45 +1200
Re: Android—Why Dalvik? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-05 01:04 -0300
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-06 18:52 +1200
Re: Android—Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-06-06 01:35 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-06 23:05 +1200
Re: Android—Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-06-06 06:32 -0700
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-06-06 11:19 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-07 10:21 +1200
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 10:30 -0400
Re: Android—Why Dalvik? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-06-07 06:53 -0300
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 10:37 -0400
Re: Android—Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-07 12:26 -0400
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-30 19:12 -0700
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 21:58 -0700
Re: Android?Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 17:42 -0400
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-03 18:48 -0700
Re: Android?Why Dalvik? Gene Wirchenko <genew@ocis.net> - 2011-06-06 13:28 -0700
Re: Android?Why Dalvik? Michael Wojcik <mwojcik@newsguy.com> - 2011-06-08 10:51 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-04 12:10 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-03 18:47 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-04 16:00 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-03 22:01 -0700
Re: Android—Why Dalvik? Abu Yahya <abu_yahya@invalid.com> - 2011-06-05 23:28 +0530
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-05 12:15 -0700
Re: Android—Why Dalvik? Abu Yahya <abu_yahya@invalid.com> - 2011-06-06 06:25 +0530
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-06 01:45 -0700
Re: Android—Why Dalvik? Abu Yahya <abu_yahya@invalid.com> - 2011-06-08 21:46 +0530
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-08 12:08 -0700
Re: AndroidWhy Dalvik? Gene Wirchenko <genew@ocis.net> - 2011-06-06 13:16 -0700
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-06 13:32 -0700
Re: Android—Why Dalvik? Tobias Blass <tobiasblass@gmx.net> - 2011-06-05 20:08 +0000
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-06-05 14:55 -0700
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-05 14:53 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-06 18:50 +1200
Re: Android—Why Dalvik? Abu Yahya <abu_yahya@invalid.com> - 2011-06-11 23:56 +0530
Re: AndroidWhy Dalvik? Gene Wirchenko <genew@ocis.net> - 2011-06-06 13:14 -0700
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-06 13:38 -0700
Re: Android—Why Dalvik? Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-07 13:34 +0000
Re: AndroidWhy Dalvik? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-06-07 13:56 +0000
Re: Android—Why Dalvik? Martin Gregorie <martin@address-in-sig.invalid> - 2011-06-07 16:47 +0000
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-31 13:53 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-30 19:14 -0700
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 22:26 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-31 18:45 +1200
Re: Android?Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-30 15:25 -0400
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 12:46 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-31 11:50 +1200
Re: Android—Why Dalvik? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-30 20:16 -0400
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-31 13:50 +1200
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-30 11:22 -0700
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-29 09:35 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 12:44 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-29 19:38 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 17:26 +1200
Re: Android—Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-05-30 00:04 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 19:11 +1200
Re: Android—Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-05-30 00:30 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 19:53 +1200
Re: Android—Why Dalvik? "Nasser M. Abbasi" <nma@12000.org> - 2011-05-30 01:28 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 22:12 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 02:35 -0700
Re: Android—Why Dalvik? "John B. Matthews" <nospam@nospam.invalid> - 2011-05-30 11:26 -0400
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 13:17 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-31 11:48 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 17:16 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-31 13:48 +1200
Re: AndroidWhy Dalvik? David Segall <david@address.invalid> - 2011-06-01 00:54 +1000
Re: Android?Why Dalvik? Steve Sobol <sjsobol@JustThe.net> - 2011-05-31 08:05 -0700
Re: Android?Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-31 11:41 -0700
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 01:57 -0700
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-30 22:30 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-05-30 13:23 -0700
Re: Android—Why Dalvik? bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-05-31 09:42 +0100
Re: Android—Why Dalvik? Michal Kleczek <kleku75@gmail.com> - 2011-06-02 09:17 +0200
Re: Android—Why Dalvik? Michal Kleczek <kleku75@gmail.com> - 2011-06-02 09:21 +0200
Re: Android—Why Dalvik? Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-06-02 19:34 +1200
Re: Android—Why Dalvik? BGB <cr88192@hotmail.com> - 2011-06-02 03:43 -0700
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> |
|---|---|
| Date | 2011-06-08 12:55 +1200 |
| Message-ID | <ismhaf$ikc$2@lust.ihug.co.nz> |
| In reply to | #5072 |
In message <vu3tu6p5lj7q1q85alge01v2hc1sjst3gn@4ax.com>, Gene Wirchenko wrote: > On Tue, 07 Jun 2011 10:23:53 +1200, Lawrence D'Oliveiro > <ldo@geek-central.gen.new_zealand> wrote: > >>In message <2odqu6p5vbq53pelct7s57uvfc8o43h1fk@4ax.com>, Gene Wirchenko >>wrote: >> >>> Finding one example does not disprove that something is rare. >> >>I provided several exampleslarge ones, too. > > Several might not be enough either. > > And you might not have to prove <not-rareness> but <in general > use> or <in general use in one or more niches>. That’s why I quoted well-known examples which most people would recognize.
[toc] | [prev] | [next] | [standalone]
| From | "H.J. Sander Bruggink" <sander.bruggink@uni-due.de> |
|---|---|
| Date | 2011-06-06 11:21 +0200 |
| Message-ID | <953kh4Fo65U1@mid.dfncis.de> |
| In reply to | #4971 |
On 06/04/2011 06:08 AM, Lawrence D'Oliveiro wrote: > Most languages (including Java) that claim to be “portable” seem to be > implemented in C. Therefore they can only be ported to platforms where a C > compiler (or cross-compiler) is already available. Therefore, > > Portability(all such languages) ⊆ Portability(C) > > or even > > Portability(all such languages apart from C) ⊂ Portability(C) The fact that there exist platforms on which there is no JVM, indicates that porting a C (or C++) program to a different platform is not simply a recompile. There is actually a big effort involved. C is very portable, yes, if you're writing a single-threaded, non-networking console application. If you want the program to be actually usable in practice, you need platform-independent libraries for the networking, the threads, the GUI, the XML processing, etc. And once you've decided which ones to use, the amount of platforms your C program compiles on without a rewrite is typically /less/ than the amount of platforms a Java program runs on. groente -- Sander
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> |
|---|---|
| Date | 2011-06-07 13:40 +1200 |
| Message-ID | <isjvip$3na$2@lust.ihug.co.nz> |
| In reply to | #5008 |
In message <953kh4Fo65U1@mid.dfncis.de>, H.J. Sander Bruggink wrote: > The fact that there exist platforms on which there is no JVM, indicates > that porting a C (or C++) program to a different platform is not simply > a recompile. There is actually a big effort involved. There are thousands of open-source C/C++ programs that can indeed be “simply recompiled” across a wide range of hardware platforms. > C is very portable, yes, if you're writing a single-threaded, > non-networking console application. If you want the program to be > actually usable in practice, you need platform-independent libraries for > the networking, the threads, the GUI, the XML processing, etc. Most of which are already available, and written in portable C/C++, right all the way down to a portable OS kernel.
[toc] | [prev] | [next] | [standalone]
| From | "H.J. Sander Bruggink" <sander.bruggink@uni-due.de> |
|---|---|
| Date | 2011-06-07 10:16 +0200 |
| Message-ID | <95652kF8muU1@mid.dfncis.de> |
| In reply to | #5047 |
On 06/07/2011 03:40 AM, Lawrence D'Oliveiro wrote: > In message<953kh4Fo65U1@mid.dfncis.de>, H.J. Sander Bruggink wrote: > >> The fact that there exist platforms on which there is no JVM, indicates >> that porting a C (or C++) program to a different platform is not simply >> a recompile. There is actually a big effort involved. > > There are thousands of open-source C/C++ programs that can indeed be “simply > recompiled” across a wide range of hardware platforms. Most open-source application use a lot of #ifdef's for the system-dependant code. So that is not a refutation of the claim that there is a big effort involved. > >> C is very portable, yes, if you're writing a single-threaded, >> non-networking console application. If you want the program to be >> actually usable in practice, you need platform-independent libraries for >> the networking, the threads, the GUI, the XML processing, etc. > > Most of which are already available, and written in portable C/C++, right > all the way down to a portable OS kernel. Even choosing only the GUI library will in general severely limit the platforms the application will compile on. groente -- Sander
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-06-07 01:30 -0700 |
| Message-ID | <isknpu$dkp$1@news.albasani.net> |
| In reply to | #5057 |
On 6/7/2011 1:16 AM, H.J. Sander Bruggink wrote: > On 06/07/2011 03:40 AM, Lawrence D'Oliveiro wrote: >> In message<953kh4Fo65U1@mid.dfncis.de>, H.J. Sander Bruggink wrote: >> >>> The fact that there exist platforms on which there is no JVM, indicates >>> that porting a C (or C++) program to a different platform is not simply >>> a recompile. There is actually a big effort involved. >> >> There are thousands of open-source C/C++ programs that can indeed be >> “simply >> recompiled” across a wide range of hardware platforms. > > Most open-source application use a lot of #ifdef's for the > system-dependant code. So that is not a refutation of the claim that > there is a big effort involved. > yep, there is this... however, if done well, the cost of getting the thing working on various targets is much less than that of writing the app to begin with, as generally the system-dependent code is a relative minority of the total codebase. >> >>> C is very portable, yes, if you're writing a single-threaded, >>> non-networking console application. If you want the program to be >>> actually usable in practice, you need platform-independent libraries for >>> the networking, the threads, the GUI, the XML processing, etc. >> >> Most of which are already available, and written in portable C/C++, right >> all the way down to a portable OS kernel. > > Even choosing only the GUI library will in general severely limit the > platforms the application will compile on. > at the same time though, there are only a small number of platforms which "really matter", so one can ignore most of the others and call it "good enough"... > groente > -- Sander >
[toc] | [prev] | [next] | [standalone]
| From | rossum <rossum48@coldmail.com> |
|---|---|
| Date | 2011-06-02 10:35 +0100 |
| Subject | Re: AndroidWhy Dalvik? |
| Message-ID | <71meu69511266d561jhov9a8d16d4ko77v@4ax.com> |
| In reply to | #4870 |
On Thu, 02 Jun 2011 11:54:06 +1200, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote: >In message <is4gtl$c2e$1@dont-email.me>, Joshua Cranmer wrote: > >> On 05/31/2011 11:05 PM, Lawrence D'Oliveiro wrote: >> >> Funny. I thought C/C++ was supposed to be portable. > >C certainly is. “Write once, run everywhere” is more true of C than it is of >Java; a portable compiler like GCC means C is the most portable language in >the world. > >> With Java, it doesn't matter which compiler I use to link the binary, they >> all the do same thing. Even if I don't program my code in Java. ;-) >> >> Java has extreme ABI portability--any compiler, any OS, any arch. > >At the cost of putting the burden on the recipient of your code to figure >out how to run a .jar file on their system. To run a .jar file on my system I double click on the file. I can run a C program using the GCC compiler as well but it is a lot more trouble than a double click. On my system a .jar file is immediately runnable while a C source file isn't. C is not "write once run everywhere" it is "write once, compile and run everywhere." Java removes the compile step from the user's end. To me the .jar is more portable. rossum
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-06-02 03:32 -0700 |
| Subject | Re: Android�Why Dalvik? |
| Message-ID | <is7p25$827$1@news.albasani.net> |
| In reply to | #4882 |
On 6/2/2011 2:35 AM, rossum wrote: > On Thu, 02 Jun 2011 11:54:06 +1200, Lawrence D'Oliveiro > <ldo@geek-central.gen.new_zealand> wrote: > >> In message<is4gtl$c2e$1@dont-email.me>, Joshua Cranmer wrote: >> >>> On 05/31/2011 11:05 PM, Lawrence D'Oliveiro wrote: >>> >>> Funny. I thought C/C++ was supposed to be portable. >> >> C certainly is. “Write once, run everywhere” is more true of C than it is of >> Java; a portable compiler like GCC means C is the most portable language in >> the world. >> >>> With Java, it doesn't matter which compiler I use to link the binary, they >>> all the do same thing. Even if I don't program my code in Java. ;-) >>> >>> Java has extreme ABI portability--any compiler, any OS, any arch. >> >> At the cost of putting the burden on the recipient of your code to figure >> out how to run a .jar file on their system. > To run a .jar file on my system I double click on the file. I can run > a C program using the GCC compiler as well but it is a lot more > trouble than a double click. > > On my system a .jar file is immediately runnable while a C source file > isn't. C is not "write once run everywhere" it is "write once, > compile and run everywhere." Java removes the compile step from the > user's end. > > To me the .jar is more portable. > yes, but to be fair though, it is a little less convenient in some cases than a native binary would be, such as (AFAIK) on Linux it would be necessary to use a shell script to wrap the call to 'java' to make it behave more like a native program (from the shell, GNome does file associations so will probably wrap this case). say, "myprogram.sh": java -jar myprogram.jar ... I just did a little experiment here, and it seems on modern Windows (Win7) one can essentially launch files (jars included) directly from the command-line (presumably arguments would be passed to the JVM and be parsed correctly, but I didn't test this...). I suspect this is because the CMD shell now checks for associations and launches the program. AFAICT, it one goes and adds JAR to the PATHEXT environment variable, then it is no longer necessary to include typing the jar file extension when launching JARs. one could do similar with C files, but alas then this would hinder their more useful behavior: double-click to launch ones' favorite text editor... well, and as well, C programs are not typically self-contained in a single source file, so one would more likely need a Makefile-like launcher script of some sort... then this made me wonder about something... apparently it seems EXE files do have file associations in the registry... odd... then again, I do remember an instance of someone going and messing with file associations to break Windows in a relatively amusing way (pretty much nothing could be done on the computer, because nearly all actions resulted in Notepad windows filled with binary garbage). it does bring up an idle mystery though as to how much of a central role the OS's binary format really needs in an OS, or if it could be largely reduced to "just another file format" as far as the kernel is concerned (all files launched by associations, including program binaries, just with a little bit of a hack for the "main program loader" or similar, with the OS possibly allowing secondary loaders with a behavior analogous to that of the main loader). or such...
[toc] | [prev] | [next] | [standalone]
| From | Joshua Cranmer <Pidgeot18@verizon.invalid> |
|---|---|
| Date | 2011-06-02 11:07 -0400 |
| Subject | Re: Android�Why Dalvik? |
| Message-ID | <is88va$dfj$1@dont-email.me> |
| In reply to | #4883 |
On 06/02/2011 06:32 AM, BGB wrote: > yes, but to be fair though, it is a little less convenient in some cases > than a native binary would be, such as (AFAIK) on Linux it would be > necessary to use a shell script to wrap the call to 'java' to make it > behave more like a native program (from the shell, GNome does file > associations so will probably wrap this case). > > say, "myprogram.sh": > java -jar myprogram.jar ... If that really pisses you off to type in `java -jar', then just chmod +x the jar file and then do ./myprogram.jar. My Linux distribution at least comes with a utility that works out based on the binary file type which program it should call to execute files. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-06-02 10:07 -0700 |
| Subject | Re: Android�Why Dalvik? |
| Message-ID | <is8g6r$tvi$1@news.albasani.net> |
| In reply to | #4894 |
On 6/2/2011 8:07 AM, Joshua Cranmer wrote: > On 06/02/2011 06:32 AM, BGB wrote: >> yes, but to be fair though, it is a little less convenient in some cases >> than a native binary would be, such as (AFAIK) on Linux it would be >> necessary to use a shell script to wrap the call to 'java' to make it >> behave more like a native program (from the shell, GNome does file >> associations so will probably wrap this case). >> >> say, "myprogram.sh": >> java -jar myprogram.jar ... > > If that really pisses you off to type in `java -jar', then just chmod +x > the jar file and then do ./myprogram.jar. My Linux distribution at least > comes with a utility that works out based on the binary file type which > program it should call to execute files. > fair enough... but, the point is more that there may be cases where launching the jar is slightly less convenient than, say, using a native binary. but, now my recent explorations are suggesting that raw OS binaries are not necessarily necessary... this is convenient to know, partly for my own VM projects as well, since I more just need compiled image files and a fairly unique file extension, rather than necessarily needing to produce native OS binaries (such as ELF or PE/COFF images). or such...
[toc] | [prev] | [next] | [standalone]
| From | Michael Wojcik <mwojcik@newsguy.com> |
|---|---|
| Date | 2011-06-03 09:38 -0400 |
| Message-ID | <isaq5h21eti@news2.newsguy.com> |
| In reply to | #4838 |
Lawrence D'Oliveiro wrote: > > Using MSVC brings its own share of problems. I remember on the Python group, > if you wanted to build a C/C++ extension for Python, you had to compile it > with the exact same version of MSVC as was used for that version of Python, > otherwise it wouldn’t work. There's no "C/C++" language. C and C++ are very different languages.[1] Requiring the same version of MSVC, for a binary compiled from C code, indicates improper use of the C runtime by either Python or the extension. Mixing C runtimes is fine as long as you follow the guidelines Microsoft publishes. In particular, resources allocated by one module shouldn't be freed by another; and some resources (notably FILE* objects) shouldn't be shared between modules. None of this is difficult to achieve. There may be other issues with Microsoft C++, particularly if the versions are very far apart, but on the whole, with properly-designed APIs, there's no reason for this to be a problem. There are certainly many infelicities with MSVC. But most of the problems people have with it are due to sloppy design and coding, and a failure to read and follow the documentation. [1] Yes, I'm well aware that Stroustrop thinks otherwise. I've had that argument (and he participated) on Usenet. I find his argument fundamentally flawed. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> |
|---|---|
| Date | 2011-06-04 12:21 +1200 |
| Message-ID | <isbtpf$dm0$5@lust.ihug.co.nz> |
| In reply to | #4939 |
In message <isaq5h21eti@news2.newsguy.com>, Michael Wojcik wrote: > Lawrence D'Oliveiro wrote: >> >> Using MSVC brings its own share of problems. I remember on the Python >> group, if you wanted to build a C/C++ extension for Python, you had to >> compile it with the exact same version of MSVC as was used for that >> version of Python, otherwise it wouldn’t work. > > There's no "C/C++" language. C and C++ are very different languages.[1] Relevance being? > Requiring the same version of MSVC, for a binary compiled from C code, > indicates improper use of the C runtime by either Python or the > extension. But that would be true of everything built with MSVC. Are you saying that MSVC is making “improper use of the C runtime”? > Mixing C runtimes is fine as long as you follow the guidelines Microsoft > publishes. In particular, resources allocated by one module shouldn't be > freed by another ... Since Python itself provides most of the memory management for objects created by extensions, it’s hard to see how this can be made to work in any practical sense.
[toc] | [prev] | [next] | [standalone]
| From | Michael Wojcik <mwojcik@newsguy.com> |
|---|---|
| Date | 2011-06-07 11:48 -0400 |
| Message-ID | <isnvsu215kt@news2.newsguy.com> |
| In reply to | #4960 |
Lawrence D'Oliveiro wrote: > In message <isaq5h21eti@news2.newsguy.com>, Michael Wojcik wrote: > >> Lawrence D'Oliveiro wrote: >>> Using MSVC brings its own share of problems. I remember on the Python >>> group, if you wanted to build a C/C++ extension for Python, you had to >>> compile it with the exact same version of MSVC as was used for that >>> version of Python, otherwise it wouldn’t work. >> There's no "C/C++" language. C and C++ are very different languages.[1] > > Relevance being? Your claim, as stated, describes an attribute of a nonexistent entity. Since the entity does not exist, its attributes demonstrate nothing about the real world. >> Requiring the same version of MSVC, for a binary compiled from C code, >> indicates improper use of the C runtime by either Python or the >> extension. > > But that would be true of everything built with MSVC. No, it is not true of everything built with MSVC. > Are you saying that > MSVC is making “improper use of the C runtime”? A ridiculous argument, even for you. >> Mixing C runtimes is fine as long as you follow the guidelines Microsoft >> publishes. In particular, resources allocated by one module shouldn't be >> freed by another ... > > Since Python itself provides most of the memory management for objects > created by extensions, it’s hard to see how this can be made to work in any > practical sense. Then that's a failure of the Python extension architecture, not of MSVC. There are many things wrong with MSVC, but the particular one you appear to be trying to describe is not one of them. Mixing MSVC runtimes is (unnecessarily) complicated; it is not impossible. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
[toc] | [prev] | [next] | [standalone]
| From | Michael Wojcik <mwojcik@newsguy.com> |
|---|---|
| Date | 2011-06-03 09:31 -0400 |
| Message-ID | <isaq5g11eti@news2.newsguy.com> |
| In reply to | #4809 |
BGB wrote: > On 5/31/2011 8:10 AM, Joshua Cranmer wrote: >> >> Besides, all autoconf gets you is setting up the hundreds of #defines. >> It does nothing else with respect to the #ifdef mess. > > yeah, and it doesn't exactly tend to work well for non-Linux operating > systems (such as Windows...). Used properly, autoconf works just fine on Windows - or, at any rate, as well as it works anywhere. (Like Joshua I am not particularly impressed with autoconf, though it's not quite as thoroughly brain-damaged as some of its fellow GNU build tools, such as libtool.) Wireshark uses it, for example. Once again, the real problem is that systems like autoconf only help with C code that is written to be portable with the help of conditional compilation. The vast majority of C code is poorly written (spend some time on comp.lang.c if you don't understand how or why) and a good portion of that is unportable assumptions. Some of the classic non-portable assumptions in C code are becoming rarer. The prevalence of two's-complement machines over one's-complement and sign-magnitude (the other two "pure binary representations" allowed for C integer types) has largely eliminated one source of bit-twiddling errors, for example; and the popularity of I32LP64 architectures has made more programmers aware of the problems of casting between pointer and integer types. But we still see a lot of code with character set assumptions, or assuming CHAR_BIT==8, or assuming huge auto-class objects are fine. Those are safe assumptions on many platforms, but they limit portability. So do endianness assumptions, etc. And we still see a lot of buffer overflows, integer overflows, unsafe or erroneous memory allocation. Failures to check for and handle error returns from library and system calls. TOCTOU races and other forms of unsafe file handling. Interpositioning vulnerabilities (a huge issue with Windows right now; not specific to C, but mitigated by runtime systems that use more-sophisticated dynamic loaders). And so on. Autoconf does *not a damn thing* to address any of this. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-06-03 12:45 -0700 |
| Message-ID | <isbdr6$86b$1@news.albasani.net> |
| In reply to | #4936 |
On 6/3/2011 6:31 AM, Michael Wojcik wrote: > BGB wrote: >> On 5/31/2011 8:10 AM, Joshua Cranmer wrote: >>> >>> Besides, all autoconf gets you is setting up the hundreds of #defines. >>> It does nothing else with respect to the #ifdef mess. >> >> yeah, and it doesn't exactly tend to work well for non-Linux operating >> systems (such as Windows...). > > Used properly, autoconf works just fine on Windows - or, at any rate, > as well as it works anywhere. (Like Joshua I am not particularly > impressed with autoconf, though it's not quite as thoroughly > brain-damaged as some of its fellow GNU build tools, such as libtool.) > Wireshark uses it, for example. > > Once again, the real problem is that systems like autoconf only help > with C code that is written to be portable with the help of > conditional compilation. The vast majority of C code is poorly written > (spend some time on comp.lang.c if you don't understand how or why) > and a good portion of that is unportable assumptions. > > Some of the classic non-portable assumptions in C code are becoming > rarer. The prevalence of two's-complement machines over > one's-complement and sign-magnitude (the other two "pure binary > representations" allowed for C integer types) has largely eliminated > one source of bit-twiddling errors, for example; and the popularity of > I32LP64 architectures has made more programmers aware of the problems > of casting between pointer and integer types. > > But we still see a lot of code with character set assumptions, or > assuming CHAR_BIT==8, or assuming huge auto-class objects are fine. > Those are safe assumptions on many platforms, but they limit > portability. So do endianness assumptions, etc. > CHAR_BIT==8 is AFAIK more acceptable, since nearly all major/common hardware at this point (and likely in the near future) has this property. endianess matters if one thinks the code may have a chance of migrating between different sorts of targets, such as between x86 and PPC. usually I handle endianness in my own code though. > And we still see a lot of buffer overflows, integer overflows, unsafe > or erroneous memory allocation. Failures to check for and handle error > returns from library and system calls. TOCTOU races and other forms of > unsafe file handling. Interpositioning vulnerabilities (a huge issue > with Windows right now; not specific to C, but mitigated by runtime > systems that use more-sophisticated dynamic loaders). And so on. > > Autoconf does *not a damn thing* to address any of this. > yes, ok. oddly, Mozilla uses Autoconf+MSVC in their Windows build setup (and apparently also a 'special' version of Autoconf). IMO it looks like a bit of a kludge. more impressive though was that it actually worked, and when one follows their directions (downloading/using MozillaBuild, ...), they can rebuild FireFox/... from source on Windows. I am currently using MSVC, but mostly this was because in 2009 I had been building for Win64, and GCC's Win64 support was not impressive (mostly in the sense that it was occasionally producing broken code apparently mixing together parts of the Win64 and AMD64 ABI's...). I am left wondering if GCC's Win64 support has improved, or if it really matters. I could probably switch back, but it would involve having to mess around some with the makefiles, which is inconvinient. or such...
[toc] | [prev] | [next] | [standalone]
| From | Michael Wojcik <mwojcik@newsguy.com> |
|---|---|
| Date | 2011-06-03 17:14 -0400 |
| Message-ID | <isbkvh1me0@news3.newsguy.com> |
| In reply to | #4949 |
BGB wrote: > > CHAR_BIT==8 is AFAIK more acceptable, since nearly all major/common > hardware at this point (and likely in the near future) has this property. It's acceptable right up until it isn't. And there are still a number of major embedded platforms which do not use 8-bit char. That said, it's often true that an explicit assumption that CHAR_BIT is 8 is acceptable. The problem is when that assumption isn't explicit, and the code might be ported to a platform where CHAR_BIT > 8. (The larger problem is the existence of C programmers who don't know about CHAR_BIT, or how C defines "byte".) > endianess matters if one thinks the code may have a chance of migrating > between different sorts of targets, such as between x86 and PPC. Since portability is the matter under discussion... > usually > I handle endianness in my own code though. Glad to hear it - though generally well-written C code should be endian-neutral, especially when marshalling and unmarshalling data that may not match the implementation's endianness. (That is, it should employ shifting and masking using unsigned integer types, which produces the correct result regardless of platform endianness.) What you do, or what I do, says nothing about what most C programmers do, however. And that was my point. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> |
|---|---|
| Date | 2011-06-04 12:23 +1200 |
| Message-ID | <isbtt9$dm0$6@lust.ihug.co.nz> |
| In reply to | #4936 |
In message <isaq5g11eti@news2.newsguy.com>, Michael Wojcik wrote: > BGB wrote: > >> On 5/31/2011 8:10 AM, Joshua Cranmer wrote: >>> >>> Besides, all autoconf gets you is setting up the hundreds of #defines. >>> It does nothing else with respect to the #ifdef mess. >> >> yeah, and it doesn't exactly tend to work well for non-Linux operating >> systems (such as Windows...). > > Used properly, autoconf works just fine on Windows - or, at any rate, > as well as it works anywhere. (Like Joshua I am not particularly > impressed with autoconf, though it's not quite as thoroughly > brain-damaged as some of its fellow GNU build tools, such as libtool.) Can you offer anything that works better? > Once again, the real problem is that systems like autoconf only help > with C code that is written to be portable with the help of > conditional compilation. The vast majority of C code is poorly written > (spend some time on comp.lang.c if you don't understand how or why) > and a good portion of that is unportable assumptions. That would certainly not be true with the vast majority of Free Software written in C/C++. Which is the main kind of C/C++ code that I deal with.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-06-03 19:01 -0700 |
| Message-ID | <isc3qu$f9a$1@news.albasani.net> |
| In reply to | #4961 |
On 6/3/2011 5:23 PM, Lawrence D'Oliveiro wrote: > In message<isaq5g11eti@news2.newsguy.com>, Michael Wojcik wrote: > >> BGB wrote: >> >>> On 5/31/2011 8:10 AM, Joshua Cranmer wrote: >>>> >>>> Besides, all autoconf gets you is setting up the hundreds of #defines. >>>> It does nothing else with respect to the #ifdef mess. >>> >>> yeah, and it doesn't exactly tend to work well for non-Linux operating >>> systems (such as Windows...). >> >> Used properly, autoconf works just fine on Windows - or, at any rate, >> as well as it works anywhere. (Like Joshua I am not particularly >> impressed with autoconf, though it's not quite as thoroughly >> brain-damaged as some of its fellow GNU build tools, such as libtool.) > > Can you offer anything that works better? > some people really like CMake. >> Once again, the real problem is that systems like autoconf only help >> with C code that is written to be portable with the help of >> conditional compilation. The vast majority of C code is poorly written >> (spend some time on comp.lang.c if you don't understand how or why) >> and a good portion of that is unportable assumptions. > > That would certainly not be true with the vast majority of Free Software > written in C/C++. Which is the main kind of C/C++ code that I deal with. > note that he was apparently also objecting to the use of "conditional compilation" as a portability strategy (IOW: "lots of #ifdef"). however, "#ifdef" is one of the main portability strategies with most FOSS, and actually most software in general. the issue though is that the requirements for making "proper" portable software (IOW: not using piles of "#ifdef"s) is generally very awkward/painful, and limits what sorts of things one can do, and doesn't really buy all that much. most people, really, probably don't care that much if the software they are using has a few ifdef's here or there, they just care that it works. however, if it could work, one could call it "ultraportability" though. IOW: code that is portable well beyond the usual set of N targets it was originally designed to work on. but, for the most part, this isn't really necessary. usually the code is at least written generically enough that it can be ported to new targets without too much added pain (usually by adding more ifdef's and special-case code for the new targets). or such...
[toc] | [prev] | [next] | [standalone]
| From | Michael Wojcik <mwojcik@newsguy.com> |
|---|---|
| Date | 2011-06-07 11:59 -0400 |
| Message-ID | <isnvsv315kt@news2.newsguy.com> |
| In reply to | #4967 |
BGB wrote: > On 6/3/2011 5:23 PM, Lawrence D'Oliveiro wrote: >> In message<isaq5g11eti@news2.newsguy.com>, Michael Wojcik wrote: >> >>> Once again, the real problem is that systems like autoconf only help >>> with C code that is written to be portable with the help of >>> conditional compilation. The vast majority of C code is poorly written >>> (spend some time on comp.lang.c if you don't understand how or why) >>> and a good portion of that is unportable assumptions. >> >> That would certainly not be true with the vast majority of Free Software >> written in C/C++. Which is the main kind of C/C++ code that I deal with. > > note that he was apparently also objecting to the use of "conditional > compilation" as a portability strategy (IOW: "lots of #ifdef"). That's not exactly how I'd interpret what I wrote. I object to writing non-portable code as a portability strategy. That said, a lot of conditional compilation (setting aside the question of defining "a lot") is not a good sign. At the very least it suggests some refactoring is called for. > however, "#ifdef" is one of the main portability strategies with most > FOSS, and actually most software in general. That seems plausible, though cumbersome to verify. > the issue though is that the requirements for making "proper" portable > software (IOW: not using piles of "#ifdef"s) is generally very > awkward/painful, and limits what sorts of things one can do, and doesn't > really buy all that much. > > most people, really, probably don't care that much if the software they > are using has a few ifdef's here or there, they just care that it works. There's a great deal of room between "piles of" and "a few". I'll claim - without support, since this nonsense has gone on long enough - that it is generally possible to cleanly refactor C programs into portable and platform-specific parts, and thereby greatly reduce the amount of conditional compilation. (In fact, the conditional compilation can be hoisted into the build system, with individual per-platform source files, thereby eliminating all in-source conditional compilation. In some applications this is a reasonable approach.) -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
[toc] | [prev] | [next] | [standalone]
| From | Joshua Cranmer <Pidgeot18@verizon.invalid> |
|---|---|
| Date | 2011-06-04 02:44 -0400 |
| Message-ID | <isck8i$92j$1@dont-email.me> |
| In reply to | #4961 |
On 06/03/2011 08:23 PM, Lawrence D'Oliveiro wrote: > In message<isaq5g11eti@news2.newsguy.com>, Michael Wojcik wrote: >> Used properly, autoconf works just fine on Windows - or, at any rate, >> as well as it works anywhere. (Like Joshua I am not particularly >> impressed with autoconf, though it's not quite as thoroughly >> brain-damaged as some of its fellow GNU build tools, such as libtool.) > > Can you offer anything that works better? I submit <language>, where <language> is your favorite interpreted and/or bytecode-compiled language and thus deprecates the need for a tool whose primary purpose is figuring out exactly what machine it's running on. > That would certainly not be true with the vast majority of Free Software > written in C/C++. Which is the main kind of C/C++ code that I deal with. I'm sure that outside of GNU or FSF-blessed programs, there are a lot of C/C++ programs that wouldn't compile on Unix-ish-but-not-Linux platforms, like OpenBSD or Solaris. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> |
|---|---|
| Date | 2011-06-05 11:11 +1200 |
| Message-ID | <isee3b$sj9$1@lust.ihug.co.nz> |
| In reply to | #4976 |
In message <isck8i$92j$1@dont-email.me>, Joshua Cranmer wrote: > On 06/03/2011 08:23 PM, Lawrence D'Oliveiro wrote: >> In message<isaq5g11eti@news2.newsguy.com>, Michael Wojcik wrote: >>> Used properly, autoconf works just fine on Windows - or, at any rate, >>> as well as it works anywhere. (Like Joshua I am not particularly >>> impressed with autoconf, though it's not quite as thoroughly >>> brain-damaged as some of its fellow GNU build tools, such as libtool.) >> >> Can you offer anything that works better? > > I submit <language>, where <language> is your favorite interpreted > and/or bytecode-compiled language and thus deprecates the need for a > tool whose primary purpose is figuring out exactly what machine it's > running on. You mean, the one that requires wrappers that basically reinvent the functionality of GNU autoconf? >> That would certainly not be true with the vast majority of Free Software >> written in C/C++. Which is the main kind of C/C++ code that I deal with. > > I'm sure that outside of GNU or FSF-blessed programs, there are a lot of > C/C++ programs that wouldn't compile on Unix-ish-but-not-Linux > platforms, like OpenBSD or Solaris. How about this one <http://www.blender.org/>, with a million lines of C code, last I counted. Or this one <http://dev.mysql.com/>. Or this one <http://www.libreoffice.org/>. Or this one <http://httpd.apache.org/>.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web