Aros/Developer/Docs: Difference between revisions

Exec (the "kernel", which is not a kernel in the modern sense),
Intuition (graphics and GUI, integrated into the system) and
AmigaDOS (Disk Operating System, the Metacomco's Tripos modified to work with Exec).

The design philosophies of AmigaDOS and Intuition are rather different, the former adopting a C-like API and the latter creating an object-oriented, message passing aware environment for the programmer. The system base is the only absolute address in AmigaOS (located at 0x00000004) - everything else is dynamically loaded. The OS is well known for delivering high performance due to its close connections with the hardware, while simultaneously having the flexibility to support re-targetable graphics (Cybergraphics) and retargetable audio subsystems (AHI).

Diagram showing relationships of libraries to system needed

Remember, AROS is a research operating system, and while all contributions to the base AROS code are welcome, please bear this in mind and contact the dev list first. Writing applications for AROS does not have this limitation.

While AROS appears and feels almost feature complete, it is still missing a number of functions from the Amiga API - as well as implementations of core functionality. There are also a number of user applications that, while not strictly part of the AmigaOS 3.1 environment, need to be written.

The current detailed status of AROS completion can be monitored on aros.org's Status of AROS implementation page. Developer activities can be monitored at ohloh

Software Development for AROS

Programming languages

Apart from 'The Developer Environment', which primarily supports C/C++ code, there are other programming languages available for AROS:

Scripting

DOS, included in all

LUA, included in all or Hollywood

REXX Regina (AROS' ARexx), included in all

Python [ Info], included in Icaros DVD

Ruby Info/download

Basic

Amos Pro compatible commands (all incomplete)

Blitz Basic none on AROS

Monkey

Amiblitz on JanusUAE amiga(TM) emulator

Amiga Basic

ACEBasic

Misc

AmigaE Portable E

FreePascal FPC Aros-Exec thread, Download, LCL

LLVM,

sge2d, Download 2D Game Engine SDL

Where to get the C/C++ Environment

Native compilers (namely gcc/g++) are supplied with the Developer Environment, which is already setup 
and part of any current AROS distribution like Icaros DVD or the nightlies but not Icaros Lite CD or Broadway.

Currently, the developer environment consists of the following software components.GNU GCC 4.2.2, GNU BinUtils, GNU Fileutils 4.1, GNU Textutils and others.

On single partition systems and the Boot ISO, the AROS Developer environment is installed under "SYS:Development/". Systems with multiple partitions - such as a Work: partition - tend to install it to there instead, however it can be installed manually to any location. Please remember, if moving, that you will need to correct the Development packages 'install location' env variable to point to the new locations root - look in SYS:S/startup-sequence.

Assign Development: SYS:Development 
Assign C: Development:bin ADD

Windows(TM) AmiDevCpp is a cross-compiling developer environment for Windows, able to create binaries for AROS, AmigaOS, and MorphOS.

A Linux option is to use cross-compilers for Linux. In order to do that, you have to compile AROS yourself. Download AROS source archive not contrib. Compile AROS by entering the main directory

./configure
make

(More on compiling AROS). The result will be a basic AROS system without development tools.

To compile C++ on Linux, type 'make gnu-contrib-crosstools', creating the cross-compilers in ./bin/linux-i386/tools/, named i386-aros-gcc, etc.

Note: Currently, to make the cross compilers usable copy 'collect-aros' from tools/ to tools/i386-aros/bin/. At the moment the cross compilers if used from the Linux command line will only find it when it's there.

If you want to compile native compilers (the Developer Environment), type 'make contrib-gnu-gcc', creating native compilers in AROS' System:Development/bin directory.

When the output needs to be stripped

--strip-unneeded --remove-section .comment

The Obj-C backend should build out of the box.

Open contrib/gnu/gcc/mmakefile.src and search for the line which contains "--enable-languages" and add "objc" to the list of languages that follows it.

   --enable-languages=c,c++,objc

Better make it --enable-languages=c,c++,objc,obj-c++

ObjC++ is broken as soon as you try to use exceptions, but that might change in future GCC versions and it does not hurt having it there already.

Do you need a crosscompiler or a real compiler? In the first case you can get away with just downloading the proper gcc archive, apply the patch and proceed with the normal gcc build. In the case of a real crosscompiler then when downloading the contrib sources, also need to download the normal sources, place the contrib sources into a directory called contrib, need to install autoconf+automake+perl+python, call ./configure, cd into the subdirectory and type make.

to rebuild GCC with host == build == target == i386-pc-aros. So just get the vanilla sources and apply the patches without bothering about the build system?

Beginners Tutorials in C C++

As AROS is C based API compatible to AmigaOS 3.x German here, so some of information on programming C on the Amiga applies to AROS as well. Please note that there is a lot of AOS 1.3 (not so useful) and AmigaOS AOS 2.x information around as well.

Overview of whats required to write AROS Applications

Using Intuition for basic screens/windows
Using the ZUNE GUI Environment
Using graphics within windows via 8bit graphics and so onto 15-16-24bit cybergraphx
Load and save work to dos disk drives

Writing native games require this extra information

Using AHI audio hardware independent API
Using USB joystick/joypad with the Poseidon USB stack through LowLevel library

Additional features that could be added later

Adding addition Locale language translations to your program
Adding an AREXX/Regina port to your application
Copy'n'paste actions: using AROS' Clipboard and use open/write/read/close
Executing Amiga(TM) DOS commands from your application
Using icons (.info files) and icon tooltypes (stack, version, and program startup options)

A good introduction to Amiga programming in general, though a little outdated, is Rob Peck's "Programmer's Guide to the Amiga". The Amiga ROM Kernel manuals: Libraries (3rd edition), and The AmigaDOS manual (3rd edition) are the most generally useful books, the other RKMs, including the Style Guide also have their uses. There were many reference examples from AmigaMail and Devcon notes (available again on an Amiga developers CD). Libraries and Devices and the Third Edition.

If using Arexx then "The Amiga Programmer's Guide to ARexx" by Eric Giguere, which was published by Commodore is useful as well as "Arexx Cookbook".

Apart from this wikibook, documentation and help can be obtained from the following sources:

Beginners C Guide C Tutorial,
AROS Dev help aros.org AROS homepage,
Reference utilitybase.com - Amiga related API reference, forum, articles Reference

Source can be found here and here and here. Lots of example code can be found inside AROS sources themselves. DOWNLOAD the contrib source archives from Aros site, and study the AROS applications source code, e.g. the test programs from the Tests drawer (folder/directory). Take a look at the code of some smaller AROS programs might be a better and more up to date guide. There a quite a lot of nice examples hidden in the AROS SVN.

Games Programming requires C or C++ and Algorithms but start small with WB games first.

Setup
2D - Maps, Tiles, Sprites and Collisions (creating their own routines or using SDL)

3D - Using their own OpenGL (Mesa) routines or using pre-written ones like Ogre3D C++, Crystal Space C++, [http://irrlicht.sourceforge.net/ irrlicht C++, Cube C, [Quake 1 to 3 in C], Luxinia in C BSD, etc

Compiling C/C++ Code

Native, although we have a IDE Integrated Development Environment (Murks), it does lack a debugger. Whilst others use a combination of a text editor and shell to edit code. Most though use an AROS hosted on Linux to take advantage of the better GCC tools like GDB and various IDEs.

Open shell - its a menu option at the top left of Wanderer (desktop). Or by using the right Win key and w (or F12 and w) within the directory with the source code. Type in

sh

to change the amiga shell into a unix shell. You can then type in ls (unix equivalent to amiga dir). Take a look here for more commands.

For a single file program-name.c or program-name.cpp

gcc -o program-name program-name.c

g++ -o program-name program-name.cpp

g++ -o test -Wall -g main.cc texturelib.cpp xmodelib.cc -lsdl -lgl

To close the shell, click on the top left-hand corner to close (twice). Once to get back the amiga shell and then again to close finally. Use cksfv as a test.

Some source code requires the addition of Amiga API libraries, like dos, which you can flag at the compile time as

gcc -o julia.exe julia.c -ldos

I use -ldos as example and if you are compiling mui codes it will be -lmui or intuition -lintuition. Other missing symbols are due to linker libraries being necessary for linking in functions that aren't in the standard C libraries. For example some source code would need added

-lz or -lm or -lpng or -larosc etc.

use this in unix line command mode to search for 'search-item' in many .c files (*.cpp for c++, etc.)

grep -l 'search-item' *.c

More information: Aros/Developer/Porting software

Coding conventions

Layout

static void 1st_function()
{
    program
    exit(0);    
}

int main(void)
{
    1st_function();
    2nd_function();
    3rd_function();
    return 0;
}

struct Screen * openscreen(void);
struct Window *openwindow(struct Screen *screen, const char *title, LONG x, LONG y, LONG w, LONG h);

VOID 1st_function();
VOID 2nd_function();


int main(int argc, char **argv)
{
    program
    return 0;
} /* main */

VOID 1st_function()
{

}

VOID 2nd_function()
{

}

General style

This code is used by many people and therefore you should keep some things in mind when you submit source code:

Keep things simple
Keep the source clean
Always know what you are doing, if not flag it and describe what needs to be done...
Explain clearly/simply what you are doing
Remember that you write code once but that it is read many times by many people

Comments

AROS uses some of the comments in the source to generate the documentation. Therefore it's necessary to keep a certain format so the tools can find their information. Other comments are ignored but they should explain what you thought when you wrote the code. If you really can't think of an explanation, then don't write the code a second time like this:

/* This adds 1 to t */
t ++;

What we think of is this:

/* Go on with next element */
t ++;

Formatting

This is only IMPORTANT if you are going to work on the core AROS code or contrib but not applications which may reside outside like on AROS Archives or other websites.

{
    /* a */
    struct RastPort * rp;
    int               a;


    /* b */
    rp = NULL;
    a  = 1;


    /* c */
    if (a == 1)
        printf ("Init worked\n");


    /* d */
    if
    (
        !(rp = Get_a_pointer_to_the_RastPort
            (
                some
                , long
                , arguments
            )
        )
    ||
        a <= 0
    )
    {
        printf ("Something failed\n");
        return FAIL;
    }


    /* e */
    a = printf ("My RastPort is %p, a=%d\n"
        , rp
        , a
    );

    return OK;
}

Looks ugly, eh ? :-) Ok, here are the rules:

If several lines contain similar code, put similar things below each other (see a and b);
Put spaces between operands and operators
Put braces {}, brackets [] and parentheses () below each other (d) if there is much code between. 
Brackets and parentheses may be in one line if the code between is small (c)
Indent by 4 Spaces. Two indent levels may be abbreviated by one tab.

Before committing please normalize the indentation - if you have a mixture of tabs and spaced - please always use spaces, 1 tab = 4 spaces.

The reasons for this are:

While some editors can use an arbitrary sizes for tabs, it's a bit complicated to tell another editor which tab size was used by the one used to write the code.
Most code in AROS was written this way and your code should look like the rest.
You can print this code on any printer without special tools to "fix" the tabs.
Most editors have smart tabs which do exactly this. If your editor doesn't, write a bug report.

If you have a function with many arguments (d, e) you should put the parentheses in lines of their own and each argument in one line (d) or put the first argument behind the opening parentheses (e) and each following argument in a line of its own with the comma in front. The closing parentheses is in a line of its own and aligned with the beginning of the expression (i.e. the a and not the opening parentheses or the printf()).

Use a single blank line to separate logical blocks. Large comments should have a blank line before and after them, small comments should be put before the code they explain with only one blank line before them.

If you see any TABS in AROS core sources then the suggestion is to "detab the file and commit that separately" either before or afterwards from making functionality changes. Make two commits instead of one. This makes it easier for others to see the real changes instead of having to dig through multiple lines of irrelevant diffs.

AROS/AmigaOS APIs and Docs

System Libraries

The AROS Guide To Libraries can be used as a guide to individual commands and they [2] are used in application programming.

The generated Aros AutoDocs HTML Read or download docs-html.bz2 from here.

General AmigaOS Reference here

Porting UNIX library to AROS - dealing with static variables which would make it easy to port such libraries to AROS, keeping the benefits of sharing them on disk, but losing the benefit of actually sharing them in memory.

Our problem arises by the fact we want to share the actual code (the .text section of the library) and constant data, but we need to have per-task .bss and .data sections. If we get rid of our intention to share the .text and .rodata sections, things get quite easy: just load and relocate the library whenever it's open, by whoever it's open. It's like statically linking the library into the executable, except that the final linking is done at runtime.

/* 1. Header for your name,date,purpose of program.
2. Pre-processor directives. This will include the #includes for files you want to add. 
3. Includes for function prototypes if necessary.
4. Main()
Create Pointers for Libraries and any Window you want to open.
5. Open necessary libraries.
6. Check if open exit program if fail.
7. Open a window exit program if fail.
8. Add your program
9. Close Window
10 Close Libraries.
11 End Program. */

#include <dos/dos.h>
#include <dos/dosasl.h>
#include <dos/dosextens.h>
#include <dos/exall.h>
#include <dos/rdargs.h>
#include <exec/memory.h>
#include <exec/types.h>
#include <utility/utility.h>
#include <intuition/intuition.h>

#include <proto/arossupport.h>
#include <proto/dos.h>
#include <proto/exec.h>
#include <proto/intuition.h>
#include <proto/graphics.h>
#include <proto/cybergraphics.h>
#include <proto/datatypes.h>
#include <proto/icon.h>

#include <workbench/workbench.h>
#include <workbench/icon.h>

#include <datatypes/pictureclass.h>

#include <proto/muimaster.h>
#include <libraries/mui.h>

#include proto/bsdsocket.h

#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define CTRL_C      (SetSignal(0L,0L) & SIGBREAKF_CTRL_C)
#define  isDir(fib) ((fib)->fib_DirEntryType >= 0)

#define ARG_TEMPLATE    "FILE/A,ALL/S,QUIET/S,W=WIDTH/N,H=HEIGHT/N,M=METHOD,DEFTOOL"



int main(void)
{


	return retval;
} /* main */

Zune - AROS' GUI system

More information: Aros/Developer/Zune

Zune is the preferred GUI to use under AROS. Significant effort is being made to firstly complete the implementation, and secondly - get all the standard AROS Applications using consistent Zune powered interfaces.

AROS Zune Guide

HIDDs

HIDD are used for device/peripheral low level hardware support drivers. The HIDD system is broken up into a collection of classes with a strict inheritance hierarchy. A HIDD class implements a device driver for a single device or in rare cases a group of devices and provides an interface for other programs and devices to access.

In order to maintain portability of interfaces across a wide range of hardware this interface will in general not present the raw interface to the underlying hardware. Instead it will present a generic interface that describes many different hardware implementations. This allows for the best reuse of both interfaces and code.

HIDD API is heavyweight though. You need to open a HIDD library, open oop.library, instantiate an object (even if there's no object); and object calls are more costly compared to plain library calls.

In the V0 branch, in workbench/hidds/hidd.nouveau I comitted pcimock.hidd. This is a pci driver that allows mocking real PCI devices under linux-hosted. The main idea is to be able to run the real hardware driver under linux-hosted with as little changes as possible(some changes will always be needed though unless someone wants to write complete device simulator) so that driver's code paths can be executed and debugged using gdb. This was a very helpful capability when I was porting nouveau. Now it is externalized from nouveau.hidd and can be used by other people porting drivers. The pcimock.hidd can currently mock 4 different nvidia cards,1 AGP bridge and also mock irq.hidd.

What's the difference between this driver and the pcilinux.hidd? I used that one to develop many different HW drivers for aros. As far as I understood the intention of pcilinux.hidd it is supposed to get access to real hardware that is running under linux. The pcimock.hidd goal is to mock the hardware. For example my dev box is a PCIE system, but I still would like to run the AGP codes paths in nouveau under linux-hosted to check if they don't seg fault. The other case would be to run codes paths for hardware that the developer does not have (Fermi cards in my case). In the case of pcimock.hidd, the AROS driver's code paths will execute as long as you add proper mocking (for example fill in PCI config area or values for registers in BARs). This is an advantage for ported drivers - the code should already work (since it worked on another system) but there might have been mistakes made during porting which can be detected easily with gdb.

In case you are writing your driver from scratch, pcilinux.hidd hidd will give you more advantage, since you can actually access the real hardware from linux-hosted.

Resources

Devices

The Amiga used Devices to communicate with additional hardware. AROS has replaced these hardware devices with hidd equivalents but some are still retained for backwards compatibility.

Local libraries/devices/modules are supposed to override the ones in ROM if their version is higher than the one in ROM.

Here is the list of commands exec default:

CMD_CLEAR	Purge the buffer of the device
CMD_READ	Playback Control
CMD_STOP	Stopped the activity of the device
CMD_FLUSH	Empty the queue of commands
CMD_RESET	Reset a device
CMD_WRITE	Playback Control
CMD_INVALID	Create an error
CMD_UPDATE	Gets updated device
CMD_START	Will restart the device

While most other "stuff you communicate with" in AmigaOS are devices ^[2] that share a common base interface. OS 1.3 Device Drivers.

Handlers

filesystem handlers have their own separate system consisting of completely differently structured messages that dos.library use to pass requests (for things like reading, writing, getting directory contents etc.) to them. AROS originally went with implementing filesystem handlers as devices, which might arguably be more consistent with the rest of the AmigaOS API but which is quite incompatible with AmigaOS itself. In retrospect it wasn't a great idea as it made it far harder to port filesystems and the gains were comparatively small, and so there's been a long standing goal of fixing this incompatibility. It has now, June 2011, been reintroduced to all AROS flavors.

AROS Subsystems

AROS Application Packages
AHI Audio Drivers - Usage/Development
AROSTCP Sana2 Network Interface Drivers - Usage/Development
gfx.hidd/cybergraphics Video Drivers - Usage/Development
IO Device Drivers - Usage/Development
USB Device Drivers - Usage/Development
PCI Device Drivers - Usage/Development
SDL
w:Gallium3D openGL - Usage/Development
A small subset of GTK through MUI-GTK
Cairo 2D Engine - Usage/Development

Debugging Code

Please use the AROS Bug Tracker if any issues are found.

GRUB Command line list

sysdebug  
usbdebug - allows to see Poseidon's log in debug output

How do I get debugging out of InitResident ? If running i386 hosted on linux sysdebug=initresident on command line.

This way you can enable any of listed flags. sysdebug=all stands for "everything"

Have an executable (crosscompiled C++ code) which has 6 MB size on disk, but after loading it in memory, 250 MB RAM is taken. Any software that would split AROS executable into ELF part which would show actual size values?

readelf -S executable

it will show you all sections in elf file, including sizes and requested alignment.

objdump -h filename

That's will give you a quick overview of the sections and sizes. Ignore all the .debug.* sections. I would hazard a guess that you have a large .bss section. That's pretty common in C++.

Next step:

nm --size-sort filename | grep ' [bB] '

The last few will be your biggest consumers. I would also suggest -C to demangle the symbols... ;)

Suggest profiling the program (just use some printf's in the main loop for time spent in each part), it usually is quite easy to spot slow parts in games or apps.

If someone has '#define IPTR ULONG' somewhere. To see where that define is, redefine IPTR in the source code that fails, just above the line that fails, and the preprocessor will tell you where it was defined first.

How to use gdb with AROS/hosted

Download AROS sources (AROS-xxxxxxxx-source.tar.bz2, where xxxxxxxx is the current date) and AROS contrib sources (AROS-xxxxxxxx-contrib-source) from aros.sourceforge.net/download.php

Untar-bzip2 and cd to the unpacked archive directory.

> tar -xvjf AROS-xxxxxxxx-source.tar.bz2
> cd AROS-xxxxxxxx-source

Check the link to "contrib" (contrib-source) inside directory, e.g. correct like this:

> rm contrib
> ln -s ../AROS-xxxxxxxx-contrib-source.tar.bz2 contrib

Make sure you have the correct locale setting, otherwise compilation will fail at some point. See here (or link below) for more on that. You might have to enter this:

> export LANG="en_US.ISO-8859-1"

Now configure for a debug build - see "./configure --help" for more - here are two examples:

> ./configure --enable-debug=stack,modules,symbols

> ./configure --enable-debug=all

You may "make" now, or choose a separate directory for your build (e.g. for easy removal), for example if compiling for i386 architecture you could create a directory like this:

> mkdir linux-i386
> cd linux-i386
> ../AROS/configure --enable-debug=stack,symbols,modules

When done configuring you're ready to go:

> make

Building AROS takes some time - minutes on fast machines (e.g. 2.5GHz quadcore), up to hours on slower machines. The result will be AROS Linux hosted with gdb debugging enabled.

See aros.org documentation for more on compiling AROS, including more --enable-debug options.

When finished, enter bin/linux-i386/AROS directory (replace "linux-i386" with your compilation target platform, e.g. linux-x86_64, etc.) inside the unpacked archive directory. This directory contains the required .gdbinit file for properly running AROS inside gdb.

> cd bin/linux-i386/AROS

Run AROS (here: with 128MB of memory) from gdb:

> gdb --args boot/aros-unix -m 128
(gdb) r

Watch the shell output - in case AROS complains about "LoadKeyCode2RawKeyTable: Loading "DEVS:Keymaps/X11/keycode2rawkey.table" failed!" you should also see some instructions on how to create a keymap table. (see link above "more on compiling", too.) Quit gdb, and try default keymap table:

(gdb) q
The program is running.  Quit anyway (and kill it)? (y or n) y
> cd ../../..
> make default-x11keymaptable

Re-run AROS, as described above. Try e.g. RAros (= right windows key) + W to open a shell. If this doesn't work you have to create a keymap table yourself, quit gdb again, and make a new keytable:

> make change-x11keymaptable

A window will open. Watch the window's title bar, and follow the instructions.

When done, re-run AROS. RAros + W should now open a shell.

Next, compile your program with gdb support.

Summary - In short:

* build AROS with debugging support (i.e. ./configure --enable-debug=all)
* build your application with debugging support (i.e. option -g)
* run AROS in the GNU debugger (you may use the GUI frontend "ddd" which simplifies usage a bit)
* start your application
* use the commands "findaddr" and "add-symbol-file" as written in the debugging manual
* if the debugger doesn't find the source code of your application use the "dir" command of the debugger.

In AROS open a shell, then (in host shell) use CTRL-Z to go into gdb. Use "b Exec_CreatePool" (one of the functions used early on by startup code in programs) to add a breakpoint, then "cont" and gdb will interrupt somewhere early during startup of "program". Use "bt" to show backtrace and "loadseg" for "??" entries. One of them will be for "program". After that you can use "disassemble program".

One thing you need to make sure is that .gdbinit you have in your build directory is the same as in source tree. It has been modified some time ago, but the build system does not refresh it - you need to copy it manually

To recap, please read our debugging manual:

To detect segfaulting when loading, try...

./configure --enable-debug --with-optimization="-O2"

Because crash or no crash may depend on optimization. For newer compilers maybe this helps...

--with-optimization=-"-O2 -fno-strict-aliasing"

One way to make crashes less random (more easily reproducible) is to activate the munging of free memory in rom/exec/freemem.c which is normally commented out:

Index: freemem.c
===================================================================
--- freemem.c   (revision 34289)
+++ freemem.c   (working copy)
@@ -154,11 +154,12 @@
         * created with their TCB placed in the tc_MemEntry list. The workaround
         * is to avoid munging when FreeMem() is called with task switching disabled.
         */
+
        /* DOH! it doesn't work even this way. What's wrong???
-        *
-        * if ((SysBase->TDNestCnt < 0) && (SysBase->IDNestCnt < 0))
-        *      MUNGE_BLOCK(memoryBlock, MEMFILL_FREE, byteSize);
         */
+
+       if ((SysBase->TDNestCnt < 0) && (SysBase->IDNestCnt < 0))
+           MUNGE_BLOCK(memoryBlock, MEMFILL_FREE, byteSize);

     }

Mungwall can be turned on at runtime. Currently this works in all hosted versions. Just specify "mungwall" on kernel command line and it works. It can work on native too. In order to enable it you need to parse kernel command line, and if "mungwall" is present, set EXECF_MungWall bit in IntExecBase.IntFlags.

This needs to be done before the first AllocMem() for obvious reasons. And never reset back this flag! If you change it on a working system, you are doomed.

Hosted ports do the processing in rom/exec/prepareexecbase.c --enable-debug=mungwall option in configure still works but is going obsolete. A kludge in rom/exec/allocmem.c is responsible for this and it needs to be removed when the transition is done.

BTW, on i386-pc port it can be activated by "mungwall" argument on command line, you don't need to rebuild AROS. New mungwall affects not only AllocMem()/FreeMem(), but also pools. I also tested it with AllocAbs(), seems to work correctly.

Runtime mungwall works on:

pc-i386
pc-x86_64
linux-i386
linux-x86_64
darwin-x86
linux-ppc

I believe it works on all hosted ports, if the port itself is working.

amiga-m68k
Not on sam440-ppc and efika-chrp-ppc, even if they would be able to be built at moment. Does not work on (for now, need NVRAM support)

When starting my freshly rebuilt i386-linux-aros which was compiled with full debugging support I get sometimes the error "Program exited with code 0377".

-With the GDB frontend DDD: AROS exits and prints the mentioned error message. Starting it again works.

-With GDB: AROS runs but prints the error message after I exit AROS. That happens again when I restart and exit AROS again.

-Without debugger: no problems

Add the following to your .gdbinit:

set follow-fork-mode child

Native debugging tools for AROS

SYS:Tools/Debug/Sashimi - displays error messages

One suggestion is to do a bug() debugging. Each time bug() is executed it will be output on sashimi. You include <aros/debug.h> and place bug("something\n"); in your source code at location though which control passes.

To get the output - open an aros shell

SYS:Tools/Debug/sashimi > RAM:out.txt

Ctrl C to end the output to the RAM Disk.

SYS:Tools/Debug/Bifteck

you must enable debugging at boot time entering the GRUB menu editing line (E key) and adding "debug=memory" to your boot line, then press Ctrl+X to complete booting.

Open a shell and enter the line below to run Biftek and grab the debug messages collected in RAM into a text file.

tools/debug/bifteck > ram:debug.txt

SYS:Utilities/Snoopy - monitors OS function calls, run "Sashimi" to see Snoopy's output

SYS:Tools/WiMP - the Window (and Screens) Manipulation Program

You can use the -E option of gcc to find out how preprocessor macros are expanded.

Errors

Old Amiga Guru Codes

If the crash is in intuition. Sometimes, if it relates to text, a null pointer sets it off. an uninitialised pointer can have any address (this is a common fault).

Compiling on 64bit, Many old code would not properly typecast when doing pointer-integer conversions and thus at least throw a warning. This can easily be located and fixed.

Then again, many current compilers also throw a warning when you try to assign a pointer value to an integer and the integer is possibly too small. This happens under .NET for example when a 64 bit pointer is assigned to something like an ULONG - so exactly the case which you described.

Use texteditor or some tool to replace all "ULONG" with "IPTR" and "LONG" with "SIPTR" in the sources.

Fix (change IPTR/SIPTR back to ULONG/LONG) the few places which really rely on ULONG/LONG being exactly 32 bit. That's for things like pixel (ARGB) buffers, structs written/read to disk, colormaps, but probably not much else.

Misc

APL, MPL, BSD, GPL and LGPL Licences

The majority of AROS sources in licensed under AROS Public License (APL) which (to a degree) protects us from someone taking AROS sources and not contributing improvements back (for example MorphOS took some AROS source and then contributed changes back)

It is written to allow the use of AROS code in other open source or commercial projects without exception whilst providing a mechanism so that improvements/additions can find their way back to the original source in one form or another.

There are "3rd" party applications used by AROS that do not fall under this license, which are an extra "Contrib" download for convenience.

Anyone can port GPL-ed network and sound drivers as AROSTCP and AHI are GPLed. Direct using (porting) GPL-ed code in other parts of AROS (gfx, sata, usb) is not possible because AROS license is not compatible with GPL. You need to utilize permissive licensed code like BSD or MIT/X11.

BSD and MPL license are the closest to APL.

APL however is not so compatible with LGPL/GPL.

LGPL case - you cannot statically combine APL code with LGPL. You can, however thank to LGPL being "lesser" restrictive, use LGPL dynamically loaded libraries in APL codes.

GPL case - you cannot combine APL code with GPL in any way if there is no explicit clause by GPLed code authors allowing that. If you do combine APL with GPL in "bad" ways described above - you have a problem (you violate GPL). This problem might result in everything in AROS becoming GPL or everything running or AROS becoming GPL (here I'm not sure really). The other scenario is that you are not allowed to legally distribute such code at all. To be honest I have grasped how to violate GPL, but I'm still no exactly sure what happens when you violate it (but I'm sure it's not anything nice)

GPL software can run on top of non-GPL "system components" (see system components exception of GPL), but the other way around (non-GPL using GPL) leads to problems. This means applications like scout, or Quake III are ok (in the majority of cases).

Theres no reason GPL drivers cannot be ported - but they cant be in AROS's ROM (requires linking APL code with GPL), nor can AROS depend on them (e.g. they must use existing apis). If they are launched (dynamically linked) by a user action that is allowed. It is also allowed to distribute such binaries together for convenience.

GPL is not about statical or dynamic linking but is about executing process and function calls.

These components - SFS, isapnp, Zune texteditor, AHi, network drivers, freetype, openuirl, BHFormat, Edit and (" dynamically loaded libraries") are LGPL, not GPL. Mesa/Nouveau stuff is MIT. Some user tools are GPL though.

AROS (system)

system components (libraries/classes/devices/etc) cannot be GPL as they would propagate GPL to complete system as well as GPL is not compatible with MPL from which APL is based
system components can be LGPL v2 or a permissive license (MIT/BSD)
system applications can be anything you like (but still I would prefer APL or permissive so the code can be reused if needed)

Contrib:

no rules - contrib does not impact AROS system since nothing in AROS system depends on contrib.

About stealing code: The chances of this happening is exactly the same whether we are APL or GPL. If any closed-source option wanted to do it, there is no one that can validate otherwise. MorphOS has used some AROS codes, but contributed changes back.

The rationale behind APL is that while it guarantees that the original developer will get the improvements back (to a certain degree - file based), the person who uses the codes does not have to open his original codes. BSD does not guarantee that the original developer gets improvements. GPL requires the person using the codes to open his codes as well.

The copyright holders needs to stay - we just need information from them that the codes are available under APL (for example a checked-in file like in case of Poseidon). We don't do transfer of copyrights.

Ultimately what can and cannot be done is up to the author(s) - not the licence.

(AS)MP support

It does not at the moment support resource tracking and SMP due to amigaOS (TM) 3.1 original design. As long as the CPU initiates the DMA transfers through the OS, and the OS ensures that the transfered memory is within the region accessible to the user initiating the transfer, everything is fine. The CPU is the conductor, and the CPU by that has the control of which DMA transfer is initiated and which is not. All you need to do is to write device drivers reasonable. Hint: CachePreDMA and CachePostDMA exist. All the Os has to do is to verify that the memory regions to be transfered are valid, and prohibit direct access to the DMA control registers from user space. None of these algorithms imply huge costs. The current OS design doesn't really allow virtual memory in first place, Forbid() is again the problem.

Another suggestion is ... Forbid/Permit function calls are meant to halt multitasking so as no other task could intervene with what ever the calling task is doing, e.g. setting semaphores. Disable/Enable calls are meant to halt interrupts and as a side effect they also halt task switching.

I don't know how much Forbid/Permit would hinder the performance if they truly would kill multitasking from all the cores. In Linux I think they call something in line of spinlocks(?) I've understood that they too kill multitasking...

If it was again up to me, I'd make it compulsory to protect shared resources with semaphores and forbid the use of simple Forbid() calls as to protect something. Setting semaphore should be done if possible with atomic instructions (check and alter in one instruction), but I don't think it would be much of a loss to system performance to do global Forbid() if no other mechanism were not available. Or make the second concurrent ObtainSemaphore call halt the second calling task and force if possible a task switch which ever gives better results.

Semaphores could store the owning tasks task pointer instead of boolean to make things easier.

Variadic

variadic functions (i.e. functions with an arbitrary amount of arguments). Please have a look in the header libraries/mui.h or below

#include <exec/types.h>
#include <libraries/mui.h>

#include <proto/exec.h>
#include <proto/intuition.h>
#include <proto/muimaster.h>
#include <clib/alib_protos.h>

#include <stdio.h>

static VOID buttonfunc(struct Hook *hook, Object *object, APTR msg)
{
    printf("button clicked\n");
}

IPTR myGet(Object *o, IPTR tag)
{
    IPTR result = 0;
    GetAttr(tag, o, &result);
    return result;
}

int main(void)
{
    Object *wnd, *app, *but, *txt, *grp;

    struct Hook buttonhook;
    buttonhook.h_Entry = HookEntry;
    buttonhook.h_SubEntry = (HOOKFUNC)buttonfunc;

    but = MUI_MakeObject(MUIO_Button, "_OK");

    txt = MUI_NewObject(MUIC_Text,
        MUIA_Text_Contents, "\33cHello world!\nHow are you?",
    TAG_END);

    grp = MUI_NewObject(MUIC_Group,
        Child, txt,
        Child, but,
    TAG_END);

    wnd = MUI_NewObject(MUIC_Window,
        MUIA_Window_Title, "Hello world!",
        WindowContents, grp,
    TAG_END);

    app = MUI_NewObject(MUIC_Application,
        SubWindow, wnd,
    TAG_END);

    if (app != NULL)
    {
        ULONG sigs = 0;

        DoMethod(wnd, MUIM_Notify, MUIA_Window_CloseRequest, TRUE,
                 (IPTR)app, 2,
                 MUIM_Application_ReturnID, MUIV_Application_ReturnID_Quit);

        DoMethod(but, MUIM_Notify, MUIA_Pressed, FALSE,
                 (IPTR)app, 2,
                 MUIM_CallHook, &buttonhook);

        SetAttrs(wnd, MUIA_Window_Open, TRUE, TAG_END);

        if (myGet(wnd, MUIA_Window_Open))
        {
            while((LONG)DoMethod(app, MUIM_Application_NewInput, (IPTR)&sigs)
                  != MUIV_Application_ReturnID_Quit)
            {
                if (sigs)
                {
                sigs = Wait(sigs | SIGBREAKF_CTRL_C);
                if (sigs & SIGBREAKF_CTRL_C)
                    break;
                }
            }
        }
        MUI_DisposeObject(app);
    }
    return 0;
}

Need to pass through modified arguments to printf().

#include <stdio.h>
#include <stdarg.h>

int printf (const char * format, ...)

{
    int     retval;
    va_list args;

    va_start (args, format);

    retval = vfprintf (stdout, format, args);

    va_end (args);

    fflush (stdout);

    return retval;
} /* printf */

Couldn't find varargs.h or stdarg.h. and have no use for AROS_SLOWSTACKHOOKS or AROS_SLOWSTACKTAGS.

GCC looks for stdarg.h in a different place:

/bin/linux-i386/tools/lib/gcc/i386-aros/4.2.2/include/stdarg.h

Here is a path for a "normal" header:

bin/linux-i386/tools/lib/gcc/i386-aros/4.2.2/../../../../i386-aros/sys-include/aros/system.h

The use of vararg.h isn't supported by newer gcc versions. If you want your code to run on architectures that pass part of variadic arguments in a number of registers you need to use AROS_SLOWSTACK macros. Otherwise your program will not work on powerpc and x86_64 ports.

Of course the SLOWSTACK stuff is not needed in a function that can use va_list, va_start, va_arg and va_end. It's only needed if you want to write functions like DoMethod or similar.

#include <stdarg.h>

should be enough no matter if you do cross or native compiling. If it does not work, something is wrong and should be corrected.

Stdarg.h is here, Development:lib/gcc/i386-aros/4.2.2/include/

...which is part of the compiler's default include paths. In other words, #include <stdarg.h> works out of the box, indeed. (sorry, I should have just tried it before invoking "search" or "find"...)

furthermore, myprintf() as shown above won't work, because...

printf(format, args);

...is wrong - the second argument does not match printf() prototype, it expects a argument list, but args is of type va_list (obviously) - so one has to use...

vfprintf(stdout, format, args);

...instead, just like in the original printf(), and add fflush(stdout).

additionally, one could use...

int myarg = va_arg(args, int);

...between va_start() and va_end() to access individual arguments, where each call to va_arg() returns an argument casted to the desired type (here: "int") from the list given (here: "args") and advances to the next one.

wrapping up vfprintf() and modifying the format string now is a major speedup! no more backslash-n typing! this has been haunting me for years!

On MOS and AmigaOS, the NewObject variadic function is kept in the static library. It takes most of the parameters on the stack - thanks to that the implementation of NewObject calls the NewObjectA function. Everything works perfect, and the typical MUI macros may be easily used.

This, however, is not the case when you compile for AROS. Here, NewObject is a variadic macro, not a function. Thanks such approach we do not need any custom compiler in case of systems, where the arguments of variadic functions are passed partially through registers and partially through the stack (This is the case of PPC and x86_64, this is also the reason why both OS4 and MOS require specially patched compilers).

Since NewObject is a macro, the gcc's preprocessor expects the list of macros arguments enclosed within parentheses. In MUI macros it is not the case. Imagine the following test code:

#define foo(a,b) ((a)+(b))

int loosy_function(int a, int b)
{
    return foo(a,b);
}

This will compile and work, but the following piece of code:

#define foo(a,b) ((a)+(b))
#define END )

int loosy_function(int a, int b)
{
    return foo(a,b END;
}

will fail with the error: unterminated argument list invoking macro "foo"

There are two ways of fixing your issue. Either create your new objects outside this huge MUI constructions, and in there use just a pointer, or get rid of the "End" macro and exchange it with "TAG_DONE)".

Types

UBYTE/BYTE for 8bit
UWORD/WORD for 16bit
ULONG/LONG for 32bit
UQUAD/QUAD for 64bit

UBYTE    Unsigned 8 bit integer variable (byte).
BYTE     Signed 8 bit integer variable (byte).
UWORD    Unsigned 16 bit integer variable (word).
WORD     Signed 16 bit integer variable (word).
ULONG    Unsigned 32 bit integer variable (longword).
LONG     Signed 32 bit integer variable (longword).
FLOAT    32 bit IEEE floating point variable.
UQUAD    Unsigned 64 bit integer variable.
QUAD     Signed 64 bit integer variable.
DOUBLE   64bit IEEE floating point variable.
BOOL     Boolean variable, TRUE and FALSE are also defined in exec/types.h.
VOID     Void.
APTR     A generic pointer for multiple purposes.
STRPTR   A pointer to a null-terminated string.
IPTR     Really important in AROS, the only way to declare a field that can contain both: an integer or a pointer.
PKCTRL_IPTR new type to specify IPTRs in structures. Now 64-bit-friendly.

if you want to write really portable app, you may be interested in standard datatypes defined in C99: int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t, intptr_t, uintptr_t. They are all defined in inttypes.h include file.

In exec/types.h the following short-cuts are typedef'd. They are used often in AROS, so you should nearly always include exec/types.h and soon only they will be removed from sys/_types.h include, all types are now defined in include files named aros/types/xxx.h.

(Preparation for C library split; sys/xxx.h include will only be available there when compiling with POSIX C library)

Compiler specific types, like int and long might change their size. In case of AROS, similar to linux, int remains 32 bit whereas long grows to 64 bits in size.

If you use Amiga-like data types, i.e. BYTE/UBYTE, WORD/UWORD, LONG/ULONG and QUAD/UQUAD or the C99 standard types (uint8_t and so on, see stdint.h include) then you should have less issues to solve than by using types without size guarantee.

Of course, all pointers grow to 64 bytes using 64bit cpu. Most of the code can be just recompiled and will work. In rare cases, where e.g. pointers are casted to integers, a special care must be taken. Especially in the cases, where pointer is casted to LONG/ULONG (this code will break on 64 bit AROS) eg. '#define IPTR ULONG'.

Know if 'unsigned long' will be 64 bits on a 64-bit machine? It really depends on the compiler. You should include stdint.h and use the types defined in there, to be really compatible. The main concern is not for the print statements, but to ensure that pointers aren't truncated to 32 bits on 64-bit systems. In the build log has 35 warnings "cast from pointer to integer of different size". In my opinion, that's 35 high priority problems. But there are also 194 warnings "format '%ld' expects type 'long int', but argument [n] has type 'LONG'". That's the kind of stuff we're probably going to see more of if we define a 64-bit type. the printf() warnings should be disabled in configure. They seem to be too UNIX-centric, and give warnings where a ULONG is used when it expected a u_int32 or similar. It also complains about a variable string, or one without formatting codes, being passed to fprintf().

The only valid conditionals that can be used on BPTR (as far as I know) are:

if ( ptr == (BPTR)0)
if ( ptr != (BPTR)0)
if ( ptr == (BPTR)-1)   /* Rare, weird DOS stuff */
if ( ptr != (BPTR)-1)
if ( ptra == ptrb)
if ( ptra != ptrb)

Many code omits (BPTR) casting on integers, since BPTR is already integer. In fact this would be all that is affected. In general, personally i like AROS_FAST_BPTR.

What about redefining BPTR type as IPTR even with AROS_FAST_BPTR defined ? The rationale: many code assumes BPTR is an integer when doing comparison and arithmetics. Also there's many code which assigns 0 to it. I know we have BNULL definition, just it seems a bit redundant to me. I tried to compile and run AROS with BPTR = IPTR and there were no problems.

Actually, no code should be doing arithmetic on a BPTR other than BADDR() and MKBADDR().

If you are doing arithmetic on a BPTR, you'd need an ifdef for m68k (where BPTR is in units of ULONG) and all other architectures (BPTR is in units of BYTE), or convert to APTR first.

The only valid conditionals that can be used on BPTR (as far as I know) are:

if ( ptr == (BPTR)0)
if ( ptr != (BPTR)0)
if ( ptr == (BPTR)-1)   /* Rare, weird DOS crap */
if ( ptr != (BPTR)-1)
if ( ptra == ptrb)
if ( ptra != ptrb)

#define BNULL     ((BPTR)0)

And that's it for the legal BPTRs, as far as I know.

'volatile' (changed in other places too)? My understanding is that it's important to tell the compiler that a register is being accessed rather than RAM, to make sure that the compiler doesn't use any shortcuts.

warning: function definition has qualified void return type

The warning disappears when I make the function non-void. Volatile is normally used to prevent the compiler from optimizing variables which can be changed by hardware. I couldn't find a hint what volatile means for functions.

With compiler delint patches which the majority of them are simple casting issues to make the compiler happy. Notice some of the changes involve introducing double casts. In very recent versions of GCC. Yes, the bulk of the double casts are for converting 32 bit addresses (ie from a 32 bit PCI DMA address register) to a 64 bit pointer. First cast is to IPTR (to expand to 64 bits, and prevent sign extension if the address is above 0x7FFFFFFF), and then to APTR.

ENV

The philosophy behind ENV: is that keeping configuration files there allows to 'Use' preferences by keeping a copy in ENVARC: intact. However in some cases (like this one) it is not required.

99% of the time that statemenet is true (not required) for pretty much every file in ENV: or do people change their default icons - and prefs settings - every boot?

There seem to be a bad habit of late of developers changing things to reflect their own personal preference when the change isnt actually necessary - It would be nice if people could refrain from doing that in the tree without atleast discussing it on the dev-list first (and with good reasoning unless they commited said work in the first place..)

We're not keen on the pollution of the "S:" dir: it's meant to be for scripts. What's wrong with "ENV:"? Only the fact that it takes up RAM. I understand that for PCs with several gigabytes of RAM this is irrelevant. But let's remember about other machines. The philosophy behind ENV: is that keeping configuration files there allows to 'Use' preferences by keeping a copy in ENVARC: intact.

However in some cases (like this one) it is not required.

How about implementing in the style of HappyENV then? RAM-disk handler that falls through to reading from ENVARC: if there is no such file stored in it already. Removes RAM usage for unchanged files, removes the need to copy ENVARC to ENV in startup-sequence. Shouldn't be too hard to make from AmberRAM, or even just extend AmberRAM to provide this service.

Is it feasable to build a special version of AmberRAM handling ENV: that will try and copy the requested file from ENVARC: if it isnt found in ENV: ? Additionaly it could mark closed "files" that are untouched - and expunge them from ENV: after a period of time to free up additional RAM:, or when the system is running low on free memory?

Silenty disappearing files may not be a good plan. Would be nice if the following would work:

ASSIGN :ENV SYS:Prefs/Env-Arc ADD ASSIGN :ENV RAM:ENV ADD

Where new files put in ENV: end up in RAM:ENV, and openning files looks in RAM:ENV first, then SYS:Prefs/Env-Arc

Well - thats essentially what im proposing but without the assigns - or need for a RAM:ENV directory. Adding it as a feature of AmberRAM sounds like the most memory efficient way (one handler to load in RAM) but thats only if it is possible to make it handle ENV: additionaly to RAM:, and if it is even possible to add the proposed functionality (...and how to make it enable it when accessing ENV:).

SVN and GIT

If you want to help develop AROS OS itself, you can view GIT/SVN entries git repo or ohloh or svn repo and access [Git version git://repo.or.cz/AROS.git here]

If you have SVN access, and/or have obtained the source AROS site - you can compile the current build tools/environment using:

> make development

and follow this procedure.

To gain access to SVN based source repository, you need to direct this directly to Aaron Digulla.

He can be reached at digulla AT the name of this project org.

Set the subject as "Access to the AROS SVN server", and just add one line of text:

Please add <username> <password-encrypted>

You'll use the webpage on aros.org to create your password in encrypted version.

For SVN write access you follow this procedure.

If you plan on contributing back changes, please post information about such changes first on this mailing list for more experience developers can validate whether they are correct.

Jason McMullan has presented a way to get a clone of all of the AROS history *without* overloading the SVN server. It leverages the GIT repos that Marcus Weiss has on repo.or.cz, and will result in a repo that work with all the 'git svn' integration features. This could be useful for developers that prefer the GIT 'trivial feature branch' workflow, using rebases instead of merges.

Make a really fast clone of all of AROS SVN, and be able to git svn dcommit

AROS.git

   * git clone git://repo.or.cz/AROS.git
         o About 10-15 minutes on a slow link 
   * git svn init --username=yournamehere https://svn.aros.org/svn/aros/trunk/AROS
   * git update-ref refs/remotes/git-svn origin/master
   * git svn fetch
         o This should take under 60 seconds 
   * git checkout -b master-svn refs/remotes/git-svn

AROS-contrib.git

   * cd AROS
   * Remove the '/contrib' line from .gitignore
   * git submodule add git://repo.or.cz/AROS-contrib.git contrib
         o About 4-5 minutes later... 
   * cd contrib
   * git svn init --username=yournamehere https://svn.aros.org/svn/aros/trunk/contrib
   * git update-ref refs/remotes/git-svn origin/master
   * git svn fetch (takes a while)
   * git checkout -b master-svn refs/remotes/git-svn

Check that the compiler does not generate bad code if it tries to inline DoSuperNew(). To prevent this there used to be

 USER_CFLAGS := -DNO_INLINE_STDARG -fno-inline
                       ^^^^^^^^^^^

in the nlist + co. mmakefile.src files to prevent this, but it might have been kicked out at some time.

Whether bad code is generated depends on compiler and whether it does this inline optimization at all (can depend on whether DoSuperNew is defined as static function or not).

The routine could consist of check if update has changed configure; if not I just make. Otherwise he/she might get into trouble sooner or later and will learn the hard way.

Then there are the nightly build machines. They svn update before the build and run configure as one of the next steps. autoconf might be added to the nightly build scripts.

Our build relies on packages downloaded from Internet (SDL for example) - it always worked this way. The minimal requirement (when just building core AROS) is binutils and gcc. If you build contrib as well, you need many more packages to be downloaded.

More information: AROS Maintainer Docs

ABI

In the head of our SVN repository there are now only 3 directories:

admin/
branches/
trunk/

We have added two extra dirs there: tags and imports

As discussed when we branch ABI V0 and ABI V1 it would also be good to introduce tags. Normally this is done in a directory in the repository called tags. Currently we don't have this directory there. (We do have branches/tags that is a hack I have done because one doesn't have write access in the top directory. I think this directory is not clean and should be removed).

The second directory I would introduce is an imports directory for implementing vendor branches as discussed in the svn book. Currently we use code from several different projects and that code is stored inside the AROS tree; we seem to have problems with keeping this code up to date and merge our changes upstream. Maintainers of up stream projects like the MUI classes etc. have complained about this (to put it lightly).

Introducing these vendor branches would make it easier to see what changes we have made and make patches to be sent upstream and make it easier to import newer upstream versions of their code. Although can't "copy" the vendor brach into the main branch because it's already there, so start with a "merge".

Yes, the first step to make the code already in the repository compatible with the vendor branches will be the most difficult. The best way to do it the following way:

first import the version on which the current AROS code is based into the vendor branch
then import the new version over it in the vendor branch
finally merge the difference between these two version in the AROS code present in the repository.

For example, place NList directly under vendor and not in a subdirectory like "contrib/zune/classes".

Actually after we have a stable ABIv1 (2012 or later). We need to move away as much as possible from the contrib directory to some other repositories. The reasons are ...

The AROS repository should be for the core AROS code.
other contrib projects should be tried to be compiled for all Amiga-like OSes.
The release scheme for AROS and the other programs should not have to be aligned.
Binary versions should be provided on aros-archives and on aminet and/or OS4Depot to install them. (Some clever programs should maybe be provided to make the life of distribution developers easier).
avoid parallel forks of programs for AROS and the other amiga OSes.

If there is really a need for a place for hosting AROS projects we may investigate setting up such a server but then including bug tracking, governance, maillist, etc. for each project separately. I personally think there are already enough places like sourceforge, google code, savannah, etc. where people can go for hosting such projects.

Locale with Flexcat

Most languages have a locale, but not every app is localized, the only thing needed is to translate the "catalog" files. It is a case of locating the correct catalog and saving the translated version.

For every app that lacks of your language catalog and is localized anyway, you should find (in the sources) files related to locale:

file.cd = catalog descriptor, contains base msg, with internal language (usually english)
language.ct = catalog translation, contains every translated msg, indexed as in the file.cd.

Compare with other localized apps... Then, "make my_app-catalogs" should create and install your translated catalogs. ex : for, saying, sys:prefs/wanderer:

on root of AROS sources, type:

"make workbench-prefs-wanderer-catalogs"

then (if you changed the .cd file):

"make workbench-prefs-wanderer"

For apps not localized, you have to adapt their code to support it, if it is possible...

noticed the original .cd file has many (//) strings at the end of any voice, so added them also to the .ct file. That (//) is only for cd files. I'm highly recommending to use FlexCat for updating ct files, e.g. like this:

flexcat app.cd deutsch.ct newctfile deutsch.ct

You'll get error checking and new entries are marked in the resulting ct file.

When editing .ct files, only change those lines containing translation and perhaps version string, nothing else. The rest is up to the relevant tool, flexcat. In order to update your translation, type in the following in your shell:

flexcat xyz.cd xyz.ct NEWCTFILE xyz_upd.ct COPYMSGNEW

This way you will not only make sure you have correct translation file but flexcat also pre-fills newly added strings with "*** NEW *** text. Even better tool for checking cd/ct/catalog files is catcheck, but this one is sadly only available for AmigaOS/68k...

Some languages have variations, like portugues from portugal and portugues from brasil differs...

This is the way to go. I will have a look at language files, but basically if those two languages differ you have to do two separated set of translation files, yes. (you could create a brazilian slang language localization too)

At system level localization for one language is a dot language file.

(ex: locale:languages/klingon.language)

At app level localization is a dot catalog file

(ex: locale:catalogs/klingon/system/libs/dos.catalog)

At sources level, the dot ct file, and "$language" dot cd files and some building framework.

(ex: catalogs/my_app.ct catalogs/klingon.cd catalogs/mmakefile.src support.c support.h)

Please, use Flexcat to generate CT files:

FlexCat wanderer.cd NEWCTFILE=deutsch.ct

Then fill the first 2 lines with something useful:

## version $VER: wanderer.catalog 1.1 (9.2.2006)
## language deutsch

You can even update the CT-File: (This adds the new strings)

FlexCat wanderer.cd deutsch.ct NEWCTFILE=deutsch.ct

To compile a catalog you only need the .cd file and your translation (.ct file):

FlexCat multiview.cd deutsch.ct CATALOG=MultiView.catalog

Linux version of FlexCat

Unicode discussion.

More information

C Utils Misc

The AROS source uses at several places the __DATE__ macro to fill the date entry of a $VER tag. Problem is that c:version doesn't understand that date format (e.g. "May 21 2011"). As a result the output of e.g. > "version c:shell full" contains "(null)". Is extending the version command to understand the format of __DATE__ the right solution for that problem?

AmigaOs compilers should use __AMIGADATE__ macro or similar form, if it isn't implemented it could be emulated in makefile: -D__AMIGADATE__=\"$(shell date "+%d.%m.%Y")\"

BTW. I think DD.MM.YYYY is better format than "Month DD YYY" because "Month DD YYY" is not localized in any way.

The Situation:

compiled a linklib using c++ object files (using the c++ cross compiler). compiled a C stub that uses the linklib (using the c++ cross compiler).

Try to link them together (using the c++ cross compiler) with C object files (using the normal target c compiler) that need to use -nostartup = cant do because using the c++ files pulls in arosc (for stdio etc) - so wants to have the autoinit stuff present.

What can I do about this??

If it is possible to manually open it then what do I need to do exactly?

References

↑ References and sources
↑ AMIGA ROM Kernel Reference Manual: Devices, 3rd Edition. Commodore-Amiga, Inc. Addison-Wesley, 1991. ISBN 0-201-56775-X

@@ Line 177: / Line 177: @@
 Games Programming requires [http://www.gametutorials.com/default.aspx?sp=tutorials C] or [http://www.cppgameprogramming.com/ C++] and [http://www-cs-students.stanford.edu/~amitp/gameprog.html Algorithms] but start small with WB games first.
 * Setup
-* 2D - Maps, Tiles, Sprites and Collisions
+* 2D - Maps, Tiles, Sprites and Collisions (creating their own routines or using [http://lazyfoo.net/SDL_tutorials/ SDL])
-* [http://lazyfoo.net/SDL_tutorials/ SDL]
+* 3D - Using their own OpenGL (Mesa) routines or using pre-written ones like [http://www.ogre3d.org/ Ogre3D C++], [http://www.crystalspace3d.org/main/Main_Page Crystal Space C++, [http://irrlicht.sourceforge.net/ irrlicht C++], [http://cubeengine.com/ Cube C], [Quake 1 to 3 in C], [http://www.luxinia.de/ Luxinia in C BSD], etc
-* 3D OpenGL (Mesa)

Revision as of 11:15, 2 February 2012

Contents

A technical overview of AROS

Software Development for AROS

Programming languages

Where to get the C/C++ Environment

Beginners Tutorials in C C++

Compiling C/C++ Code

Coding conventions

Layout

General style

Comments

Formatting

AROS/AmigaOS APIs and Docs

System Libraries

Zune - AROS' GUI system

HIDDs

Resources

Devices

Handlers

AROS Subsystems

Debugging Code

How to use gdb with AROS/hosted

Native debugging tools for AROS

Errors

Misc

APL, MPL, BSD, GPL and LGPL Licences

(AS)MP support

Variadic

Types

ENV

SVN and GIT

ABI

Locale with Flexcat

C Utils Misc

Links

References

Navigation menu

Aros/Developer/Docs: Difference between revisions

Revision as of 11:15, 2 February 2012

A technical overview of AROS

Software Development for AROS

Programming languages

Where to get the C/C++ Environment

Beginners Tutorials in C C++

Compiling C/C++ Code

Coding conventions

Layout

General style

Comments

Formatting

AROS/AmigaOS APIs and Docs

System Libraries

Zune - AROS' GUI system

HIDDs

Resources

Devices

Handlers

AROS Subsystems

Debugging Code

How to use gdb with AROS/hosted

Native debugging tools for AROS

Errors

Misc

APL, MPL, BSD, GPL and LGPL Licences

(AS)MP support

Variadic

Types

ENV

SVN and GIT

ABI

Locale with Flexcat

C Utils Misc

Links

References

Navigation menu

Search