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 ecm Homepage E-mail, Düsseldorf, Germany, 13.06.2011, 14:49

> [I'm transferring this argumentative thread to the Developers' section
> rather than Announcements!]
Alright.

> You might want to wait before blindly hammering at it all :=)
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.

However, I don't see why you implemented the unused fields the way you did. Wouldn't it suffice to let, say, cx contain a function number, and then indicate success (if the function number is supported) by changing some register's value? For example, you could change the signature in bx to indicate that the interface is supported, and then you could change the function number in cx to something to indicate whether the particular function number is supported.

The current buffer method seems unnecessary. And if you re-use and extend it, you would theoretically have to check for older versions which will not touch the currently unused fields. (You probably will not implement that, but whatever.)

> Implementation details which do not affect function, and might or might not
> change between versions.
Yes, hardcoding TSR data offsets in the uninstaller only affects cross-version compatibility. Bad enough.

> 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.

> >Your interrupt handler still isn't using the interrupt sharing protocol.
> >Your uninstaller still doesn't walk interrupt sharing protocol handler
> >chains and doesn't query AMIS TSRs for their chain entries.
>
> Won't do. Size matters :=)
Extending (only) the uninstaller's code will not increase your resident size. And you could implement the header for the interrupt handler (about 18 additional bytes) as a build option so that users who would prefer a cooperative TSR instead of one squeezing out the last byte can create that from the source.

> > You sometimes discard the saved flags by returning with "retf 2" from an
> > interrupt handler.
>
> Not "sometimes", it's in the one place iirc - where it returns from the API
> call.
Ah, yes.

> Are you suggesting I made a mistake ?
I am suggesting you are discarding the flags, for example, the trace flag (could still be off even though it was on before the call), the direction flag (could still be on, ie, "downwards"), the interrupt flag (could still be off). (Note that the trace flag issue isn't actually an issue with Japheth's debugger since it will skip interrupts by placing a breakpoint behind that opcode. It might be a problem with some programs tracing through other code though.)

> > critical section protection doesn't appear to be necessary any longer
>
> I thought we discussed this at length, and I thought I'd won the argument.
> Apparently not ? Anyways, I'm content with how it stands.
I don't remember that.

What I did say back here already was this:

> > > Is there a way to make : (free, then allocate) into a "critical
> > > section" of sorts ?
> >
> > No, and that's not necessary if you properly keep all the data you need
> > inside allocated space.
As you seem to be keeping all used data inside allocated space all the time now, the need for the critical section (however well it is implemented) goes away. (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.)

And you said here, before that:

> > > try and put DOS functions to work whenever possible rather than
> > > direct manipulation of structures.
So I thought, without the need for a critical section, why not use function 49h to free the memory?

> It's in my development version already.
What kept you from uploading that? Just curious.

> >Still not checking for errors after 21.48. Can't happen?
>
> Appropriate checks are added as I reestablish auto highloading. I have to
> verify things will default to working properly under old (pre MS DOS 5
> e.g.) DOS versions as well.
What does that have to do with error checking? Yes, obviously you'll have to make sure that it will work properly even in DOS versions not supporting UMBs via the DOS memory allocation functions, and even when a DOS version that does support UMB management in this way doesn't currently manage any UMBs. However, you have to check for errors after pretty much any function 48h call independently of the exact allocation method and of DOS-managed UMB availability.

> You might have chased a few typos, too... just kidding.
Obviously I would chase source code comments that are not written in English first.

> Thanks for the punctilious peeking !
What can I say, my pleasure ;-)

---
l

Post reply
 

Complete thread:

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