LINUX.ORG.RU

История изменений

Исправление bigbit, (текущая версия) :

Да, сейчас говорят, что fork/exec - более гибко, и лучше предоставить самому процессу возможность сделать с файловыми дескрипторами то, что что он хочет, чем создавать единый системный вызов с 10 параметрами (как CreateProcess)... Но на самом деле, причина, скорее всего, в другом.
Есть статья Дениса Ритчи, в которой он рассказывает, что fork/exec - одно из тех решений, которое было сделано потому, что тупо требовало меньших усилий по кодированию на определенном этапе развития Unix.
Это было еще в те времена, когда Unix пешком ходил под стол, и не существовало ни fork, ни exec, и то, что сейчас делает exec, делалось самим шеллом (sh). И не было смысла дублировать этот код в новом системном вызове для создания процесса, а все, что было нужно сделать тогда - это добавить fork(), что и заняло всего 27 строчек =)

http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf

Исходная версия bigbit, :

Да, сейчас говорят, что fork/exec - более гибко, и лучше предоставить самому процессу возможность сделать с файловыми дескрипторами то, что что он хочет, чем создавать единый системный вызов с 10 параметрами (как CreateProcess)... Но нам самом деле, причина, скорее всего, в другом.
Есть статья Дениса Ритчи, в которой он рассказывает, что fork/exec - одно из тех решений, которое было сделано потому, что тупо требовало меньших усилий по кодированию на определенном этапе развития Unix.
Это было еще те времена, когда Unix пешком ходил под стол, и не существовало ни fork, ни exec, и то, что сейчас делает exec, делалось самим шеллом (sh). И не было смысла дублировать этот код в новом системном вызове для создания процесса, а все, что было нужно сделать тогда - это добавить fork(), что и заняло всего 27 строчек =)

http://www.read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf