ghenniga@nmsu.edu (Gary Hennigan) (07/07/90)
Maybe somebody out there can help me with this one? I'm running MSW v3.0 on an IBM PS/2 Model 55sx with 4.0Mb of RAM. The problem is that when I try to start up a process with the Background and the full screen options set in the executable's PIF Windows gives me an error that this application cannot be run in the background and it puts the application to a DOS icon. When I consequently double click on this icon the appliaction starts up fine and I am then able to run it in the background with no problems, so it's really not a major problem just a major inconvenience. All this occurs in 386 enhanced mode by the way. Any ideas of any sort would be greatly appreciated. Thanks in advance, -- Gary Hennigan +---------------------------------------------------------------------------+ + e-mail: ghenniga@NMSU.Edu, henninsf@maxwel.NMSU.Edu + + Department of Electrical Engineering, Grad Student + + Physical Science Laboratory, Assistant Systems Programmer + +---------------------------------------------------------------------------+
davidr@hplsla.HP.COM (David M. Reed) (07/19/90)
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.
markg@cbnewsk.att.com (mark.r.gibaldi) (07/20/90)
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
nelson_p@apollo.HP.COM (Peter Nelson) (07/24/90)
From: markg@cbnewsk.att.com (mark.r.gibaldi)
:>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.
The fact that this issue can go unresolved for such a long time
on Usenet says volumes about Microsoft's inability to get their
story straight and communicate it to their customers.
Most of my DOS apps freeze when iconized (most of them use graphics)
so I've been trying to get a straight answer from Microsoft. As
I promised a few weeks back, I've been taking a poll of Microsoft
tech support staff on this one. Results so far: 2 say categorically
that Windows 3.0 does not do ANY multitasking, two say it can multitask
almost all DOS programs, including ones which run graphics. And a
fifth one says that Windows will freeze any iconized DOS graphics
program which attempts to do a direct access to any address inside
the address range of the graphics board (i.e., control registers or
display memory). This actually seemed plausible but he didn't
know whether the program would run happily in background *until*
that point or how Windows calculated what the relevant addresses
are.
This is pretty typical of the mickey-mouse tech support organizations
which plague the PC industry. It's not that Microsoft's is any MORE
brain-dead than anyone else's, it's just that none of these companies
have a clue of what it means to provide competent, professional tech-
nical support and the people who answer the phones, however
hard working and well-meaning they might be, haven't got a clue
about the products they are allegedly supporting.
---Peter
pajerek@usenet@kadsma (Don Pajerek) (07/24/90)
In article <4bc4c9a3.20b6d@apollo.HP.COM> nelson_p@apollo.HP.COM (Peter Nelson) writes: [ article on Windows 3.0 multi-tasking confusion deleted ] > This is pretty typical of the mickey-mouse tech support organizations > which plague the PC industry. > > ---Peter A big part of the problem here is economics: anyone who is mentally astute enough to grasp the subject matter necessary to provide good customer support is also capable of using that ability to get a job which is a) a lot more pleasant, and b) better paying. Peter, would *you* want to spend you workday answering calls from customers? Don Pajerek Disclaimer: any opinions are strictly my own.
bg11+@andrew.cmu.edu (Brian E. Gallew) (07/24/90)
I have to agree with your opposition, Peter. I *DO* take phone calls for customer service every day. I try my best to give competent help, but sometimes the urge to shout RTFM becomes so strong that I have to start acting as dumb as some of my customers. I don't want to offend my customers, as I do get a lot of intelligent questions, too. On the other hand, the idiot that kept me on the phone for 45 minutes while he initialized a hard disk on a Macintosh really irritated the flock out of me.
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (07/24/90)
In article <Yaeuanu00Ug7A2E1MN@andrew.cmu.edu> bg11+@andrew.cmu.edu (Brian E. Gallew) writes: >I have to agree with your opposition, Peter. I *DO* take phone calls for >customer service every day. I try my best to give competent help, but >sometimes the urge to shout RTFM becomes so strong that I have to start acting >as dumb as some of my customers. I don't want to offend my customers, as I do >get a lot of intelligent questions, too. On the other hand, the idiot that >kept me on the phone for 45 minutes while he initialized a hard disk on a >Macintosh really irritated the flock out of me. Some companies are VERY good. Dell, for example. My first Dell had a bad motherboard. However, it ran ALL their diagnostics perfectly, and almost all ordinary programs. All, that is, except AutoCad. AutoCad would fail after 10 to 30 minutes trying to "hide" the house (site-3d). A Dell tech-person had me on the phone for **2 and a half hours** once while I tried various tests. Most of the time he was on hold, talking to other folks. That is the beauty of 800 numbers. I would tell him when I started AutoCad and he would come back 30 minutes later. This didn't fix anything - the next morning a service-person arrived with a new motherboard. And he stayed until AutoCad ran correctly. THAT is good service. Doug McDonald
david@jdyx.UUCP (David Mandell) (07/24/90)
markg@cbnewsk.att.com (mark.r.gibaldi) writes: >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. Your NOTE is the KEY!!! Windows will allow DOS Apps to multitask if and only if you are running in 386 Enhanced mode. In standard mode, there is no multitasking of DOS apps. Also, just for the record, note that ALL Windows Apps are considering "multi-tasking" ... no matter what mode you run Windows in. -- David G. Mandell david@jdyx.UUCP david@jdyx.atlanta.ga.us PLANNET CRAFTERS gatech!emory!jdyx!david CompuServe: 73040,334 BIX: davidmandell "Just place your order ... and wait for space to catch up with time"