> For fun, I implemented initial versions of both the 0x2b interrupt > hook and a partial 0x2d implementation to locate the Logger device > driver. > > The 0x2d version is very bare bones and does not include several > functions required to be fully compliant. It only responds to the > install check function for whichever multiplexer it allocates. Other > function requests only respond with AL=0x00 which i guess is not > implemented. > > As such, 0x2d uses 35 bytes more resident memory than 0x2b. > (actually 49 bytes more if you count a title string that is not > required). If I spend the time making it fully compliant, it will > require even more. It really would need function 04 (determine > chained ints) and should have 06 (device driver info).
While keeping the memory footprint as small as possible is important, you also need to weigh that against the user experience. To give the user things that are useful (even if they don't realize they are useful) usually takes more memory than a bare-bones approach, but the extra memory is usually worth the trouble. Sometimes it's worth an extra few hundred bytes to make things easier for the user (and for other programs). That's why I encourage AMIS (which includes IISP) and use it in all new versions of my programs. In early versions I used INT 2Fh. According to MS, INT 2Fh multiplex numbers below C0h are reserved for MS applications but user applications can use C0h+. The problem is, there really is no standard on how INT 2Fh should be implemented, even for something as simple as a basic installation check. Even the MS applications aren't consistent between each other. I finally gave up on that idea and there were two viable alternatives that I found: AMIS and TesSeRact, with AMIS being vastly superior (though still not "perfect"). Even if you end up not using AMIS, I would still recommend IISP. Among other things, it lets the user be much less concerned about the order of TSR installation, particularly when uninstalling. AMIS has a lot of other nice "features" as well. I also would not suggest implementing an "incomplete" AMIS. > I think overall, it might be better to figure out why walking the > device driver chain was not working correctly. Most likely, it was > some dumb thing I was doing wrong. It would have the smallest > resident footprint of the locating schemes. The device driver chain search usually works pretty well, but doesn't necessarily work correctly in all VMs and may not work correctly in early DOS "clones", either. I know that in DOSBox (and its clones/forks) the device driver chain is "messed up". A standard DOS Device Driver chain includes several character devices (CON, NUL, COM1-COM4, LPT1-LPT3, AUX, PRN, and CLOCK$) but DOSBox only has CON and NUL. The other devices (at least can) exist but are "virtualized" somehow and don't show up in the chain. BTW, that's another test I've added to ISLOADED for the detection of a Virtual Machine (or at least a virtual DOS). > I'll probably take another look at that. Or maybe, I'll just stick > with the 0x2d multiplexerf despite it's larger footprint. > > All are better (and much faster) than the temporary brute force > search in previous versions. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
