Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

discussion (Developers)

posted by Ninho E-mail, 13.06.2011, 19:28

Quickie reply

> I have to admit that I'm no expert on the 15.4F interface, so others who
> know that better should judge the overloading of it with this interface.
It was given much consideration so as to avoid confusing other users and issuers of that software interrupt (be it the BIOS or even Brett Johnson)

An alternative (int 15/8F, apparently unused elsewhere) was considered and reserved in case, the interest of overloading, as you put it, 15/4F being it saves us a few code bytes w/o sacrificing correctness, as I'm sure we'll see.

> However, I don't see why you implemented the unused fields the way you did.
Precisely because of the "overloading" : int 15/4F callers and hookers must not be disturbed. You'll see when I publish supplementary doc.
...

> Yes, hardcoding TSR data offsets in the uninstaller only affects
> cross-version compatibility. Bad enough.
I think you're mistaken, it's the installer portion that for convenience uses some hard coded offset, not the uninstaller. BICBW.

>> As the resident's effective size happens to be now an integral # of
> > "paragraphs", I felt little incentive to inline trans ... for no gain
> ;=)
> The saved bytes could easily gain you a paragraph after further (or future)
> changes.

> I am suggesting you are discarding the flags, for example, the trace flag
Indeed. I don't make it a sovereign goal to be tracer-friendly :=)

- the infamous critical section :

> (As I have shown in this post, any
> critical section implementation which still uses function 48h can hardly
> insure that no other resident code modifies MCBs before the function call
> reaches DOS. So even preventing resident code interference that could
> result in non-optimal installation doesn't hold as purpose of the critical
> section.)
But you'll remember I modified my implementation such that interrupts inside of the critsec can only occur inside of DOS (function 48) - I won't insult the reader by reminding that IRET back from DOS to my code restores a cleared interrupt flag. And you agreed there a TSR awoken during int 21/48 would not be well advised to mess with DOS mem allocation.

> ... my assumption was wrong. While in DOS (potentially in
> code messing with MCBs itself: 21.48 or 21.4A or 21.5803 or 21.4B or
> 21.67) TSRs must not alter MCBs...
Indeed they mustn't ! Ergo I think my critsec /is/ playing its role against unwanted MCB tampering.

> And you said here, before that:
 >>>> try and put DOS functions to work whenever possible rather than
>>>> direct manipulation of structures.

I must have been right then :=) But as in all matters, circumstances command

> So I thought, without the need for a critical section, why not use function
> 49h to free the memory?
Even if we weren't caring for criticality - we have to access those MCBs in the course of installation anyway, as it stands it is a gain rather than a cost to emulate DOS functions 49 and 4A. Emulating fn 48 OTOH, would be costly even a simplified version (dealing with low memory only and strategy #0).
>
>> It's in my development version already.

> What kept you from uploading that? Just curious.
Would you like if I uploaded a new package for every little change I do ? I don't think so ;=)

So long... (pun intended of course)

---
Ninho

Post reply
 

Complete thread:

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