Launch Deluxe Paint from Wanderer!
Even so I did not fix all screen related bugs, I was too bored with screen stuff already. So I decided to go for an "easy" target, the integration into wanderer.
I had to add some code to wanderer.c, which is very j-uae specific. But wanderer.c is not the most beautiful code on earth anyways (no offense), so I don't think it does any harm there. As soon as wanderer detects an m68k amigaos binary, it searches for a special public port "J-UAE Execute" and sends a message to it. If the port is not available, the original wanderer functionality is not changed. Wanderer code is not yet committed, as it is not complete yet (parameters will change) and I don't want some incompatible nightlies causing a debugging nightmare for me.
J-uae starts a thread at startup, which opens that port and waits for messages. As soon as one arrives, it checks, if the path of the clicked icon is inside an in amigaOS mounted volume and if launchd is running. The tread then stores the command in a linked list (GSList, sorry) and sends a signal to the amigaOS launchd, which you should have started in s:startup-sequence of your amigaOS installation for example.
Now the launchd calls a trap to get the next command from the j-uae master thread and the tries to start it with the help of the wbstart.library from aminet. As soon as launchd got his command, j-uae master deletes the command from the list.
As launchd is independent of all other j-uae features, you can use it in a non-integrated j-uae environment, too of course.
Three things are still missing:
- error handling/messages
- buffer overflow checks, if path gets too long
- wb parameters
All solvable, but boring ;). So enough for today :).
Even so I did not fix all screen related bugs, I was too bored with screen stuff already. So I decided to go for an "easy" target, the integration into wanderer.
I had to add some code to wanderer.c, which is very j-uae specific. But wanderer.c is not the most beautiful code on earth anyways (no offense), so I don't think it does any harm there. As soon as wanderer detects an m68k amigaos binary, it searches for a special public port "J-UAE Execute" and sends a message to it. If the port is not available, the original wanderer functionality is not changed. Wanderer code is not yet committed, as it is not complete yet (parameters will change) and I don't want some incompatible nightlies causing a debugging nightmare for me.
J-uae starts a thread at startup, which opens that port and waits for messages. As soon as one arrives, it checks, if the path of the clicked icon is inside an in amigaOS mounted volume and if launchd is running. The tread then stores the command in a linked list (GSList, sorry) and sends a signal to the amigaOS launchd, which you should have started in s:startup-sequence of your amigaOS installation for example.
Now the launchd calls a trap to get the next command from the j-uae master thread and the tries to start it with the help of the wbstart.library from aminet. As soon as launchd got his command, j-uae master deletes the command from the list.
As launchd is independent of all other j-uae features, you can use it in a non-integrated j-uae environment, too of course.
Three things are still missing:
- error handling/messages
- buffer overflow checks, if path gets too long
- wb parameters
All solvable, but boring ;). So enough for today :).