As some of you may aware, we find out that the crashes of os3 version of dopus5 on os4, was because of hardcode define of PF_ASYNC in dopus which cause conflict with private os4 define. In code of dopus5 relative parts looks like this:
Everything is going to work. And i test it on os3 and mos as well: all is fine as before.
Now question to all developers: As that (1<<7) its kind of hardcore, maybe it will make sense to not just #ifdef amigaos4 in those parts, but change it completely like this ? By changes you can see that its all the same, and should make no harm, and will works as before everythere.
What you think ?
Last edit: kas1e 2012-12-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks good to me, go ahead and checkin' those changes. But please make sure to add enough comments to the code so that these changes are reproducible for everyone.
BTW: I am still seeing no SVN checkins since the initial checkin. Please everyone working on the sources of DOPUS5. Please add your changes immediately and don't keep them private or otherwise we will run into merge problems quickly. I will also shortly add a "ChangeLog" file to the root of the trunk so that we can document each change more easily.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But please make sure to add enough comments to the code so that these changes are reproducible for everyone.
Yeap, sure.
BTW: I am still seeing no SVN checkins since the initial checkin.
Because there is none currently :) You and Itix only plays with it just for first tests, and i only worry about that PF_ASYNC problem. Will retest it more before checkin, to be sure that its all make no harm, and then can start from creating a gcc makefiles.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, i made a commit about, with detailed info in changelog. I also save the old dopus5 lines as comments, so its all will be very easy to rewert back if anything will going wrong.
Last edit: xenic 2012-12-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
Maybe it would be simpler (and better?) just to change the PF_ASYNC definition to an unused mp_Flag like: ./Library/dopusbase.h:#define PF_ASYNC (1<<6). According to my exec includes only 3 mp_Flag bits are used by the system. Maybe there is a reason I don't know about, but it seems strange to use port->mp_Node.ln_Pri as a flag. Do you know what effect adding a high node priority will have on message handling?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You never know if another flag bit is allocated in the future for whatever reason.
mp_Node.ln_Pri is not used anywhere in the system and is often left uninitialized i.e. when message port is allocated from the stack or with AllocMem() programs only initialize required fields and leave other fields as is.
Alternatively a magic cookie could be put to mp_Node.ln_Name but using ln_Pri field is just fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As some of you may aware, we find out that the crashes of os3 version of dopus5 on os4, was because of hardcode define of PF_ASYNC in dopus which cause conflict with private os4 define. In code of dopus5 relative parts looks like this:
$ find -type f | xargs grep -i PF_ASYNC
./Program/function_launch.c: handle->reply_port->mp_Flags|=PF_ASYNC;
./Library/ipc.c: if (reply->mp_Flags&PF_ASYNC)
./Library/ipc.c: port->mp_Flags|=PF_ASYNC;
./Library/dopusbase.h:#define PF_ASYNC (1<<7)
./NewRegModules/dopusbase.h:#define PF_ASYNC (1<<7)
So : (1<<7). Which is hardcore and hardcode, and on os4 that is defined in exec/port.h as: #define PF_SIGALLOC (1<<7)
Because of that we have heavy problems, and once i with help of Georg Steger replace it all on:
./Program/function_launch.c: handle->reply_port->mp_Node.ln_Pri = PORT_ASYNC_MAGIC;
./Library/ipc.c: if (reply->mp_Node.ln_Pri == PORT_ASYNC_MAGIC)
./Library/ipc.c: port->mp_Node.ln_Pri = PORT_ASYNC_MAGIC;
./Library/dopusbase.h:#define PORT_ASYNC_MAGIC 0x5A
./NewRegModules/dopusbase.h:#define PORT_ASYNC_MAGIC 0x5A
Everything is going to work. And i test it on os3 and mos as well: all is fine as before.
Now question to all developers: As that (1<<7) its kind of hardcore, maybe it will make sense to not just #ifdef amigaos4 in those parts, but change it completely like this ? By changes you can see that its all the same, and should make no harm, and will works as before everythere.
What you think ?
Last edit: kas1e 2012-12-22
Looks good to me, go ahead and checkin' those changes. But please make sure to add enough comments to the code so that these changes are reproducible for everyone.
BTW: I am still seeing no SVN checkins since the initial checkin. Please everyone working on the sources of DOPUS5. Please add your changes immediately and don't keep them private or otherwise we will run into merge problems quickly. I will also shortly add a "ChangeLog" file to the root of the trunk so that we can document each change more easily.
Yeap, sure.
Because there is none currently :) You and Itix only plays with it just for first tests, and i only worry about that PF_ASYNC problem. Will retest it more before checkin, to be sure that its all make no harm, and then can start from creating a gcc makefiles.
Ok, i made a commit about, with detailed info in changelog. I also save the old dopus5 lines as comments, so its all will be very easy to rewert back if anything will going wrong.
Last edit: xenic 2012-12-27
@kas1e
Maybe it would be simpler (and better?) just to change the PF_ASYNC definition to an unused mp_Flag like: ./Library/dopusbase.h:#define PF_ASYNC (1<<6). According to my exec includes only 3 mp_Flag bits are used by the system. Maybe there is a reason I don't know about, but it seems strange to use port->mp_Node.ln_Pri as a flag. Do you know what effect adding a high node priority will have on message handling?
@xenic
You never know if another flag bit is allocated in the future for whatever reason.
mp_Node.ln_Pri is not used anywhere in the system and is often left uninitialized i.e. when message port is allocated from the stack or with AllocMem() programs only initialize required fields and leave other fields as is.
Alternatively a magic cookie could be put to mp_Node.ln_Name but using ln_Pri field is just fine.