Path: utzoo!utgpu!watserv1!watmath!att!cbnewsk!markg From: markg@cbnewsk.att.com (mark.r.gibaldi) Newsgroups: comp.windows.ms Subject: Re: Starting processes Message-ID: <1990Jul20.130059.18927@cbnewsk.att.com> Date: 20 Jul 90 13:00:59 GMT References: <3130022@hplsla.HP.COM> Organization: AT&T Bell Laboratories Lines: 28 In article <3130022@hplsla.HP.COM> davidr@hplsla.HP.COM (David M. Reed) writes: >I believe what you are being informed of is that the application really >will not "run" in the background. This does not mean the application will >die (thus it can be iconized or switched to the background, and later >de-iconized or brought to the foreground), but that if it were performing >some process (such as a sort, recalculation, or any other process that >actually requires cpu cycles) that the process is suspended while the >application is running in the foreground, and will probably resume when >brougt back to the foreground whatever it was doing when it was put in >the background. In other words, you get task-switching, but not true >multi-tasking like DESQview provides. I keep seeing posts like this, and I must admit, I'm baffled. I regularly run DOS apps in the background that continue to process while in the background. Some of these are communications packages which have file transfer protocols which will time out due to in activity. Perhaps the persons having these problems are running their apps from the DOS icon in the main program group. This is, I believe, not set up to run while in the background. I always set up a PIF file with Background processing enabled for each of my DOS apps. NOTE: I am running in 386 Enhanced mode. Mark R. Gibaldi AT&T Bell Laboratories mrg@cblph.att.com