bagpiper@csvax.caltech.edu (04/01/87)
I thought I knew the answer to the following question until I started reading
some essays in a Bell Laboratories Tech Journal:
What is the difference between fork and exec in a unix environment and
furthermore how does that map into a MS-Dos environment??
Can someone give me a straight authoritative answer or at least point me
toward a set of essays that would give me an answer.
Mike Hunter
UUCP: cit-vax!oxy!bagpiperron@brl-sem.UUCP (04/01/87)
In article <6635@brl-adm.ARPA>, Primixsys!bagpiper@csvax.caltech.edu writes: > What is the difference between fork and exec in a unix environment and > furthermore how does that map into a MS-Dos environment?? > Fork: causes an exact copy of the currently running process to be made. The two copies differ only in the return that the fork function makes. The child always sees a return value of zero and the parent sees the return value which is the process id of the child (if the child wants to know the parents process ID, it can either do a getppid, which will not be the former parent process ID if that process has exitted, or the parent could have done a getpid before the fork). When processes have sections that can't be written by a user process (write protected text) or on machines with slick enough memory management, the fork will actually allow multiple processes to share unchanged regions rather than making a copy. exec: Replaces the currently running process, with the process specified in it's arguments. This obliterates the current process. As a result, the only return from exec that the calling program will ever see is an error (if it succeeds, the caller won't be there anymore). If you would like to run a new process concurrently with the existing one you need to fork first, and then obliterate one of the two processes by exec-ing the new process. Use exec by itself if you just want to "chain" into another program (this is exactly analogous and is the origin of the "exec" command in the shell). If you want to make a new process without disturbing the current process, use fork then exec. Now fork is a bit costly with slicker programs that use lots of memory. The shell frequently does fork followed by not much more than exec. This means that there is a lot of copying of the shell that lives only a few instructions before it gets wiped out by the subsequent exec. To alleviate this, Berkeley has added "vfork" to their system. Vfork, works like fork (creating a duplicate process) except that the new process uses the exact same memory image as the old one. You have to be very careful doing this, but if the new process doesn't mess with memory before doing the exec, you can get away with it and avoid a lot of memory copying. -Ron
ark@alice.UUCP (04/01/87)
In article <6635@brl-adm.ARPA>, bagpiper@csvax.caltech.edu writes: > What is the difference between fork and exec in a unix environment and > furthermore how does that map into a MS-Dos environment?? Fork creates a new process. Exec replaces the contents of the current process' memory without creating a new process.
joecar@pyuxe.UUCP (04/02/87)
In article <6635@brl-adm.ARPA>, bagpiper@csvax.caltech.edu writes: > > I thought I knew the answer to the following question until I started reading > some essays in a Bell Laboratories Tech Journal: > > What is the difference between fork and exec in a unix environment and > furthermore how does that map into a MS-Dos environment?? > > Can someone give me a straight authoritative answer or at least point me > toward a set of essays that would give me an answer. I understand the difference between fork and exec system calls, but I'd like to expand the question and ask if anyone can help me understand the mapping of fork-exec and/or fork-exec-wait sequences to other non-UNIX computing environments like MVS, VM, VMS, and as the other article asks, MS-DOS. Joe Carfagno ...!bellcore!pyuxe!joecar
madd@bucsb.bu.edu.UUCP (04/02/87)
In article <6635@brl-adm.ARPA> bagpiper@csvax.caltech.edu writes: > What is the difference between fork and exec in a unix environment and > furthermore how does that map into a MS-Dos environment?? No problem. fork() causes program execution to split into two identical processes. They have independent data sections (although the two are identical to begin with) and may have shared code, although on some systems it is easier to duplicate the code than to share it. exec() is slightly different. It means to load in a new program ON TOP OF the current one. Thus to run a program and return, you would fork(), then have the child process of the fork perform an exec(). When the new program exits, the program that executed the fork() will be notified. Usually this parent sits in a wait state, although not always. MS-DOS is a bit different. Because it's not multitasking, the concept of fork() is impossible. Instead, there exists an exec function that performs the functions of ALL THREE of the unix functions fork(), exec() and wait(). When you call exec, MS-DOS loads the new program into a new space, and gives it control. When it terminates, control is returned to the parent process. This is much more primitive than in unix. I hope this is helpful. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Jim Frost * The Madd Hacker | UUCP: ..!harvard!bu-cs!bucsb!madd H H | ARPA: madd@bucsb.bu.edu H-C-C-OH <- heehee +---------+---------------------------------- H H | "We are strangers in a world we never made"
drw@cullvax.UUCP (04/02/87)
ron@brl-sem.ARPA (Ron Natalie <ron>) writes: > exec: Replaces the currently running process, with the process > specified in it's arguments. This obliterates the current process. > As a result, the only return from exec that the calling program will > ever see is an error (if it succeeds, the caller won't be there anymore). > If you would like to run a new process concurrently with the existing > one you need to fork first, and then obliterate one of the two processes > by exec-ing the new process. Maybe I'm wrong here, but I believe that a more accurate statement is: Exec replaces the current memory and register contents of the process with the information specified in a particular executable file. The process itself retains its former identity (including, I beleive, its open I/O channels, parent process, child processes, etc.). Since the *code* that called exec isn't around anymore, that call doesn't return a value if exec succeeds. There's a big difference between a process itself and the code that the process happens to be running at the moment. Dale -- Dale Worley Cullinet Software UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw ARPA: cullvax!drw@eddie.mit.edu Un*x (a generic name for a class of OS's) != Unix (AT&T's brand of such)
throopw@dg_rtp.UUCP (04/04/87)
> joecar@pyuxe.UUCP >> bagpiper@csvax.caltech.edu >> What is the difference between fork and exec in a unix environment and >> furthermore how does that map into a MS-Dos environment?? > I understand the difference between fork and exec system calls, but > I'd like to expand the question and ask if anyone can help me understand > the mapping of fork-exec and/or fork-exec-wait sequences to other non-UNIX > computing environments like MVS, VM, VMS, and as the other article > asks, MS-DOS. I'll talk about how Unix-style fork() and exec() map to AOS/VS (Data General) operations. But first, we have to get a handle on what operations we are talking about here. There are really three. There is "create a process", "load an executable image", and (most difficult for AOS/VS) "duplicate a process's executable image". In Unix, fork() == "create a process" & "duplicate a process's executable image" exec() == "load an executable image" Whereas on AOS/VS, ?PROC == "create a process" & "load an executable image" ?CHAIN == "load an executable image" You can see that AOS/VS has no notion of the duplication of a running process's address space. Luckily, it is possible to implement this operation as a user-level operation under AOS/VS. In fact, fork() can be simulated on AOS/VS by ?PROC (loading a very simple image, which in turn copies it's parent's address space), and exec() maps almost directly into ?CHAIN. Note that Berkeley's vfork() operation is close to "create a process" alone, without loading or duplicating an image. This means that systems that have vfork(), fork(), and exec() come fairly close to separating out the three functions. For sure, they have the common cases covered. Further note that the issues of what to do with open files, IPC connections, and other non-memory-image state-of-a-process when each of these three operations occur muddies up this clear picture quite a bit. > madd@bucsb.bu.edu (Jim Frost) > When you call exec, MS-DOS loads the new program > into a new space, and gives it control. When it terminates, control > is returned to the parent process. This is much more primitive than > in unix. I'll pick a nit here. It is *not* more primitive than the Unix operations. In fact, the whole reason that the Unix operations are superior is that they ARE more primitive. They come closer to performing only one operation each. For this reason, the Unix operations are more powerful and flexible, *because* they are more primitive. -- "You've got three minutes to talk, or my friend here'll get angry." "Grrrrrrrrrr." --- Galaxy Rangers -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw