Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

This version needs 0/0/0/0 Bytes - but not on EDR-DOS (Announce)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 31.03.2009, 23:10

> Cm wrote:
>
> > Stop using god damned hardcoded values for the size of all data and code
> > parts of your program. This makes everything impossible to maintain and
> > you can't write any large program.
>
> This one isn't ...
Isn't what?

> > Stop hooking interrupts by modifying the IVT.
>
> If you supply a reason why ...
What's your reason not to? Some nanosecond "speed gain" by not using the Int21 service? Then DOS is rather not what you want to use, I think.

> > Comment your files better. F.e. I had to study the complete TSR (and
> evaluate
> > some hardcoded values) before I understood what the second handler in
> > the resident part is for.
>
> See UI21DEB :-)
See what? See bad comments in UI21DEB, too?

> > Write the allocated memory block's segment into its MCB.
> > This enables MEM to show the name of the resident part.
>
> Done ! But MEM fails completely and [J]DEBUG reveals 2 letters only
> :clap:
Because the owner value is 0008h which is reserved for system blocks. And because MS-DOS system blocks only used the first 2 letters as actual name and didn't initialize the remaining 6 bytes, resulting in unterminated trash. Give your MCB an owner value of the associated memory block. (Same as MCB segment plus one.)

> > use the IBM Interrupt Sharing Protocol (IISP) when hooking permanent
> > interrupt vectors (i.e. anything except Int22, Int23, Int24).
>
> Benefit ?
Your TSR then wouldn't stop IISP-aware TSRs (that hooked Int21) when they want to uninstall their interrupt handlers. IISP is a great solution to the "can't uninstall because of other TSR" problem, and easily disabled by interrupt hookers that don't conform to it. [Sometimes it's possible to tweak around this by searching through information provided by the AMIS interface but then again it sometimes isn't.]

> > if they do so carefully, they'll fail because
>
> you always find a risk :lol:
Yes, look at my signature ;-) Thinking about everything a lot helps a lot with bugfixing, too.

> > There's also the point that Int25, Int26 and I think some Int2F calls
> > (NLSFUNC file open/lseek/read/close?) might cause Int24 errors.
>
> See 10 lines above.
I counted 10 lines in various ways and didn't get a useful answer. Please cite the line you referenced.

> > Read in RBIL about Int2F.4A00, which is queried by the block device's
> code
>
> Thanks, I'll check it. (actually INT $2F is not very inviting to me ...
> guess why)
I have no idea. Int2F contains some essential DOS internal services which should be used, if available, instead of guessing the layout of all DOS internal data. It also contains the well-designed (just not as well-implemented) redirector interface. And then much other services, most of which I never want to use. [Maybe because you're a real DOS user and think Int2F was only added in later MS-DOS versions so that it "isn't quite DOS" enough?]

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 308 users online (0 registered, 308 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum