Hi Tom,

> On Apr 21, 2023, at 2:01 PM, tom ehlert <t...@drivesnapshot.de> wrote:
> Hi ecm,
>> [1]: 
>> https://gitlab.com/DOSx86/logger/-/blob/aae3dfddcdacfea18950a96ce9449767c20b2d66/source/logger/common.inc#L267
> this got me looking into this 'too slow' detection method.
> and it is indeed slow. as in molasse. let me explain.
> a) isn't
>  %%Comparing:
>        inc             di
>        lodsb
>        cmp             al, [es:di]
>        jne             %%Next
>        loop            %%Comparing
> more or less the definition of
>        repe cmpsw
> ??

Yes, more or less it was a  “repe cmpsb”

That was a while ago and I forget the reasoning I did it that way. Possibly, 
not requiring a case-specific match. 

> b) decompiling the actual code, it's basically
>  for (seg = 10; seg < 0xa000; seg++)
>        {
>        if (fmemcmp(MK_FP(seg, 9), "LOGGER", DriverLength))
>                {
>                return found_our_driver_at(seg);
>                }
>        }
>   return failure;
> that's indeed slow as it compares all memory up to 0xa000 to lookup the 
> driver,
> or up to the drivers address (which is much better most of the time.

Yup it is a very slow way to locate the driver. It was only meant to be 
temporary until better method was implemented.  

The better method will most likely be INT 0x2D (AMIS).

During the development stage, locating the driver needed to be done quickly so 
other things could be developed and tested. 

That process went something like this:

1) We could walk the MCB chain…. That will require some overhead and 
complexity. Too big of a pain for now (see below).
2) We could walk the device driver chain. Thats fairly straight forward and 
easy enough to implement. Lets do that… Hmmm, not all device drivers are 
showing up in the chain and logger is not being seen. Let’s not worry about 
that for now and do something else.
3) We could hook an interrupt somewhere. Yeah, that will be good and reliable. 
Lets do that. But, which one will not cause any conflicts or collisions. Hmmm, 
lets worry about it later and just get something that works for now.
4) Well a brute force search will work. It is slower than a glacier and as 
clever as a stone. But, it will work well enough that I can get to work on 
writing and testing the important stuff. 
5) Brute force search it is then with a very few optimizations… For now, good 

Even though the delay incurred when launching the interface program is not very 
noticable, it is way to slow.

Now that the important stuff has been written and is being tested, the brute 
force search needs to go. 

> when I mentioned microseconds, I had the DOS memory chain in mind where you 
> would have 
> to compare 20-50 locations to your drivers name.

I did consider walking the MCB chain to find it. But, that comes with its own 
set of problems. Some blocks contain sub-blocks. The upper memory blocks may or 
may not be linked into the primary MCB chain. 

There are other aspects involving interaction between the Driver, Interface and 
Log that are also just “good enough for now” and will probably be changed a 
great deal. 

It is an alpha version for a reason.



Freedos-devel mailing list

Reply via email to