DOS ain't dead

intermediate handler issued calls (Developers)

posted by Ninho , 15.06.2011, 15:32

Taking a break out of retirement...

> You must have misunderstood me. What I proposed is the same.

> Clearly, DOS is never re-entered.*

> What I proposed is conceptually the same, just with memory allocation
> functions instead of file access functions:
>
> i21:
> cmp ah, 48h
> jne .next
> ...
> mov ah, 48h
> pushf
> push cs
> call .next
> ...
>

OK now what you'd in mind is clear. Some confusion came from the use of the term TSR, that in general I take to mean a (HW)interrupt activated TSR. What you have here are soft int 21 hookers (of course they are also TSRs in the general sense).

Then my response can be stated clearly too :

1. the "hooker" MUST NOT do its own (private, hidden) 21/48 call BEFORE effecting the user's (more foreground). That would be IMO a bug (because it changes the actual result expected by the foreground program), and I would never knowingly use any kind of monitoring program that did such things.

Besides there is little reason you would want to program the "hooker" in that rude manner. Presumably the mythical utility will use its hidden memory chunk to record or annotate the foregounder's memory operation, it had better wait till DOS returns.

2. IF otoh, "hooker" passed the unchanged user's request FIRST, and did its own allocation when DOS returns, it's ACCEPTABLE (and in particular it's OK with KBFR's strategy).

3. However, much better would be for your "hooker" to do its underground memory reservations, not from conventional memory which is a precious resource and should not leak or move or vanish mysteriously. Using scratch memory from XMS or EMS or similar looks right. This is no more 1981 !

>> - keep my loading scheme as is - not only is is working in practice,
> also
>> thought 'attacks' have not succeeded in breaking it in the least (safe
> in
>> dream).

> Yes, it is safe. As stated, the current critical section is already
> unnecessary. (Notwithstanding the (im)possibility of always optimal
> placement, which has nothing to do with safety.)

Optimal placement is granted unless backgrounders don't behave. If not, so much the worse! (or use the alternate method I've outlined, basically do "function 48" by hand still under CLI)

> Get well soon!

Doing my best...

---
Ninho

Complete thread:

• KBFR 1.9 beta discussion opened by CM - Ninho, 13.06.2011, 12:17 (Developers)
  • discussion - ecm, 13.06.2011, 14:49
    • discussion - Ninho, 13.06.2011, 19:28
      • discussion - splitting MCBs again - ecm, 13.06.2011, 20:20
        • discussion - splitting MCBs again - Ninho, 13.06.2011, 21:52
          • discussion - splitting MCBs again - bretjohn, 13.06.2011, 22:38
            • discussion - splitting MCBs again - ecm, 13.06.2011, 23:41
              • discussion - splitting MCBs again - bretjohn, 14.06.2011, 00:17
            • discussion - splitting MCBs again - Ninho, 14.06.2011, 02:05
              • discussion - splitting MCBs again - ecm, 14.06.2011, 02:10
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 04:09
                  • ! - ecm, 14.06.2011, 05:17
                    • ! - Ninho, 14.06.2011, 05:59
                      • ! - ecm, 14.06.2011, 06:06
              • discussion - splitting MCBs again - bretjohn, 14.06.2011, 05:11
                • on overloading and AMIS - ecm, 14.06.2011, 05:50
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 13:38
          • discussion - splitting MCBs again - ecm, 13.06.2011, 23:33
            • discussion - splitting MCBs again - Ninho, 14.06.2011, 01:31
              • discussion - splitting MCBs again - ecm, 14.06.2011, 02:20
                • discussion - splitting MCBs again - Ninho, 14.06.2011, 04:05
                  • discussion - splitting MCBs again - ecm, 14.06.2011, 05:54
                    • discussion, & "retiring" for awhile - Ninho, 14.06.2011, 12:50
                      • DOSLFN, intermediate handler issued calls; "retiring" - ecm, 14.06.2011, 18:51
                        • intermediate handler issued calls - Ninho, 15.06.2011, 15:32
                          • intermediate handler issued calls - ecm, 15.06.2011, 16:50
                            • intermediate handler issued calls - Ninho, 15.06.2011, 17:53
                              • intermediate handler issued calls - ecm, 15.06.2011, 22:37