Hi All, I implemented walking the device driver chain to locate the Logging Driver. Not sure what dumb thing I did wrong the first time I looked at it. But, it seems to work fine now.
After writing the 3 different methods to locate the driver, here are the results for the current ALPHA version. (COM=LOGGER interface binary, SYS=LOGGER device driver) 1) When using the 0x2b interrupt hook, COM size 4460, SYS size 3006, SYS resident size 1216. This is definitely the fastest method to locate the driver. It is a single interrupt call with verification and it is done. But as discussed before, it is a “new standard” that most likely should be avoided. 2) When using the partial implementation of the AMIS interrupt 0x2d multiplexer, COM size 4476, SYS size 3055, SYS resident size 1232. If it is made "fully compliant” with the AMIS protocol, it will add a minimum of 22 more bytes. Most likely, it will eventually be double or triple that. There are advantages to using AMIS. But, it requires calling the interrupt 255 times to check every multiplexer. If fully implemented, it would also increase the resident footprint by roughly 10% of the current requirements. If additional functionality is added to the driver (things like screen capture, hot keys, 3rd party driver control interface, etc) the larger size would be less important. Plus, it would provide a “semi-official” interface to that additional driver functionality. 3) When walking the device driver chain, COM size 4480, SYS size 2966, SYS resident size 1168. This is also very quick and should only require checking a couple links in the device driver chain. It requires no extra code in the driver and has the smallest memory resident footprint of the three methods. It seems to work great under FreeDOS, MS-DOS and PC-DOS. There could be compatibility issues under other DOS distributions. However, there are some safeguards in place to prevent getting stuck if walking an invalid device driver chain. Although it would be nice, I do not really care if it is not compatible with other DOS platforms. I think for the time being, walking the driver chain will be the way to go. Eventually, it will probably be moved to AMIS in a future version. As for using a single binary that doubles as both the device driver and driver interface, I’m still undecided. There are good reasons for doing that. First, it would be just a single binary to worry about. Second, the overall size would be reduced by not duplicating the code shared between them. But, there are some drawbacks as well. Although the total size would be smaller, the single binary would be much larger than the two individual binaries. Even though the resident footprint of the driver would remain unchanged, it would require a larger free memory block when initially loaded. It would also require loading everything each time the interface program is used to directly append the log. The extra couple KB won’t matter much when running from a hard disk or if caching is used. But if run from a floppy, the loading delay would add up with repeated execution. To be fair, that probably will not matter very much. Finally if space is critical on a boot floppy, using two binaries allows having just the small driver on the boot diskette and putting the interface program on a separate diskette. I think the advantages of a single binary probably outweigh having two separate ones. But like using AMIS and providing a 3rd party log control interface, I feel that would be better suited for a version 2.x release. For version 1.x, I think it may be better to use the SYS+COM pair of binaries. I’m still undecided. :-) Jerome _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
