


                     Important Notes About the Fryers32.DLL
                                  02/22/99 -med


        The 32bit Windows version of Fryers has more limitations than the 
        older MSDOS version of the driver. The Windows driver requires 
        more care to prevent unexpected things from happening.

        With the MSDOS driver, you could call undefined function numbers 
        and get a version number response back (same as function ffff). 
        This was done because the MSDOS version hooked into the BIOS 
        interrupt and the unknown calls had to be allowed for potential 
        system interrupt calls that might use the numbers even if Fryers 
        didn't use them. 

        The Windows driver does not hook the interrupt, so additional 
        hooks don't exist. If you do call an invalid function number, you 
        will get back a Failed function call result (Register AX = -1).

        In the MSDOS Fryers TSR you could call some functions (such as 
        loading the send buffer) before the driver had actually been 
        enabled. This is not possible in the Windows 32 bit DLL. You 
        should enable the port first before calling any other function.

        The following calls are allowed when a port is not yet enabled:

           ffff - get version number
           fffe - get extended version information 
           fffd - get version string
           ff0f - kill port
           ff00 - enable port
           00xx - init port *

        The get version number commands (ffff, fffe, fffd) can be called 
        anytime whether the port is enabled or not. This to maintain 
        compatibility with older MSDOS code that used the version command 
        to determine if the driver was loaded in memory. 

        The enable port command can also be called anytime. You can use 
        it to enable the port, and to get the status of the port to see 
        if it is enabled. 

        The init port command is also allowed when the port is not yet 
        enabled. The purpose for this is the same as the version 
        functions, it maintains backwards compatibility with older MSDOS 
        code that could initialize the port before it was enabled. This 
        is not recommended, and you should change the code if possible to 
        perform the initialization after the port has been enabled. 
        If you do call the init port function before the port is enabled, 
        it will save the information for later. The port itself will not 
        actually be initialized until it has been enabled with the 
        function ff00. 





                                        1








        The Kill Port function is only for the 32 bit Windows version of 
        the driver. Its purpose is to provide a means to completely 
        deallocate the driver resources should the driver fail. Normally 
        you should not call this function, it may leave the system 
        unstable. You should use the ff00 function to perform an orderly 
        shut down of the driver. You can determine if the driver has 
        failed by getting the status results of the ff00 function. This 
        should normally never be a problem and you should normally not 
        need to worry about using the ff0f function. It is primarily 
        intended for use when debugging the driver. If the ff00 function 
        is successful, the resources will be deallocated. If the ff00 
        function fails, some resources may be left connected. The ff0f 
        function tries to clean up the mess if it can. Regardless, when 
        your application program terminates, the DLL resources will be 
        released by the operating system anyway (unless another 
        application is using the DLL).

        The 32 bit Fryers driver is not completely thread safe. Only one 
        process or thread may own any particular port. It is possible for 
        another process or thread to own an alternate port. You should 
        not allow two threads to communicate with the same port since it 
        is possible for the data or status information to be damaged.

        The 32bit Fryers driver passes information via a register 
        structure pointer. The register structure is read and modified by 
        the DLL. The register structure should not be touched by the 
        application or other process or thread until the DLL is done with 
        it. Changing the register structure while it is being used by the 
        DLL may cause unexpected things to happen, and the DLL may become 
        very unhappy.

        The DLL allocates an object and launches two threads for each 
        port that is attached. The threads operate at the 
        THREAD_PRIORITY_TIME_CRITICAL level. That means that the threads 
        will have priority over any other thread that may be running. 
        Normally this should not be a problem, when the threads are not 
        doing anything, they go to sleep. The critical level is required 
        because the Fryers protocol cannot allow data to be missed, and 
        has a turn-around processing time that is critical. 

        It is possible that some applications or processes may select an 
        even higher priority (Real time priority class). If the real time 
        process takes too much cpu time, it could potentially interfere 
        with the Fryers driver. An example of potential applications that 
        might use such a priority are games, or other multi-media 
        applications such as video conferencing. You should not use the 
        Fryers driver when one of those applications are running. At the 
        least, you may loose data, at the worse, the system may crash. 









                                        2








        When programming for Windows, you are operating in a multi-
        tasking environment. Because of that, you should be friendly to 
        other applications. One area of Fryers that can hog cpu time is 
        waiting for a command to complete. While waiting for a Fryers 
        command to complete (using function ff13), you may want to put 
        your application to sleep (using the Sleep() api call) if you are 
        not doing anything else so as to release the cpu to do other 
        tasks. 

        This can also help the Fryers driver itself since it doesn't have 
        to wait as long to gain access to the cpu when it is ready. The 
        trade-off is that when you release your process's time slot with 
        the Sleep() call, you won't get control back until the next time 
        slice. If you are time critical, this will change timing slightly 
        (typically as much as 10ms increase).  

        Normally releasing your time slot will not be a problem. Windows 
        itself does it when you call an API function that has to wait on 
        a result. The result can make a big difference in system 
        performance, especially if there is more than one application 
        running on the system. A potential negative is that if the other 
        application is not multi-task friendly, your application may not 
        get as much cpu time, resulting in slightly slower performance. 
        The only way to know what to expect is to try it and see what 
        happens.


        Programming notes for using Fryers32.DLL with Win9x and WinNT

        If you load Fryers32.dll by using the Win32API function 
        "LoadLibrary", do not use the function "FreeLibrary" to detach it 
        from your process. Using the "FreeLibrary" call causes the 
        release of some globally allocated data while the threads that 
        were created by the DLL are still running. This may cause 
        exception errors such as "Access violation error". When your 
        program quits running, the DLL will be detached by the system, so 
        you don't need to call "FreeLibrary".

        Always try to terminate your process in normal ways. Forcing a 
        process to terminate abruptly may cause some variables or 
        pointers in the DLL to "hang around" which might cause exception 
        errors.

        When using Visual Basic, do not call the "End" function since 
        this function causes the process to terminate abruptly. 

        Do not close the Fryers port twice in a row and do not use the 
        Fryers calls above $FF00 once the port has been closed.









                                        3








        You can tell if a Fryers port has been allocated by using 
        function Regs.AX=0xFFFF. If it returns Regs.BX containing zero, 
        the port is not allocated. If Regs.BX contains a non-zero value, 
        it is the Windows Handle for the serial port that Fryers is using 
        for the indicated com port passed in Regs.DX. You can use the 
        returned handle to make Windows API calls against the com port 
        otuside of the Fryers Driver. You should try to avoid this since 
        it can potentially seriously disrupt the Fryers driver. Use the 
        appropriate Fryers call to do what needs to be done if at all 
        possible. 



                             Fryers32 Bug Fixes

        Versions prior to 5.16 would cause WinXP systems to lockup and 
        deactivate the serial port if you attemted to send a character 
        using the Send Ascii Character command ($01xx) when the port was 
        not activated. This was corrected in V5.16. The command will 
        return a -1 in Regsister AX and the data will not be sent if the 
        port is not activated. 

        Command $FF18 was not returning the proper values when setting 
        the buffer size. The size was being properly set, but the new 
        size was not being returned. This was corrected in V5.16.


        <eof>





























                                        4





