AMIGA NOTES ----------- This document contains various notes, tips and proposals for Amiga programmers and users, and lists of known bugs and workarounds for various software. It was written by James Jacobs of Amigan Software on 9/8/04, and last updated on 17/7/24. 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 ReActor Extra Files Function Equivalents Online Help Lint Serial Debugging Tools Undocumented AmigaOS Porting to OS4 OS3.9 Bugs OS4.1 Bugs MorphOS Bugs ReAction Bugs ReSource 6.06 Bugs SAS/C 6.59 Notes StormC Bugs GCC 4.2.4 Notes VBCC Annoyances WHDLoad Notes Floppy Notes MorphOS Networking MorphOS Upgrading OS4 on WinUAE Notes AmigaOS Improvements AISS on OS3 Enhancer Software Bugs BOOPSI Tag List OS3.5 Icon Format bookmark.device 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 (in StormC) 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. 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. Also, for WinUAE users, we suggest the following script: SegTracker >NIL: ;45.1 (9.8.2004) VBRcontrol ON >NIL: ; 1.0 (16.2.2000) WinUAEenforcer >NIL: This will tell you about Enforcer hits (illegal memory accesses). Undocumented AmigaOS -------------------- This has now been expanded and made into its own document. See http://amigan.1emu.net/releases/UndocumentedAmigaOS.lha Porting to OS4 -------------- At the top of source files, add: #ifdef __amigaos4__ #define __USE_INLINE__ // define this as early as possible #else #define ZERO (BPTR) NULL #endif #define ASL_PRE_V38_NAMES #include #define __USE_OLD_TIMEVAL__ #include Change all #include to #include and move these #includes to the end of the #includes. Change all BPTR NULLs to ZERO. Change: #ifndef __STORM__ IMPORT struct ExecBase* SysBase; #endif to: #if (!defined(__STORM__)) && (!defined(__amigaos4__)) IMPORT struct ExecBase* SysBase; #endif You should declare interfaces, eg.: #ifdef __amigaos4__ EXPORT struct IntuitionIFace* IIntuition = NULL; #endif After opening libraries, you should add eg.: #ifdef __amigaos4__ IIntuition = (struct IntuitionIFace*) GetInterface((struct Library*) IntuitionBase, "main", 1, NULL); #endif and likewise when quitting: #ifdef __amigaos4__ if (IIntuition) { DropInterface((struct Interface*) IIntuition); } #endif Change eg. SysBase->LibNode.lib_Version to eg. SysBase->lib_Version In your InitHook() function, change: hook->h_Entry = (ULONG (*)()) HookEntry; to: #ifdef __amigaos4__ hook->h_Entry = func; #else hook->h_Entry = (ULONG (*)()) HookEntry; #endif OS3.9 Bugs ---------- These might also be present in earlier or later versions of AmigaOS. There is a separate "ReAction Bugs" section of this document, listing bugs in the ReAction GUI. See also the list at http://lilliput.amiga-projects.net/ABugs.htm 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 as 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. appp.device 3.4: "I kept getting "SANA2 COULD NOT BE PUT ONLINE" when trying to connect to my dialup ISP. I switched back to appp.device from the OS3.9 CD and the problem went away." - Kevin Hoague. asl.library 45.4: If you type a nonexistent path into the "Drawer" gadget (eg. SYS:Foo when there is no such drawer) and then press ENTER, then (after you have declined any offer to create the drawer), the program which called the ASL library will crash (suspend/reboot requester) with error $80000005. xadmaster and therefore unarc turns spaces in LHAs into underscores when extracting. OpenURL 7.17 prefs editor requires a large stack. AWeb (BB4 version): It requires a decent stack (eg. 6K is *not* enough). AWeb creates the AWebPath: assign at startup (if it doesn't already exist), and removes the AWebPath: (whether created by itself or not) at exit. This will cause problems if eg. you then click on a project icon which has a tooltype of "AWebPath:AWeb". Some images on web pages (eg. Abandonware Page) are not being shown (just placeholders instead). Some image colours are very wrong (eg. black instead of white). Not enough pens? But shouldn't it still use the closest available colour? The font size is always 8. C:Dir and C:List commands: Softlinks are shown as directories. dos.library: LoadSeg() will always report success on files that are less than 4 bytes in size, even though the smallest valid executable is 36 bytes. Files from 4-35 bytes in size are still correctly reported as non-executable. IconEdit: The clipboard functionality (eg. "Edit|Copy", "Edit|Paste") is broken (gives "Couldn't read message from the clipboard" error). Similarly for "Images|Load >>|Image...". Also, when switching from "Old Image" to "New Image", the palette for the old image seems to be used for the new image. "It should allow to save the icon in defined size (instead of always doing an optimized save which is wrong for many icons)." icon.library: ICONPUTA_OptimizeImageSpace does nothing in any existing version of AmigaOS or MorphOS, including PeterK's icon.library replacement. (PeterK's icon.library does the optimization automatically whenever PutIconTags() is called, without needing to use this tag.) Installer: The documentation for the "askchoice" function is wrong. The result of "askchoice" is returned as a zero-based ordinal integer, not a bit mask. intuition.library: If you have a GimmeZeroZero window with one or more GFLG_RELRIGHT gadgets, and the window gets resized, some areas near the top of the window are not redrawn. This is fixed in OS3.2 and OS4.1FEu1. lowlevel.library: Not really a bug but something that is easy to overlook: You must call SetJoyPortAttrs(unit, SJA_Reinitialize, NULL, TAG_END) for each unit you have called ReadJoyPort(unit) on, before closing lowlevel.library. This applies to OS3.1 as well. MultiView 44.10: Transparencies are ignored (at least when using ILBM.datatype V44.9) when showing images. MultiView timing is incorrect for playback of (at least) IFF ANIM. Eg. the file ADCD_2.1:EXTRAS/IFF/TEST_FILES/ANIM/COLORSPIN.256.ANIM is 32 frames, each of 1/60th sec (as can be seen by looking at the ANHD chunks in Report+), so should take about half a second to play back, but instead takes about 6 seconds. Most likely the bug is in animation.datatype or ANIM.datatype . This bug occurs on both OS3.9 and OS3.1.4. AmigaGuides containing lines longer than 4095 characters cannot be opened ("bad data"). This applies to OS3.9 and 4.1FEu1, but is fixed for OS3.2. png.datatype: All OS3 versions (including 3.2) don't handle PNGs with alpha channel transparencies correctly. RAWBInfo: Rightmost characters in tooltypes texteditor are not reliably shown (probably texteditor.gadget bug?). SetPatch 44.38 (BB2): This attempts to perform a ROM checksum on reboot after installing the AmigaOS ROM Update and crashes the system. Users of a Flash ROM or softkicked ROM are unlikely to experience this problem if the 3.9 ROM was created with Remus. The are presently two workarounds for this problem. "SetPatch SKIPROMUPDATES exec.library" for SetPatch 40.38 or use SetPatch 40.17 from BB1. "ram" is not understood by SetPatch to be synonymous with "ram-handler". SetPatch 44.40 (older BB4s): This has been reported to cause infinite reboots on some systems, unless "SKIPROMUPDATES exec.library" is used. You can modify your startup-sequence as follows: C:Version >NIL: exec.library 45 If WARN C:LoadResident >NIL: Libs:exec.library EndIf C:SetPatch QUIET SKIPROMUPDATES exec.library "Now, I will explain why I believe this works. Setpatch >44.17 attempts to place the Kicktags in FASTMEM which causes exec.library to fail on reboot. Loadresident places the Kicktags in CHIPMEM and exec.library works fine. Apparently, the SetPatch AVOIDMEMFKICKFORPATCHES option is broken! So until SetPatch can be fixed, the above startup-sequence should provide a workaround." - Kevin Hoague. text.datatype 45.14: "It is buggy displaying underlined text (eg. from an ANSI file) when scrolling up/down. If you try to scroll up/down this file in a window on WB (https://nofile.io/f/oSfJ6VUGmgs/Banshee_manual.txt) you'll see the section "Pick Ups" will sometimes miss underline...doesn't happen with old text.datatype 40.3." UnArc: It replaces spaces in filenames by underscores when unpacking LhAs, due to a bug in xadmaster.library. version.library: It doesn't seem to like being closed if some other program still has it open (very briefly flashes up some guru alert). workbench.library: When any program like AsyncWB is running, selecting multiple files and/or directories and then copying them with the Workbench "Icons|Copy" command will only copy the first file/directory. This is confirmed to be a Workbench bug (rather than eg. an AsyncWB bug) and has been fixed for OS3.2 and OS4. OS4.1 Bugs ---------- Generally, only bugs which are still present under OS4.1.1 and/or OS4.1FEu1 are listed. These bugs do not occur under OS3.9. The OS3.9 bugs which are listed above may or may not be present under OS4.1FEu1. audio.device: (*) OS4.0, at least, will report success for opening/using/closing audio.device, but will not actually make any sound, even on systems that have real Paula hardware. This may or may not have been fixed for OS4.1.1, who knows? Where are the fucking changelogs!? bitmap.image: (*) Transparent IFF ILBMs are not shown correctly unless you provide BITMAP_Width and BITMAP_Height tags. boot: (*) Sometimes, while booting, it hangs on a green screen; resetting will allow allow booting to continue. This may be a WinUAE issue. checkbox.gadget: (*) CHECKBOX_BackgroundPen has no effect. exec.library: (*) Alert() is broken: Alerts cannot be closed on a SAM; only on a PS/2 interface, not a USB or Synergyc interface. Consequently, DisplayAlert() (in intution.library) is likewise broken. (You can use http://aminet.net/util/misc/AlPatch.lha (or similar) to work around this.) Installer: (*) Installer V44 functionality (such as the "effect" command) is not supported by the OS4.x Installer and will cause the script to abort with an error message. intuition.library: (a) MENUDISABLEDTEXTPEN does not exist. Therefore, there is no method of specifying the colour for the text of disabled menus and menu items. Using the SA_LikeWorkbench, TRUE tag seems to help AmigaOS to choose a reasonable pen for this. (b) It isn't documented which pen is used for the highlight on selected menu items. It is probably SELECTPEN, but could possibly instead be GLYPHFILLPEN or FILLFLATPEN. (Not strictly a bug.) (c) To get sticky menu support, you need to use the SA_LikeWorkbench, TRUE tag. (d) Autoscrolling screens seem to be always forced by the OS into an AGA mode. On closing such a screen, there can be eg. a corrupt Workbench screen. keyboard.device: (*) KBD_READMATRIX does not work correctly (returns 0s for all keys). layout.gadget: (*) When replacing a group box at given coordinates with another group box, with different text, the background of the old text is not erased properly (if the new text is narrower, in pixels, than the old text). lowlevel.library (and perhaps gameport.device): (*) Joysticks plugged into the classic joystick sockets (eg. on a Classic Amiga or WinUAE) do not work. ReAction: (a) When you click on any button with mixed text and graphics, they don't have a transparency effect. It shows an azure background around the text. You need to use the BITMAP_Transparent tag (and perhaps BITMAP_Masking?). (b) string.gadgets and integer.gadgets which are inside a virtual.gadget do not have a bevel rendered for their their edit box. This occurs under OS4.1FEu2 (but not OS3.x, as far as is known). 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. (c) "If I create a file with nothing but the OS3 executable identifier ($000003F3) at the beginning followed by a valid version string, the Version command won't find the version. If the executable identifier is replaced with anything else (binary or alphanumeric) then the Version command works. My suspicion is that if the Version command finds an OS3 executable identifier at the beginning of a file, it only looks for a version string in a particular type of Amiga OS hunk. If that's not the case then it is a complete mystery to me. Regardless, the Version command should get fixed for the next OS4 release." window.class: (*) If a CHILD_MinWidth is passed, the window size code is assuming that is the actual width of the layout, but the layout itself realizes that the passed CHILD_MinWidth is insufficient and widens it. Hence, the window is (when opened) not wide enough for its gadgets. (OS4.1FEu2) Workbench: (a) Close gadget clicks on a Workbench window are ignored while Workbench is reading the directory. (b) The free space calculation in the titlebar of a drive's window (and thus also the fuel gauge in the left border of the window) can be incorrect. Eg. when "96.8Gb free, 352.2Gb in use" (which is correct), it declares "1% full"; it is truthfully over 3/4 full. MorphOS Bugs ------------ Ambient: (a) "New drawer..." on the popup menu doesn't work if there is no icon selected. (b) Icons do not appear at the correct coordinates as specified in the .info file. asl.library: (*) It changes the palette (eg. on custom screens) when opening an ASL requester, and doesn't restore the palette afterwards. bullet.library: (*) The entire library is missing, therefore it lacks CompuGraphic font support. You need to copy this over from your OS3.9 CD. Filesystem: (*) The filesystem becomes confused by filenames containing characters such as (eg. StormC project files). exec.library: (*) NewGetTaskAttrs() with TASKINFOTYPE_STACKSIZE always returns 32756 as the stack size, regardless of the actual stack size. gadtools.library: (*) For text-entry gadgets (at least), GA_Disabled of TRUE seems to be ignored for CreateGadget(), although it works for GT_SetGadgetAttrs(). graphics.library: (*) PlanePick and PlaneOff are incorrect (compared to eg. OS3.x), in DrawImage() and for GELs, at least, resulting in different colours being used. Also, the old bob imagery is not always erased when they are moved or removed. intuition.library: (a) ShowTitle() has its logic inverted; ie. TRUE will hide it, and FALSE will show it. (b) Replying to a MENUHOT IDCMP_MENUVERIFY message with MENUCANCEL via GT_ReplyIMsg() does not cancel the menu operation (and no MENUUP message is generated either). Sometimes using ReplyMsg() instead will fix the problem; other times this doesn't help. (c) Custom checkmark imagery for menus does not work. (d) WA_ExtraGadgets_Iconify does not work when called from ReAction (has no effect). (e) Screen dragging via mouse does not work. (f) Screen depth-arrangement via keyboard does not work. (g) Pop-up menus do not work by just holding the right mousebutton and releasing it. You must also press the left mousebutton when you have reached the desired menu item. keyboard.device: (a) About 90% of the time, the backspace, Delete, Tab, and cursor keys have no effect in MUI string gadgets (eg. ASL requesters, the Find utility, Preferences, etc.). This has been tried under various versions of MorphOS and with several different keyboards. (b) The Caps Lock sends a KEYDOWN code whenever it is pressed, and sends a KEYUP code when it is released. This is different to the behaviour under eg. AmigaOS 1.0-3.9, where KEYDOWN is sent when it is turned on, KEYUP is sent when it is turned off, and no code is sent when it is released. (c) The Left Windows key is being mapped to the Right Amiga key instead of to the Left Amiga key. (d) It is not possible to reset via keyboard (or menu) if the system is frozen. It is necessary to power cycle in such cases. lowlevel.library: (a) Force feedback (rumble) does not seem to work? (b) Buttons 8-12 (at least) are not detected by ReadJoyPort(). (c) Often, calling SetJoyPortAttrs(foo, SJA_Type, SJA_TYPE_AUTOSENSE) will hang the machine (depending on what USB devices are attached). This is caused by Poseidon's patching of lowlevel.library at boot. Multiview: (*) It is unable to read most or all IFF ANIMs. ReAction: (a) ReAction iconification gadgets are not skinned correctly and thus look bad. (b) window.gadget 45.16 requires functionality that is not present on MorphOS; opening it will cause a hang. (c) If a window is too wide or tall for the screen, and thus gets truncated, this seems to make page.gadget unstable, and therefore eg. changing pages can cause the system to go into a mode whereby all input (mouse and keyboard) is thereafter ignored (although programs will still continue to run). (d) MorphOS compatibility with texteditor.gadget (V15.5 and V15.8 were tested) is badly broken: ENTER has no effect, and generally the system will hang after about ten characters have been entered into the gadget. But even read-only and/or disabled gadgets will cause instability. (e) Scrolling a speedbar (ie. holding down Shift while click-dragging sideways) will hang the machine. Miscelleanous: (a) The nagware requester reappears whenever OK is pressed. If the requester is intended to be persistent, it should not have an OK button. (b) Occasionally, the system fails to complete booting (possibly a fault with the hardware used for testing rather than with MorphOS). (c) On this hardware, at least (Mac Mini G4 Cube), the speaker socket does not work. (d) There is no way to disable the annoying boot sound from MorphOS. The suggested solution involves downloading over 700Mb and installing another OS. usb.device: (*) After the computer has awoken from a sleep state, you must disconnect and reconnect the mouse before it (the mouse) will function. This also occurs under V3.3. To improve the behaviour (to make it closer to OS3.9) you can do this: Choose "Settings|Ambient..." from the Ambient menu. On the "Icon Display" tab, in the Resizing group, change Minimum Size to Micro. Click Save. Choose "Settings|System" from the Ambient menu. Click IControl. Untick "Menus shall remain opened even when mouse button is released". Click Save. In the latest MorphOS GCC, assigning NULL to eg. a ULONG requires a cast. ReAction Notes -------------- These fall back completely (font, width and height): checkboxes integers strings child labels (on OS3.2) On 3.9, child labels fall back for font and height, but not width. These fall back for font but not for width and height: buttons listbrowsers These don't fall back at all: standalone labels The rest of these ReAction notes are concerned with bevels: As far as frameiclass.c is concerned: STROKEHEIGHT is always 1 StrokeWidth[] can be 1 or 2 These are the Intuition frame types: Size Strokes InsetBox WidthPad HeightPad StrokeWidth STROKEHEIGHT Equivalent 0: FRAME_DEFAULT 1*1 1 0 4 4 1 1 -> BVS_THIN 1: FRAME_BUTTON 2*1 1 0 8 4 2 1 -> BVS_BUTTON 2: FRAME_RIDGE 4*2 2 1 12 6 2 1 -> BVS_FIELD 3: FRAME_ICONDROPBOX 6*3 2 2 16 8 2 1 -> BVS_DROPBOX 4: FRAME_CONTEXT ? 2 (special) 6 6 1 1 -> BVS_THIN IM_FRAMEBOX: fbox will be -WidthPad[]/2, -HeightPad[]/2 Caller (ie. bevel.image) passes a (zeroed, in this case) contents box to frameiclass: fbox->Left = 0 - ((fbox->Width - 0) / 2); fbox->Top = 0 - ((fbox->Height - 0) / 2); A complete FRAME_RIDGE, including space, with nothing inside it, looks like this: SSSSSSSSSSSS S=Space SSOOIIIIOOSS O=Outer SSOOIIIIOOSS I=Inner SSOOIIIIOOSS SSOOIIIIOOSS SSSSSSSSSSSS Its contents, if it had any, would be in the middle of the Is. WidthPad[FRAME_RIDGE] can be explained as follows: WidthPad[FRAME_RIDGE] = ((InsetBox[frametype] + 2) * StrokeWidth[frametype]) * 2; WidthPad[FRAME_RIDGE] = (( 1 + 2) * 2) * 2; // == 16; So, WidthPad[] is the total (ie. both sides) width of the bevel, plus a stroke width's worth of space on each side. InsetBox[frametype] takes care of the outer bevel, if there is one. The +2 is for the inner bevel and the spacing. HeightPad[FRAME_RIDGE] can be explained as follows: HeightPad[FRAME_RIDGE] = ((InsetBox[frametype] + 2) * STROKEHEIGHT) * 2; HeightPad[FRAME_RIDGE] = (( 1 + 2) * 1) * 2; // == 6 So, HeightPad[] is the total (ie. both sides) height of the bevel, plus a stroke height's worth of space on each side. InsetBox[frametype] takes care of the outer bevel, if there is one. The +2 is for the inner bevel and the spacing. LBarGT/RA[] is horizontal thickness (horizontal Length) of vertical lines (per edge). TBarGT/RA[] is vertical thickness (vertical Tallness) of horizontal lines (per edge). GT is used for the GadTools style. RA is used for all other styles. bevel.image (in adaptstyle() function) does these changes: for Thin mode: BVS_STANDARD (11) or BVS_BUTTON (1) -> BVS_THIN (0) BVS_FIELD (3) -> BVS_GROUP (2) for Thin XEN and XEN modes: BVS_FIELD (3) -> BVS_GROUP (2) and we should probably also be converting BVS_BUTTON (only) -> BVS_THIN (0) if we wanted it to really look XENish. layout.gadget does these changes for group bevels: BVS_BUTTON (1) -> BVS_STANDARD (11) Visual observations: ---------OS3.9----------+---------OS3.2---------- GT Thin Thick XEN T-XEN|GT Thin Thick XEN T-XEN ------------------------+------------------------ 0: BVS_THIN 1*1 1*1 1*1 1*1 1*1 |1*1 1*1 1*1 1*1 1*1 1: BVS_BUTTON 2*1 ->0 3*2 2*2 1*1 |2*1 ->0 3*2 2*2 1*1 2: BVS_GROUP 2*2 2*2 2*2 2*2 2*2 |4*2 2*2 2*2 2*2 2*2 3: BVS_FIELD 4*2 ->2 4*2 ->2 ->2 |4*2 ->2 4*2 ->2 ->2 4: BVS_NONE 0*0 0*0 0*0 0*0 0*0 |0*0 0*0 0*0 0*0 0*0 5: BVS_DROPBOX 8*4 8*4 8*4 8*4 8*4 |6*3 8*4 8*4 8*4 8*4 6: BVS_SBAR_HORIZ ? ? ? ? ? | ? ? ? ? ? 7: BVS_SBAR_VERT ? ? ? ? ? | ? ? ? ? ? 8: BVS_BOX ? ? ? ? ? | ? ? ? ? ? 9: BVS_FOCUS ? ? ? ? ? | ? ? ? ? ? 10: BVS_RADIOBUTTON ? ? ? ? ? | ? ? ? ? ? 11: BVS_STANDARD 2*1 ->0 2*1 2*1 2*1 |2*1 ->0 2*1 2*1 2*1 OS4 only... 12: BVS_CONTAINER ? ? ? ? ? | ? ? ? ? ? 13: BVS_KNOB ? ? ? ? ? | ? ? ? ? ? 14: BVS_DISPLAY ? ? ? ? ? | ? ? ? ? ? -> means it is converted to another BVS type as indicated. 3.9 and 3.2 are identical, except that 3.2 in GT mode changes GROUP from 2*2 to 4*2 and DROPBOX from 8*4 to 6*3. ReAction Bugs ------------- This is a list of ReAction bugs occurring on OS3.9+BB2 (and OS3.9+BB4). Most of them have been fixed for OS4 (OS4.1FEu1 is what we used for testing but in most cases they were fixed considerably earlier). OS3.9 only (fixed or at least explained for OS3.2): * bevel.image: (a) On 3.9, BVS_STANDARD bevels in BVT_XENTHIN style are rendered at 2*1 thickness instead of 1*1. Fixed for 3.2. (b) On 3.9, the default BEVEL_Style is actually BVS_GROUP despite it being documented to be BVS_BUTTON. On 3.2 and 4.1FEu1, the actual behaviour has been changed to match the autodoc. * button.gadget: (a) On 3.9 and 4.1FEu1, there is an excessive amount of horizontal padding (10 pixels). On 3.2, this has been reduced so it now matches the vertical axis (4 pixels). (b) On 3.9, BUTTON_AutoButtons selected via keyboard tabbing do not rendering their glyph (you just get a solid block of FILLPEN). This is fixed for 3.2. * chooser.gadget: (a) OS3.9 and OS4 do not support images in chooser gadgets, only in the pop-up menus of those gadgets. OS3.2 does support this. (b) Pop-up chooser gadgets cannot have a label; you must use a separate label image object for this purpose. If you pass GA_Text, the gadget does not use it for anything. This is now stated explicitly in the OS3.2 NDK. * clicktab.gadget: (a) On OS3.9, when you programmatically change CLICKTAB_Current, clicktab.gadget sometimes becomes confused and does not update all its internal variables; it still thinks the old tab is selected and therefore will a) generate WMHI_GADGETUP messages when the new tab is clicked on, and b) not generate WMHI_GADGETUP messages when the old tab is clicked on. Fixed in OS3.2 and OS4. (b) CLICKTAB_Current is wrongly documented: OM_GET isn't listed as a supported operation even though it works. The documentation has been corrected in the OS4.x SDKs. (c) AllocClickTabNode() is documented as having a "columns" input argument. This argument does not exist. (d) CLICKTAB_PageGroup supposedly requires V42, but apparently V41.43 supports it too (eg. V41.43 is the version included in Aminet's classact33.lha, and the example included therein uses that tag). (e) GA_Disabled has no effect (gadget is still enabled). This bug doesn't happen on OS3.2 nor OS4.1FEu1. * drawlist.gadget: (*) DLST_CIRCLE and DLIST_ELLIPSE are broken (radii are far too large). This bug applies to OS3.9 and OS4.1FEu1, but is fixed for O3.2. * fuelgauge.gadget: (a) If ReAction falls back to the fallback font, the initial GA_Text will appear in the fallback font, but changing GA_Text later will either just blank the text, or use the non-fallback font. This appears to have been fixed for OS3.2 (seems always to use the non-fallback font). (b) On 3.9, ticks are still shown even if FUELGAUGE_TickSize is 0. Fixed for 3.2. (c) Various other rendering bugs, especially with FUELGAUGE_Orientation, FGORIENT_VERT, are present in 3.9 but have been fixed for 3.2 (and probably fixed for 4.1FEu1 also). * gradientslider.gadget: (*) 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). These bugs are only on OS3.9, not on OS3.2 nor OS4.1FEu1. * integer.gadget: (a) On OS3.9, there is an upper limit (ie. INTEGER_Maximum) of 1,410,065,407. (It is documented to support signed 32-bit numbers, ie. up to 2,147,483,647.) (b) Integer gadgets are too wide for INTEGER_MinVisible characters. (c) Attempting to enter high numbers can cause the gadget contents to become corrupt, typically containing the gadget's *previous* contents, a NUL (square), and the final digits of the new contents. (d) Setting INTEGER_Min/MaxValue is not sufficient unless you also ensure INTEGER_MaxChars is high enough (eg. INTEGER_MaxChars of 11 is necessary for numbers <= -1,000,000,000). This is still true for OS3.2 but is now mentioned in the NDK. * label.image: (a) 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. (b) On 3.9, text and images are not vertically centred. This is fixed for 3.2. 4.1FEu1 has the LAYOUT_VertAlignment tag which is another solution to the issue. (c) On 3.9 and 4.1FEu1, mixing images and multi-line text will cause incorrect size of the label and incorrect positioning of its elements (eg. the second and later lines of multi-line text being rendered at the far left). This is fixed in 3.2. * layout.gadget: (a) In GM_DOMAIN, the width of the widest label was being added to the minimum width of members having no label, when computing the minimum width of a vertical group. That could make certain layouts much wider than actually necessary. Fixed in 3.2 and 4.1FEu1. (b) LAYOUT_LabelImage does nothing (this fact is mentioned in the 3.2 and 4.1FE NDKs). (c) If the user has a tall screen font, child labels are not necessarily tall enough on 3.9. Fixed in 3.2 and 4.1FEu1. (d) Tooltips are not shown if there is an active gadget. Occurs on 3.9 and 4.1FEu1, fixed for 3.2. (e) The passed CHILD_MinWidth/Height could be used even when they were not large enough. This affects 3.9 and 4.1FEu1, but is fixed for 3.2. (f) Group labels for LAYOUT_BevelStyle of BVS_NONE are still being drawn in some circumstances, under 3.9 at least. Fixed for 3.2. (g) When using LAYOUT_ShrinkWrap, the space saved by removing the inter-gadget spacing is added to the right or bottom of the group, so the group does not actually shrink. This occurs on 3.9, and is fixed for 3.2. (h) On 3.9, in fallback mode, CHILD_Label objects still have their original (larger) widths. Fixed for 3.2. OS4 has no concept of fallback mode. (i) On 3.9, Thin XEN bevels are being considered to be 2*1 instead of the 1*1 they actually are, leading to spacing differences between eg. Thin and Thin XEN modes. (j) On 3.9 and 4.1FEu1, the LABEL_Justification of CHILD_Labels has no effect. This is fixed for 3.2. (This is a layout.gadget issue rather than a label.image one). (k) The specified IA_Font is respected for BVS_FIELD but ignored for (at least) BVS_GROUP and BVS_SBAR_VERT, at least on OS3.2.1. * listbrowser.gadget: (a) If you want LBNCA_CopyText, you must specify it *before* specifying LBNCA_Text. This is mentioned in the OS3.2 and OS4 NDKs, but not the OS3.9 NDK. (b) Passing LISTBROWSER_MinVisible with the number of nodes in the list can result in an excessively tall listbrowser (eg. it assumes there are always column titles). Occurs in 3.9 and 4.1FEu1, but fixed for 3.2. (c) Column widths are not changeable. Even though you can change the number of and/or titles of columns, the previous column widths are being retained on 3.9 and 4.1FEu1. Fixed for 3.2. (d) Clicking on an empty part of the listbrowser can send a GADGETUP message. (This bug is fixed for 3.2 and 4.1FEu1.) The workaround is, when passing LISTBROWSER_Labels, to also pass LISTBROWSER_Selected, (ULONG) ~0 . (e) CIF_DRAGGABLE separators can only be dragged when the mouse is over the table body, not over the column headers. This is fixed in 3.2 and 4.1FEu1. (f) You cannot give LISTBROWSER_MakeVisible at the same time as LISTBROWSER_Labels. You must give make separate calls to SetGadgetAttrs() for each. This applies to 3.9 and 4.1FEu1, but is fixed for 3.2. (g) Clicking on a read-only item deselects the currently selected item. This happens on 3.9 and 4.1FEu1, but has been fixed for 3.2. (h) Listbrowsers with column titles and vertical scrollbars have cosmetic corruption of the top of the scrollbar on OS3.9. This does not occur on OS3.2 nor OS4.1FEu1. (i) The CIF_NOSEPARATORS flag has no effect; separators are still drawn. Fixed for 3.2. (j) LISTBROWSER_VertSeparators/LISTBROWSER_Separators, FALSE is broken: column titles still have separators, and column bodies (ie. non-title rows) are too wide and don't align with the titles. Fixed for 3.2. (k) LISTBROWSER_AutoFit columns with images are 3 pixels too wide on 3.9. (l) The default (built-in) LISTBROWSER_LeafImage glyph is blank. This is mentioned in the 3.2 autodocs. (m) Hierarchical listbrowsers will use the leaf image for all nodes, even non-leaf nodes, unless you set LBNA_Flags to LBFLG_HASCHILDREN. This is mentioned in the 3.2 autodocs. (n) giving LISTBROWSER_Labels, NULL doesn't update the vertical scrollbar accordingly on 3.9 (but giving LISTBROWSER_Labels, &EmptyList does). (o) When editing listbrowsers that have imagery, the string gadget is positioned at top of the cell rather than in the middle. (But so is the normal text anyway.) Fixed for 3.2. (p) AllocLBColumnInfo()/AllocLBColumnInfoA() are not completely implemented in 3.9 and 3.2 and thus do not work. This is mentioned in the 3.2 autodocs. (q) If weighted and fixed-width columns are used in the same listbrowser, the calculation of the width of the weighted columns and of the overall gadget width will be wrong. This is fixed in OS3.2 and OS4.1FEu1. * page.gadget: (*) ActivateLayoutGadget() does not work correctly with pages, if you pass the window's root layout instead of the page's root layout (can cause issues like pop-up choosers popping open when changing pages, etc.). This is fixed in OS3.2 and OS4.1FEu1. * palette.gadget: (*) PALETTE_ColourTable expects a UWORD*, not a UBYTE* . Corrected in OS3.2 and OS4 autodocs. * radiobutton.gadget: (*) GA_Disabled, FALSE doesn't visually unghost the gadget (even after calling RefreshGadgets()) on OS3.9. * scroller.gadget: (a) Using small values for CHILD_MinHeight causes cosmetic problems, and gadget selection problems. Probably, the same applies for CHILD_MinWidth. This only affects OS3.9; OS3.2 and OS4.1FEu1 will force a minimum size to avoid the problem. (b) Scrollers don't work properly if there are a lot of lines to scroll through (eg. 60,000 or so). Fixed in 3.2 (and 4.1FEu1?). * slider.gadget: (*) Using large values for eg. SLIDER_Max can cause problems. The limit is documented (in OS4.1 SDK) as 65535, but in practice is far lower. This only happens on 3.9. 3.2 and 4.1FEu1 are OK. * speedbar.gadget: (a) Speedbars with CHILD_WeightedWidth of 0 are not sized correctly (not quite enough space for 4 buttons is allocated). This is fixed for 3.2 and 4.1FEu1. (b) The WINDOW_HintInfo feature of window.class doesn't work correctly for speedbar buttons which have an ID of 0. This applies to 3.9 and 4.1FEu1, works OK on 3.2. (c) The minimum width/height of horizontal/vertical speedbars is too wide/tall when using less than 4 buttons, on 3.9 and 4.1FEu1. Fixed for 3.2. * string.gadget: (a) In STRINGA_ReplaceMode, it is not possible to overwrite characters when the string is at its maximum permitted length. Occurs on 3.9 and 4.1FEu1, fixed for 3.2. (b) if you increase STRINGA_MaxChars, you must also supply sufficiently large display/edit/undo buffers with the STRINGA_Buffer, STRINGA_WorkBuffer and STRINGA_UndoBuffer tags. This is now stated explicitly in the OS3.2 NDK. (c) On OS3.9, STRINGA_MaxChars includes the NULL terminator; therefore you must set it = strlen(string) + 1 . Even then, this may not be enough for eg. proportional fonts. On OS4.1FEu1, on the other hand, string gadgets are excessively wide. These issues are fixed for OS3.2. (d) When setting STRINGA_MinVisible or INTEGER_MinVisible for editable gadgets, be aware that the system does not allocate space for the cursor. Therefore, for editable gadgets, 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). This is fixed for OS3.2. (e) For proportional fonts, string gadgets are not always wide enough to show STRINGA_MinVisible characters, or are too wide, depending on the font. Occurs on 3.9 and 4.1FEu1. * tapedeck.gadget: (*) The 3.9 and 4.1FEu1 versions of this gadget have the wrong height (gadget is considered to be 16 pixels tall but only 15 rows are drawn). They also are positioned and redrawn wrongly when used with GFLG_RELRIGHT/BOTTOM. These bugs are fixed for 3.2. * texteditor.gadget: (*) Doing an ActivateLayoutGadget() on a texteditor.gadget causes an Enforcer hit on 3.9, but not on 3.2. * window.class: (a) 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. This is now mentioned in the OS3.2 and OS4 NDKs; these OSes also have the new WINDOW_NoDisposeIcon tag which can be used to change this behaviour. (b) WMHI_NEWSIZE, etc. are not sent unless the appropriate WA_IDCMP flags have been enabled. Documented this for 3.2. (c) If the user resizes the window, this change is not reflected in eg. the WA_Width attribute; you need to look at the Width member of the struct Window instead. Only affects 3.9. 3.2 and 4.1FEu1 are OK. (d) WA_Width and WA_Height behave like WA_InnerWidth and WA_InnerHeight when eg. opening a window. This is mentioned in the 3.2 and 4.1FEu1 window.class autodocs. (e) On 3.9 and 4.1FEu1, WMHI_VANILLAKEY messages are sent only on the key upstroke (release), in violation of the Style Guide. On 3.2, this has been changed so they are sent on the downstroke instead. These affect both OS3.9 and OS3.2, at least (currently): * button.gadgets: (a) You can't receive any IDCMP_MOUSEBUTTONS or IDCMP_GADGETDOWN messages for the down-press of the left mouse button over a button (no matter what hooks, IDCMP flags, etc. are enabled), even if the button is read-only and disabled. Not really a bug. (b) For some reason, BAG_POPUP uses GLYPH_DROPDOWN instead of GLYPH_POPUP. * layout.gadget: (*) 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. This occurs on 3.9 and 3.2 but is fixed on 4.1FEu1. * string.gadget: (a) STRINGA_Justification only has effect in situations where the entire string can fit into the gadget. Otherwise, the displayed part of the string is right-justified (ie. only the end of the string is shown). Occurs on 3.2, 3.9, 4.1FEu1. (b) STRINGA_FixedFieldMode is ignoring all input. Occurs on 3.2, 3.9, 4.1FEu1. * texteditor.gadget: (a) GA_TEXTEDITOR_Pen has no apparent effect. Likewise for sending colour change escape sequences. (b) Support for text colours and styles (eg. bold) is not implemented, contrary to the documentation. (c) Not strictly a bug but an inconsistency worth noting: the global library base variable is TextFieldBase, not TextEditorBase. * virtual.gadget: (a) Buttons contained in a virtual.gadget do not hear the first mouse click, on all 68K versions of this gadget (this is fixed for BB3). On OS4 it works correctly. (b) Putting a weightbar inside a virtual.gadget causes a guru (at least on OS3.2, not sure about OS3.5/3.9/4.x). * window.class: (a) It doesn't seem possible to use window.class (specifically, WMHI_HANDLEINPUT) with windows containing (at least certain kinds of) GadTools gadgets, due to differences in message handling. Probably a design limitation; possibly even a bug in GadTools. (b) Remember that any IDCMP hook you install for one window will not be called while you have another modal window open; this is a problem particularly for IDCMP_MENUVERIFY. You should turn that flag off in the main window before opening a subwindow (and restore it afterwards, of course). OS3.2 only: * texteditor.gadget: (*) on OS3.9, you can use Esc p[] to change the text colour, but this does not work in 3.2; the escape sequence is added as plain text instead. OS4.1FEu1 only: * listbrowser.gadget: (*) OS41FEu1 (at least) listbrowser.gadget can get confused about the width of a listbrowser in some circumstances, and make it far too wide; OS3.9+BB2 (at least) listbrowser.gadget seems not to have this problem. * speedbar.gadget: (*) SBNA_Help is not supported by OS4.x and will crash the machine. This is not mentioned in the OS4.x autodocs. Works OK on 3.2 and 3.9. Not reconfirmed: * layout.gadget: (*) It can fall back to the fallback font in some circumstances where this is not necessary. * texteditor.gadget: (*) Scrollable read-only text editors don't seem to handle cursor key input correctly. Possible improvements that could be made: * listbrowser.gadget: (*) It would be good to support editing of LBNCA_Integer cells (ideally by using an integer.gadget). * led.image: Ideally it could: (a) fill its own background (b) draw itself automatically rather than needing DrawImage() (c) have margins around the text (d) not always have colons (e) have decimal points (f) have user-controllable inter-pair spacing Other enhancements that could be made: (a) have a "fill segment intersections?" option. (b) have a "slanted" (italicized) option. These autorefresh: button GA_Disabled button GA_Selected button GA_Text chooser GA_Disabled integer GA_Disabled BUTTON_BackgroundPen BUTTON_TextPen CHOOSER_Selected CLOCKGA_Time INTEGER_Number INTEGER_Minimum INTEGER_Maximum LISTBROWSER_Labels LISTBROWSER_Selected SCROLLER_Top SLIDER_Level STRINGA_TextVal Untested: BUTTON_Integer CHOOSER_LabelArray GETCOLOR_Color LISTBROWSER_Selected PALETTE_Colour These don't autorefresh and thus need a call to RefreshGadgets() after SetGadgetAttrs(): checkbox GA_Disabled checkbox GA_Selected string GA_Disabled LISTBROWSER_MakeVisible RADIOBUTTON_Selected Note that GA_Left/Top/Width/Height are not gettable (with eg. GetAttr()) from gadgetclass (except on OS4). You must instead look directly at the relevant field of the Gadget structure. 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. SAS/C 6.59 Notes ---------------- If you are writing a program which can be started from shell or Workbench, the standard SAS/C startup code can be used to set a minimum stack size. Declare long __stack = 10000; in your program (with the minimum required stack size as needed) and the startup code will make sure that your program has that much available (see the SAS/C header file for a bit of information on what the effects are). Note that the SAS/C automatic stack size extension feature is something related but altogether different from declaring how much minimum stack space your program wants. These are known bugs: * For functions such as sprintf(), the %f format specifier is documented as being supported but is actually unsupported unless you link with LIBRARY LIB:scm.lib LIB:sc.lib (in that order). * The rand() function gives very poor random numbers. * kprintf()/KPrintf() don't seem to work properly for word-sized values (%d); workaround is to use %ld and cast them to LONG. * In some circumstances, you can either initialize your variable and be told "dead assignment eliminated" for that line, or leave it uninitialized and be told "possibly uninitialized variable" when it is used. * Very long if...else if chains can cause the compiler to overflow its stack and guru. * The size optimization in SAS/C is known to be less robust than the time optimization; ie. sometimes the code will not work correctly if optimized for size. 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". In GCC mode, the optimizer has bugs. Eg. at optimization level 2 or higher, you can get errors such as "operand out of range -- statement 'addb #-256,d0' ignored". Using optimization level 1 or lower avoids this bug. In GCC mode, if you stop the assembler, this can cause it to crash. If more than 999 warnings or messages are generated, only the leftmost 3 digits of the warning/message count are shown. 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. GCC Notes --------- Bugs: GCC for AmigaOS: Your must use a HDF for your source files rather than the Windows filesystem, at least for WinUAE 4.9.1 on Windows 8.1. Otherwise, the program will not link (you will get "Multiple definition of 'no symbol'" and other such nonsense errors. GCC for MorphOS: When linking C++ programs for MorphOS, you cannot do this: gcc -noixemul -o foo bar1.cpp bar2.cpp (as you will get these kinds of errors: undefined reference to 'ios virtual table' undefined reference to 'strstreambase::ios virtual table' etc.) but must instead do this: g++ -noixemul -o foo bar1.cpp bar2.cpp or this: gcc -noixemul -o foo bar1.cpp bar2.cpp -lstd++ Options: -c don't link -g generate debug hunks -lauto auto-open Amiga libraries -lm link maths library -o name the output executable as -x c program is written in C language -W same as -Wextra -Wno-deprecated-declarations turns off "'foo' is deprecated" warnings ppc-amigaos-strip -o will strip debugging symbols. VBCC Annoyances --------------- The output filename defaults to a.out if you don't specify -o foo . You must give the -c99 argument if you want // support (otherwise even the official NDK3.9 header files won't compile). Beware of case sensitive parameters (eg. -L vs. -l). Common functions like str(n)icmp() are missing. It is not compatible with reaction.lib (nor ReActor, presumably). You are responsible for opening and closing every library and class in the system yourself. You cannot use preprocessor directives such as #ifdef in the middle of a taglist. Statements such as putchar(a[b++]); will cause b to be incremented twice. WHDLoad Notes ------------- In general: (a) JIT should be turned off. If you get errors about illegal opcodes, line 1111 emulation, etc., this is usually the cause. (b) Some games will run too fast unless "Hardware|Chipset|Options|Cycle exact" is selected (in WinUAE). Bomb Jack: You need to use "Match A500 speed". Even then, it is somewhat too fast (eg. end-of-level tune does not finish playing before the next level starts). Legend of Ragnarok: There seems to be a bug in the WHDLoad version with regards to movement of the mouse pointer. Ski or Die: This has a bug: clicking on the high score table graphic in the shop doesn't show the high scores. Ultima 5: You need to unzip this inside UAE rather than eg. using WinZIP; otherwise, you will get corrupt tile graphics. Additionally, you should add QUITKEY=$5D to the icon's ToolTypes to enable quitting via the numeric * key. Floppy Notes ------------ Great Giana Sisters 1: The Flashtro megatrained version (at least) appears to be badly cracked; saving the high score table will permanently corrupt the game. Strike Force Harrier: This needs Kickstart 1.2 and no external floppies (for the version on Defjam/CCS Compact Disk #7, at least). Transylvania: This game expects only chip RAM to be present; therefore, a configuration such as 512K chip + 0K fast should be used. Otherwise, you get a corrupted title screen, invisible pointer, etc. X-Beat/STLC demo: This needs Kickstart 1.2 and no expansion RAM. MorphOS Networking ------------------ This tutorial explains how MorphOS can use an Internet connection (eg. from a mobile broadband USB modem) from a Windows XP machine, via an Ethernet crossover cable between the two machines. The connection will also be usable for eg. Ami/WinArcadia networking. Turn on both machines and plug in the crossover cable. On MorphOS: Double-click System. Double-click Prefs. Double-click Preferences. Click Network. Select Static IP Address. Tick IP Address, enter 192.168.0.99 Tick Mask, enter 255.255.255.0 Tick Gateway, enter 192.168.0.1 Click Host and DNS. Tick Primary, enter 8.8.8.8 Tick Secondary, enter 8.8.4.4 Click Save. On Windows XP: Click Start|Settings|Network Connections. Right-click the crossover connection and choose Properties. Ensure Internet Protocol (TCP/IP) is ticked, and double-click it. Choose "Use the following IP address:" IP address: 192.168.0.1 Subnet mask: 255.255.255.0 Default gateway: 192.168.0.1 Choose "Use the following DNS server addresses:" Preferred DNS server: 8.8.8.8 Alternate DNS server: 8.8.4.4 Click OK and then OK. Right-click the Internet connection and choose Properties. Click the Advanced tab. Tick "Allow other network users to connect through this computer's Internet connection". Click OK. To test basic connectivity: On Windows, type PING 192.168.0.99 On MorphOS, type PING 192.168.0.1 If this doesn't work (eg. PING returns error 65), try disabling any firewall(s). MorphOS Upgrading ----------------- This tutorial explains how to upgrade MorphOS without burning a CD. Note that the instructions at meta-morphos are incorrect. 1. Go to www.morphos-team.net/downloads and download the appropriate boot image (morphos-3.3.iso or morphos-3.3-efikainstall.img). 2. Copy the ISO to eg. your Work: partition. 3. Select the ISO, hold the right mousebutton and choose Mount... 4. Rename Boot:boot.img as eg. Boot:boot.img.old. 5. Copy the appropriate boot image from MorphOSBoot: to Boot: For Pegasos 1: bootpeg1.img For Pegasos 2: boot.img For Efika: bootefika.img For G4 Mac: mac_ppc32/boot.img For G5 Mac: mac_ppc64/boot.img 6. Rename the boot image you just copied as Boot:boot.img 7. Choose "Ambient|Shut Down|Reboot". 8. Check that the splash screen shows the new version. 9. Open your Work: partition, select the ISO, hold the right mousebutton and choose Mount... 10. Run MorphOSBoot:Tools/IWizard 11. Follow the instructions. 12. Choose "Ambient|Shut Down|Reboot". 13. You can now delete Boot:boot.img.old and the ISO file. OS4 on WinUAE Notes ------------------- Not always emphasized/mentioned in the guides commonly available: a) Host paths can't be mounted (you must use HDFs, ISOs, etc. instead); b) Initial bootup of the OS4.0 CD takes about 20 minutes. During this time, guest screen will mostly just have blocks of various colours, mostly black. c) OS4.0 installs with screen savers active, including turning off the machine completely after 20 minutes. So the first thing you should do after installation is to go to Preferences and turn these off. d) You need to have the correct version of DirectX (even if the date on the website is earlier than the purchase date of your machine), otherwise you will get pointer trails and other graphics corruption. AmigaOS Improvements -------------------- Here are suggestions for the most straightforward ways for resource tracking and memory protection to be added to OS3, OS4, MOS and/or AROS, in a backwards compatible way. Also, there is a brief discussion of API protection. The term "AmigaOS", as used in this document, refers to all Amiga-like operating systems. The term "resources" refers to memory, file locks, devices, libraries, resources, etc.: anything you allocate via the AmigaOS API and then are supposed to later similarly deallocate. The term "feature" is used for system characteristics that are expected as a matter of course by the vast majority of non-Amigans in 2016. These ideas (how and why) are rather obvious and probably have been proposed many times, at least since the early 1990s. They are generally considered the most serious architectural lacks in AmigaOS. Lack of memory protection, in particular, means it is considered as completely insecure and prevents many users from taking it seriously. Modest changes could enable AmigaOS to become a secure, or at least potentially secure, OS. It is time to do something at last about these issues. (As Steven Solie said back in 1996, "I hope the next release of AmigaOS will make this type of library redundant." :-) ) Also frequently suggested then was virtual memory. However, that is not really important, then or (especially) now. Modern systems have huge amounts of RAM and a reasonably-written application will not conceivably require gigabytes of memory to be allocated at any given instant. And of course if they do, a hard disk is thousands of times slower than RAM. OS4 has it already anyway. The usual objection to most of these proposals is that they would break backwards compatibility. However, 99% of all correctly written software doesn't allocate/deallocate resources it didn't deallocate/allocate, or read/write memory not belonging to it. For the 1% that do, there are the file/hunk flag(s) discussed below so that these features can be disabled for those programs. (Additionally, the compatibility of MOS and OS4 with old non-trivial programs (eg. most PD games) seems to be less than 50%, so another 1% or so would be insignificant anyway.) For badly-written software, these features can be disabled for those programs, or you may still want to turn these features on for them anyway: eg. then you will get the benefit of AmigaOS freeing resources the programmer forgot to free (thus preventing memory leaks, etc.), and preventing the program from corrupting memory. There is no need to sacrifice backwards compatibility. Argument checking by AmigaOS functions would also be a worthwhile improvement. It is normally only a matter of a few bytes of code requiring only microseconds to execute. There are various third-party programs available that operate similarly to what is described here: eg. CodeWatcher, Enforcer, IntuiTrack, PatchWork, etc. This proves that such features are quite feasible. Proper integration of these features into AmigaOS would have huge benefits for developers and users alike. Files could have two extra attribute flag bits (like the "pure" bit), or there could be some flags in the loadfile hunk(s), indicating whether the program is resource tracking and/or memory protection compatible. (There could be a Preferences option for whether or not to ask the user for confirmation before running a program that is not compatible.) There could be Preferences options for whether to use resource tracking/memory protection or not, for programs which don't specify whether they support it. Or there could be a whitelist/blacklist stored in ENV:, but that is probably not the best solution. Resource Tracking: Programs that allocate some resources and then exit, while deliberately not freeing some resources, would not be resource tracking compatible. Eg. a program that allocates some resources, spawns a new task (which later accesses some of these resources), and then kills itself. All other new software (and most old software) could be resource tracking compatible. While such a program is running, AmigaOS keeps a record of all allocations (eg. memory allocations, file locks, opened libraries, etc.) made by that program, and automatically calls the appropriate deallocation functions when that program exits. There could also be an option to list the required deallocations, as well as or instead of actually performing them. If/when a program frees one of its own resources (eg. as all properly written old programs do), AmigaOS of course removes that resource from its list and thus doesn't attempt to free the resource twice. The proposed improvement would require only minor changes to AmigaOS: * a list of what resources have been allocated (and which program allocated them). Probably most efficient in terms of speed would be a separate list for each task and/or function. Allocation functions would each add an entry to this list. Deallocation functions would each remove an entry from it. * changes to eg. Exit() so that all items on the list for that task are deallocated. Resource tracking would help avoid memory leaks after running old (and new) software, and could enable programmers to not have to bother about freeing of resources that are held until exit (as is already the case for most OSes). It is easier and less error-prone to put such resource-freeing code once into each relevant API function, rather than into every AmigaOS application. Memory Protection: Memory protection means programs can only read from or write to certain memory areas: * their stack (eg. local variables); * memory they have allocated from the heap; * their global variables; * custom chip registers (where such chips exist or are emulated); * various fields in various AmigaOS structures that are not private. Basically, Enforcer-type functionality integrated into AmigaOS. (So, it requires an MMU, but most OS3 machines, all or nearly all OS4 machines, all x86 AROS machines, and all or nearly all MOS machines have this. So for machines without an MMU, memory protection doesn't happen, but that doesn't mean users with an MMU can't have it.) The address space is still flat (linear); ie. there is no need for a virtual address space. Programs like memory viewers/editors would not be memory tracking compatible, as they want read/write access to all memory. All other new software (and most old software) could be memory protection compatible. There could also be an option to list the violations, as well as or instead of actually preventing them. The proposed improvement would require only moderate changes to AmigaOS: it is mostly just a matter of telling the MMU what memory to fault on for which program. The same as Enforcer already does. API Protection: Something else to be considered in the context of securing AmigaOS is API protection. Eg. the user may not want programs reading/deleting/ modifying files outside PROGDIR: (and subdirectories thereof), formatting disks, rebooting the machine, uploading/downloading to/from the Internet, killing/modifying other tasks, operating hardware outside its specifications (eg. switching the monitor into a potentially damaging screenmode), disabling task switching, and/or various other possible actions that might be taken by malware. Also, there should be protection against programs deliberately or accidentally calling API functions with illegal arguments (eg. passing a NULL pointer to functions that don't check for that), a la PatchWork. So, to generalize, there should be a mechanism for the user to prevent certain programs from accessing suspicious API functions, and the system should check API function arguments (from all programs) for known-wrong arguments (a la PatchWork). This could take various forms: eg. asking the user each time (or the first time, per program) before such an action is allowed, having a whitelist of programs and actions, a blacklist, etc. AISS on OS3 ----------- To convert AISS imagery from 24-bit PNGs to 256- (or less) colour IFF ILBMs, with appropriate transparency: 1. load into paint shop pro 2. reduce to 256 colours 3. count colours 4. save as iff 5. load into personal paint 6. reduce colours if possible 7. find an unused colour (eg. #255) 8. set it to green 9. set colour #0 to blue 10. floodfill everything that was blue with green 11. floodfill everything that was pink with blue 12. set colour #255 (or whatever) from green to black 13. set pink to white 14. set personal paint LMB and RMB colours to 0 15. cut out brush 16. save brush Enhancer Software Bugs ---------------------- * piechart.gadget: (a) slice names (PCSA_Name) are not being shown anywhere. (b) FreePieChartList() is causing a crash. Calling FreePieChartSlice() for each slice works. BOOPSI TAG LIST----------------------------------------------------------- TAG_USER $80000000 ( $80000000) REACTION_Dummy $85000000 (TAG_USER + $05000000) SBNA_Dummy $80010000 (TAG_USER + $00010000) SB speedbar TNA_Dummy $80010000 (TAG_USER + $00010000) CT clicktab IA_Dummy $80020000 (TAG_USER + $00020000) IM image RBNA_Dummy $80020000 (TAG_USER + $00020000) RA radiobutton GA_Dummy $80030000 (TAG_USER + $00030000) GA gadget PGA_Dummy $80031000 (TAG_USER + $00031000) PR prop STRINGA_Dummy $80032000 (TAG_USER + $00032000) ST string LAYOUTA_Dummy $80038000 (TAG_USER + $00038000) GA gadget POINTERA_Dummy $80039000 (TAG_USER + $00039000) PO pointer SHARED_Dummy $80041400 (TAG_USER + $00041400) SH shared MA_Dummy $80440000 (TAG_USER + $00440000) MN menu NM_Dummy $80450000 (TAG_USER + $00450000) MN menu BUTTON_Dummy $84000000 (TAG_USER + $04000000) BU button DIFFVIEW_Dummy $84000000 (TAG_USER + $04000000) DV diffview LED_Dummy $84000000 (TAG_USER + $04000000) LE led LISTVIEW_Dummy $84000000 (TAG_USER + $04000000) LV listview PIECHART_Dummy $84000000 (TAG_USER + $04000000) PC piechart TABS_Dummy $84000000 (TAG_USER + $04000000) TA tabs WHEEL_Dummy $84000000 (TAG_USER + $04000000) CW colorwheel PCSA_Dummy $84005100 (TAG_USER + $04005100) PC piechart TICKBOX_Dummy $84020000 (TAG_USER + $04020000) TB tickbox THUMBLIST_Dummy $84050000 (TAG_USER + $04050000) TL thumblist CLOCKGA_Dummy $84070000 (TAG_USER + $04070000) CL clock DIFFOBJECT_Dummy $85000000 (TAG_USER + $05000000) DV diffview GRAD_Dummy $85000000 (TAG_USER + $05000000) GS gradientslider MDECKA_Dummy $85000000 (TAG_USER + $05000000) MD mediadeck TDECK_Dummy $85000000 (TAG_USER + $05000000) TD tapedeck CHOOSER_Dummy $85001000 (REACTION_Dummy + $00001000) CH chooser CNA_Dummy $85001500 (TAG_USER + $05001500) CH chooser INTEGER_Dummy $85002000 (REACTION_Dummy + $00002000) IN integer LISTBROWSER_Dummy $85003000 (REACTION_Dummy + $00003000) LB listbrowser LBNA_Dummy $85003500 (TAG_USER + $05003500) LB listbrowser PALETTE_Dummy $85004000 (REACTION_Dummy + $00004000) PL palette SCROLLER_Dummy $85005000 (REACTION_Dummy + $00005000) SC scroller LABEL_Dummy $85006000 (REACTION_Dummy + $00006000) LA label FILLER_Dummy $85006666 (REACTION_Dummy + $00006666) FI filler LAYOUT_Dummy $85007000 (REACTION_Dummy + $00007000) LY layout CHILD_Dummy $85007100 (LAYOUT_Dummy + $00000100) LY layout PAGE_Dummy $85007200 (LAYOUT_Dummy + $00000200) PA page SPACE_Dummy $85009000 (REACTION_Dummy + $00009000) SP space CHECKBOX_Dummy $85011000 (REACTION_Dummy + $00011000) CB checkbox FUELGAUGE_Dummy $85012000 (REACTION_Dummy + $00012000) FG fuelgauge SPEEDBAR_Dummy $85013000 (REACTION_Dummy + $00013000) SB speedbar RADIOBUTTON_Dummy $85014000 (REACTION_Dummy + $00014000) RA radiobutton GLYPH_Dummy $85015000 (REACTION_Dummy + $00015000) GL glyph BEVEL_Dummy $85016000 (REACTION_Dummy + $00016000) BE bevel DRAWLIST_Dummy $85017000 (REACTION_Dummy + $00017000) DL drawlist PENMAP_Dummy $85018000 (REACTION_Dummy + $00018000) PM penmap BITMAP_Dummy $85019000 (REACTION_Dummy + $00019000) BM bitmap VIRTUALA_Base $85024500 (REACTION_Dummy + $00024500) VI virtual SKETCHBOARD_Dummy $85024600 (REACTION_Dummy + $00024600) SK sketchboard WINDOW_Dummy $85025000 (REACTION_Dummy + $00025000) WI window POPUPMENU_Dummy $85025900 (REACTION_Dummy + $00025900) PU popupmenu TEXTEDITOR_Dummy $85026000 (REACTION_Dummy + $00026000) TE texteditor CLICKTAB_Dummy $85027000 (REACTION_Dummy + $00027000) CT clicktab SLIDER_Dummy $85028000 (REACTION_Dummy + $00028000) SL slider AREXX_Dummy $85030000 (REACTION_Dummy + $00030000) RX arexx PARTITION_Dummy $85039000 (REACTION_Dummy + $00039000) PR partition PARTNA_Dummy $85039500 (TAG_USER + $05039500) PR partition GETFONT_Dummy $85040000 (REACTION_Dummy + $00040000) GT getfont GETSCREENMODE_Dummy $85041000 (REACTION_Dummy + $00041000) GM getscreenmode GETCOLOR_Dummy $85043000 (REACTION_Dummy + $00043000) GC getcolor REQ_Dummy $85045000 (REACTION_Dummy + $00045000) RQ requester REQS_Dummy $85045100 (REQ_Dummy + $00000100) RQ requester REQI_Dummy $85045200 (REQ_Dummy + $00000200) RQ requester REQP_Dummy $85045300 (REQ_Dummy + $00000300) RQ requester STRING_Dummy $85055000 (REACTION_Dummy + $00055000) ST string GETFILE_Dummy $85060000 (REACTION_Dummy + $00060000) GF getfile DATEBROWSER_Dummy $85061000 (REACTION_Dummy + $00061000) DB datebrowser LINECMP_Dummy $86000000 (TAG_USER + $06000000) DV diffview INFOWINDOW_Dummy $8A100000 (TAG_USER + $0A100000) IW infowindow OS3.5 ICON FORMAT--------------------------------------------------------- $0.. $1: UWORD do_Magic $3E10 $2.. $3: UWORD do_Version $0001 $4..$2F: struct Gadget: do_Gadget $4.. $7: struct Gadget* NextGadget $00000000 $8.. $9: WORD LeftEdge $0002 $A.. $B: WORD TopEdge $0013 $C.. $D: WORD Width $000A $E.. $F: WORD Height $000A $10..$11: UWORD Flags $0006 $12..$13: UWORD Activation $0001 $14..$15: UWORD GadgetType $0001 $16..$19: APTR GadgetRender $402AA008 $1A..$1D: APTR SelectRender $402AA038 $1E..$21: struct IntuiText* GadgetText $00000000 $22..$25: LONG MutualExclude $00000000 $26..$29: APTR SpecialInfo $00000000 $2A..$2B: UWORD GadgetID $0000 $2C..$2F: APTR UserData $00000001 $30 : UBYTE do_Type $03 $31 : UBYTE alignment byte $00 $32..$35: STRPTR do_DefaultTool $1062C1A0 $36..$39: STRPTR* do_ToolTypes $1061B6E8 $3A..$3D: LONG do_CurrentX $0000002A $3E..$41: LONG do_CurrentY $00000004 $42..$45: struct DrawerData* do_DrawerData $00000000 $46..$49: STRPTR do_ToolWindow $00000000 (reserved) $4A..$4D: LONG do_StackSize 8192 $4E..$61: struct Image: $4E..$4F: WORD LeftEdge $0000 $50..$51: WORD TopEdge $0000 $52..$53: WORD Width $000A $54..$55: WORD Height $000A $56..$57: WORD Depth $0001 $58..$5B: UWORD* ImageData $402AA020 $5C : UBYTE PlanePick $01 $5D : UBYTE PlaneOnOff $00 $5E..$61: struct Image* NextImage $00000000 $62..$75: Unselected image data: $62..$75: 1st plane $76..$89: struct Image: $76..$77: WORD LeftEdge $0000 $78..$79: WORD TopEdge $0000 $7A..$7B: WORD Width $000A $7C..$7D: WORD Height $000A $7E..$7F: WORD Depth $0004 $80..$83: UWORD* ImageData $402AA050 $84 : UBYTE PlanePick $0F $85 : UBYTE PlaneOnOff $00 $86..$89: struct Image* NextImage $00000000 $8A..$9D: Selected image data: $8A..$9D: 1st plane $9E..$B1: 2nd plane $B2..$C5: 3rd plane $C6..$D9: 4th plane $DA+ : Strings: Default tool SYS:Utilities/Multiview Tooltypes The first string in the file is the default tool. It is then followed by the list of tooltypes. Each string is stored as follows: $0.. $3: Length of next string, including NUL terminator $4+ : The string itself, including NUL terminator The list of strings is terminated by an entry with size of $00000001, consisting of just a NUL terminator. This is immediately followed by the IFF ICON FORM. $FF+ : IFF ICON FORM: FACE chunk (there is 1 of these): $0 Icon width $1 : Icon height $2:0 : Frameless flag $3 : Aspect ratio $4.. $5: Maximum palette entries IMAG chunk (there are 2 of these): $0 : Transparent colour $1 : Number of colours $2:1 : Palette data attached flag $2:0 : Transparent colour flag $3 : Image storage format $4 : Palette storage format $5 : Depth $6.. $7: Image size in bytes $8.. $9: Palette size in bytes $A+ : the actual data Some offsets ($78+) are dependent on eg. the dimensions and depth of the icon imagery, what tooltypes it has, etc. bookmark.device------------------------------------------------------------ Thanks to Mijo aka CaptFuture for this information. bookmark.device provides no "legal" way to iterate through the list of bookmarks. The BD_DUMP command is a way of getting to the data, as it will always return all bookmarks regardless of where they are stored on a system. To traverse the dump, you can do the same thing the device code does: - Get the offset to the first bookmark entry from the Bookmark memory header - Do whatever you want with the bookmark - Use the bookmark header’s BE_DATALEN field to jump to the next bookmark entry - Loop until last bookmark entry Here’s the structure of the Bookmark memory header, which should be at offset 0 in the dump: mb_MemoryId equ 0 mb_HeaderLen equ 2 mb_HeaderSum equ 3 mb_MemSize equ 4 mb_MaxSize equ 8 mb_CheckSum equ 10 mb_FirstMark equ 12 mb_FirstFree equ 16 mb_FreeSpace equ 20 mb_SizeOf equ 24 And here’s what a bookmark header looks like: BE_MANFID equ 0 BE_PRODID equ 2 BE_PRI equ 4 BE_AGE equ 5 BE_DATALEN equ 6 BE_DATA equ 8 So you could use mb_FirstMark to jump to the first bookmark entry, then use BE_DATALEN to jump to the next bookmark, until you’ve reached offset mb_FirstFree, which points to first free mem location (bookmark.device always "defragments" bookmarks so there should be no more bookmarks after mb_FirstFree). END OF DOCUMENT-----------------------------------------------------------