So you are going to write wrappers for every known file system packet out there? Fine. Dont forget filesystem hooks, though. What are you going to do if someone wants to execute 68k native code in the filesystem context?
No, I'd suggest supporting the known packets *with known uses* by *known apps that people still care about*. There aren't all that many, and the mapping is fairly mechanical and can to some extent be automated (you'd need to describe the fields, but there's no need to manually write all the code).
As for handling the hooks, again, why do you think this is even a problem? It is no different from handling any other part of the system - you need to trap any attempted read/writes from/to the "host" and translate appropriately. Tedious, sure, but not much more.
But more importantly, since the number of possible applications is small and finite, if there are any particularly troublesome applications you can add workarounds for that specific application.
This is a shortcut for rewriting a subset of applications - it doesn't need to be perfect. It needs to work for the m68k applications a reasonable number of people still care about and where it's not easier to port an existing alternative application instead. For the rest there's UAE.
I think a lot of those of you that think this is so hard are massively overestimating the scope of this.
We don't need Emumiga to be able to run every legal m68k Amiga app - the only reason to do that would be just to say you can -, just ones already in existence. We don't need Emumiga to even be able to run all of the ones in existence, only the ones that people want to be able to run regularly on AROS with tight integration.
For apps that people rarely if ever run or want to run other than the occasional trip for nostalgia and/or that doesn't need any form of integration (like most games and demos), there's no point - Janus UAE is sufficient.
This isn't like Wine where there are millions of apps that people want to to run, and where tons of apps are still actively developed for the Win32 API that are not being made available for Linux, and that drives people to want and expect Wine to run "everything" (even then: I for one have noticed how the interest in Wine has waned since virtualization meant that people increasingly only care about Windows apps that they want tightly integrated with the rest of their desktop)
There are "only" about 30000 m68k archives on Aminet that are even *potential* candidates (when you've excluded MOD's, demos etc.). Beyond that there are a few thousand commercial applications at most. I don't know how many of those are still interesting enough to care. Games (barring possible "workbench games") are outside the scope of Emumiga.
My guess is that 5000 packages that would be even worthwhile for Emumiga to target would be seriously overestimating it, given that a ton of those 30000 either won't be code, will be various old versions, utilities that plain doesn't make any sense anymore, apps that nobody uses, apps that are open source and better handled by porting/recompiling for AROS etc., or apps that have already been ported.
There's no doubt Emumiga will be a lot of work, but even if you have to add manual workarounds for a lot of the applications in the "interesting" set, it'd still be feasible.
Parent and child objects (which could be 68k or AROS code, you never know) are called via DoMethod() calls. And DoMethod() call is not an OS call but it is simple call in amiga.lib or inlined to application so you can not easily trap calls to AROS code.
It's fairly simple to automatically create thunks to handle this. I've written enough compilers with custom object systems to have done far nastier things than that.
and it will be slow because on every context switch you dont have to change only one data structure but data of every object in Zune application (objects have pointers to other objects so every referenced object must be translated to right endianess).
Since the m68k side is emulated, you can easily lazily mutate data first when it's actually needed on the m68k side. Will it be slower than "just" emulating everything in UAE? Maybe, but frankly it doesn't matter with the performance of modern x86 hardware.
