FFmpeg + FFplay SVN-r18880 (m68k)

[bernd_afa]

@Piru

I have write here and send you a PM because you give no answer in the last ffmpeg news.I can not find a link, maybe somebody can post it here ?

here i explain more, that i think about it and i am near sure i make a 100% compatible solution and i explain how it work.but you do not asnwer or have some arguments wy it not work.

everything is possible and ixemul can also work with amiga tasks.

BTW; I make zune working together with MUI.and if i can get MUI4 sources i want make it too working together with MUI3, because for my matter of taste MUI4 is too incompatible to MUI3.

maybe you know not much about me, i like to have perfect compatible solutions, and no feature loss and unlimitet feature enhance , and i like the fastest and cheapest CPU ;-)

A also offer you, that you change the lib.I have no time for that, there is lots more needed to do.

MorphOS ixemul can run both original 68k and PPC native binaries.

Any application built for 68k using the new SDK fails to start on MorphOS. Remember: ixemul can also be used for closed source projects, so source code might not be always available.

The new functionality breaks even with 68k: namely trying to make ixemul amigaos thread safe. This is not possible mainly because of the way unix like signalling works.

what is your problem, wy should ixemul 68k not get new functionality  ?.

Have somebody cry when OS4 the ixemul without working vfork and other problems number it as V51.1 instead of rename it ?

have somebody cry when MOS number his ixemul to V49 and miss features or break compatibility without reason, or add the 60 features, because the change userdate structure order, or dont implement ixtrace ?

As i told V61 is full compatible.You can see this also when you look on source.

So there is more reason to rename MOS or OS4 ixemul lib.But i never told that ixmeul for MOS and OS4 should rename.

I for example make zune seperate of MUI, the same i do with MUI4 if i have sources, because zune and MUI4 are less compatible to MUI3.

But ixemul V61 is much more compatible as MUI4 and MUI3, so wy i should rename lib ?
 
when you see the new features, most of them can need on old programs too.so wy i should implement this twice ?

I accept that a library get progress,  and i see that on MOS in last years not much progress done.no C99 funcs add.missing features are not add.(no ixtrace)

I think zapek was the guy who mainly work and implement over 60 Unix functions to enhance MOS ixemul(what is enhance in OS4 i dont know).I think he make the buildscripts and make it possible to build this lib also on 68k with amogaos option in buildscript.

But zapek give up MOS long time ago and release ixemul and some other sources.
And there is since year not much necessary enhance  i see.

so if MOS or OS4 ixemul never reach V61 then there is no problem possible.MOS have since years V49 OS4 since years V51, so its easy to speculate that MOS or OS4 ixemul maybe never reach V60.

I think ixemul with his ixtrace and profile features very good to develop fast programs and find where the slowdown is

The new functionality breaks even with 68k: namely trying to make ixemul amigaos thread safe. This is not possible mainly because of the way unix like signalling works.

But sdl programs use no unix signalling.SDL have own signalling and thread functions that are based on amiga os.look on SDL source and sdl program.

same when use pthread.this too use own signalling

ffplay is very complex in threading, there run 5 SDL treads together, so if something is really wrong, crashes and enforcer hits can see very soon.and if somebody know that ffplay play sound and no video, this is a known problem on all systems.

[bernd_afa]

As you say, old program will work just fine when using the old library.

with the new library they work much better.the first was increase of buffer size.gcc compile faster and many programs start faster.

and when there come later speedup on some funcs old programs are too faster.maybe a new mem allocator

see also ixemul V61 featurelist.

* because most Linux programs do not check if enough memory is here and to avoid them crash badly after a failed malloc
  a check is add if memory cant allocate.
  then a requester come that show how many mem need, and the user can free memory on other programs
  and can then click on try again.


also i know when there are more programs use code, then Bugs find better.i for example always test a little new ixemul lib with OWB 68k.if that make problems, i see fast i have add a bug.

this is one of the importants of software developing.the more programs or users execute functions and the faster can tell it is rock solid.

If it's not 100% API compatible across all systems, it should be forked.

thats not my fault.ixemul is create on 68k

ixemul is port to MOS.MOS add in V49 functions that V48 ixemul dont have and MOS V49 miss some functions and is not 100% compatible.i have add all funcs MOS V49 have so i do all right.when i add additional features then it is clean to increase libnum to V50.

But see here the readme.morphos

Remaining issues:

"""""
- traps are not handled yet.
- ix_panic() does not work properly (varargs conversion needed).
- 'man' crashes here. I've not investigated why yet.
- programs that rely on low-level internal ixemul structs won't work.
The only one I know doing that is 'gdb'. Recompiling it with some minor
changes should take care of the problem.
- ixtrace is not yet supported.
- neither is profiling.
- not compatible with the powerup bridge currently. That may or may
not change.
- DTYPE_MEM is broken, disabled for now.
""""

ixemul is port to OS4.it have number V51.1.But it contain not the features MOS V49 ixemul have.

also OS4 version miss more features as vfork, than MOS V49 have.

here is readme of OS4 Version, and there is since several years no update

""""
You can use this AmigaOS4 port of ixemul.library to run most m68k ixemul
software on AmigaOS4, but it's not a complete port, especially for PPC
native software some functions are not implemented (actually the most
important ones, you can only build simple PPC native programs for which
you wouldn't need ixemul ...), and even for running m68k ixemul software
it's not complete: It has no automatic stack enlargment, if the stack is
too small it will crash the application with a "trap".
"""""

if there really need a lib rename, then i think it is the ixemul of MOS and OS4 and not ixemul 68k.

because they break compatibility much more, thats a Fact.

and if they want emulate 68k then they need upgrade their lib, or less programs run, but dont force 68k side to stop further developing on ixemul.

i dont understand wy on MOS or OS4 the 68k ixemul V61 not work.it use ne special 68k code and no traps.

if somebody want help then 68k ixemul can use and then the incompatible native libs are not need.
 
sure i know there are some guys that want that 68k make no feature progress and stay retro and new features should only MOS or OS4 have.

[bernd_afa]

You're adding large default buffers just to get good performance with specific programs?

I use the default buffer size other systems have.clib2 use 8192 bytes, so i use that too.

i know from very program on my real classic, that 1024 bytes of buffer is too small.aztec c use default 4096 bytes.this also cause some speedloss.8192 used on clib2 is a good value.

most do no  benchmarks, so they dont notice that.

Good luck with that. The ixemul memory system is quite fast in fact. But even if you add a new memory system it will still be bound by the memory system of the OS itself, so the correct place to fix it is at the OS level.

sure but old ixemul have own mem system.when i have tlsf in amiga os, then i must change ixemul that it support stright amiga os alloc

and that is need on both versions.

This should not be in libc, or at least it should be off by default.

Wy do you write its in libc ?

its of course in malloc func.look the source
and if malloc return 0 then the requester come.
and this feature is testet and confirm its lots better than crash whole system because Linux programs assume unlimitet memory, because of virtualmem  and selden check for enough mem.  

Huh, OWB uses ixemul? That's just horrible. Please tell me ain't so!?

thats the Version Jörg Strohmayr do, 1.4 work stable.
the OWB 1.2 use SDL and is 2-3 * faster than 1.4.

that 1.2 is faster with SDL is also confirm from more User.but 1.2 is unstable but thats because SDL 1.2.6 used for OWB was too old and buggy and slow

[bernd_afa]

And how can you tell that the application is not testing for the result? This

do you want faking me ?
everybody know when linux run out of virtuel mem, apps crash, because devs are most part lazy and dont check for enough mem.

If somebody know this not, please lower ram and deactivate swap space and use linux try ffplay or other player progs show some images etc.

The problem is, as it is now the decision is not left to the user. If the developer makes the mistake of installing the latest bernd-ixemul he will automagically create binaries that are only able to work with bernd-ware

ok it seem you think i am stupid, but now it seem you think all developers are stupid and dont know that the dev files must copy by hand to lib dir.

If a developer not copy crt0.o from V61 and not use libc.a from V61 and use instead the old versions from V49 or V48 all should work on MOS.if it not work on MOS, then its a Bug in MOS ixemul.

also the attached crt0.o is named crt0_v61.o.a dev must foirst rename it

what you want is this.

You want force that ixemul on 68k is not furtherdevdelop because it is port since long time to MOS.right ?

burt what rights MOS have, that now that ixemul run on MOS 68k ixemul cant get new features ?

That you write here so much wrong text, instead  change the source so the buildsystem can create another lib show me too its not enough to only change the name.

as you know ixemul is a BSD kernel running on AOS.Can you 100% sure that all work well, if a program use ixemul V48 and 1 program ixemul_ng at same time ?

then there run unnecessary 2 Unix kernels, that need additional  signalling , shedulling mem etc.
Can you be sure, that it not slowdown system, when there now 2 ixemultaskswitchers are installed ?

But today I see that Piru has exposed at least 1 bug in Berndemul.

what bug you mean have V61 ?
i read Piru post, they are very long but i see no Bug

I even created my own ixesux.library to try to "go around" the problems of ixemul and that did fix one set of problems but other problems persisted if someone used ixemul and ixesux at the same time they magically conflicted with each other. There is some heavily illegal code in there somewhere.

so and here are the Facts, what i think, just a rename is not enough.

[bernd_afa]

Um, probably not. I didn't quite understand that, sorry.

The correct way to handle this would be to have a link-library that replaces malloc/realloc/free. This link library would then have the requester code. When building a program that can be expected to crash if malloc fails just add the linklib to the link cmdline in makefile (say -lsafemalloc). Clean, easy, no need to mess up the libc with silly requesters.

Anyone with even decent emount of design experience can see this.
.

i see no reason, that programmer need do additional work.A requester is always 1000* more usefull than a complete amiga OS crash.
but if there is really a reason that it is better that amiga crash than show a error requester that users should free more memory, i can add a envvar that switch it off.no problem

With proper GCC 'specs' file it would be trivial to specify the target library you want. This is the industry standard way to handle it.

But MOS ixemul handle this not.there are no diffrent spec files to support programs that run on V48.

when use the V49 MOS libc or cr0.o this programs fail on V48 ixemul because V48 miss features.

when use such a program on OS4, then it crash badly, because OS4 ixemul have number V51.

on ixemul V61 such a program work, because this ixemul support V49 MOS funcs too.

so you see MOS V49 is exact same problem, this should rename.there should be a V48 that is compatible and a ixemul_ng for MOS that offer this new functions.

and when you do that what you want from me on the ixemul code, and it work well, i do same.

But dont be believe that i am so stupid and do extra work others want to do.

So my offer is easy, change MOS ixemul to be clean, name the V49 MOS Version that have new functions to a new name.if then both ixemul work on MOS (i have a cybppc and can test)then i make that too.

You still have no logical arguments wy 68k ixemul should rename, but MOS ixemul V49 not.

if you want discusss more, then we can this together with neutral people here.

Morphos is already known on the GPL Violaters, see that entry and read the comments.

http://developers.slashdot.org/comments.pl?sid=142894&cid=11973934

if they say that the furtherdevelop 68k ixemul should rename and the MOS furtherdevelop ixemul need not not renaim, then i accept it.

[bernd_afa]

MorphOS ixemul doesn't allow developers to create 68k binaries that don't run on other ixemul versions.

then all is clear.ixemul V61 doesnt allow developers to create programs that need V61 funcs to run on other ixemul Versions.

if in the readme stand need V61 ixemul then its clear and the requester show this.

again, it seem not easy possible to run 2 ixemul.Have you not read the Post ?

if it is only a rename this take 5 minutes, i think you need more than 5 minutes to read and post about that, and it is more clever, when you instead of writing here only spend 3 minutes to rename ixemul and post here the diff.

Whats your roadmap about ixemul.after how many years you think reach V60 with MOS ixemul ?.

Or do you think 68k programmers should always force that new programs with modern features run on MOS too and MOS devs should not write programs to use new features that run on 68k ?

I have also the new function add from MOS, so programs can common written with V49 functions on 68k and MOS.

currenlty you have bring no facts, is it true that MOS give a PPC program a ppc ixemul before a 68k version ?

and a 68k program that want a V61 ixemul but there is only a V49 PPC ixemul open then a 68k ixemul with that number ?

so wy cant V61 68k ixemul not run on MOS, if there is no native lib ?
I use no traps.

then MOS user and you can see, that all work stable and clean and 100% backward compatible.i am sure if V61 run on MOS, then there run more 68k ixemul programs than with V49 ixemul.

[bernd_afa]

Yes, without SDL it might be faster because less code would be used. Also, SDL is not asm-optimized, only C code.

most speedcritical is in sdl the YUV to RGB conversion and scaler.MOS or OS4 SDL support working cgx or P96 overlay code, so code can merge easy i think.

but if on classic amigas cards are out that support HW overlay Bug free i dont know.

i remember on my cybervision PPC and the phase5 videoplayer that support overlay (forget name) crash randomly.

so i also dont know if overlay can work stable.

sound is slow, because it use 64 bit commands a 68060 dont have.this is used in the DCT code and antialiasing Filter code.
if somebody know a fast DCT code for 68k cpu, then this func can add.i dont like the gcc assembler mess and i like a amiga dspmath.library i can code in amiblitz, that is systemspecific for 68060 winuae or other CPU.


on winuae it call then native ISSE code, for 68060 asm optimized code.

BTW: You forget in your feature list, that ffplay with no filename open a amiga filerequester.

here is the code of the DCT.i think this are the few speedcritical lines but MULH use a 64 bit mul.the antialiasing filter can also work with FPU, maybe thats faster on a 060.

maybe this code can move in a amiga library imdct36 and more programs can use it ?

same with other speedcritical funcs ?

static void imdct36(int *out, int *buf, int *in, int *win)
{
    int i, j, t0, t1, t2, t3, s0, s1, s2, s3;
    int tmp[18], *tmp1, *in1;

    for(i=17;i>=1;i--)
        in += in[i-1];
    for(i=17;i>=3;i-=2)
        in += in[i-2];

    for(j=0;j<2;j++) {
        tmp1 = tmp + j;
        in1 = in + j;
        t2 = in1[2*4] + in1[2*8] - in1[2*2];

        t3 = in1[2*0] + (in1[2*6]>>1);
        t1 = in1[2*0] - in1[2*6];
        tmp1[ 6] = t1 - (t2>>1);
        tmp1[16] = t1 + t2;

        t0 = MULH(2*(in1[2*2] + in1[2*4]),    C2);
        t1 = MULH(   in1[2*4] - in1[2*8] , -2*C8);
        t2 = MULH(2*(in1[2*2] + in1[2*8]),   -C4);

        tmp1[10] = t3 - t0 - t2;
        tmp1[ 2] = t3 + t0 + t1;
        tmp1[14] = t3 + t2 - t1;

        tmp1[ 4] = MULH(2*(in1[2*5] + in1[2*7] - in1[2*1]), -C3);
        t2 = MULH(2*(in1[2*1] + in1[2*5]),    C1);
        t3 = MULH(   in1[2*5] - in1[2*7] , -2*C7);
        t0 = MULH(2*in1[2*3], C3);

        t1 = MULH(2*(in1[2*1] + in1[2*7]),   -C5);

        tmp1[ 0] = t2 + t3 + t0;
        tmp1[12] = t2 + t1 - t0;
        tmp1[ 8] = t3 - t1 - t0;
    }

    i = 0;
    for(j=0;j<4;j++) {
        t0 = tmp;
        t1 = tmp[i + 2];
        s0 = t1 + t0;
        s2 = t1 - t0;

        t2 = tmp[i + 1];
        t3 = tmp[i + 3];
        s1 = MULH(2*(t3 + t2), icos36h[j]);
        s3 = MULL(t3 - t2, icos36[8 - j], FRAC_BITS);

        t0 = s0 + s1;
        t1 = s0 - s1;
        out[(9 + j)*SBLIMIT] =  MULH(t1, win[9 + j]) + buf[9 + j];
        out[(8 - j)*SBLIMIT] =  MULH(t1, win[8 - j]) + buf[8 - j];
        buf[9 + j] = MULH(t0, win[18 + 9 + j]);
        buf[8 - j] = MULH(t0, win[18 + 8 - j]);

        t0 = s2 + s3;
        t1 = s2 - s3;
        out[(9 + 8 - j)*SBLIMIT] =  MULH(t1, win[9 + 8 - j]) + buf[9 + 8 - j];
        out[(        j)*SBLIMIT] =  MULH(t1, win[        j]) + buf[        j];
        buf[9 + 8 - j] = MULH(t0, win[18 + 9 + 8 - j]);
        buf[      + j] = MULH(t0, win[18         + j]);
        i += 4;
    }

    s0 = tmp[16];
    s1 = MULH(2*tmp[17], icos36h[4]);
    t0 = s0 + s1;
    t1 = s0 - s1;
    out[(9 + 4)*SBLIMIT] =  MULH(t1, win[9 + 4]) + buf[9 + 4];
    out[(8 - 4)*SBLIMIT] =  MULH(t1, win[8 - 4]) + buf[8 - 4];
    buf[9 + 4] = MULH(t0, win[18 + 9 + 4]);
    buf[8 - 4] = MULH(t0, win[18 + 8 - 4]);
}

[bernd_afa]

Anyone using the new ixemul for development will lose the ability to run the binaries under MorphOS.
Instead the programs will just crash and die horribly (there is no way to avoid this now, it is inevitable because of the bernd version mess).

thats complete wrong, because MOS have only a V49 ixemul, a program that need V61 ixemul bring a requester V61 ixemul need.

then User can try 68k ixemul V61.If thats not work on MOS, thats not my fault.MOS is announce as 68k compatible, and when ixemul V61 not work, then MOS 68k EMU have Bugs until you show me whats wrong in ixemul V61 Code.

and currently you have not show me whats wrong, about the out of mem requester it is also easy possible to change.

Overall this will lead to death of ixemul as a portability platform. Such incompatible versions will spell total chaos and confusion for both developers and end users.

again this is done with your MOS V49.

A MOS developer can choose if he want develop faster and use V49 funcs or develop slower and have 68k compatibilty.

and what do you guess is the choose ?
A developer can also on V61 choose that he want only use V48 V49 funcs so the 68k program run maybe on MOS.again if it not work there is possible that MOS ixemul is incompatible.


working together seem not possible of diffrent platforms on amiga land,
and thats not my fault, i make you many suggestions to solve this problem, but you react in my eyes as a little child without logical reason, wy 68k ixemul should always stay on functionaltiy as V48 and never should get more features as V48.

You also dont want help to get running ixemul V61 on MOS or post the changes need in the buildscript to change the name.

[bernd_afa]

This thread blows my mind. I don't know how somebody could accumulate enough skill and experience to develop stuff like this and come to the conclusion that modifying the standard behavior of malloc is a good idea. Mind blowing.

on a harddrive this behaviour is standard, there come message disk full, and a user can free some memory and try again.Is this not usefull ?.Or is it better to change as in memalloc case, to crash the system, if not enough hardisk space is here, or end the program, or force a developer to check if there is always enough diskspace free ?

i have now download apache and search for malloc

the first entry i find was in support.ab.c

""""
ssl_info = malloc(128);
                apr_snprintf(ssl_info, 128, "%s,%s,%d,%d",
                             SSL_CIPHER_get_version(ci),
                             SSL_CIPHER_get_name(ci),
                             pk_bits, sk_bits);
""""

here you see no check for enough mem, result is crash, with overwrite of execbase.i can make ixemul more stable when i do a check in snprintf that it do nothing when 0 pointer, so all programs work better, annother reason again 2 Versions.

""""
if ((cleanenv = (char **) calloc(AP_ENVBUF, sizeof(char *))) == NULL) {
        log_err("failed to malloc memory for environment\n");
        exit(120);
    }
""""

here if the memalloc fail the program is end (exit(120)) do that and a user cant free some memory so the program contiue to work

there are other places that do mem alloc check in apache, but i think all result in that case that apache end.but the requester in ixemul allow a user to free some mem and he can then click on try again and apache do not end and continue to work.


A black and white list is too much work for this feature, but there are only contra about that feature here read only pro from me, i deactivate it as default, and if a user want be more sure that his system not crash, he can activate that.

Jumping back to version 49.30 sounds better. The main problem here is IMHO that there's no cooperation between OS4/MOS/OS3 developers and they don't work together to bring new ixemul versions...
[/ QUOTE]

this too not work.OS4 have their lib number as V51.1 but this support not OS4 functions.

Also when you say, we should stay at a same level, then look on programs that are out.

every dev side do additional work, to support only their features.

for example read here about the itf8_decode function only in MOS 2.0
http://utilitybase.com/

for this few lines, netsurf is not easy portable and need MOS 2.0.o think with codepage.library utf comvert is too possible, maybe it need not char by char call and is faster, i dont know.

My experience is, that new MOS or OS4 functions are mostly small functions, and devs do their best to make their programs not easy portable.

.see netsurf or OWB or other opensource programs that are portet opensource.Yam /simple mail have much more complex GUI as OWB or netsurf and there is a sourcetree possible without changes.

but when look on netsurf, i see  1,3 megabyte OS4 only code and 960 kb MOS MUI only sourcecode.

I really ask how it is possible to write so much diffrent code only for diffrent GUI that is far not so large as YAM or simplemail.

Is reaction really worth to do this big extra work ?

in the linux world there is tolerance for each system.but not an amiga OS.the comercial aspect, that every commercial AOS need enough user to support further development, introduce the red versus blue war i think and some strange comments to other systems that enhance AOS features too.

Again it is not easy to change the ixemul name only and programs can work together.

if it is easy, then i think Piru have done this and post the diffs here.I have suggest him this at beginnung to do, but he write instead long in my eyes unlogical and senseless Posts with wrong Facts, i must correct, so i need write too much.

As ChaosLord as suggested, couldn't new v61 ixemul be statically linked? that way we would fix the problem temporarily until the 3 teams cooperate.

i prefer that with 68k SDL, but sdl is also a static lib, so it is easy.

but for ixemul this also is too much work in compare the advantage you get, i really dont know what problem it have.

ixemul V61 programs dont crash MOS, situation is same as a MUI4 program run not on MUI3.

[bernd_afa]

@bernd

The Apache example is a good example because it's not a user program. It's a webserver which won't have a user infront of a desktop at all times. It will for exaple run headless (no monitor/screen attatched) on a computer, and when it crashes will be autorestarted by a script or other admin tools. It's up to the admin to setup and configure such a system. If a library then start dioing GUI requesters, the admin gets unexpected behaviour, and the server cannot recover by its self. There are many readily made scripts for apache and other server tools which does this, they don't know or have any way of muting such a requester.

ok, i add a env var, a blacklist is too much work.adding this usefull requester cost me 20 minutes and help a lot.thats a good effort in time to usability.but for coding several hours on such a feature i have no patience because many other i want do that i need more important, maybe something other do that perfect with black and whitelist ?

you are right, i think more as a user, because i want use amiga OS Software and not only coding for fun.i know lots of programs that theoretic, selten used functions can easy use and the everday functions are hard to reach.

I like a feature that give in 99,9% of real world usage a advantage or easier to use.if this is in 0,1% give more work, then overall the time save is a better result.

i think in praxis it more happen get 6 rights in lottery than on amiga os a apache run out of mem ;-)

i think when somebody set up a webserver that run standalone he look that he can not run out of mem carefull on amiga and look that at least 5 megabytes of mem stay free.

And he mus also be carefull that the harddrives are not run out of diskspace.

and when he have appache running and start another program, that need more mem, he have access on his computer, the requester come and he can close the other program or free some mem.

[bernd_afa]

Well, in those last posts we didn't mention to rename the lib, i just suggested to set the version back to 49.x considering it should be ok to both parts (you Bernd, and Piru).

Yes, i can do that

Please, forget about the existence of ixemul for OS4, and then tell us, what do you think now?

the Facts are this.

68k have a unix emul lib that want MOS devs port to use ixemul Software on MOS.

but during time, ixemul miss more and more features (C99) so they need add.

But when there is somebody that enhance this ixemul library on the Home platform, Piru didnt like that.

now we find out, that it is from MOS dev side not suppport to create 68k progs that use V49 functions on MOS.

i think thats nearly the same as when i add a requester in ixemul 68k V61 libc.new ixemul progs cant use on MOS.

then i can name the ixemul libnum as V51.

should i do that, is then Piru happy ?

thats exact the same situation, because V49 funcs on MOS can only run on PPC.68k they want not support.

MOS have a 68k emulator and can exute 68k progs.

so to follow the MOS side rule, i must add a requester this code cant run on MOS.

Is this now better ?

But i think its better to get new features on MOS too running and increase the feature of all ixemul

If you add blacklist whitelist code is nice.
i think best is only a blacklist, here can add the few programs as apache, that can restart on crash.

What do you think about this ?

[bernd_afa]

Wasn't NetSurf first made for another platform not related to Amiga at all? how it could require some MOS specific stuff?.. (if some implementation indeed requires mos, then just skip it, you know what i mean  )

the OS4 and MOS side add own code, look on source, OS4 side add a amiga folder with 1,2 megabyte source, and MOS side add a mui folder with 900 kb size.but this folder contain 400 kb of OWB source.

So it look like coding on MOS the same features, there is not so much code typing need

the dir render that contain the browser engine use too 900 kb
another folder css contain 730 kb

so on the source contents can say netsurf is amiga browser, because many is code for amiga specific ;-)

there is a folder for beos, this use 568kb of code.
I like OS that can with less typing reach features, maybe i should change to Beos ;-)

[bernd_afa]

If I understand Piru's arguments correctly, the changes to the ixemul includes will affect anything compiled with

do you think Piru is god ?

Wy you dont believe what i write or wy you not download the ffmpeg and try out on MOS ?.Here you see it do not crash.a requester come need V61 ixemul.

the new includes cant crash on MOS.

but i get in mind, its possible when you do stupid thing.

When you use new V61 libc (that must copy by hand in lib dir)AND not the corresponding V61 crt0.o is copy to lib dir, then it can crash on MOS, because ixemul have the bad design that the version check is in crt0.o and not in libc.

but it is easy possible to remove the check in crt0.o so they are always the same and add the version check in libc.maybe in further release i do that.

[bernd_afa]

I have absolutely no doubt that is what will happen - because ffmpeg specifically requires v61.

But consider a program that specifies v48. Compile it once with the v48 includes. Compile it again with the v61 includes. Run each of them under MorphOS. What will happen? If nothing bad happens, then I'll shut up and say no more on the matter. :-)

this work too.if a program crash because new features are miss, is not dependent from includes.

it depend on lib you link.the libc contain the functions for ixemul.

when you link with V48 libc then only the V48 functions can use.if a Unix program use a function that V48 not have, but V61 then you get a compiler error.the program cant build, no executable here, that can crash.

same happen when you use SDL for ixemul.on V48 libc.You get compiler error ix_CreateChildData not find.

when you use V61 libc stuff, then it compile well but on MOS get now error ixemul V61 need.

>I again refer back to the suggestion to integrate multiplatform >builds in the style of Jens Langner's projects.

but thats not my problem, we have ixemul on amiga sourceforge and everybody can jump in and do a MOS or OS4 native Port.

But there is red versus blue war and as can see on netsurf, OWB, or other ports that OS4 and MOS cant working together, same on ixemul lib too.MOS V49 and OS4 V51.1 are some kind of diffrent and diffrent sourcetree.

I ask some times about the OS4 source of ixemul, this i not get.

No, if you really hate MOS let those programs crash

i dont hate MOS.

[bernd_afa]

it was an ironic joke, meaning it should be better doing nothing (let it crash or whatever) rather than showing annoying requesters about a program [MAY] not work under MOS and making it die. (unless you create a crt0 which check for version AND revision of installed ixemul..)

on german anews there are more lies tell about ixemul V61 , but nobody tell wy this version not work.MOS os4 can run 68k programs.

So to have same effect as rename the library, a check for MOS and OS4 must done and the program end and if really a MOS or OS4 user copy the ixemul v61 lib to his system, then this is not load.

but of course nobody can test and find bugs wy this ixemul not work on MOS or OS4.

when enhance a amiga library for OS3, for example intuition library, or guigfx library  this make then too problems on MOS or OS4.

because MOS and OS4 have diffrent enhancement, that make only no problem because mos binaries cant execute on OS4 and OS4 benaries cant execute on MOS without emu.

but 68k executable can run on both.

So thats the reason that there some guys that want that 68k not furrtherdevelop.the degrade 68k to a retro system that should not enhance.And this is bad.

and this problem can either solved complete by rename the lib or by check for MOS or OS4.

how mos can detect i know, but how is OS4 detect in clean way ?