bak10413@uxa.cso.uiuc.edu (05/25/90)
/* Written 6:14 am May 24, 1990 by wjin@cs.purdue.EDU in uxa.cso.uiuc.edu:comp.sys.ibm.pc */ /* ---------- "Why use MS-window ?" ---------- */ According to the discussions, windows for 88/86/286 machines cannot do muti-tasking. Then my question is why use windows if multi-tasking is impossible ? Anyway you start one job and wait until it is done. Maybe you can hold a process like an editor, and do something in other window, wait util it is finished and get back to the editor. Is this all reason why they use ms-window ? ------ W. Jin /* End of text from uxa.cso.uiuc.edu:comp.sys.ibm.pc */ I didn't read the discussions to which you refer, but I imagine you misinter- preted them. MS-Windows does do multitasking on any machine, which is the primary reason for using it. In fact, I'm using it right now to run CrossTalk XVI to access the net, because I can grab text off of the screen into an editor, modify it, and then send it back to the net as if I were typing it, and also so I can do other things with my computer while I download files. -Brent bak10413@uxa.cso.uiuc.edu
john@newave.UUCP (John A. Weeks III) (05/26/90)
In <10699@medusa.cs.purdue.edu> wjin@cs.purdue.EDU (Woochang Jin) writes: > According to the discussions, windows for 88/86/286 machines cannot do > muti-tasking. Then my question is why use windows if multi-tasking is > impossible ? Anyway you start one job and wait until it is done. Windows (at least 2.x) is multi-tasking. Things can be done in the back-ground when the machine has extra cycles. Some "experts" say windows is not true "pre-emptive" multi-tasking. If this means anything to you, then you might want to investige further. > Maybe you can hold a process like an editor, and do something in other > window, wait util it is finished and get back to the editor. Is this > all reason why they use ms-window ? I find that to be a major asset. Especially for programming. When working on one file, I like to bring up other files in other windows to use as a reference. It is also nice to cut and paste statements to use as a template while programming. > According the discussions, ms-window seems to be icon based like McIntosh. Icons alone do not make a Mac. The Mac philosophy that is burned into thier ROM chips is an entirely different world than DOS or Windows. Some say better, others say worse, but mainly just different. > As old saying, "Seeing is believing" applies to me. But I think that MS will > not return my money I do not like it. Go to any local IBM-PC-ish dealer and play with windows. Egghead Software and Software ETC usually has at least one machine in their stores running windows. Even a quick look at it should give you an idea of how you will like it. -- =============================================================================== John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!rosevax!bungia!wd0gol!newave!john ===============================================================================
bcw@rti.rti.org (Bruce Wright) (05/28/90)
In article <46500092@uxa.cso.uiuc.edu>, bak10413@uxa.cso.uiuc.edu writes: > > /* Written 6:14 am May 24, 1990 by wjin@cs.purdue.EDU in uxa.cso.uiuc.edu:comp.sys.ibm.pc */ > /* ---------- "Why use MS-window ?" ---------- */ > According to the discussions, windows for 88/86/286 machines cannot do > muti-tasking. Then my question is why use windows if multi-tasking is > impossible ? Anyway you start one job and wait until it is done. > Maybe you can hold a process like an editor, and do something in other window, > wait util it is finished and get back to the editor. > Is this all reason why they use ms-window ? > ------ > W. Jin > /* End of text from uxa.cso.uiuc.edu:comp.sys.ibm.pc */ > > I didn't read the discussions to which you refer, but I imagine you misinter- > preted them. MS-Windows does do multitasking on any machine, which is the > primary reason for using it. In fact, I'm using it right now to run > CrossTalk XVI to access the net, [...] > -Brent Brent is right that Windows can do multitasking (on _all_ machines), but reading the previous article I get the impression that Mr. Jin is asking something a bit different (sorry if I misinterpret what's being asked). In Windows for 8086/8088/80286 machines, Windows uses _non-pre-emptive_ multitasking. This means that programs run until they relinquish the CPU. Windows can run (many) ordinary DOS programs in this mode, but if they don't relinquish the CPU then other programs won't get any. Normally, programs written for Windows are pretty careful about not taking over the entire system; programs written for MS-DOS are often not so careful, though these tend to be compute-intensive tasks and not the "typical" PC program (word/text processing, spreadsheet, database, communications, -- or even compilers, though some of them hit the CPU pretty hard from time to time). Programs written for Windows _can_ do significant computation, but must make special system calls to relinquish the CPU every once in a while. If you want a demonstration of this, open up a COMMAND.COM window on Windows (my impression is that on Windows 3.0 this would require running Windows in "real" mode on a 286), and when you get the C> prompt do a DIR on a large directory. Then switch to another window - the directory will continue to be listed in the background while you use the other program. Other ordinary DOS programs can be used similarly, though they may require customization in the .PIF or WIN.INI files. Then try a program that goes into an infinite loop, like: C>debug loop.com -a nnnn:0100 jmp 100 nnnn:0102 -r cx CX 0000 :2 -w -q Try running this program from your COMMAND.COM window or from the Windows MS-DOS Executive (But not when you have anything important running!!). You will now find that Windows is locked up - the mouse pointer will move around the screen but Windows ignores the mouse buttons and the keyboard (actually it sees them but queues the events to programs that never deal with them because they never get the CPU). Windows for 80386 and 80486 machines can do _pre-emptive_ multitasking, so that even misbehaved DOS programs that go into infinite loops or otherwise hog the CPU can't take over the machine. In Windows 3.0 (say the trade rags, my order is in but I haven't seen it yet), the DOS programs can be run in virtual 8086 machines so that even illegal memory references will rarely (if ever) crash the machine. The biggest problem with Windows is that it's slower than running in text mode (although it's not as slow as you might think). If all you're doing is text, and you never need the multitasking features, it may not be for you. But I'd try out the new Windows 3.0 before deciding that - from everything I've seen about it, it sounds like a really nice product. Bruce C. Wright
fordke@ingr.com (Keith Ford x8614) (05/30/90)
in article <404@newave.UUCP>, john@newave.UUCP (John A. Weeks III) says: > > In <10699@medusa.cs.purdue.edu> wjin@cs.purdue.EDU (Woochang Jin) writes: >> According to the discussions, windows for 88/86/286 machines cannot do >> muti-tasking. Then my question is why use windows if multi-tasking is >> impossible ? Anyway you start one job and wait until it is done. > > Windows (at least 2.x) is multi-tasking. Things can be done in the > back-ground when the machine has extra cycles. Some "experts" say > windows is not true "pre-emptive" multi-tasking. If this means anything > to you, then you might want to investige further. As I thought I read in BYTE, the multi-tasking is only available on 386 machines. 286's can only program switch. Is this clarification correct? -- | fordke@ingr.com, ...!uunet!ingr!fordke, sysop@f12.n373.z1.fidonet.org | Micro Magic BBS (1:373/12 - 205/830-2362) IBM/Apple2/Trackstar/Echoes/News | "...and the Trees are all kept equal by hatchet, axe, and saw." -Rush
wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) (05/31/90)
In article <10509@ingr.com> fordke@ingr.com (Keith Ford x8614) writes: > >As I thought I read in BYTE, the multi-tasking is only available on 386 >machines. 286's can only program switch. Is this clarification correct? >-- >| fordke@ingr.com, ...!uunet!ingr!fordke, sysop@f12.n373.z1.fidonet.org >| Micro Magic BBS (1:373/12 - 205/830-2362) IBM/Apple2/Trackstar/Echoes/News >| "...and the Trees are all kept equal by hatchet, axe, and saw." -Rush As usuall BYTE's negative bias towards MSWindows creaps through as errors. MSwindows does multitask on 286s (and if you are patient enough even 8086s). I know, I play Wintris, a form of Tetris that works in Windows, while I down load stuff on my 10MHz clone. MSwindows will even multitask some DOS aps-like command.com. One word of note, MSwindows in the non-386 2.X versions could only "non-pre-emtively" multitask, as well as MSwindows 3.0 in protective or real mode. MS Windows version 386 2.X and the new MS Windows 3.0 in enhanced mode(386s only) can really multitask DOS aps due to the abilities of the 386 chips virtual 8086 modes. "non-pre-emtive mulitasking" is where any single process gets 100% (minus interupts) of the CPU until it gives it up, hence the name meaning not until the process is ready. Most Windows programs 'give other processes a chance to run very often and avoid "hogging the cpu", so as to "multitask". As far as I know with DOS aps running in a window, Windows will automatically switch to other processes when there are bios calls(like printing to the screen or receiving from the keyboard). It is not as bad as it sounds, go to your local software store and try it out-. As far as I'm concerened, non-pre-emptive multitasking is not that bad, if you are working in one window, you generaly want that one to have more of the CPU anyways, and not things like the clock aplication.... but the clock aplication (as well as other neat and useful programs) still continue to work unlike simple task switchers. One last word of caution. You can not run ill-behaved DOS apts in a window and must opt for the task switching full screen option that windows gives you. An ill-behaved Dos aplication is one that writes directly to memory or directly to the screen. (the 386 version of 2.X and MS Windows version 3.0 in enhanced(386) mode do not have this problem!) -Dean Wallwey
fordke@ingr.com (Keith Ford x8614) (05/31/90)
in article <21691@boulder.Colorado.EDU>, wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) says: > In article <10509@ingr.com> fordke@ingr.com (Keith Ford x8614) writes: >>As I thought I read in BYTE, the multi-tasking is only available on 386 >>machines. 286's can only program switch. Is this clarification correct? > As usuall BYTE's negative bias towards MSWindows creaps through as > errors. MSwindows does multitask on 286s (and if you are patient > enough even 8086s). > [stuff deleted] I have received a number of email replies, thanks to all. When I mentioned multi-tasking, I mistakenly assumed readers would assume the "pre-emptive" form where background tasks can use the cpu. This is not available with Windows on a 286, but it is with the 386. PS- There error was mine, and not that of BYTE magazine. Their article was very supportive of Windows. -kef/MM- -- | fordke@ingr.com, ...!uunet!ingr!fordke, sysop@f12.n373.z1.fidonet.org | Micro Magic BBS (1:373/12 - 205/830-2362) IBM/Apple2/Trackstar/Echoes/News | "...and the Trees are all kept equal by hatchet, axe, and saw." -Rush
derekho@microsoft.UUCP (Derek HOIEM) (06/01/90)
In article <10509@ingr.com> fordke@ingr.com (Keith Ford x8614) writes: >in article <404@newave.UUCP>, john@newave.UUCP (John A. Weeks III) says: >> >> In <10699@medusa.cs.purdue.edu> wjin@cs.purdue.EDU (Woochang Jin) writes: >>> According to the discussions, windows for 88/86/286 machines cannot do >>> muti-tasking. Then my question is why use windows if multi-tasking is >>> impossible ? Anyway you start one job and wait until it is done. >> >> Windows (at least 2.x) is multi-tasking. Things can be done in the >> back-ground when the machine has extra cycles. Some "experts" say >> windows is not true "pre-emptive" multi-tasking. If this means anything >> to you, then you might want to investige further. > >As I thought I read in BYTE, the multi-tasking is only available on 386 >machines. 286's can only program switch. Is this clarification correct? >-- >| fordke@ingr.com, ...!uunet!ingr!fordke, sysop@f12.n373.z1.fidonet.org >| Micro Magic BBS (1:373/12 - 205/830-2362) IBM/Apple2/Trackstar/Echoes/News >| "...and the Trees are all kept equal by hatchet, axe, and saw." -Rush Well kind of. Windows does "timeslicing", which appears to be multitasking. Windows timeslices on 286 and 386 machines. Windows basically divides the microprocessor's time into milliseconds which are assigned to each job. Windows 286/Windows 3.0 real mode can timeslice between Windows applications, but cannot for DOS applications. For example, if I was running Crosstalk for Windows in Win 3.0 real mode, I could be working in Excel while Crosstalk diligently downloads a file. Thus, you appear to be multitasking. But if I was running WordPerfect under Win 3.0 real mode, Windows would suspend all jobs and assign all of the processor's time to WordPerfect. Now if I'm using a 386 or 386SX with Windows in protected mode (enhanced), it will timeslice even between DOS applications. For example I could be editing in WordPerfect, recalulating in Lotus 1-2-3, and telecommunicating in Works all at the same time. In actuality, however, Windows is just updating each application every X number of milliseconds. You will notice that each application will be running a little slower than normal. That is because they have to share the processor's time amongst each other. OS/2 is the operating system capable of *real* multitasking. OS/2 has "threads" which are processes that can be happening at the same time. For example, I can be formatting a floppy disk and downloading a file without noticeable system degradation in speed. Pagemaker for OS/2 is a great example of how threads can be utilized for real multitasking.
shim@zip.eecs.umich.edu (Sam Shim) (06/01/90)
In article <54985@microsoft.UUCP> derekho@microsoft.UUCP (Derek HOIEM) writes: >OS/2 is the operating system capable of *real* multitasking. OS/2 has >"threads" which are processes that can be happening at the same time. For >example, I can be formatting a floppy disk and downloading a file without >noticeable system degradation in speed. Pagemaker for OS/2 is a great >example of how threads can be utilized for real multitasking. Huh? Is it true that in a single processor chip, multi-tasking is accomplished by time-slicing since the processor can handle only 1 thing at a time. You might be able to break the time-slices into very small amounts but it is not possible to have a single processor chip do true multi-tasking relative to a multi-processor chip. Sounds like you are taking on the high-level operating system level. I just want to clarify that in the low-level hardware level, OS/2 uses time-slicing to multi-task, as would any single chip computer that multi-tasks. ----------------------------------------------------------------------------- | Sam Shim | "I didn't do it... | | EECS Departmental Computing Organization | It wasn't me... | | University of Michigan | Nobody saw me do it... | | Ann Arbor, MI 48109 | Nobody can prove a thing..." | | internet: shim@eecs.umich.edu | - Bart Simpson | -----------------------------------------------------------------------------
nelson_p@apollo.HP.COM (Peter Nelson) (06/01/90)
From: derekho@microsoft.UUCP (Derek HOIEM) >Now if I'm using a 386 or 386SX with Windows in protected mode (enhanced), >it will timeslice even between DOS applications. For example I could be >editing in WordPerfect, recalulating in Lotus 1-2-3, and telecommunicating in >Works all at the same time. In actuality, however, Windows is just updating >each application every X number of milliseconds. You will notice that each >application will be running a little slower than normal. That is because >they have to share the processor's time amongst each other. Great. Could you, or someone, please explain something to me? How do programs like Desqview or Windows 3.0 run communications programs in background? I know they do it. I have Desqview and I can download files in background just fine while I'm running DTP software in foreground. Microsoft claims that they can do it in Windows 3.0, too. Don't say they just make the time slices Real Thin or something; that doesn't work. In Windows 3.0 the foreground task is guaranteed 50% of the CPU. In Desqview the minimum time-slice is an 18th of a second and they recommend using bigger chunks than that. But even an 18th of a second at 1200 baud is enough time to drop 7 characters. So how do they do it? I've always wondered about this. (Assume a 386SX with 4 meg of RAM running Windows 3.0 in enhanced mode if that helps.) Thanks in advance. ---Peter
altman@sbstaff2.cs.sunysb.edu (Jeff Altman) (06/01/90)
One way to allow communication packages to run in background to perform file transfers is to not actually let the applications receive the interrupts from the UART. What you do is capture the interrupts and then when the Comm Package is given its chance to use the CPU re-echo the interrupts to the Comm Package, thereby making it think that it is actually receiving the characters when they were received. I'm not sure if this is how it is done, somebody please correct me if I am wrong. I should mention however that Win 3.0 does not multitask DOS Apps well enoungh on a 16 MHz 386sx machine with 4MB to allow MS-Kermit to download files in background. Data transfers are aborted. But this might be caused by the Kermit Protocols requirement that once a packet is started to be received there can not be any pauses in the receipt of the packet of more than 1 sec. Whereas, Windows based communication packages such as Crosstalk for Windows do a wonderful job of performing file transfers in background. - Jeff (jaltman@ccmail.sunysb.edu)
pwong@batcomputer.tn.cornell.edu (Patrick Wong) (06/01/90)
In article <3867@rtifs1.UUCP> bcw@rti.rti.org (Bruce Wright) writes: > >In Windows for 8086/8088/80286 machines, Windows uses _non-pre-emptive_ >multitasking. This means that programs run until they relinquish the >CPU. Windows can run (many) ordinary DOS programs in this mode, but >if they don't relinquish the CPU then other programs won't get any. > > Bruce C. Wright By the way, you've got me interested ! So (pardon my ignorance) which version of Windows will work for a 8086/8088 compatibles ? Is it the one called Windows 286, or is it some older and no-longer-available version ? Thanks in advance ! Patrick Wong pcw@squid.graphics.cornell.edu
nelson_p@apollo.HP.COM (Peter Nelson) (06/01/90)
I got lots of interesting answers to my question of how DOS multitaskers handle communications programs running in the background. From: shim@zip.eecs.umich.edu (Sam Shim) >Multitasking programs can download in the background without losing characters >because the UART chip has a buffer (the size depends on the chip). Just give >the comm program enough time and it will be able to fetch the data off the >buffer before it overflows. I'm skeptical because too many UART chips (f'rinstance the venerable but popular Intel 8251) don't have very big buffers. The 8251 holds *1* character, many others hold *4* characters. But at 4800 baud in two ticks of the Desqview clock (the minimum they recommend using) you can receive 26 characters. Yet Desqview claims that they can successfully run *multiple* comms programs in the background at 9600 baud! Of course it's possible the hardware has improved a lot recently and the UARTs currently in use have deep buffers. Does anyone know what some typical UARTS for PC's are and how deep their buffers are? Also what about chipsets used to implement MNP on modern modem boards? Since they do data-compression they *have* to do some considerable buffering. Anybody know anything about these? From: altman@sbstaff2.cs.sunysb.edu (Jeff Altman) >One way to allow communication packages to run in background >to perform file transfers is to not actually let the applications >receive the interrupts from the UART. What you do is capture >the interrupts and then when the Comm Package is given its chance >to use the CPU re-echo the interrupts to the Comm Package, thereby >making it think that it is actually receiving the characters when >they were received. I didn't get this at all. What IS handling the characters before the Comm package gets it's chance? They have to get processed and buffered *somewhere*. ...And from my mailbag (anonymous) simply sez... > Hardware interrupt. Yeah, but if the comms program is not mapped in to the virtual 8086 machine's address space because someone else is the "current" owner of the machine, then how does the multitasker assure that the comms program gets to handle the interrupt? Does it remap memory every tine an interrupt comes in on that port? ------------------------------------------------------------------------- This is like the old "how many different ways can you use a barometer to measure the height of a building?" Sure, there are lots of ways you *could* do it. But I'm not giving points for creativity. Does anyone out there know how it REALLY works? Is there a better newsgroup for this question? This question does have practical significance because if indeed there is a hardware approach (UART-buffering) then if you are having problems with background comms programs you could consider using a different UART or modem chip set that has a deeper FIFO which, given the relatively low cost of moidems and serial ports these days, might be a reasonable choice. On the other hand, if it's done "in software", this would be a waste of money. ---Peter
kshaffer@modcomp.UUCP (06/01/90)
> How do programs like Desqview or Windows 3.0 run communications > programs in background? > Don't say they just make the time slices Real Thin or something; > that doesn't work. In Windows 3.0 the foreground task is guaranteed > 50% of the CPU. In Desqview the minimum time-slice is an 18th > of a second and they recommend using bigger chunks than that. > But even an 18th of a second at 1200 baud is enough time to > drop 7 characters. So how do they do it? INTERRUPTS! You program the com chip and enable interrupts. On receive, When you get a character, stuff in a big enough (256 bytes) circular receive buffer. On transmit, take characters out of the transmit buffer and send down the line. Meanwhile when the communications program gets its time slice, the bytes are put in/gotten out of the appropriate buffers. Ken
bdlepla@caen.engin.umich.edu (Bryan Dennis Lepla) (06/02/90)
In article <54985@microsoft.UUCP>, derekho@microsoft.UUCP (Derek HOIEM) writes: > In article <10509@ingr.com> fordke@ingr.com (Keith Ford x8614) writes: > >in article <404@newave.UUCP>, john@newave.UUCP (John A. Weeks III) says: > >> > >> In <10699@medusa.cs.purdue.edu> wjin@cs.purdue.EDU (Woochang Jin) writes: > >>> According to the discussions, windows for 88/86/286 machines cannot do > >>> muti-tasking. Then my question is why use windows if multi-tasking is > >>> impossible ? Anyway you start one job and wait until it is done. > >> > >> Windows (at least 2.x) is multi-tasking. Things can be done in the > >> back-ground when the machine has extra cycles. Some "experts" say > >> windows is not true "pre-emptive" multi-tasking. If this means anything > >> to you, then you might want to investige further. > > > >As I thought I read in BYTE, the multi-tasking is only available on 386 > >machines. 286's can only program switch. Is this clarification correct? > >-- > >| fordke@ingr.com, ...!uunet!ingr!fordke, sysop@f12.n373.z1.fidonet.org > >| Micro Magic BBS (1:373/12 - 205/830-2362) IBM/Apple2/Trackstar/Echoes/News > >| "...and the Trees are all kept equal by hatchet, axe, and saw." -Rush > > Well kind of. Windows does "timeslicing", which appears to be multitasking. > Windows timeslices on 286 and 386 machines. Windows basically divides the > microprocessor's time into milliseconds which are assigned to each job. > Windows 286/Windows 3.0 real mode can timeslice between Windows applications, > but cannot for DOS applications. For example, if I was running Crosstalk > for Windows in Win 3.0 real mode, I could be working in Excel while Crosstalk > diligently downloads a file. Thus, you appear to be multitasking. But if > I was running WordPerfect under Win 3.0 real mode, Windows would suspend > all jobs and assign all of the processor's time to WordPerfect. > > Now if I'm using a 386 or 386SX with Windows in protected mode (enhanced), > it will timeslice even between DOS applications. For example I could be > editing in WordPerfect, recalulating in Lotus 1-2-3, and telecommunicating in > Works all at the same time. In actuality, however, Windows is just updating > each application every X number of milliseconds. You will notice that each > application will be running a little slower than normal. That is because > they have to share the processor's time amongst each other. > > OS/2 is the operating system capable of *real* multitasking. OS/2 has > "threads" which are processes that can be happening at the same time. For > example, I can be formatting a floppy disk and downloading a file without > noticeable system degradation in speed. Pagemaker for OS/2 is a great > example of how threads can be utilized for real multitasking. OS/2's *real* multitasking is no different than windows 3.0 in the enhanced mode. OS/2's threads also use timeslices. There is no possible way for the threads to *happen* at the same time on a one cpu machine.
bdlepla@caen.engin.umich.edu (Bryan Dennis Lepla) (06/02/90)
In article <10343@batcomputer.tn.cornell.edu>, pwong@batcomputer.tn.cornell.edu (Patrick Wong) writes: > In article <3867@rtifs1.UUCP> bcw@rti.rti.org (Bruce Wright) writes: > > > >In Windows for 8086/8088/80286 machines, Windows uses _non-pre-emptive_ > >multitasking. This means that programs run until they relinquish the > >CPU. Windows can run (many) ordinary DOS programs in this mode, but > >if they don't relinquish the CPU then other programs won't get any. > > > > Bruce C. Wright > > By the way, you've got me interested ! So (pardon my ignorance) which > version of Windows will work for a 8086/8088 compatibles ? Is it the > one called Windows 286, or is it some older and no-longer-available > version ? > > Thanks in advance ! > > Patrick Wong > > pcw@squid.graphics.cornell.edu The new windows 3.0 will run on all ibm compatibles, from the 8086 to the 80?86. If it is on a 8088/8086 then windows will start up in the real mode. It will start up in protected and enhanced modes depending on 286 or 386 and how much memory you have. Please correct me if I'm wrong. Check out PC Weeks dedicated section to windows 3.0 that came out a couple weeks back.
pnl@hpfinote.HP.COM (Peter Lim) (06/03/90)
Hi Peter, > Don't say they just make the time slices Real Thin or something; > that doesn't work. In Windows 3.0 the foreground task is guaranteed > 50% of the CPU. In Desqview the minimum time-slice is an 18th > of a second and they recommend using bigger chunks than that. > But even an 18th of a second at 1200 baud is enough time to > drop 7 characters. So how do they do it? I've always wondered > about this. (Assume a 386SX with 4 meg of RAM running Windows > 3.0 in enhanced mode if that helps.) > I think this has something to do with INTERRUPT. When data is knocking at the door of the incoming serial port, the serial port generates an interrupt which is captured by the communication software sitting in the background. That is why you must not allow the communication software code to be swapped out when it goes into the background. This has nothing to do with time-slicing which goes around distributing CPU power to process not propelled by interrupts. For a little bit more details, on UART system which has FIFO, you can set the interrupt to occur when the FIFO is filled to certain level instead of interrupting whenever a character arrive at the serial port. That is why, smarter comm cards with chips like 16550 imposed much less CPU overhead than dumb card like those with 8250 (did I get the number correct ?). Of course your comm software has to be aware of the FIFO feature in the smart comm card, or else, it will go to waste. It is the combination of interrupts and time-slicing that make these multi-tasking systems tick. Another 2 cents to the net. > Thanks in advance. > You are welcome :-). Regards, ## Life is fast enough as it is ........ Peter Lim. ## .... DON'T PUSH IT !! >>>-------, ########################################### : E-mail: plim@hpsgwg.HP.COM Snail-mail: Hewlett Packard Singapore, : Tel: (065)-279-2289 (ICDS, ICS) | Telnet: 520-2289 1150 Depot Road, __\@/__ ... also at: pnl@hpfipnl.HP.COM Singapore 0410. SPLAT !
poffen@sj.ate.slb.com (Russ Poffenberger) (06/04/90)
In article <54985@microsoft.UUCP> derekho@microsoft.UUCP (Derek HOIEM) writes: >In article <10509@ingr.com> fordke@ingr.com (Keith Ford x8614) writes: > >Well kind of. Windows does "timeslicing", which appears to be multitasking. >Windows timeslices on 286 and 386 machines. Windows basically divides the >microprocessor's time into milliseconds which are assigned to each job. [stuff deleted] >Now if I'm using a 386 or 386SX with Windows in protected mode (enhanced), >it will timeslice even between DOS applications. For example I could be >editing in WordPerfect, recalulating in Lotus 1-2-3, and telecommunicating in >Works all at the same time. In actuality, however, Windows is just updating >each application every X number of milliseconds. You will notice that each >application will be running a little slower than normal. That is because >they have to share the processor's time amongst each other. > >OS/2 is the operating system capable of *real* multitasking. OS/2 has >"threads" which are processes that can be happening at the same time. For >example, I can be formatting a floppy disk and downloading a file without >noticeable system degradation in speed. Pagemaker for OS/2 is a great >example of how threads can be utilized for real multitasking. Whoa! hold on here! Unless you have a seperate processor for each process, there is still going to be degradation when more than one task is running. As long as there is only one CPU to do all the work, then multiple tasks will each run slower than they would if they were run by themselves. Plain and simple, no ifs, ands, or buts. A good multitasking OS can reduce the overhead of multitasking since it was desgined to do that, as opposed to a more band-aid approach like windows takes, but the performance hit is still there. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) (06/05/90)
In article <1990Jun4.144158.22800@sj.ate.slb.com> poffen@sj.ate.slb.com (Russ Poffenberger) writes: >Whoa! hold on here! Unless you have a seperate processor for each process, >there is still going to be degradation when more than one task is running. >As long as there is only one CPU to do all the work, then multiple tasks will >each run slower than they would if they were run by themselves. > >Plain and simple, no ifs, ands, or buts. > >A good multitasking OS can reduce the overhead of multitasking since it was >desgined to do that, as opposed to a more band-aid approach like windows >takes, but the performance hit is still there. > > >Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com >Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen >1601 Technology Drive CIS: 72401,276 >San Jose, Ca. 95110 (408)437-5254 There is not neccessarily a large hit at all if the OS is designed right. The previous example about pagemaker is very good. Granted a proccessor can only do x amount in x time but how you distribute that HIT (example-printing) is very important. In PageMaker for OS/2, when you print something, it creates a low priority thread to do it. That way you can go on doing your work as usuall. While the computer is waiting for you to type more, it can be 'printing' in the background, but at soon as you hit a key, the main pagemaker thread comes into action. After a couple of (relatively) 100s instructions when the kerstroke is proccessed, page maker can return back to the print thread which requires (relatively) 100s of thousands of instructions. The small time required to proccess the keystroke is practically nill in light of how much work must be done to printout a page. So your page takes an aditional 3 seconds to printout--almost nothing in light of how long it takes to print out Pagemaker docs. On the other hand if it takes 1/2 second after every keystroke to get a responce, you can obviously see the degration. This is what makes OS/2 so great and Windows so bad! Even though in theory there is the same amount of degration on both, for practical purposes there is no degration of OS/2 in certain cases. EACH TASK DOES NOT RUN SLOWER, ONLY SOME DO, when you increase the number of tasks! To find out more on the subject, see Charles Petzold's article in one of the latest PC Magazines. (This is actually where I got the Pagemaker example!) -Dean Wallwey
poffen@sj.ate.slb.com (Russ Poffenberger) (06/05/90)
In article <21855@boulder.Colorado.EDU> wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) writes: > >There is not neccessarily a large hit at all if the OS is designed right. >The previous example about pagemaker is very good. Granted a proccessor can >only do x amount in x time but how you distribute that HIT (example-printing) >is very important. In >PageMaker for OS/2, when you print something, it creates a low priority >thread to do it. That way you can go on doing your work as usuall. >While the computer is waiting for you to type more, it can be 'printing' >in the background, but at soon as you hit a key, the main pagemaker >thread comes into action. After a couple of (relatively) 100s >instructions when the kerstroke is proccessed, page maker can return >back to the print thread which requires (relatively) 100s of thousands >of instructions. The small time required to proccess the keystroke is >practically nill in light of how much work must be done to printout a >page. So your page takes an aditional 3 seconds to printout--almost nothing >in light of how long it takes to print out Pagemaker docs. On the other >hand if it takes 1/2 second after every keystroke to get a responce, you >can obviously see the degration. This is what makes OS/2 so great and >Windows so bad! Even though in theory there is the same amount of >degration on both, for practical purposes there is no degration of OS/2 >in certain cases. EACH TASK DOES NOT RUN SLOWER, ONLY SOME DO, when you >increase the number of tasks! To find out more on the subject, see >Charles Petzold's article in one of the latest PC Magazines. >(This is actually where I got the Pagemaker example!) > > -Dean Wallwey True, the amount of degradation depends entirely on the mix of applications. I was stating that the original post was erroneous in the general sense. When I think of multitasking, I think of multiple compiles and other CPU/DISK/IO intensive things (that is what I do all day on my Sun 4/370). When running multiple tasks of this nature, each task will DEFINITELY take longer than if run alone, however the total time taken is almost always less than the sum of the two runs separately. This is what makes a true multitasking OS preferable. Now I wish I could get a good BSD Unix for my PC. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
joel@techunix.BITNET (Yossi (Joel) Hoffman) (06/06/90)
In article <9609@sbcs.sunysb.edu> altman@sbstaff2.cs.sunysb.edu (Jeff Altman) wr ites: >I should mention however that Win 3.0 does not multitask DOS Apps >well enoungh on a 16 MHz 386sx machine with 4MB to allow MS-Kermit >to download files in background. Data transfers are aborted. >But this might be caused by the Kermit Protocols requirement that >once a packet is started to be received there can not be any pauses >in the receipt of the packet of more than 1 sec. > Anyone know if the PC Unix packages that have DOS windows will let Kermit run? I find it hard to believe that Kermit won't run under a Unix DOS window, but Unix is always time-slicing many processes. -Joel --
pelegrin@geocub.greco-prog.fr (06/07/90)
In article <21855@boulder.Colorado.EDU> wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) writes: >In article <1990Jun4.144158.22800@sj.ate.slb.com> poffen@sj.ate.slb.com (Russ Poffenberger) writes: >>Whoa! hold on here! Unless you have a seperate processor for each process, >>there is still going to be degradation when more than one task is running. >>As long as there is only one CPU to do all the work, then multiple tasks will >>each run slower than they would if they were run by themselves. [...] >>Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com >>Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen >There is not neccessarily a large hit at all if the OS is designed right. >The previous example about pagemaker is very good. Granted a proccessor can >only do x amount in x time but how you distribute that HIT (example-printing) >is very important. [...Stuff deleted, saying that in OS/2 PageMaker, there was ALMOST no noticeable effect of multitaskink on each process speed ...] This is what makes OS/2 so great and >Windows so bad! Even though in theory there is the same amount of >degration on both, for practical purposes there is no degration of OS/2 >in certain cases. EACH TASK DOES NOT RUN SLOWER, ONLY SOME DO, when you ^^^^^^^^^^^^^^^^ Ha-ha ! So your previous discussion leaded to nothing. 9-) >increase the number of tasks! > -Dean Wallwey You are leading the discussion to a different subject : you take, to measure process speed, your human perception : in the PageMaker case, since you type at a rate of, say, 4 chars per second, you can not notice any degradation since by the time you have pressed a key, the program has already finished the processing of your previous key, and IS WAITING FOR YOU. This extra time acts like a kind of buffer and prevents you from noticing anything... Now, run brute strength tasks, and you'll feel that Russ' arguments are perfectly true. f.p. ------------------------------------------------------------------------------- | Zeu<FP> : The craziest programmer in France | _________ | |------------------------------------------------| / | \ \ | | Francois Pellegrini is : | / |__ ___/ \ | | goofi!pelegrin@geocub.greco-prog.fr | \ | | / | | mcsun!inria!geocub!goofi!pelegrin@uunet.uu.net | \ | | / | | goofi!pelegrin@geocub.UUCP | | -------------------------------------------------------------------------------
poffen@sj.ate.slb.com (Russ Poffenberger) (06/08/90)
In article <10343@batcomputer.tn.cornell.edu> pwong@tcgould.tn.cornell.edu (Patrick Wong) writes: >In article <3867@rtifs1.UUCP> bcw@rti.rti.org (Bruce Wright) writes: >> >>In Windows for 8086/8088/80286 machines, Windows uses _non-pre-emptive_ >>multitasking. This means that programs run until they relinquish the >>CPU. Windows can run (many) ordinary DOS programs in this mode, but >>if they don't relinquish the CPU then other programs won't get any. >> >> Bruce C. Wright > >By the way, you've got me interested ! So (pardon my ignorance) which >version of Windows will work for a 8086/8088 compatibles ? Is it the >one called Windows 286, or is it some older and no-longer-available >version ? > Windows 3.0 has three modes, real, standard, and 386 enhanced. Real mode will run on any CPU type, however with limitations. It can sortof multitask between windows applications (not DOS applications). You are limited to 640K plus expanded memory. Standard mode runs only on 286/386 CPU's. It can take advantage of up to 16Mb of extended memory, and run windows 3.0 applications in extended memory. 386 enhanced mode is preferred because it utilizes the virtual memory mode of the 386 CPU's. It can multitask between DOS applications. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
brand@janus.Berkeley.EDU (Graham Brand) (06/09/90)
Will existing applications programs run under Windows 3.0 or would I have to upgrade the myriad of programs that I have? Cheers, -Graham Brand (brand@janus.berkeley.edu)