ms@oatmeal.ai.mit.edu (Morgan Schweers) (09/15/90)
Greetings,
I recently was asked to write the basic equivelant of a fork() command for
an MS/DOS programming project. It is (of course) to be in assembly language,
and I have determined that INT 1Ch is my target. Before I spend a week or so
determining how exactly to write the blasted thing, does anyone know of a
currently existing implementation of the fork() command under MS/DOS,
preferrably in a Turbo C compatible library, or in ASM Source?
Many thanks for any help, and even any words of wisdom to assist me.
-- Morganbobmon@iuvax.cs.indiana.edu (RAMontante) (09/15/90)
You should investigate the "spawn...()" family of functions in Turbo C. (Also the "system()" function.) These functions spawn a child process, and resume the parent upon the child's completion. You can't really create "fork()" semantics for MS-DOS, since it's single-tasking. I think that as close as you could come, you can do already with "spawn...()". Fork() might be more meaningful in a multitasking environment such as Desqview or Windows gives you (isn't Windows a multitasker now?), but that isn't really "under MS-DOS" as the parent or child would have to know how to open another window to run in.
stever@Octopus.COM (Steve Resnick ) (09/18/90)
In article <58769@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: > >You should investigate the "spawn...()" family of functions in Turbo C. >(Also the "system()" function.) These functions spawn a child process, >and resume the parent upon the child's completion. > >You can't really create "fork()" semantics for MS-DOS, since it's >single-tasking. I think that as close as you could come, you can do >already with "spawn...()". Fork() might be more meaningful in a >multitasking environment such as Desqview or Windows gives you (isn't >Windows a multitasker now?), but that isn't really "under MS-DOS" as >the parent or child would have to know how to open another window to >run in. In DESQview a fork which works like the UNIX fork would not be possible. In windows I don't think so either, but I may be wrong. It is possible in both environments to start up copies of the same program, but not duplicate the same process (which, I believe, is what fork() does.) Just another side note... :) Steve . -- ---------------------------------------------------------------------------- steve.resnick@f105.n143.z1@FIDONET.ORG #include<std_disclaimer.h> Flames, grammar errors, spelling errrors >/dev/nul ----------------------------------------------------------------------------
ralf@b.gp.cs.cmu.edu (Ralf Brown) (09/18/90)
In article <1990Sep17.190834.21412@Octopus.COM> stever@octopus.UUCP (Steve Resnick ) writes: }In DESQview a fork which works like the UNIX fork would not be possible. }In windows I don't think so either, but I may be wrong. It is possible in }both environments to start up copies of the same program, but not duplicate }the same process (which, I believe, is what fork() does.) Well... Under DESQview, a program can create a new task which shares the same address space (code & data) but with a different stack. Unfortunately, you can't then do an EXEC without clobbering both tasks.... The main use of this capability is to create multiple threads (for those who are intensely curious, the demo program in DV-GLUE fires up two subthreads--on SIMTEL in PD1:<MSDOS.DESQVIEW>DVGLU*.ARC). -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/3.1 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | Everything is funny as long as it is happening to I claim something?| someone else. --Will Rogers
jaswal@suna2.cs.uiuc.edu (09/18/90)
If you have Desqview or Windows and you successfully write a fork() that's compatible with Unix's, it would be in very high demand! As far as I know, Desqview provides preemptive scheduling, meaning that it can steal control from multiple tasks. This is how Unix does it. Windows does non-preemptive scheduling, meaning that concurrent tasks must voluntarily give up control of the processor before other tasks get a time slice. (I'm not positive of this.) This may have changed with Windows v3.0 or when running on a 286 or 386. Anyway, fork() might have to be written differently depending on the type of scheduling done. Both environments provide lots of programming tools and system calls, especially Windows. vsj
hughes@volcano.Berkeley.EDU (Eric Hughes) (09/29/90)
In article <69400001@suna2> jaswal@suna2.cs.uiuc.edu writes: >Windows does non-preemptive scheduling, meaning that >concurrent tasks must voluntarily give up control of the processor >before other tasks get a time slice. (I'm not positive of this.) >This may have changed with Windows v3.0 or when running on a 286 >or 386. From _Microsoft Windows: a guide to Programming_, page 1-16 (this book is from Microsoft Press and include version 3): "1.6 Tips for Writing Windows Applications ... "Do not take exclusive control of the CPU--it is a shared resource. Although Windows is a multitasking system, it is non-preemptive. This means it cannot take control back from an application until the application releases it. A cooperative application carefully manages access to the CPU and gives other applications ample opportunity to execute." "Cooperative application" is _such_ newspeak. Eric Hughes hughes@ocf.berkeley.edu