@Aslak3

the explanation is i was drunk posting it. i just tried to find the rubbish i might have posted yesterday to delete it. seems too late.

@Deniil715

Quote:

Deniil715 wrote: Jahc might take back over development at some point.

well what happens if he dont ? let me ask how can i reach him because incase if he dont than i like to take on
-------------
SabreMSN
WookieChat
-------------
and continue development for aros version.

Thanks..

_________________
http://aros-exec.org/

http://serk118.blogspot.com/

@Aslak3

Just FYI since I have no opinion on this:

http://os4depot.net/index.php?function=showfile&file=driver/utility/mercurial.lha
http://os4depot.net/index.php?function=showfile&file=development/utility/hggit.lha

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

@Thematic

Interesting. I've never used mercurial myself. Have used CVS, SVN and git - git is far away the best.... I really hope there is a git port, or I might have to do that first...

On the subject of cross-amigalike-portability, where do we stand on building applications from a single codebase that can run on AOS4, MOS and AROS? Has everything diverged too much or is it feasable to do multiplatofrm builds? What if the project in question was originally for OS3.1, say?

Note that I'm referring to source-code compatability, not runtime (though it would be interesting to hear if it is possible to run, say, AROS PPC on AOS4 PPC etc).

Lawrence

_________________
Blog

@Aslak3

There is incomplete GIT port, I think CrishH is going to be rally happy if you like to help out.

Last edited by NutsAboutAmiga on 19-Sep-2012 at 10:16 PM.
Last edited by NutsAboutAmiga on 19-Sep-2012 at 05:05 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Aslak3

Quote:

On the subject of cross-amigalike-portability, where do we stand on building applications from a single codebase that can run on AOS4, MOS and AROS? Has everything diverged too much or is it feasable to do multiplatofrm builds? What if the project in question was originally for OS3.1, say?

You can do that it is feasible but does require some knowledge of etch of operating systems; It might be easily fixed whit a few macros.

It might be smart split the project in common parts, and platform dependent parts, for example if you like to use reaction on AmigaOS4, and MUI on AROS, MorphOS, and older versions of AmigaOS.

Last edited by NutsAboutAmiga on 19-Sep-2012 at 05:16 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Aslak3

If it was originally for AmigaOS3.1 you might like replace some deprecated DOS.library (32bit) functions , and replace whit newer (64bit) functions, you also might wont to use mutex instead for forbid in some places where it’s safe to do so, there are probably a few places where you won’t to replace AllocVec() whit AllocVecTags(), because it gives you better control.

MEMF_FAST, MEMF_CHIP is legacy, should not be used on AmigaOS4.x for native programs.

So there are differences but this can be ether solved by macros or splitting project up in platform dependent objects, or you might just wrap into you own functions.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Sounds like converting my AB prog over should be simple enough. Of course using one code base for OS3.1 and OS4 will make things fun.

I'm interested to know what the substantial differences (API wise) between the three main platforms is? Is it documented anywhere? Are there any reasonable sized programs that are cross platform buildable?

Thanks for the info! I can't wait to get started now.

Lawrence

_________________
Blog

@NutsAboutAmiga

Converting 32-bit DOS calls to 64-bit (like Seek(), Examine() etc) make no sense if your data files are always smaller than 2 GB.

Similarly converting AllocMem() to AllocVecTags() make no sense if it doesnt bring any new functionality to your program.

And converting code from semaphore API to mutex API makes no sense either if you are not using any new functionality there.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

On the plus side removing "obsolete" calls means you don't have to worry when they are finally deprecated. On the minus side it gives you more work to do for no clear gain.

In this example, namely my AB program written to OS3.1 APIs, it would seem sensible to as little as possible, ASSUMING I wanted to continue building the program for 3.1. This, in my case, is unlikely. What might complicate things is if I want the same source-base buildable on AROS (say).

Lawrence

_________________
Blog

@Aslak3

VBCC already has the option of various target specific includes and libs that can be chosen right on the command line, so at least compiling and linking wouldn't cause a headache. Which doesn't help at all if your code is C++.

_________________
: AmigaOneXE (unmod.) 750FX/512 MB +stuff & AmigaOS 4.(0|1)
: A1200/68060&96MB/SCSI/EM1200-Voodoo3 & OS 3.5
: A500/1MB
: Pegasos (ff) 512 MB & MorphOS
Praise seitan.

@Aslak3

Quote:

I'm interested to know what the substantial differences (API wise) between the three main platforms is? Is it documented anywhere?

If you are using OS 3.1 API you dont necessarily need any changes. If you have used M68k registers or depend on 68k alignment or stack layout you have to modify your code.

* get rid of 68k registers in your code (i.e. hook calls)
* fix vararg calls
* fix alignment in public structures

Most of changes are required due to different CPU target or compiler differences. At API level you rarely need any changes if it is written for OS 3.1 API. Everything beyond that is incompatible to each other, though.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Aslak3

What new functionality your AB program would have if it used AllocVecTags() instead of AllocVec() ? Besides you can always write your own AllocVec() -> AllocVecTags() wrapper if AllocVec() is removed for reason or another.

Last edited by itix on 19-Sep-2012 at 08:41 PM.
Last edited by itix on 19-Sep-2012 at 08:37 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@Aslak3

Depends on what application does, if won’t read correct file size, then you can’t whit the old api, so even if you just wont to list files the new API is better.

But as I say, you can split the application up in .o and .h files, so that you use best for etch platform, instead of old and outdated API.

SRCDIR:include/fileio.h
SRCDIR:OS3/source/fileio.c
SRCDIR:OS3/objects/ fileio.o
SRCDIR:OS4/source/fileio.c
SRCDIR:OS4/objects/ fileio.o
SRCDIR:AROS/source/fileio.c
SRCDIR:AROS/objects/ fileio.o
SRCDIR:MorphOS/source/fileio.c
SRCDIR:MorphOS/objects/ fileio.o

Once you have your .o and .h files you just link the files in one exe file, and this is it,

To make a makefile that does this is really easy:

Quote:

// behind you list everything to build all: test_os4.exe test_morphos.exe // all dependent objects and header files and source code should be listed after “:” // files you do not modify do NOT need to be listed, when you do this compile will only make the file if one of files are new then your output file. test_os4.exe: OS4/objects/fileio.o main.c gcc_cross_compiler_for_aos4 main.c OS4/objects/fileio.o –o test_os4.exe test_morphos.exe: MorphOS/objects/fileio.o main.c gcc_cross_compiler_for_mos main.c MorphOS/objects/fileio.o –o test_morphos.exe // and so on //to compile objects you type OS4/objects/fileio.o: OS4/source/fileio.c include/fileio.h gcc -c OS4/source/fileio.c -o OS4/objects/fileio.o MorphOS/objects/fileio.o: MorphOS/source/fileio.c include/fileio.h gcc -c MorphOS/source/fileio.c -o MorphOS/objects/fileio.o // we compile whit “-c” parameter when we create objects. // and so on, two lines for etch platform and object.

Last edited by NutsAboutAmiga on 19-Sep-2012 at 09:53 PM.
Last edited by NutsAboutAmiga on 19-Sep-2012 at 09:51 PM.
Last edited by NutsAboutAmiga on 19-Sep-2012 at 09:41 PM.
Last edited by NutsAboutAmiga on 19-Sep-2012 at 09:40 PM.
Last edited by NutsAboutAmiga on 19-Sep-2012 at 08:57 PM.
Last edited by NutsAboutAmiga on 19-Sep-2012 at 08:52 PM.
Last edited by NutsAboutAmiga on 19-Sep-2012 at 08:51 PM.
Last edited by NutsAboutAmiga on 19-Sep-2012 at 08:50 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

The biggest problem is not having a cross compiler for OS4 that can make MorphOS or AROS elf files.
You might need to synchronize the files between different setups.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@itix

Quote:

Converting 32-bit DOS calls to 64-bit (like Seek(), Examine() etc) make no sense if your data files are always smaller than 2 GB.

Even if you just want to list some files in a directory you wont to use the 64-bit version, you do not wont the wrong filesize, anyway the compiler complains about using deprecated functions and its annoying.

Quote:

Similarly converting AllocMem() to AllocVecTags() make no sense if it doesnt bring any new functionality to your program.

True, but whit AllocVecTags() you can control if memory should allowed to be swap or not, it was not a feature in AmigaOS3.

Quote:

And converting code from semaphore API to mutex API makes no sense either if you are not using any new functionality there.

mutex is forbid() free, while semaphore's are not, it generally more multitasking friendly to use mutex, anyway if he is using forbid some pleases because of some internal threading then it might possible to replace it whit mutex in some cases, (unless Autodocs says some thing else.)

Last edited by NutsAboutAmiga on 25-Apr-2013 at 09:30 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

Even if just want to list some files in a directory you wont to use the 64-bit version, you do not wont the wrong filesize, anyway the compiler complains about using deprecated functions and its annoying.

If you have to list files in the directory for a user there is standard asl.library to do that.

Quote:

True, but whit AllocVecTags() you can control if memory should allowed to be swap or not, it was not a feature in AmigaOS3.

Why should applications have control for swapping? Just use malloc() and let kernel handle it for you.

Quote:

mutex is forbid() free, while semaphore's are not,

Why semaphore is not? There is no any reason why you couldnt use read-modify-write instructions in Amiga semaphores.

Quote:

it generally more multitasking friendly to use mutex, anyway if he is using forbid some pleases because of some internal threading then it might possible to replace it whit mutex in some cases, (unless Autodocs says some thing else.)

Do you have concrete examples where avoiding Forbid() has enhanced user experience?

Last edited by itix on 20-Sep-2012 at 05:43 AM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Why should applications have control for swapping?

maybe if you have patch or memory handler or some interrupt routine, at least that's a condition where you don't wont a slowdown (Default anything is swappable).

Sorry don't know way they (hyperion) did not fix semaphore, but insted created mutex.

Well forbid() locks up multitasking, its pretty bad way to protect integrity of data, when you have mutex() that was designed for this, ideally its better to use if your have routine that can be in a forbid() loop, whit Mutex(), one task can modify the data, while your have maybe 2 or 3 tasks waiting or query to get access, and rest of tasks/OS multitasking. Also many tasks may share a read access, while task that wont to modifying has to wait.

forbid's where used when its was no other way to do it, but be careful you can't mix and match, you don't wont a task waiting for mutex in a forbid state, and you can't protect data from tasks that don't expect mutex. But you may use it to make your program thread safe, handling different tasks whit in your program.

Amway should not keep a lock on data for long time, one way or the other, it does ether make your application feel like crap (mutex / semaphore), or does make your system feel like crap (forbid)

Last edited by NutsAboutAmiga on 20-Sep-2012 at 11:26 AM.
Last edited by NutsAboutAmiga on 20-Sep-2012 at 09:49 AM.
Last edited by NutsAboutAmiga on 20-Sep-2012 at 09:39 AM.
Last edited by NutsAboutAmiga on 20-Sep-2012 at 09:37 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@serk118

Quote:

Deniil715 wrote: Jahc might take back over development at some point.

Quote:

well what happens if he dont ? let me ask how can i reach him because incase if he dont than i like to take on

Saw your post on AROS-exec too, so just to confirm...

http://wookiechat.amigarevolution.com/

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Quote:

number6 wrote: @serk118 Quote: Deniil715 wrote: Jahc might take back over development at some point. Saw your post on AROS-exec too, so just to confirm... http://wookiechat.amigarevolution.com/ #6

Thank you for the link @number6..

I think its upto Deniil715 now since I had no replay from jahc..

_________________
http://aros-exec.org/

http://serk118.blogspot.com/