From: jmfbahciv on
In article <er7am7$ijh$1(a)blue.rahul.net>,
kensmith(a)green.rahul.net (Ken Smith) wrote:
>In article <er734o$8qk_001(a)s994.apx1.sbo.ma.dialup.rcn.com>,
> <jmfbahciv(a)aol.com> wrote:
>>In article <er4g1l$1ln$5(a)blue.rahul.net>,
>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>In article <er49e9$8qk_004(a)s897.apx1.sbo.ma.dialup.rcn.com>,
>>> <jmfbahciv(a)aol.com> wrote:
>>>>In article <er33t7$8jq$1(a)blue.rahul.net>,
>>>> kensmith(a)green.rahul.net (Ken Smith) 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.
>>>>
>>>>I would expect that. Why aren't you expecting that?
>>>>
>>>>> Most of them eventually come through.
>>>>>
>>>>>Tomorrow, we may try it with "dosemu" to see how well that works.
>>>>
>>>><shrug> Change the threshold number that causes the DOS emulator
>>>>to hand over bits. There's gotta be one.
>>>
>>>I believe that neither XP nor dosemu use a threshold.
>>
>>It has to have a threshold (we may be using this term differently).
>
>If you include one as a threshold then yes, but I don't generally consider
>that as a case of a threshold. A UART generally makes an interrupt upon
>receiving the first character. The built in FIFO is to give the OS
>enough time to service the interrupt.
>
>When coding your own DOS serial handler, you usually can turn off the FIFO
>in the UART and have the software continue to work normally. The
>exception is in some laptops where for some silly reason there is code
>that turns the interrupts off while it fiddles with the LCD.

Oh, bletcheroo. Some days you need an interrupt for the interrupt handler.
My guys struggled with hardware guys quite a bit. It was
a huge breakthrough when the hardware designers began to use
computers for their work.
>
>
>>> The delay under XP
>>>appears more random.
>>
>>It's not random (from the gut feels I'm getting from your description).
>
>I is likely it is not really random. The rule isn't "every N characters"
>or "every n milliseconds" as far as I can see. It is likely based on a
>combination of numbers of milliseconds.

Nope. I don't see it as that. It sounds a lot like a memory
spillover. The reason you don't see it right away is because
the spilling didn't destroy code that you needed to use until
later. It is your usage that is the random factor, not the
bug.

Again, this is all from what you've written here. I can
be completely wrong.

>
>
>>> Chances are the timing under XP runs the DOS stuff
>>>at a priority level equal to other tasks. There is some task between the
>>>DOS stuff and the hardware that runs at some other time and priority.
>>
>>>
>>>I believe that under dosemu, the serial stream gets checked every time the
>>>emulator needs to pretend to access a serial port.
>>
>>Here's my guesstimate about what may be happening. Note that
>>I have not read the sources nor have I watched the failure happen...
>>
>>You start things up. The serial starts dumping bits into a
>>memory buffer on your machine. From your specs, it is a slow
>>filler. So there has to be some kind of mechanism that
>>allows the buffer filler and buffer reader to not get ahead
>>of the other (depending on which way the bits are moving).
>
>The FIFO inside the UART is 16 bytes long. The next FIFO action is done
>by some OS code. Eventually 99,999 of every 100,000 characters do make it
>to the end application. We are not talking about a case where the bulk of
>the data is lost. The problem is that the OS is sticking a delay in the
>characters getting to the application of up to 5 seconds.

But 5 second is a millenium in computing lifetime terms. Are you sure
it doesn't start over from the beginning? That would explain that
humungous 5 seconds.

>
>[.....]
>>I'd try to make the buffer filler's buffer size smaller
>>than the buffer reader's buffer size.
>
>We don't really have any options on adjusting stuff. This is an XP system
>you have to write a bunch of windows code if you want to be able to change
>anything about how serial ports work.

There isn't a twiggle deep in the dark ruts of menus? There has
to be. The guys who write that stuff would include those kinds
of toggles.

/BAH
From: jmfbahciv on
In article <gtfet2pm27tpil33cdu0io3gn25l6kvf8l(a)4ax.com>,
MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote:
>On Sat, 17 Feb 07 12:26:44 GMT, jmfbahciv(a)aol.com Gave us:
>
>>In article <t3jct2h2m7upjn9dho5vsppe4hb02ukvib(a)4ax.com>,
>> MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote:
>>>On Fri, 16 Feb 07 14:07:30 GMT, jmfbahciv(a)aol.com Gave us:
>>>
>>>>
>>>>There is a huge difference between tasking and being able to
>>>>interrupt any task at any time and resuming it seamlessly
>>>>later and not being able to start another task until the
>>>>previous one is completely finished including EOFing the
>>>>files.
>>>
>>>
>>> Batch process mentality bullshit.
>>
>>Quite the contrary. Your style of thinking is single-use
>>concentration of gear. That has been clear since you tried
>>to correct your elders.
>>
>
> The only thing about your that even comes close to being elder is
>your resemblance to a dried turd.
>
> Aged, yes. An "elder"... not in any way, shape, or form.

I wasn't talking about me; although it wouldn't hurt you at all
to learn what I know.

/BAH
From: jmfbahciv on
In article <er7av0$ijh$2(a)blue.rahul.net>,
kensmith(a)green.rahul.net (Ken Smith) wrote:
>In article <er6s31$8ss_006(a)s994.apx1.sbo.ma.dialup.rcn.com>,
> <jmfbahciv(a)aol.com> wrote:
>[.....]
>>When Linux can be installed and used with very little relearning
>>by any computer owner, then it will cease to be a toy and become
>>a general purpose tool. It hasn't reached that maturity..yet.
>>It is getting there rapidly.
>
>
>That is the case today. The average computer owner sends email, recieves
>spam, surfs the web and plays Minesweeper.

Then you have not been keeping up with what is going on in the
real world. Clear your windows and take another look.

> You get all that in many
>installs today. All the user has to do is answer yes to installing the
>software.

Youare a decade behind.

/BAH

From: jmfbahciv on
In article <3ofet2p13f44cg4im5u5719bvqltcig4df(a)4ax.com>,
MassiveProng <MassiveProng(a)thebarattheendoftheuniverse.org> wrote:
>On Sat, 17 Feb 07 12:22:57 GMT, jmfbahciv(a)aol.com Gave us:
>
>>When Linux can be installed and used with very little relearning
>>by any computer owner, then it will cease to be a toy and become
>>a general purpose tool. It hasn't reached that maturity..yet.
>>It is getting there rapidly.
>
>
> You're an idiot. I can boot Linux from a DVD and RUN it all day
>long, and I don't need to do ANY installation!

That is only the first step of using the OS. There are at least
a thousand more things that have to be done to adapt a human's
computing to it.


>
> I'd say that that is mile above the rest when the entire OS can be
>configured at runtime from an autodetection routine.

This isn't new.
>
> I'd also say that that pretty much makes you an uninformed bullshit
>artist, at best.

I'm very good at turning bullshit into something useful.

/BAH
From: jmfbahciv on
In article <er7blr$ijh$4(a)blue.rahul.net>,
kensmith(a)green.rahul.net (Ken Smith) wrote:
>In article <er6sft$8ss_009(a)s994.apx1.sbo.ma.dialup.rcn.com>,
> <jmfbahciv(a)aol.com> wrote:
>>In article <er4gcr$1ln$6(a)blue.rahul.net>,
>> kensmith(a)green.rahul.net (Ken Smith) wrote:
>>>In article <er45hl$pkf$1(a)jasen.is-a-geek.org>,
>>>jasen <jasen(a)free.net.nz> wrote:
>>>>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.
>>>
>>>If you call two tasks "multi",
>>
>>I don't :-).
>
>I could do 3 too.
>
>It just takes a little more coding.

My point is that it should not take more coding to add and/or
subtract. To have to do coding in order to add one is a crock.
None of our old customers would have accepted this. We certainly
did not have the resources to code every time we needed to run
an extra task.

>
>>
>>> I wrote one that worked quite nicely. It
>>>allowed the user interface task to run while disk I/O and printing etc
>>>also ran. It was very special purposed so it wouldn't be something to
>>>market.
>>>
>>>It really isn't that hard to create a multitasking system if only one task
>>>is allowed to touch a given bit of hardware. Mostly you just have to
>>>change the stack pointer and return from the timer interrupt into the
>>>other task's context.
>>
>>You have a very big IF in that sentence. ;-)
>
>Yes, but the two tasker served its purpose quite nicely. I created only
>the tool I needed for the purpose not a general OS.

Sure. I understand what you did. :-) Now think about all the
different kinds of hardware, formats, software, etc. and the
fact that each person's individual system are all different from
any other system in the world, past and future.

You can't force everybody to code every time they want to do
something extra.

/BAH