Welcome, Guest. Please login or register.

Author Topic: new ixemul V62.1 for 68k.  (Read 10562 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: new ixemul V62.1 for 68k.
« Reply #14 from previous page: November 18, 2009, 05:56:07 PM »
Quote
again, where can see what API functions the libnix of MOS have ?

You cant.

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

Quote
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.
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: new ixemul V62.1 for 68k.
« Reply #15 on: November 19, 2009, 06:42:27 AM »
Quote
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.

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

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

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

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

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

And how about sockets? Can I assume WaitSelect() works?
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: new ixemul V62.1 for 68k.
« Reply #16 on: November 19, 2009, 12:01:16 PM »
Quote
when amiga OS go memory Protection.

For fantasy writings I prefer J.R.R. Tolkien.
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: new ixemul V62.1 for 68k.
« Reply #17 on: November 20, 2009, 06:40:15 AM »
Quote
I watch out for news of Hyperion Secret Project on their Webpage.maybe they do memory protection... ;-)

Then existing Amiga software is not going to work anyway. So...

Quote
but anyway, a Function that set and get Task user Pointer is the cleanest solution so nobdy need hack in the task structure.

But the task structure is already public. Adding Set/GetTaskUserData() is not going to change anything. There is no way you could add non-co-operative memory protection, there is no way you could get existing software support new APIs, the whole Amiga API is flawed anyway.
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: new ixemul V62.1 for 68k.
« Reply #18 on: November 20, 2009, 01:53:47 PM »
Quote
normaly you need write

struct Task * task = FindTask(0);
task->tc_UserData = dat;

or write

SetTaskUserData(FindTask(0),dat);

This is only little bit more useful than using AllocDosObejct() to allocate FileInfoBlock. Luckily your version does not have return code.

Quote
I think changing a big Unix program to work with libnix is lots more work than use a function

You might thinks so but it isnt so. Not with MorphOS libnix.

Quote
also i told you ixemul can easy change to use tc_taskTrap instead of tc_TaskUserData.

But maybe I am using tc_TrapData field for my own purposes. Unlikely but possible.

Quote
there need lots more programing work to get a Big unix program with libnix MOS working i think.

Usually problems lie on path handling. They default to /usr/ or parse paths in Unix way. If I was using ixemul I would have to do that anyway because it is not very nice when users start getting "Please insert volume usr: to any drive" requesters. Unless it is GeekGadgets port which requires GG environment anyway.

Another big problem is porting dependencies which sometimes takes over five minutes. Five hours if I create shared library out of it.
« Last Edit: November 20, 2009, 01:57:30 PM by itix »
My Amigas: A500, Mac Mini and PowerBook
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show all replies
Re: new ixemul V62.1 for 68k.
« Reply #19 on: November 21, 2009, 02:05:06 PM »
Quote

make a unix lib for MOS seem lots work.


It is basicly the same as in that ixlibrary package you posted above and if you had used it in more complex projects you would know why ixlibraries also need lot of work sometimes ;-)
My Amigas: A500, Mac Mini and PowerBook