Re: OT: Yet Another Unhappy Customer for Vista

On Jun 11, 4:18 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Mon, 11 Jun 2007 15:38:28 -0700, MooseFET <kensm...@xxxxxxxxx>
wrote:



On Jun 11, 1:19 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Mon, 11 Jun 2007 14:10:21 -0400, James Beck

[...]
Running TSRs wasn't true multitasking because a TSR had a single entry
point, kluged somewhere into an interrupt chain, and didn't have a
persistant context like a real application.

That last bit isn't always true. TSRs can be written so that at the
end of the code for every 18.2th of a second, a common routine is
called. This code changes the vector to the next bit of code to run
and then returns to the system.

This way things that take too long can be spread over many ticks. You
can make it cycle, lets say, between 3 sections that each get to run
every 6th of a second or so.

True, but the TSRs weren't general-purpose programs. A multitasking os
should (by my definition, at least) allow one to load and run several
true applications that run with identical OS services available to
all, like a spreadsheet and a word processor, ideally multiple copies
of each.

Yes absolutely. What I described is not an OS. It also doesn't have
a fixed entry point. I was only pointing out an error in detail not
disagreeing with the broad thrust of your arguement.

It's really not difficult, although Microsoft did its best to
make it difficult.

Actually a lot of it was just sloppiness. They copied an old OS and
used some very bad programming practices in converting it to run on
the 8088. They stored data into code segments (SPIT) etc instead of
putting them on the stack or in some data segment. This looked to me
like it was a kludgy conversion from something that ran on a machine
that couldn't address onto the stack.

Way back in the day, I disassembled large sections of DOS while trying
to figure out what was happening in the TSRs I wrote. The DOS
function entry point had more scar tissue than you could shake a stick
at. The first bits of the code were very clunky. A little way into
it suddenly there was a change in style and the use of a simple jump
table to select the correct function.

In one of the routines, they did extra work so that they could return
you a stack with an extra word on it.


John


.

Relevant Pages

  • Re: Just started ASM...
    ... The simplest Windows program I know of uses the stack to pass parameters... ... You might want to learn how the stack works, how "call" and "ret" work, *before* you have to use 'em to access your OS. ... I'd agree that it isn't worth spending a lot of time learning the complete workings of dos. ... File I/O routines can be used to get/print from/to the keyboard/screen, as well as disk files - might want to learn them. ...
    (alt.lang.asm)
  • Re: Not your usual DOS program
    ... Is a DOS .com program still limited to 64K on a 32 bit machine? ... The reason I'm asking is because Windows Me comes with a ... I think you will find that the reason the code relocates the stack is so ...
    (alt.lang.asm)
  • Stack Segment
    ... I'm trying to write a 16-bit DOS console app with MASM32 that converts ... It seems I need a STACK segment for the ... Converts a decimal digit input to binary and then display it ... Anyone know why the lines in the .stack segment aren't being ...
    (comp.lang.asm.x86)
  • Re: EMS trouble: Turbo Pascal 6 not working with EMS in OS/2 ?
    ... >> specify the right mix of parameters to the darn dos box. ... when trying the /f option to free the 2k stack ... Supports my suspicion that I might have used up all the space that EMS ... could use with some hw-specific BIOS stuff, ...
    (comp.os.os2.apps)
  • [PATCH -tip -v11 05/11] x86: add pt_regs register and stack access APIs
    ... Add following APIs for accessing registers and stack entries from pt_regs. ... Query the name of register by its offset. ... * Since usually the kernel stack will be changed right after function entry, ...
    (Linux-Kernel)