Jihad needs scientists
in [Design]
|
From: Ken Smith on 16 Feb 2007 10:18 In article <er47qv$8qk_001(a)s897.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: [.....] >>NT was written in the first place for a processor that didn't do >>interrupts well. > >Nuts. If the hardware doesn't do it, then you can make the software >do it. As TW used to say, "A small matter of programming". On the N10 there was no way to code around it. The hardware was designed so that it had to walk to the breakroom and back before it picked up the phone. Nothing you could say over the phone would help. >> The N10 AKA 860 processor had to spill its entire >>pipeline when interrupted. This slowed things down a lot when the code >>involved interrupts. When the project was moved back to the X86 world, it >>was marketed as secure ... well sort of .... well kind of .... its better >>than 98. I don't think a lot of time was spent on improving the interrupt >>performance. > >You are confusing delivery of computing services by software with >delivery of computing services of hardware. No, hardware sets the upper limit on what software can do. If you wrote code for a machine that had no interrupts at all, you would have to poll the I/O ports. There is nothing you could do about it on that machine. If once you are done, management tells you to now port onto a machine that does interrupts, without a lot of recoding, the polling will stay. This is the sort of thing that happened in NT's development. It was written for the N10 and then ported. >>>I was talking about simple things like being able to print a file, >>>download yesterday's newsgroups posts, build an EXE while the PC >>>user played a session of Pong! while waiting for everything to >>>finish. This all should have happened on one machine without >>>interfering with each other. >> >>Linux does ok at this. > >Of course it does. However, no Unix is "PC-user friendly". I'm >trying to work on this problem but I've been getting side-tracked. Sure it is "user friendly". Take a look at SuSE10 with KDE. It is more user friendly than Windows by a long shot. > >> Right now I also have LTSpice running on another >>desktop. I'm typing this while if figures. > >My point is that you should not have to have another computer _system_ >to do any other task. "Another desktop" in this case refers to the same machine. I have 4 little boxes at the bottom of my screen. If I click in one it switches me to that "desk top". [.....] >a task requires [what we used to call] real-time computing. Other >than instrumentation, there usually isn't any computing task that >has to have the CPU pay attention to it *right now*. GUI stuff needs to respond modestly quickly also. A 0.25 second delay is trouble. Most of what I do with computers needs it to respond quickly. >>>For some strange reason, MS products can't chew gum and salivate >>>at the same time; it appears that they think this is a feature. >> >>The DOS mind set was to only do one thing at a time. > >That is OK but it should never display the monitor prompt until >it's done with each task. You do not lie to your user! EVER!!!! In a multitasking situation, you often tell a little white lie. When I write to a file, the OS acts as though the job is done before the physical write happens. So long as the power stays on, there is no way the user will ever see any effects from this. The physical write happens a little later in the back ground. If you open the same file for reading, the OS gets the data that it was planning on writing and gives it to you at the right time. You can't tell that the file isn't total on the disk yet. >>Some bits of later >>versions looked like multitasking was intended but abandoned. Even very >>later versions save registers into code space instead of onto the stack. > >That [saving regs in core] has nothing to do with anything. Saving registers into code space makes it near imposible to do multitasking and is in general very bad coding practice. > Their >problem was never understanding how to do memory management MS-DOS's memory management was about right. It was limited to the size of memory an 8086 could address but it was obviously thought through. It had the code for the automatic freeing of memory when a program aborted and all that stuff. They should have made the allocation headers a linked list from the PSP[1] but give the amount of memory having to walk the whole chain was no big problem. Windows on the other foot didn't. This is part of why windows had such memory leak problems. [1] Under DOS the Program Segment Prefix was a block of memory just below the loaded program that kept track of stuff. When you allocated memory, 16 bytes before the pointer you go back was used to store information about that allocation. -- -- kensmith(a)rahul.net forging knowledge
From: Rich Grise, Plainclothes Hippie on 16 Feb 2007 16:21 On Fri, 16 Feb 2007 12:49:30 +0000, jmfbahciv wrote: > "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: .... >>As usual, you redefine the discussion to suit yourself. > > I don't think he is redefining it; I think he believes he's talking about > the same thing. He keeps reminding me of the last tech I had to finally > resort to beating up in order to get him to understand what was going to > happen. I don't think that guy knows to this day why his way was the > exactly wrong way. > Yes, sadly most people would rather be right than happy. Cheers! Rich
From: nonsense on 16 Feb 2007 18:18 Rich Grise, Plainclothes Hippie wrote: > On Fri, 16 Feb 2007 12:49:30 +0000, jmfbahciv wrote: > >> "nonsense(a)unsettled.com" <nonsense(a)unsettled.com> wrote: > > ... > >>>As usual, you redefine the discussion to suit yourself. >> >>I don't think he is redefining it; I think he believes he's talking about >>the same thing. He keeps reminding me of the last tech I had to finally >>resort to beating up in order to get him to understand what was going to >>happen. I don't think that guy knows to this day why his way was the >>exactly wrong way. >> > > > Yes, sadly most people would rather be right than happy. To hold those two concepts as mutually exclusive is, to coin a phrase, strange.
From: MassiveProng on 16 Feb 2007 19:04 On 16 Feb 2007 11:29:32 GMT, jasen <jasen(a)free.net.nz> Gave us: >On 2007-02-16, Ken Smith <kensmith(a)green.rahul.net> wrote: >> In article <be273$45d50d69$49ecf9d$20196(a)DIALUPUSA.NET>, >> nonsense(a)unsettled.com <nonsense(a)unsettled.com> wrote: >> [.....] >>>None of the has anything to do with the OS biz. >> >> >> We just had another wonderful experience with XP. Characters pumped into >> the serial port may take up to 5 seconds before a DOS application running >> under XP gets to see them. Most of them eventually come through. >> >> Tomorrow, we may try it with "dosemu" to see how well that works. > >with the right serial driver it should work well, people were running serial >games in dosemu, dunno all the tricks they employed. > His problem is likely that he hasn't set up the serial port correctly. I get regular 115kb/s feeds at the port level, and there is no delay. He pr5obably has it set to software control instead of hardware. This is what happens when someone guesses at what is needed, and then subsequently assumes it to be correct, and then blames all issues being encountered on the base level OS, when it is really the fault of the base level brain doing the tasks.
From: MassiveProng on 16 Feb 2007 19:08
On 16 Feb 2007 11:45:57 GMT, jasen <jasen(a)free.net.nz> Gave us: >On 2007-02-15, Ken Smith <kensmith(a)green.rahul.net> wrote: > >> The DOS mind set was to only do one thing at a time. Some bits of later >> versions looked like multitasking was intended but abandoned. Even very >> later versions save registers into code space instead of onto the stack. > >I read that there was a multitasking dos released by Microsoft in >Europe. and then there's Deskview and I think Digital Research had >a go at multitasking dos too. > >I played with something called multidos (I think it) was shareware or >freeware and faked multitasking somehow. > > DesqView was a task switcher. One app at a time. DesqViewX was a true multitasking system that ran under DOS with a memory manager. It was also an x server and could run distributed processes on another machine running DesqViewX and TCP/IP had to be the protocol. DR didn't do any multithreaded OS. OS/2 was a true multi-threaded, multitasking OS, despite coming out back when all we had were 386s and 486s. |