FFmpeg + FFplay SVN-r18880 (m68k)

[dcr8520]

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

apache was a very good example.. and using a global environment variable to disable your "hack" (requester) is not good either for other programs which may need it.. The best should be to create a "blacklist" (or "whitelist") where to add programs which should or not use that extra check over malloc(), IMHO.

That said, IIRC all that regarding "strange versions bumps" started due the broken V49 version for m68k. Well, what about REMOVING from Amiga.sf ixemul V49, 50, and 61, AND THEN change your ixemul 61.1 to version eg 49.30 (i think last MOS version is ixemul 49.26) ?? Can't this be ok for both parts?.. (if this cause certain m68k programs to crash under MOS/OS4, don't worry, we should interpret it as a MOS/OS4 fault, the same way other programs already crashes under OS4 by the V51 version used there(?))

[dcr8520]

They don't really need to "work together" to bring new ixemul versions... there we had V48 for ages and a new V49 was made for MOS bringing new API functions, then that lib gets backported to OS3.. if new functions are added later to that os3/68k version, the MOS's ixemul-maintainer should implement such new api functions to create THE compatibility, and so on for each platform.

How the library itself works internally on each platform does not "really" matter.. while it works ok (without causing conflicts between systems), of course. For example, for the ixemul >= 50 Bernd had to get the vfork/signals stuff from the V48, because the one re-implemented for V49-MOS didn't worked ok under OS3/m68k.. but thats ok after all, the new ixemuls are (should be) compatible with the <= V49 branch, regardless how it works internally.

and about SDI headers, thats ixemul.. not a simple OOP "program" i doubt it can be done by using macros, i think everything would need to be ifdef'ed to compile ok around systems.

[dcr8520]

A black and white list is too much work for this feature

This isn't much work at all, imho. i can write such code myself if you want.

Jumping back to version 49.30 sounds better.

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

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

(You DON't need to worry about if a ixemul program crash under OS4, it is just not your problem)

netsurf is not easy portable and need MOS 2.0.

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 )

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

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).

ixemul V61 programs dont crash MOS.

I really wonder why you worry too much regarding if 68k programs could crash under MOS/OS4, seeing you don't said good things about those OSs at all.

[dcr8520]

treat the incident based on blacklists and whitelists.

Yeah... you had a very good idea there..

[dcr8520]

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

Ok, we achieved something

then, Piru, it is ok to you as well to set the ixemul-68k's version back to 49.30?

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

Is this now better ?

No, if you really hate MOS let those programs crash

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 ?

I hope you do not mean to auto re-start programs when an allocation fails.. in the worst case we can add a per-task flags/options for the behavior to be achieved when an allocation fails, EG: a) show a requester b) kill the application c) let the app continue, etc...

I'll start working on this the next weekend.

[dcr8520]

If I understand Piru's arguments correctly, the changes to the ixemul includes will affect anything compiled with them, even if they don't use v61 features

isn't (only) about the ixemul includes, it's mainly related to the crt#?.o files (startup code each program is linked with, which requires a newer ixemul version regardless if it really needs it)

and that's why running those programs under MorphOS will result in crashes.

No, ATM those programs can't crash under MOS because those programs can't even run there (no ixemul V5x or V6x there)

But, those programs will start to crash under MOS if we set the ixemul-68k version back to 49.30 (until the Ixemul-MOS is updated to implement the new API functions added on newer m68k builds), whatever it is, setting the version back to 49.30 seems the correct action, rather than bumping to 50, 61.1, 70..

[dcr8520]

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

do you think Piru is god ?

Well, in the Amiga World... yes, almost at least

Do you know/remember he rewrote the Exec? with that i said all

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.

Yes... we need to find a proper way to not require always the higher ixemul version, if new features are not really required/needed/used.

[dcr8520]

i dont hate MOS.

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..)

[dcr8520]

I find now a solution that is easy to add, and PPC User can happy that they have the higher library number ;-)

I open in crt0.o the ixemul library V48
when a lib is open, i check in library structure for V48 number and the revisionsnumber.

Don't do this.

Yesterday, I started testing a method to open only the required library, meaning that if someone compiles a program using V61 SDK, and that program only uses V48 functions, the program will only require ixemul.library V48. that's nice/best, isn't it?

First tests i did succedd, and for now i only found a problem... that method only works with no-baserel programs... anyhow, i guess thats the 90% of the software..

i'll continue with it sometime soon.. (yesterday i just had some free time, and i decided to try that rather than the blacklist implementation which will require more time than i used for this )

[dcr8520]

yes this work, when the libc and crt0.o from V48 is used.

I do not mean to use V48 files, this will work dynamically (at runtime) from whatever ixemul version you build next. well, i already provided you the details by email

win vista for example bring such a requester when you want install a XP driver.

Vista brings a requester everywhere with everything ;P