Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

This TSR is impossible to beat !!! 116/48/32/0 Bytes ARF pr (Announce)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 22.03.2009, 11:36

> My next cool TSR is out. It isn't unique by features but by size and
> memory hoggines :clap: , and it is still useful. All size/memory related
> bugs of my FIX7ZIP TSR pointed by Cm some time ago are fixed
> here in. :clap:
Well there are still some things I'd do another way:

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

- Stop hooking interrupts by modifying the IVT.

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

- Free the environment if you don't need it anymore. Especially with such a small resident part, this often enables programs with simple memory allocation schemes to move that part to an optimal position, avoiding any (further) memory fragmentation.

- Write the allocated memory block's segment into its MCB. This enables MEM to show the name of the resident part.

- Please use the IBM Interrupt Sharing Protocol (IISP) when hooking permanent interrupt vectors (i.e. anything except Int22, Int23, Int24).

> * It permanently disables Abort Retry Fail (see shot) and
> workarounds the "Must-press-A-or-F-1'000'000-times-BUG" of FreeDOS
It does this by re-storing it's own Int24 handler on any Int21 call by modifying the IVT directly. Because you can't call Int21.25 in MS-DOS safely, this is a legitimate direct IVT modification.

However, other programs might want to hook Int24 for one or another reason, and their hook will be disabled by the next Int21 call after Int21.2524. Although the Int24 handler is not permanent (i.e. restored by PSP termination) programs might try to unhook their Int24 handler, and if they do so carefully, they'll fail because ARFKILL's (or ARFSUCKS's) handler has overwritten the IVT reference to their handler.

The short version: This is bad hack which might work most of the time but could cause quirky behaviour of some programs.

There's also the point that Int25, Int26 and I think some Int2F calls (NLSFUNC file open/lseek/read/close?) might cause Int24 errors. If one of these is called by any program after Int21.4B but before any other Int21 call, and if it does cause a critical error, then the previously restored Int24 handler is used, not the ARFSUCKS handler. This is a really improbable situation and I'm not even certain it would work this way, but it could do.

> * It doesn't prevent the intrusive "Remove diskette from A: Insert
> diskette into B:" messages ... I have no idea where they come form, but
> since I am getting them with both FreeDOS and EDR-DOS, this can't be a
> FreeDOS BUG :clap:
> Hints how to kill them also are welcome :hungry:
This is the message popping up if you access a phantom floppy drive B: (i.e. actually the same Int13 drive as A:, but other DPB and device unit). Read in RBIL about Int2F.4A00, which is queried by the block device's code before showing this prompt.

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