[uae] Re: 'New' bsdsocket emulation (was Re: A bit of static/extern problems with GNU GCC 4.0.0)

  • From: anarkhos@xxxxxxxxxxx
  • To: uae@xxxxxxxxxxxxx
  • Date: Mon, 13 Jun 2005 12:16:03 -0700

I always wondered why they hung on to the Mach-O binary format. About the only
advantage it is has over ELF is support for fat binaries. Of course, now its
obvious why they wanted fat binaries. ;-)

Actually they kept Mach-O purely due to their ObjC tool chain :-\

I wouldn't call FAT binaries much of an advantage. Personally I think they should have stuck with CFM, but then I'm not Steve.

 > Like what? :)

Well, the problem is how to call AmigaOS functions from the emulator. The
solution at the moment is the 'stack-magic' code, which creates a new stack
frame and thus makes it possible to swap to a new stack context to execute an
AmigaOS call and then swap the stack back to resume the emulator code. It's
kinds of like setjmp/longjmp with knobs on. ;-)

A more portable method to do this, at least SYSV-compatible operating systems,
might be to use makecontext/swapcontext.

A better idea all together would be make the CPU emulation re-entrant, so all
this nonsense shouldn't be necessary. There's still some way to go to achieve
this yet.

Wouldn't it be better with some kind of shared memory scheme where the native code behaves like some kind of callback...oh who am I kidding. You're more in the know with respect to these issues than I am :)


 > BTW: You have less than a year to add PowerUp support ;)

Hehe. It's on my list of things to do.

Well things seem to be pretty stable now... ;)

> I'm sorry if I haven't been working on e-uae OS X, but I've been busy
 working on Darwine since Apple's announcement. Learning some nitty-gritty
 about OS X's event handling and graphics. Not too dissimilar to what e-uae
 needs to squeeze out some better performance and compatibility.

That's an interesting project. Good luck with it.

Thanks.

I've gotten to the point where I can create a window, draw in it, put a custom control over the title bar, handle click, keyboard, and menu events:



(imagine this except with a menu for WINE stuff)

I've also made a custom WindowDefSpec which will eventually replace the control-over-title-bar cheesiness.

David, who is working on this with me, has been working on a lot of the back-end issues like thread blocking and window handle saving. I don't think either of us would have done too well on our own.

Alright, back to hacking :)

Attachment: bluebar.png
Description: PNG image

Other related posts: