new ixemul V62.1 for 68k.

[itix]

If HOME is missing you could just throw a requester kindly asking user to reinstall GeekGadgets.

[itix]

I have not tried 7z on MorphOS but AFAIK there are no known bugs in MorphOS ixemul. It does not mean it is bug free but MorphOS ixemul is perfectly compatible with the original 68k ixemul software. Minor bug fixes have been here and there with enforcer hits.

Only exception is applications which are using statically linked ixemul code and wont work in MorphOS. Similary 68k ixemul.library wont work in MorphOS. IIRC vfork() is major problem there.

[itix]

maybe you can try it.just a simple start is enough.that there are not known bugs happen maybe because users do not use MOS and ixemul software.or if the soft not work, they accept and dont report, because they like more native software

I dont know but I am using ixemul software daily because I code using GeekGadgets environment. And it is the same for rest MorphOS developers.

But i notice lots bugs that happen in 68k programs with ixemul from MOS and new MOS code.
All in all i can say it was a mistake to use the MOS version but its possible to fix this bugs

It could have been easier use the original 68k source code and import only bugfixes from MorphOS version. MorphOS version is MorphOS version and AmigaOS compatibility is not maintained there.

http://aminet.net/package/mus/play/pmdplay_68k

It was compiled under "ixemul.library 48.0".

First of all it is broken port because it is using ixemul. Ixemul is meant to be used only with software running in GeekGadgets environment.

But I can try it out later anyway. I dont have Internet at home and my Efika is not running yet either. It is the same with Abuse. Though, Abuse should not have used ixemul either...

With ixemul you run into other problems because ixemul supports Unix paths along Amiga paths and Unix paths have precedence. When I started working on SDL I thought that I should support both Unix and Amiga paths but later I realized I should only support Amiga paths. Unix paths should be fixed in the ported application instead including $HOME.

I have ported only one SDL game using ixemul where it was too problematic port it using libnix. Luckily it works even though SDL on MorphOS can load files only using Amiga paths. On every other port I have fixed Unix paths to Amiga paths and fixed $HOME to use PROGDIR:. In early days I didnt care about $HOME and my ports were cluttering $HOME on my GeekGadgets installation.

[itix]

Its more easy to do a lib that run only a few programs well and dont test other programs

Most if not all binaries in gg:bin are ixemul including gcc2, gcc3 and gcc4. That is plenty of software. I also ported Ruby to GeekGadgets. And when you look at Ruby you see why ixemul and GG is usually used together: directory layout of Ruby fits perfectly to GeekGadgets.

but it work with V48.there are lots programs compile in last year from diffrent devs that work well with Linux or amiga paths.so there is no reason see currently that a geek Gadget system install is need.

But there is no any reason to use ixemul for non-GG software. There is libnix for that. And clib2. Why would you use Unix paths on an Amiga Internet browser?

So limit ixemul only to few programs is not need.
because time is short the easiest way can go to get soon a result

In MorphOS we are using libnix for quick ports. Sure, lbinix for 68k is outdated but then MorphOS developers extended and developed libnix more to get it more compatible and up to date.

[itix]

there is also no reason to use ixemul not.if there is really a problem with unix and amiga OS paths, then tell a example.

For example if you have path "/foobar" will it work right?

having unix paths is also a enhancement for AOS and fit good in AOS.

Sure, why not make it default in AfAOS.

instead Progdir: you can just write ./

But what if I want to access a file named "." or even ".." ? And I want to use PROGDIR:. This is Amiga, not some Unix clone written by some Torvalds.

I dont know how much MOS libnix is update, is there somewhere a explain of funcs ?.Is there full C99 support ?.

I dont know what C99 exactly needs from it but new headers like inttypes.h were added.

Can with this ffmpeg and ffplay compile with comfigure and make ?

Dunno. I never tried. But then, ffmpeg is shitty Unix software.

I think ixemul have far the best Linux/Unix comapibility and when use Linux code, its best to use the best.

If you want Linux compatibility I can recommend installing Ubuntu or Kubuntu. AFAIK they have better Linux compatibility.

If the MOS devs dont like that, and their lib is only test with GCC geek gadget and ruby and not with the ixemul programs that are out, then this lib should be better named as mini_ixemul for MOS and OS4.

Nah, MorphOS build is full ixemul build. It supports all ixemul features. It is just that MorphOS developers are not trying to bring Unix to Amiga. If you want Unix, get OS4.

[itix]

I dont have Internet at home so I am replying late.

But what if I want to access a file named "." or even ".." ? And I want to use PROGDIR:. >This is Amiga, not some Unix clone written by some Torvalds.

thats more a theory.Do you know a program that use . or .. as file ?

I think my I start using . and .. as filenames in my future developments for Amiga.

Nah, MorphOS build is full ixemul build. It supports all ixemul features. It is just that MorphOS developers are not trying to bring Unix to Amiga. If you want Unix, get OS4.

sadly on OS4 ixmemul work too not full.I still have no MOS tester see, that say me that this ixemul programs work well on MOS.

I dont care about OS4. If there is no full ixemul port -- too bad.

My software synthesizer have 170 GUI elements in diffrent tabs and 1 window.I think its hard to keep an overview about this, when i like change something when this is in MUI or reaction syntax.

but there is also nice Linux Software here.so wy not use it.but i dont spend lots work to port Linux soft, because i dont like MUI or Reaction.Storm Wizard cant furtherdevelop so need go another way.

Sure. I have ported n+1 SDL games to MorphOS. Many of them are bad while some games are brilliant.

GTK i think is acceptable, there are nice GUI Editors here so i have hope, that i can soon change all my software to gtk+ and zune and use the GUI Editors.

When it comes to GTK you probably can not port it natively to Amiga Intuition. You must either use custom screen (Cygnix style) or go GTK-MUI kind of route. And GTK-MUI needs more work because GDK-MUI layer is needed in the future. On the other hand GTK-MUI is not that bad because if you do it cleverly you can recycle lot of original GTK source code.

I have to comment this one:

>- total leakage of any AmigaOS allocated resources on exit() or abort()

thats on all AOS libs same, they have no resourcetracking, when a program need that it must use atexit.

Do you know what happens to your atexit() calls at abort() ?

[itix]

but as i told i add a function
ix_AmigaPaths(true)

then the unix path translation is not done.

Or do you reall think thats not possible ?

I have found better method: I am using -noixemul switch.

Btw how is auto-open libraries working with ixemul?

There are lots other ixemul soft out that run well on ixemul V48 and V62.1.
And if you dont want that it run on MOS native ixemul well and fix Bugs, then the MOS devs should rename their ixemul to mini_ixemul or maybe tiny_ixemul.

whne look at storm mesa the MOS side do it right, they do not port a stormmesa which miss man features and name it Mesa.They name it tinygl

There is one difference. Tinygl is not based on mesa. MorphOS ixemul was ported from 68k ixemul and is compatible with the original 68k ixemul software but makes it possible use ixemul from PPC native software. So it is the same but extended for MorphOS.

Then there is someone who figures out that MorphOS ixemul has higher version number and it is somehow important to have this ixemul on 68k Amiga because it has higher version number. There was nothing wrong with the original 68k ixemul but ixemul had to be ported and now Amiga users had ixemul V49 for 68k Amiga. It didnt work but they had ixemul with higher version number which matches with MorphOS.

Okay, there are bug fixes in MorphOS ixemul, some maybe even important, but only reason why 68k ixemul went out of hand was a version number.

[itix]

I and i think many other dont know how auto open in libnix work.

Time to find it out then.

Most do the logical Amiga OS way, that is explain in RKM.Its really not much work to open a lib.there can also do a code snippet that open often needed aos libs.you need only paste it

but its really lots more easy to use way from RKM then port a big Linux program to work with a small libnix.

struct Library *AslBase:

AslBase = OpenLibrary("asl.library");

and at end of source or in a atexit func you need do

CloseLibrary(AslBase);

It is not enough for ports :-) I have created lots of shared libraries for MorphOS: powersdl.library, iconv.library, intl.library, hpdf.library, littlecms.library and many more which are used in my ports. When I am porting stuff from other systems (usually from Unix) I dont have to add code to open those libraries. It is done automatically for me.

You still have not written if the programs i post work on your MOS.Your excuse is only that this programs should not use with ixemul.

I dont have Internet at home (yet).

what do you say when a program use opengl functions that MOS tinygl not have.
Do you think this program should port so it work with the fewer functions of tinygl or its a shitty program ?

There is tinygl maintainer. When there is missing opengl call I ask what could be done about it. Sometimes there is workaround, sometimes tinygl maintainer adds missing functionality, sometimes I have to drop project.

enhance libnix is too possible but wy need not 2 big unix API(ixemul and libnix) i think.You yourself tell you want not use this shitty Un++ix Ports, but then i dont understand, wy MOS devs have add more functione to libnix to make porting more easy.

The official word is: do not used ixemul unless you know what you are doing.

more functions help more easy port programs.MOS devs see that too and add this new funcs to libnix as closedsource.

There is also clib2 developed by Olaf Barthel. It is open source. I dont know how well it compares with libnix but I think it is fairly good alternative solution.

[itix]

and where is a program that use auto libopen as an example ?

I dont know how it works in 68k but in MorphOS it works just like SAS/C constructors/destructors work.

Maybe this one: http://aminet.net/package/mus/play/ahxplay

There is libahxplay.c which could have auto-open feature. I can not verify this without having an access to my sources and I cant bother installing LhA unpacker to this XP machine.

btw when create a library then it must do always by hand.libauto cant work.

Actually it can work if you know how to make it work. Anyway, please dont tell me you are using ixemul in shared libraries.

Do you mean this maintainer or do you mean MOS maintainer ?

MorphOS maintainer.

And what do you do if this maintainer

http://fabrice.bellard.free.fr/TinyGL/

update his tiny GL Version so its not compatible to MOS new stuff and increase lib number ?

Apples and oranges. MorphOS TinyGL is heavily extended and pretty much only thing it has common with the original TinyGL is a name.

But even then, so what. The official SDL is maintained separately from PowerSDL. When there is new SDL version I maybe update PowerSDL on MorphOS. Or maybe not. It is up to me.

Bit i see diffrent on MOS sdl.its called powersdl and it is based on old SDL Version 1.2.6 that was here for AOS and AROS.You add new features, choose another name and version numbering as SDL.

There is good reason for that: I dont maintain Amiga SDL nor sdl.library. Thus any changes to sdl.library would be incompatible if Amiga SDL development was continued by its maintainer.

So wy there must do much work to make this identical Ports working with the less featured libnix ?

Ixemul is not safe.

its fact, ixemul is born on 68k and if you accept me as furtherdeveloper or not, you cant force that MOS devs are right when they want force that ixemul should stay forever on this low linux compatible level and instead should enhance libnix with more Linux funcs.

We cant force you to do anything but we would appreciate if there was more experienced developer maintaining 68k port.

[itix]

string = malloc(;

strcpy(string,"123456789");

now with libnix you get memtrash and your program overwrite memory and crash sooner or later randomly.ixemul report this.so a programmer notice this.so ixemul is more safe and bring no speedloss

Bleh. That is not safe. It is placebo. It can crash your system at any time. Ixemul can not magically trap malicious code.

But now what test we should use to show that ixemul is not safe ?

It just isnt. Do not mix ixemul with native Amiga API calls.

YOu should really try out ixemul V62 with more programs,then you see it run stable.Then use your MOS ixemul.I think you see this run not so stable.

I can not use your ixemul because it does not support PPC native callbacks (i.e. atexit(), obviously).

but your only excuse is, that programs should not use ixemul and thats wrong.ixemul can do more than libnix and need not static link, so programs can be smaller.

With ixemul you still have static linking because of stubs.

[itix]

but you can use UAE and here its possible that you can run 68k Software everywhere.

I dont have UAE, I dont have ROMs and I dont intend to buy ROMs.

Every software can change so it can work, so its impossible that ixemul cant work with Amiga OS funcs when we know the reason wy it cant work to fix that.

Lets see... if I recall correctly ixemul uses tc_UserData for its own purposes. Right/wrong?

I can say you, that i planed buy a Mac mini and maybe MOS.But now i am sure, i not buy or need it, because guys that do that, the feature we not have we need not, i dont want suppport with money.

And I was going to buy Amiga Forever package but I decided to not buy it.

BTW:I remember MOS devs say long time ago when there are devs that ask for a newer GCC as 2.95 that there is no newer GCC need.or should i post links ?

Yeah. Problem is that newer GCC versions are quite buggy. There are still newer GCC versions for MorphOS, I have got all three GCC2, GCC3 and GCC4. GCC2 works for me so I am using it most of time. No need to use latest stuff always.

[itix]

I think not, does OWB or netsurf or any other with AOS Code enhanced Linux Port use that ?

I dont know. Do you?

#ifdef NOTRAP
printf ("#define USERPTR_OFFSET %ld\n", offsetof (TASK, tc_UserData));
#else
printf ("#define USERPTR_OFFSET %ld\n", offsetof (TASK, tc_TrapData));
#endif

there are other unused fields in the process structure, just tell me a place which is better.
i get a better idea.

It is not unused. I can use it in my own applications.

I really dont like when people say new Version have Bugs i use older without reporting the Bugs so devs have a chance to fix.when all users do that, then software get never be more features.best is test newer version and when it have bugs, then report it and use old software until fixed

Why? I am not a beta tester and I dont have time for that.

Have you try out 4.3/ 4.4/ or 4.5 on MOS and this are buggy ?

I tried some GCC 4.x version couple of months ago but I dont know which version it was. But it did its job.

Because the GCC Team make not GGC as opensource so that commercial OS developers port it to their OS to have a compiler but dont want to help to make it better.

If GCC developers are unhappy about it they can always quit developing GCC.

when the MOS 68k emul is fix, then ixemul should be run wirthout amiga forever

It would need support for PPC native callbacks.

[itix]

i think you should know if your netsurf store data in this field.its unused but can use in apps, but i know no practice software that use it.

Some of my Amiga software is using it. Mostly to pass pointers to subtasks.

I get in mind OWB, flashplayer, netsurf, mplayer.What did i miss ?

Any Amiga software with a GUI.

Btw Netsurf is not "Unix software". It was written for RISCOS and then ported to other systems.

[itix]

again, where can see what API functions the libnix of MOS have ?

You cant.

libnix have only a small first fit allocator 4 kb pool allocator, which do lots fragment and libnix have very small pools that need a lot of free poolsearch when there are programs that use much mem.

You forget that in MorphOS, when using TLSF, memory pools are completely different.

Was this mostly based on Unix code and need much API Features ?

Amiga native code but I recall I used it in my still uncompleted and unreleased Netsurf 68k release passing data to subthreads (my Netsurf port runs MUI GUI on separate thread). Or, I dont know. I just link with libnix and dont care about ixemul.

But even in Amiga native coding you often use at least snprintf(), maybe printf() or dos I/O. Even if you are happy with ixemul for your ports you still need good libnix for native coding.

[itix]

and btw i see that you open libs by hand also when __MORPHOS__ defines and not with libnix autoinit.so no need for libnix too.

When using Amiga native APIs (i.e. using MUI GUI) I prefer opening libraries manually. In SDL ports I dont because I dont want Amiga specific code to otherwise fully portable application.

I get also the idea just add the alloced memblock at the beginnung or end of the list tc_MemEntry that contain the userdata.

You can not guarantee it is compatible with applications using tc_MemEntry. They can add entries to head or tail of list at their will or even remove existing entries.

but i dont know how AOS work and add this allocate memblock to the list and on what place it come and of it is always sure that the block is at 1. or last place when i add it here.

Amiga does not do much with it. Applications itself manage tc_MemEntry.

Its also possible to change the process create function so it add additional space for that value.

task cant use dos, so ixemul funcs need no userdata

So you have to hack the OS.

Its possible to add the iserdata address at the end of stack range.only need not forget when use stackswap to copy this value too.but here can use a function ix_stackswap that work more easy as the AOS func.

But again you are putting restrictions. Ixemul works as long as developer does not do X but uses Y instead.

so you see no reason to enhance libnix and not use ixemul

And how about sockets? Can I assume WaitSelect() works?