> On Apr 21, 2023, at 10:21 AM, tom ehlert <t...@drivesnapshot.de> wrote: > > Hi, > > >> At present, the interface program for Logger just performs a slightly >> optimized brute force search for the Logger device driver. Although >> reliable, it is very slow compared to providing a simple interrupt call to >> test for installation. > > given that this detection will be done once per program start: how many > microseconds do you expect to save?
Well, there is the catch. At present, the current semi-optimized brute force search is quick. The delay in finding the driver is not really noticeable when a user invokes the interface program to view, print or perform some other operation. But there is a delay and those delays can add up. For example, if the FreeDOS installer ran the interface program many times to put messages into the log or write the results of programs like FDISK there for debugging installation issues. All those executions will add up. But, like you said, how much performance will be gained? For example, if adding a comment to the log takes 1 second to load the interface program from floppy diskette and only 1/1000 of a second to find the driver, then improving that makes almost no sense at all. I should probably benchmark it to see if it is worth the bother. But, it would vary widely based on system and numerous other factors. > >> Looking at the different interrupts, I think I have come up with a solution >> that will work well for Logger and any other driver or program that needs >> such a check. So, I’d like to propose a “standard” we could use. I’d like to >> get your feedback on what I’m thinking… > > setting a "standard" which is used probably exactly once ? we write year 2023 > ;) > > https://xkcd.com/927/ > > INT 2D has been mentioned by others Maybe go for 16 instead. It is an even binary number. LOL XKCD is great. > > >> Looking at RBIL, interrupt 0x2b is barely used by anything. Under MS-DOS and >> FreeDOS, this simply points to an IRET. Under IBM ROM-DOS, AH functions >> 0x00-0x03 do some things. But, all other calls do nothing. > >> https://fd.lod.bz/rbil/interrup/dos_kernel/2b.html >> <https://fd.lod.bz/rbil/interrup/dos_kernel/2b.html> > >> An install check issuing this interrupt would be simple to perform. A >> program could set the Carry Flag, load AH/AX with “check for install” >> function and set DS:BX to point to an identifier string (minimum 8 >> characters, no maximum). Then call the interrupt. On return, if the Carry >> Flag is still set, then the install check failed. If the Carry Flag is >> clear, it succeeded and other register would be modified to according to the >> needs of the programs. > >> Implementation for Logger (as an example) could be: > >> >> CHECK: >> push cs >> pop ds ; set DS to our code segment >> stc ; set the carry flag >> mov ax, 0xfd00 ; set AX to install check function >> mov bx, LOGGER_ID ; offset to LOGGER device driver ID >> int 0x2b ; call install check interrupt >> jc NOT_INSTALLED ; nothing changed, driver is not >> loaded > > ;you should add > cmp ax, MAGIC_VALUE > jne NOT_INSTALLED > > your proposed INT2B might be used by some other software that for some crazy > reasons > clears the carry flag. Your correct of course. :-) In implementation, I would probably have it return the pointer to the driver header and verify the signature of the driver again by the caller. > > anyway, INT2D is probably the better choice anyway. Probably, I just don’t like to add extra code and increase the resident footprint without good cause. :-) Jerome > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
