14.11.12

Ancient Browser Experience

While trying to match 68k bsdsocket calls to x86 bsdsocket calls, I realized, how "old" our bsdsocket.library seems to be. Nearly every bsdsocket.library function is marked with texts like "THIS IS A DEPRECATED METHOD OF GETTING HOST NAMES" in modern man pages..
Nevertheless, there is progress :).


Aweb can be started in AmigaOS 3.1 running in j-uae v1.3 and load at least parts of a webpage. The real challenging parts of m68k <-> x86 communications seems to be fixed. 

Every call from an m68k application has to take the following route (aweb example):


aweb -> 
m68k/bsdsocket.library ->
j-uae TRAP handler -> 
x86/j-uae-bsdsocket-task -> 
x86/bsdsocket.library
 

For every open of a 68k bsdsocket.library (every open creates a new SocketBase), I start a new x86 process, which then himself opens a x86 bsdsocket.library. Every 68k bsdsocket.library function call needs to be serialized through the j-uae trap handler and then routed to the according x86 process. 

The communication between the x86 native trap handler and the x86/j-uae-bsdsocket-tasks is done with simple Put/GetMsg calls, just to get an individual task context for each library base.

9.11.12

Maybe Santa prepares a gift for you

I can't promise, if this feature will make it into v1.3, as it won't be stable so soon (and I won't release anything known to be broken), but have a look yourself:


Seems as if the 68k AROS side got a bsdsocket.library :). And it can at least send data to a webserver and get something back. And it can resolve IP addresses to host names.

But this is all quite an ugly hack. Only one process can access bsdsocket.library at the same time, the AROS sibling bsdsocket.library is never closed etc. etc.

Yeah, I know, I should first fix Paolo's bug list, but from time to time something new is nice, too ;).