AMIGA CODING GUIDE ------------------ This document contains various notes and tips for Amiga programmers and users. It was written by James Jacobs of Amigan Software on 9/8/04, and last updated on 10/8/10. If you have any additions, corrections or suggestions, please email us. EMail: amigansoftware@gmail.com URL: http://amigan.1emu.net/ Contents -------- StormC Patches Resource Tracking Startup Code StormC Bugs ReAction Bugs ReSource 6.06 Bugs ReActor Extra Files Function Equivalents Online Help Lint Serial Debugging Tools Undocumented OS3.9 Functions List OS3.9 Bugs OS4.1 Bugs MorphOS 2 Bugs StormC Patches -------------- There are 3 versions of StormC 4.0. H&P were still sending out the 2nd version (19/12/2000) in at least some cases, even in 2004. It is vital therefore to patch this to the 3rd version (26/3/2001). You must check the creation date of your StormC 4 CD-ROM to ascertain which version you have been sent, and then apply any patch(es) necessary. See http://www.haage-partner.com/storm/sc_sup_e.htm Resource Tracking ----------------- To make full use of the powerful resource tracking feature of RunShell there are several conditions which must be met: At compile time: . You must be using direct API calls rather than stub calls (ie. #amicall rather than #libcall); this generally necessitates use of the StormC includes (StormC:include) rather than the 3.9 NDK includes (NDK_3.9:include/include_h). . Settings|Compiler|Options|Debugger: "Small debugfiles" or "Fat debugfiles", not "No debugfiles". . You must use proto/, pragma/, or pragmas/ (ideally pragma/) rather than clib/ in your includes. At run time: . Settings|Program Start|Program|Options|Use resource tracking protocol: must be checked (enabled). These factors, among many others, are NOT important: . Which includes you use of proto/, protos/, pragma/, as long as they are from StormC:include. Wherever possible, clib/ must not be used. . Settings|Project Environment|Make|Project|Compiler: does not matter which option is selected ("StormC 3" or "GCC"). . Settings|Compiler|Preprocessor|#define: NDEBUG need not be defined. . Settings|Compiler|Options|Debugger|Compile debugger friendly: need not be checked. . Settings|Compiler|Options|Debugger|Write debugsymbols: need not be checked. . Settings|Compiler|Options|Debugger|ASM Output: does not matter which option is selected ("No ASM Output", "ASM Without Source", or "ASM With Source"). . Settings|Linker|Linker 2|Options|Map File: does not matter which option is selected ("No Map File", "Write Map File", or "Write Long Map File"). If your program does not leak, the RunShell window will automatically close when your program ends. Otherwise, you must close the RunShell window yourself. This is the only way to flush the resources - the Debugger|Free Resources menu item documented on page 156 of the manual does not exist. Sometimes RunShell loses control of your program and no longer works properly (this includes the debugger). The only remedy is to quit and restart StormC. To help avoid this, always be sure to close the RunShell window each time your program ends, and only run one instance of your program at a time. Some leaks such as "Memory not freed" and "Library not closed" have no corresponding source line. Apparently they are leaks in the StormC startup code. Some leaks have been observed even in the provided H&P examples. Eg. the IllResource.c program, in addition to the deliberate leaks, has these accidental leaks: Library "intuition.library" not closed. Library "dos.library" not closed. The RunShell status line is not updated when your program ends, so it will be stale and may still for example still claim that "Program is waiting for signals to arrive.". However, the protocol list will correctly indicate "Program finished." or "Program killed.", as appropriate. Startup Code ------------ If you want your program to be able to run from Workbench as well as CLI, add these lines: #ifdef __STORM__ void wbmain(struct WBStartup* wb) { main(0, (char **) wb); } #endif This not only allows the program to run under Workbench, but also allows parsing of Workbench tooltypes in main(), a la SAS/C. However, as the StormC startup does not set up a console for your program, you will be unable to use standard I/O (eg. printf()) when started from Workbench, unless you set up a console yourself. StormC Bugs ----------- These are in addition to the "Known Bugs" listed on the StormC 4 CD. 64-bit multiplication is unreliable in StormC 3 mode. Eg.: #include void main(void) { long long number; number = 10; printf("%Ld!\n", number); number *= 2; printf("%Ld!\n", number); } Assembler error messages produced by StormC may be incorrect; eg. "Unable to open utility.library" instead of "Unable to open exec/types.i". Many programs, including some by H&P and/or Amiga, are reported by StormRun to have resource leaks (eg. unfreed memory chunks) without apparent cause (see above). Some switch statements can cause a "bxx.b L0" to be generated by the compiler. No label L0 is defined, thus we get "Panic: Assembler failed at n: Undefined Label". Replacing the relevant switch statement(s) with a chain of "else if"s seems to avoid the bug. When two instances of a StormC-compiled program are running, exiting one will cause a recoverable alert guru of type $0100000F. The bracket-matching feature (Amiga-[) of the editor does not always work correctly. Sometimes keys such as F9 (for Run) are ignored from inside text editor windows and you must activate a different window (eg. message window) or use the toolbar. If you close the window while it is building your program, it will no longer allow you to build. You need to stop it properly (eg. with the Stop button). The menu bar is not redrawn while StormC is busy (eg. compiling). The compiler does not always detect the case where a source file needs to be recompiled because one or more of its header files have changed. AMIGA is not defined when in StormC 3 mode. When using source files containing CR+LF (ie. IBM-style) EOL pairs in GCC mode, multi-line #defines (ie. using \) will be flagged as erroneous. (Converting the source files to LF (ie. Amiga-style) EOLs will fix this.) When using source files containing CR+LF (ie. IBM-style) EOL pairs, in StormC mode at least, the editor will go to the wrong line when you double-click on an error message. Floating point arithmetic (eg. subtraction) does not work properly, at least in StormC 3 mode. Linker errors are not shown unless warnings are enabled. Some linker warnings are undocumented in the manual: eg. "24 bit reloc is illegal". The following bugs have been mentioned by others but not confirmed by us: . improperly constructed arrays of polymorphic objects . broken function template instantiation . non-threadsafe exception handling There are two issues to be aware of when performing multi-file searches, although they are not strictly speaking bugs. The "Messages" window is not cleared automatically at the start of the search; you can click the "X" button near the bottom right hand corner of the "Messages" window to accomplish this. Also, the search results will not be displayed unless message output ("i" checkbox near the top of the "Messages" window) is enabled. ReAction Bugs ------------- These bugs are still currently unfixed, even with Boing Bag 3. If you know any patches or workarounds to these bugs, or can explain them further, please contact us. . Button gadgets: (*) The height of a button will not be tall enough, if the button uses any imagery. (Eg. the top bevel will not be rendered above the image). . Chooser gadgets: (a) Pop-up chooser gadgets cannot have a label; you must use a separate label image object for this purpose. (b) Apparently ReAction does not support images in chooser gadgets, only in the pop-up menus of those gadgets. . Gradient sliders: (*) The gadget seems to only have 2 positions (0 and 1), regardless of the use of the GRAD_MaxVal tag. Also, the slider knob seems to be not correctly positioned (disappears entirely for values other than 0). . Labels: (*) Labels are not centred correctly; they are still placed at the top left even with LABEL_Justification, LJ_CENTER. (It is thus necessary to enclose them within their own layout object.) . Layouts: (*) Group box labels are not taken into consideration when calculating the minimum/nominal/etc. size of a layout group. Therefore, for example, if a lengthy (ie. wide) group box label is encapsulating narrow gadgets, the group box label text will be truncated. . Listbrowser gadgets: (a) Column borders with CIF_DRAGGABLE do not size correctly and are not draggable. (b) Column borders with LISTBROWSER_VirtualWidth are not rendered correctly. (c) Column widths do not seem to be changeable. Even though you can change the number of and/or titles of columns, the previous column widths are being retained. (d) LBNCA_VertJustification seems to have no effect. Eg. for listbrowsers with tall cells (eg. AmiArcadia sidebar), text is aligned to the top of each cell; there doesn't seem to be any way to centre it, for example. The top pixel row of the text will be cut off on eg. Amiga Forever 6.0. . Page/clicktab gadgets: (*) some valid-seeming uses of these do not work properly. (Although the provided examples do seem to work.) . Radio buttons: (*) GA_Disabled, FALSE doesn't visually unghost the gadget (even after calling RefreshGadgets()). . Speedbar gadgets: (a) Speedbars with CHILD_WeightedWidth of 0 are not sized correctly. (b) SBNA_Help is not supported by OS4.x and will crash the machine. This is not mentioned in the OS4.x autodocs. (c) The WINDOW_HintInfo feature of window.class doesn't work correctly for speedbar buttons which have an ID of 0. . String gadgets: (a) STRINGA_MaxChars seems to include the NULL terminator; therefore you must set it = strlen(string) + 1 . (b) When setting STRING_MinVisible or INTEGER_MinVisible for editable gadgets, be aware that the system does not allocate space for the cursor. Therefore it is best to set this value one higher than the maximum number of characters in the field, so that the the entire contents of the gadget are simultaneously viewable during editing (otherwise the gadget will scroll horizontally). . Text editor gadgets: (*) Scrollable read-only text editors don't seem to handle cursor key input correctly. . Windows: (*) WMHI_NEWSIZE appears not to be sent, at least in some circumstances. These aren't really bugs so much as undocumented usage instructions: . Labels: (*) According to label_ic.doc, "If you do not use IA_Font...then you MUST [use LABEL_DrawInfo] before you give the LABEL_Text tag." However, in practice it seems harmless to omit both IA_Font and LABEL_DrawInfo; this is done by examples such as NDK_3.9:Examples/ReAction/CheckBox/CheckBoxExample.c. . Space gadgets: (*) You must use LAYOUT_AddChild, not LAYOUT_AddImage, for these (seems to work under OS3.9 but not OS4.1). . String gadgets: (*) You must use STRINGA_Buffer, not STRINGA_TextVal, when initializing the gadget. The buffer must be allocated by you (can be just a normal string, heap allocation is not required) and must remain valid throughout the lifetime of the gadget. You can read the gadget at any time by simply examining your buffer. To write to the gadget, use SetGadgetAttrs(STRINGA_TextVal, foo) where foo is your buffer. . Windows: (*) If you use a WINDOW_Icon, this icon is freed automatically when you dispose the window. So you must call GetDiskObjectNew("foo") first, every time you want to create the window. Never call FreeDiskObject(); you must let ReAction do it. . Buttons, listbrowsers and strings autorefresh... . ...but checkboxes, choosers and radios need RefreshGadgets(). ReSource 6.06 Bugs ------------------ . Creates .W offsets for some .B type branches when near the +/- 127/ 128 byte offset limits. Especially when branching ahead. . Creates incorrect word offsets when code with an offset in the relocation table resolves to an absolute location outside the hunk that the relocation table belongs to. ReActor ------- The object files generated by ReActor are malformed and will not work with SAS/C, only StormC. You must run ReActor from Workbench rather than from CLI. You can of course use the WBRun command to get around this problem, as follows: WBRun ReActor On the Window page, when previewing your window (Open button), the lowest- numbered window is always previewed, instead of the currently selected window. You can use the Up and Down buttons and the Edit|Renumber menu item to arrange and then renumber the windows (ie. move the window you want to preview to the top of the list, then renumber and preview). Although the gadget ID is set in the "Object Name" string field in the hierarchical window (ie. the subwindow of "Gadget Groups" containing the treelist), you must also have a GA_ID entry in the "Attributes of " window (ie. the tags window for that gadget). If you don't do this, you won't be able to correctly refer to your gadgets in your program. (Of course, you should set GA_RelVerify to TRUE for any gadgets you want to hear WHMI_GADGETUP messages for, as always.) Each label object MUST have a valid LABEL_Text field (and associated locale id), or the assembler will panic. There appears to be a bug as follows: for the SBNA_Image and SBNA_SelImage attributes of nodes of SPEEDBAR_Buttons, ReActor is not seeing bitmaps, only labels. There are some restrictions on the filenames you can use. You should ensure that you only use valid C/assembler symbol names as the pre- extension components of the filenames; ie. beginning with an alphabetic or underscore character, and consisting only of alphanumeric and underscore characters. Filenames containing hyphens or other such characters will cause problems with the assembler. Also, the names of the main source module (eg. app.c), ReActor files (eg. gui.res) and catalogue-related files (eg. lang.asm) should all be distinct in the pre-extension component, because there will be distinct app.o, gui.o and lang.o object files which will need to be linked to generate the executable. Each text string (eg. labels) in the ReActor resource MUST have a non- empty locale ID field, contrary to the documentation. You must use CatComp to generate the assembler file as follows: CATCOMP gui.cd XDEF ASMFILE=lang.asm In Settings|Assembler|Options|Set|#define, you should add these two #defines: CATCOMP_NUMBERS CATCOMP_STRINGS In the IFD CATCOMP_STRINGS section of the lang.asm file, you can add this line: EVEN before each XDEF line, to suppress the "Misaligned symbol" warnings. (Note that as it is an assembler directive, it must be preceded by eight spaces.) However, the supposed misalignment of these symbols has not proven to cause any problems, so this step is not strictly necessary. Files such as the following are used. Of course, the "app", "gui" and "lang" names used here are purely arbitrary and you can choose different names; the important point is that filenames should be distinct, as explained above. app.¶ - the project file, created by you in StormC, containing references to these files (at least): app.c gui.h lang.asm gui.o storm.lib amiga.lib gui.o - object file, generated by ReActor from gui.res, for linking. gui.h - object ID #defines, generated by ReActor from gui.res (you should #include this in app.c). gui.cd - catalog descriptor for the GUI text, generated by ReActor from gui.res. gui.res - the GUI saved in the native ReActor file format. app.c - the main source code of the application, written by you (the tutorial in the ReActor documentation provides a working application skeleton). app.o - object file, generated by StormC from app.c, for linking. lang.asm - source code, generated by CatComp from gui.cd. lang.o - object file, generated by StormC (PhxAss) from lang.asm, for linking. app - executable file, generated by StormC (StormLink) from app.o, gui.o and lang.o. ReActor generates four files automatically when a project is saved: gui.res, gui.h, gui.o and gui.cd. (The gui.h file will not be written by ReActor if the gadget IDs have not changed and gui.h already exists, and the gui.cd file will not be written by ReActor if the locale IDs have not changed and gui.cd already exists.) Extra Files ----------- Manuals: The StormC 3.0 manual in PDF format is available from http://www.haage-partner.net/download/Amiga/Storm/StormC3.pdf The StormC 4 English AmigaGuide documentation is available from http://www.haage-partner.net/download/Amiga/Storm/StormC4-Docs-English.lha There are also various other useful files available from http://www.haage-partner.net/download/Amiga/Storm/ OS3.9 Support: The 3.9 includes in StormC format are available from http://amigan.1emu.net/releases/StormCIncludes.lha (or from Aminet: dev/c/StormCIncludes.lha) The 3.9 autodocs in AmigaGuide format are available from http://amigan.1emu.net/releases/OS39AGAD.lha Function Equivalents -------------------- SAS/C provides many useful functions which are unavailable under StormC. Equivalent functions for some of these are provided here to ease conversion. #include #include #ifdef __STORM__ ULONG stcul_d(STRPTR out, LONG val) { // Convert (32-bit) unsigned integer to ASCII decimal string. sprintf(out, "%lu", val); return(strlen(out)); } ULONG stcl_d(STRPTR out, LONG val) { // Convert long integer to ASCII decimal string. sprintf(out, "%ld", val); return(strlen(out)); } ULONG stcl_h(STRPTR out, LONG val) { // Convert long integer to ASCII hexadecimal string. sprintf(out, "%lx", val); return(strlen(out)); } #endif Online Help ----------- The full online help and colourization subsystem data is contained in StormC:Manuals/, StormC:StormSys/Help and StormC:StormSys/Dictionary. Manuals/ contains the StormC 4 manuals. The contents of this directory are listed on the the Help menu. Although these manuals do not require updating for OS3.9, they are in German and thus should be replaced by their English equivalents (see below). Help/ is effectively a copy of the ADCD_2.1:Reference/ Includes_and_Autodocs_3.5/ directory, with the addition of the files STORMREFERENCE.GUIDE and STORMREFERENCE.IDX. STORMREFERENCE.GUIDE is an AmigaGuide table of contents for all ANSI C functions and C++ classes, and thus doesn't need updating. All the other files are obsolete and need to be updated. STORMREFERENCE.IDX is an index containing symbols from Include/, StormC: StormSys/Help/, and StormC:Manuals/. You should unpack the OS39AGAD.lha archive into StormC:StormSys/Help/. You should unpack the StormCIncludes.lha archive into both StormC:include/ and StormC:StormSys/Help/include/. Then you can update STORMREFERENCE.IDX and the Dictionary/ files (four of them) yourself using the scripts in StormC:Tools/GEN_DICS_INDEX/. Note that the GenDictionaries program requires a large stack, otherwise it will hang. Dictionary/ contains the following files: Amiga Functions.dic - Function declarations AmigaGuide.dic - AmigaGuide keywords for editor colourization Amiga Types.dic - Structure templates, typedefs ARexx.dic - ARexx keywords for editor colourization C Library.dic - Function declarations, structure templates, typedefs C Symbols.dic - C/C++ keywords for editor colourization Installer.dic - Installer keywords for editor colourization Preprocessor.dic - Preprocessor keywords, defines User 1.dic User 2.dic User 3.dic Lint ---- There are two versions of Lint available for the Amiga: the obsolete Gimpel Lint 2.0b (1986) and the powerful LCLint 2.2a+ (1996) (Aminet: dev/c/lclint.lha). Both are annoying to set up :-( Here is described how to install and use LCLint. Note that the solutions presented here are not optimal. Unfortunately, you must apparently have GCC installed to use LCLint. It does not seem to be compatible with StormC, but you can use it to check StormC programs. A suitable hardfile to boot from is the GCC-AmigaOS: HDF 1.11 made by LouiSe; grab it while it is still available from: http://www.innoidea.hu/subsites/amiga/developer/FILES/HardFiles/gcc111.zip http://www.innoidea.hu/subsites/amiga/developer/FILES/HardFiles/gcc111.txt You will also need access to your usual partition, here referred to as HD1:. We assume you have copied the LCLint files to the following locations: hd1:LCLint/lclint hd1:LCLint/ansi.lcd and that StormC is installed to HD1: (ie. StormC: is normally HD1:StormC). You can delete the LCLint SETUP file. The only change you need to make to the GCC-AmigaOS: hardfile is to append these lines to GCC-AmigaOS:S/User-startup: ;BEGIN LCLint setenv HOME hd1:misc/dev/lclint setenv LARCH_PATH hd1:misc/dev/lclint assign .: hd1:misc/dev/lclint path add hd1:misc/dev/lclint assign USR: hd1:stormc setenv LCLINT_CPPCMD GCC-AmigaOS:ade/bin/cpp ;END LCLint HOME and .: are the directory containing .lclintrc. LARCH_PATH is the directory containing ansi.lcd. LCLINT_CPPCMD is the command used to invoke the C preprocessor. USR:include is the directory searched for system includes. Create the file hd1:LCLint/.lclintrc, containing the lines: -weak -duplicatequals -unrecog -weak specifies weak linting, ie. only the most important checks are performed. -duplicatequals suppresses messages about "long long". -unrecog suppresses messages about "STRING_GetClass()", "STRINGA_MinVisible" and "stricmp" being undeclared identifiers. Create a file "lint.h" in the same directory as your source code, containing the lines: #ifdef __LCLINT__ typedef char * STRPTR; typedef char * CONST_STRPTR; typedef char TEXT; #define ASM #define REG(x) #define __inline #undef __chip #define __chip #define __STORM__ #endif Then you should insert this line at the top (start) of each .c file you want to check: #include "lint.h" Now, to lint a file, you just boot from GCC-AmigaOS: (with HD1: mounted) and issue the command: lclint foo.c where foo.c is of course the file to check. The .c extension is required. Also note that LCLint is case-sensitive; ie. if your program has a line such as: #include "foo.h" and the relevant include file is actually named Foo.h, then LCLint won't be able to find it. Redirection of the output is not possible, as LCLint writes directly to the console. One workaround is to use a console such as KingCON which provides a review buffer, and save this buffer as a file. The official LCLint site at http://mm.iit.uni-miskolc.hu/Data/texts/ LCLint/ contains the manual, source code, release notes, example, etc. for V2.4b, which is similar to V2.2a+. Serial Debugging Tools ---------------------- These tools can be found in the following locations on the Amiga Developer CD 2.1: ADCD_2.1:Contributions/Olaf_Barthel/Tools/Debugging/BlowUp/BlowUp ADCD_2.1:Contributions/Olaf_Barthel/Tools/Debugging/Sashimi/Sashimi ADCD_2.1:Contributions/Richard_Koerber/Tools/Debugging/PatchWork/PatchWork ADCD_2.1:NDK/NDK_3.1/SWToolkit3/IO_Torture ADCD_2.1:NDK/NDK_3.1/SWToolkit3/MungWall or on Aminet: dev/debug/Blowup.lha dev/debug/IO_Torture.lha dev/debug/Mungwall37_64.lzh dev/debug/PatchWork.lha dev/debug/Sashimi.lha Copy them to C:. Create this script, call it "s:debug.s": Echo "Starting all..." Run >NIL: Sashimi CONSOLE Echo "Sashimi started." Run >NIL: BlowUp Echo "BlowUp started." Run >NIL: PatchWork LEVEL 1 Echo "PatchWork started." Run >NIL: MungWall Echo "MungWall started." Run >NIL: IO_Torture Echo "IO_Torture started." Echo "All started." Create this script, call it "s:undebug.s": Echo "Removing all..." Status >T:Number COMMAND=IO_Torture Break NIL: ? Echo "IO_Torture removed." Status >T:Number COMMAND=MungWall Break NIL: ? Echo "MungWall removed." Status >T:Number COMMAND=PatchWork Break NIL: ? Echo "PatchWork removed." Status >T:Number COMMAND=BlowUp Break NIL: ? Echo "BlowUp removed." Status >T:Number COMMAND=Sashimi Break NIL: ? Echo "Sashimi removed." Delete T:Number QUIET Echo "All removed." You can use the Settings|Shell|Environment|Tools-Menu|New button to create appropriate entries in the Tools menu. Don't forget to thereafter use the Settings|Save Settings menu item. Undocumented OS3.9 Functions List --------------------------------- // amigaguide.library #pragma amicall(AmigaGuideBase, 0x1E, amigaguidePrivate1()) #pragma amicall(AmigaGuideBase, 0x30, amigaguidePrivate2()) #pragma amicall(AmigaGuideBase, 0x78, amigaguidePrivate3()) #pragma amicall(AmigaGuideBase, 0x96, amigaguidePrivate4()) #pragma amicall(AmigaGuideBase, 0x9C, amigaguidePrivate5()) #pragma amicall(AmigaGuideBase, 0xA2, amigaguidePrivate6()) #pragma amicall(AmigaGuideBase, 0xA8, amigaguidePrivate7()) #pragma amicall(AmigaGuideBase, 0xAE, amigaguidePrivate8()) #pragma amicall(AmigaGuideBase, 0xB4, amigaguidePrivate9()) #pragma amicall(AmigaGuideBase, 0xBA, amigaguidePrivate10()) #pragma amicall(AmigaGuideBase, 0xC0, amigaguidePrivate11()) #pragma amicall(AmigaGuideBase, 0xC6, amigaguidePrivate12()) #pragma amicall(AmigaGuideBase, 0xCC, amigaguidePrivate13()) // asl.library #pragma amicall(AslBase, 0x42, aslPrivate1()) #pragma amicall(AslBase, 0x48, aslPrivate2()) // battclock.resource #pragma amicall(BattClockBase, 0x30, battclockPrivate1()) #pragma amicall(BattClockBase, 0x36, battclockPrivate2()) // bullet.library #pragma amicall(BulletBase, 0x3C, bulletPrivate1()) // commodities.library #pragma amicall(CxBase, 0x6C, commoditiesPrivate1()) #pragma amicall(CxBase, 0xBA, commoditiesPrivate2()) #pragma amicall(CxBase, 0xC0, commoditiesPrivate3()) #pragma amicall(CxBase, 0xC6, commoditiesPrivate4()) #pragma amicall(CxBase, 0xD2, commoditiesPrivate5()) #pragma amicall(CxBase, 0xD8, commoditiesPrivate6()) #pragma amicall(CxBase, 0xDE, commoditiesPrivate7()) #pragma amicall(CxBase, 0xE4, commoditiesPrivate8()) #pragma amicall(CxBase, 0xEA, commoditiesPrivate9()) // console.device #pragma amicall(ConsoleDevice, 0x2A, consolePrivate1()) #pragma amicall(ConsoleDevice, 0x30, consolePrivate2()) #pragma amicall(ConsoleDevice, 0x36, consolePrivate3()) #pragma amicall(ConsoleDevice, 0x3C, consolePrivate4()) // datatypes.library #pragma amicall(DataTypesBase, 0x1E, datatypesPrivate1()) // dos.library #pragma amicall(DOSBase, 0x0A2, GetPacket(d1)) // wait // aka dosPrivate1() #pragma amicall(DOSBase, 0x0A8, QueuePacket(d1)) // packet // aka dosPrivate2() #pragma amicall(DOSBase, 0x34E, dosPrivate3()) #pragma amicall(DOSBase, 0x390, dosPrivate4()) #pragma amicall(DOSBase, 0x3C0, dosPrivate5()) // exec.library #pragma amicall(SysBase, 0x024, ExitIntr()) // aka execPrivate1() #pragma amicall(SysBase, 0x02A, Schedule()) // aka execPrivate2() #pragma amicall(SysBase, 0x030, Reschedule()) // aka execPrivate3() #pragma amicall(SysBase, 0x036, Switch()) // aka execPrivate4() #pragma amicall(SysBase, 0x03C, Dispatch()) // aka execPrivate5() #pragma amicall(SysBase, 0x042, Exception()) // aka execPrivate6() #pragma amicall(SysBase, 0x1F8, RawIOInit()) // aka execPrivate7() #pragma amicall(SysBase, 0x1FE, RawMayGetChar()) // aka execPrivate8() #pragma amicall(SysBase, 0x204, RawPutChar(d0)) // char // aka execPrivate9() #pragma amicall(SysBase, 0x2E2, execPrivate10()) #pragma amicall(SysBase, 0x2E8, execPrivate11()) #pragma amicall(SysBase, 0x2EE, execPrivate12()) #pragma amicall(SysBase, 0x2F4, execPrivate13()) #pragma amicall(SysBase, 0x318, execPrivate14()) #pragma amicall(SysBase, 0x31E, execPrivate15()) #pragma amicall(SysBase, 0x324, execPrivate16()) #pragma amicall(SysBase, 0x32A, execPrivate17()) #pragma amicall(SysBase, 0x330, execPrivate18()) #pragma amicall(SysBase, 0x336, execPrivate19()) #pragma amicall(SysBase, 0x342, execPrivate20()) #pragma amicall(SysBase, 0x348, execPrivate21()) #pragma amicall(SysBase, 0x34E, execPrivate22()) // expansion.library #pragma amicall(ExpansionBase, 0x9C, expansionPrivate1()) #pragma amicall(ExpansionBase, 0xA2, expansionPrivate2()) // gadtools.library #pragma amicall(GadToolsBase, 0x8A, gadtoolsPrivate1()) #pragma amicall(GadToolsBase, 0x90, gadtoolsPrivate2()) #pragma amicall(GadToolsBase, 0x96, gadtoolsPrivate3()) #pragma amicall(GadToolsBase, 0x9C, gadtoolsPrivate4()) #pragma amicall(GadToolsBase, 0xA2, gadtoolsPrivate5()) #pragma amicall(GadToolsBase, 0xA8, gadtoolsPrivate6()) // graphics.library #pragma amicall(GfxBase, 0x282, ReleasePen(a0,d0)) // cm,n // also at -$3B4 // aka graphicsPrivate1() #pragma amicall(GfxBase, 0x288, ObtainPen(a0,d0,d1,d2,d3,d4)) // cm,n,r,g,b,f // also at -$3BA // aka graphicsPrivate2() #pragma amicall(GfxBase, 0x2E2, AddDisplayData(a0)) // aka graphicsPrivate3() #pragma amicall(GfxBase, 0x2E8, AddDisplayInfoData(a0,a1,d0,d1,d2)) // handle,buf,size,tagID,displayID // aka graphicsPrivate4() #pragma amicall(GfxBase, 0x2EE, SetDisplayInfoData(a0,a1,d0,d1,d2)) // handle,buf,size,tagID,displayID // aka graphicsPrivate5() #pragma amicall(GfxBase, 0x324, graphicsPrivate6()) #pragma amicall(GfxBase, 0x34E, graphicsPrivate7()) #pragma amicall(GfxBase, 0x38A, graphicsPrivate8()) #pragma amicall(GfxBase, 0x390, graphicsPrivate9()) #pragma amicall(GfxBase, 0x3F6, graphicsPrivate10()) // icon.library #pragma amicall(IconBase, 0x1E, GetWBObject(a0)) // name // aka iconPrivate1() #pragma amicall(IconBase, 0x24, PutWBObject(a0,a1)) // name,object // aka iconPrivate2() #pragma amicall(IconBase, 0x2A, GetIcon(a0,a1,a2)) // name,icon,freelist // aka iconPrivate3() #pragma amicall(IconBase, 0x30, PutIcon(a0,a1)) // name,icon // aka iconPrivate4() #pragma amicall(IconBase, 0x3C, FreeWBObject(a0)) // WBObject // aka iconPrivate5() #pragma amicall(IconBase, 0x42, AllocWBObject()) // aka iconPrivate6() #pragma amicall(IconBase, 0x72, iconPrivate7()) #pragma amicall(IconBase, 0x90, iconPrivate8()) // intuition.library #pragma amicall(IntuitionBase, 0x01E, OpenIntuition()) #pragma amicall(IntuitionBase, 0x024, Intuition(a0)) #pragma amicall(IntuitionBase, 0x192, AlohaWorkbench(a0)) // wbport // aka intuitionPrivate1() #pragma amicall(IntuitionBase, 0x240, intuitionPrivate2()) #pragma amicall(IntuitionBase, 0x2A0, intuitionPrivate3()) #pragma amicall(IntuitionBase, 0x2D0, intuitionPrivate4()) #pragma amicall(IntuitionBase, 0x2D6, intuitionPrivate5()) // locale.library #pragma amicall(LocaleBase, 0x1E, localePrivate1()) #pragma amicall(LocaleBase, 0xA8, localePrivate2()) #pragma amicall(LocaleBase, 0xBA, localePrivate3()) #pragma amicall(LocaleBase, 0xC0, localePrivate4()) #pragma amicall(LocaleBase, 0xC6, localePrivate5()) #pragma amicall(LocaleBase, 0xCC, localePrivate6()) #pragma amicall(LocaleBase, 0xD2, localePrivate7()) #pragma amicall(LocaleBase, 0xD8, localePrivate8()) // lowlevel.library #pragma amicall(LowLevelBase, 0x2A, lowlevelPrivate1()) #pragma amicall(LowLevelBase, 0x78, lowlevelPrivate2()) #pragma amicall(LowLevelBase, 0x7E, lowlevelPrivate3()) #pragma amicall(LowLevelBase, 0x8A, lowlevelPrivate4()) #pragma amicall(LowLevelBase, 0x90, lowlevelPrivate5()) #pragma amicall(LowLevelBase, 0x96, lowlevelPrivate6()) #pragma amicall(LowLevelBase, 0x9C, lowlevelPrivate7()) #pragma amicall(LowLevelBase, 0xA2, lowlevelPrivate8()) // workbench.library #pragma amicall(WorkbenchBase, 0x1E, wbPrivate1()) #pragma amicall(WorkbenchBase, 0x24, wbPrivate2()) #pragma amicall(WorkbenchBase, 0x2A, wbPrivate3()) #pragma amicall(WorkbenchBase, 0x54, wbPrivate4()) OS3.9 Bugs ---------- Only bugs which are still present under BB4 are listed. amigaguide.library: (a) A delay is required between the SetAmigaGuideContext() and SendAmigaGuideContext() calls. (b) No AmigaGuideMsg is sent back to the launching application when the user quits an AmigaGuide which was launched via the OpenAmigaGuideAsync() function. AnimatedIcon/GIF.datatype: "AnimatedIcon can read both, large pictures with the animation frames next to each other, while the real picture dimensions must be give in the tooltypes, and also real GIF anims. The AmigaOS 3.9 GIF datatype can of course read GIF pictures and it presents GIF animations to the application a a multi-image file. So programs like AnimatedIcon can extract each animation frame from the file and display it. AnimatedIcon ony works with the original AmigaOS 3.9 GIF datatype. There is a GIFANIM datatype on Aminet that presents GIF animations as real animations. This does not work with AnimatedIcon or any other picture viewer. I also saw that some optimised GIF anims are corrupted by the GIF datatype. But most animations work though." - Thomas Rapp. OS4.1 Bugs ---------- Only bugs which are still present under OS4.1.1 are listed. These bugs do not occur under OS3.9. Hyperion is aware of most or all of these but has not bothered to fix them. The OS3.9 bugs which are listed above may or may not be present under OS4.1.1. keyboard.device: (*) KBD_READMATRIX does not work correctly (returns 0s for all keys). ReAction: (*) When you click on any button with mixed text and graphics, they don't have a transparence effect. It shows an azure background around the text. Version: (a) Version strings which are not prepended by a NUL ($00) byte are not parsed correctly. (b) Multiple version strings in one file confuse the parser. MorphOS 2 Bugs -------------- ReAction: (*) ReAction iconification gadgets are not skinned correctly and thus look bad. END OF DOCUMENT-----------------------------------------------------------