BUG: MBPC LIBRARY Fails in Compiled Mac QuickBasic w/o LIBINIT (39870)

SYMPTOMS

This article applies to programs compiled in QuickBasic Version 1.00 for the Macintosh that use the LIBRARY statement to access assembly-language routines or MBPC pure code resources that you have created yourself in assembler, C, or Pascal (as documented in Appendix E.9 "Building Your Own Libraries" in the "Microsoft QuickBasic for Macintosh: Language Reference").

This article does not apply to using the LIBRARY statement with the MBLC routines that are built into QuickBasic.

If CALLing your customized LIBRARY routine fails (such as by returning garbage, a system error, or a system hang) in a compiled program, but works correctly in the interpreter, you need to CALL LIBINIT right after the LIBRARY statement in the compiled program.

Microsoft has confirmed this to be a bug in QuickBasic Version 1.00. We are researching this problem and will post new information as it becomes available.

MORE INFORMATION

Programs compiled in QuickBasic Version 1.00 for the Macintosh fail to automatically CALL LIBINIT in programs using the LIBRARY statement. This behavior differs from the QuickBasic interpreter environment (and the earlier Basic compiler Version 1.00 and interpreter Version 3.00), which automatically invokes CALL LIBINIT in programs using the LIBRARY statement.

To make the program run as a QuickBasic compiled program, the following statement should be added as shown right after the LIBRARY statement:

   LIBRARY "YourCustomLibrary"
   IF SYSTEM(4) THEN CALL LIBINIT

In the above IF statement, CALL LIBINIT will execute in a compiled program, and will be ignored in an interpreted program. The SYSTEM(4) function returns 1 ("true") when compiled, and 0 ("false") when interpreted.

Note: The MBLC (Macintosh Basic Library Code) resources built into QuickBasic do not require the CALL LIBINIT statement (even if you put them into an external library file that can be opened with the LIBRARY statement).

Note: Instead of using LIBRARY statements that access external libraries (as done above), Microsoft recommends doing the following:

Don't use the LIBRARY statement. Instead, include all required resources (including MBLC resources and MBPC pure code resources) into the application (and source code) itself. Then you do not need a LIBRARY statement, because the application's resource fork is automatically open at run time, and all stored code and pure code resources are automatically available for calling.
Explicitly CALL all needed routines, including LIBINIT (if needed by your MBPC pure code resources). Be sure to give all routines unique names; you may want to rename LIBINIT to avoid confusion.