@xenic
Quote:
I wonder if your OS3 version works on MOS. We already knew there would be some problems using it with OS4.
Yeah, i test that build on MOS for now: it works. Listers opens fine and works, no crashes or problems which arise on os4.
Quote:
It would be interresting to know if your compiled version works on a classic (68k) Amiga.
If you mean in general: yeah,i test it on os3 and it works. But if you mean those small bugs: nope, on os3 i didn't have them. I can do "load theme" and so on. But its all expectable of course, those small bugs will need to address later.
Quote:
Since I can't really help with the OS3 compile you are working on, I'll take a look at some of the assembler functions to see if I can convert them to C. For some it may take a 68k assembler expert.
That will be a good start ! I can just then grab C versions and include to os3 build, to see, if they works fine.
@all
Currently i trying to find out the roots of opening-lister crashes, and so far i hope i pretty close already (but help of amiga-coders-experts is need it of course :) ):
Code structured like this: Once we choice "Lister/New" in dopus5 menu, lister_new() function is called from lister.c. But its just simply IPC_Launch -> in end of lister_new() we have such kind of code:
// Start lister process
if (!(IPC_Launch(
&GUI->lister_list,
&ipc,
"dopus_lister",
(ULONG)lister_code,
STACK_DEFAULT,
(ULONG)lister,(struct Library *)DOSBase)))
{
if (!ipc) lister_free(lister);
return 0;
}
I.e. actuall code is "lister_code()".
lister_code() are placed in the lister_proc.c file, which inside have lister_open(), which placed in the lister_window.c file. But lister_code() not only call lister_open(), its in general main code with all the loops and stuff: that involve timing, icon, appmessage, reply to messages and handle answers from, and so on. lister_open() its just some crap like making actual window, idcmps, and so on, whicle lister_code() are our main mess (imho).
So, that "main" lister_code() structured like this:
Lister *lister;
IPCMessage *lmsg;
struct IntuiMessage *imsg;
DOpusAppMessage *amsg;
short pending_quit=0;
struct MinList sniff_list;
some_other_init_code;
FOREVER
{
Go an icon drag timer?
Busy request returned?
Periodic timer return
intuition messages
Application messages
Icon notification
commands (in some of them lister_open() is called if need it).
IPC_Reply(lmsg);
check_on_exit(), etc and continue or exit
}
some_cleanup_code;
I.e. code in FOREVER works like while() , and "commands" its all usuall stuff with CASE balblabl: break.
Sooo.. once we run dopus5, and spawn a lister, code do:
lister_new()->lister_code->Loop_with_all_the_crap->open_lister_from_IPC_Show_with_Lister_Open->replyMSG
Firstly on running of lister, all the code from FOREVER passes fine and debug prinfs brings:
before Go an icon drag timer?
before Busy request returned?
before Periodic timer return
before intuition messages
before Application messages
before Icon notification
before commands
Then prinfs brings that we are in the
case IPC_SHOW:
LISTER_OPEN:
...lister_open() + some small settings for ..
break;
and lister_open() from that happens (there is also another places where lister_open() can be called, but first one, after which we already will have dsi, happens in that CASE).
At this moment, visually, lister already opens, but but with no actual content inside. (only borders, top bar, etc).
So i firstly prinfs/delays all the code in the IPC_SHOW/LISTER_OPEN: nothing. Then, i go to the place what happens after break from, and that is:
IPC_Reply(lmsg);
(almost at the end of lister_code function, and almost end of FOREVER loop).
And i just add such stuff:
printf("we are before IPC_Reply(lmsg)\n");
Delay(500);
IPC_Reply(lmsg);
printf("we are after IPC_Reply(lmsg)\n");
Delay(500);
And what is interesting, is that after all that initial/first code happens, and it breaks from IPC_SHOW/IPC_LISTER, it prinfs/do that:
we are before IPC_Reply(lmsg)
we are after IPC_Reply(lmsg)
we are before IPC_Reply(lmsg)
BANG !! BANG !! DSI !
we are after IPC_Reply(lmsg).
we are before IPC_Reply(lmsg)
we are after IPC_Reply(lmsg)
we are before IPC_Reply(lmsg)
we are after IPC_Reply(lmsg)
and then we finish whole FOREVER loop, and continue from begining (but already crashes, we continue to see new prinfs because its running in different process).
So, its something with messages (?). I through do not know why it reply 4 times instead of 1 (its is ok?), and why it crashes at all, on second reply (on first one is ok). I can assume that there should be only 1 reply, and because of that it crashes on second one, but i am not expecrt in messages, so dunno..
If anyone will take a look at the code, then IPC_Reply() together with all other IPC related stuff define in the include/dopus/ipc.h , and some ipc related code in the library/ipc.c
Btw, what is intersting, is when i add Delays there and there, i even sometime can ignore DSIs and have spawned lister:
But i think that kind of understanable : ipc + messages => delays can make differences visually. + That can make us think, that if it spawns sometime, then problem not in lister code itself, but in that IPC / messaging crap and whole FOREVER loop.
I remember there was such kind of problems for me when i do bad loops with messages in my warp3d mags (the same loop, the same answering on messages, etc). And while on os3/mos it was ok even with "wrong" code, on os4 it give kind of the same problems with DSIs and crashes..
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
