DOpusRT5

xenic
2013-10-26
2013-10-29
  • xenic
    xenic
    2013-10-26

    I tried our compiled DOpusRT5 and can't reproduce any crash. In fact, when I ran SnoopDOS there was no indication that DOpusRT5 is even used. It's never run no matter what I do.

    @kas1e
    How did you reproduce that crash??

     
    Last edit: xenic 2013-10-26
  • tomsmart1
    tomsmart1
    2013-10-27

    He start DOpusRT5 form the normal System Shell.

     
  • xenic
    xenic
    2013-10-27

    @tomsmart1
    The original DOpusRT5 was linked with a special SASC object file so there is no way to tell what the code in that object file may have been doing with the arguments before passing them to the DOpusRT5 code. I wrote a small utility that just sends whatever arguments it receives to serial debug output so I could rename it as "DOpusRT5" and see what arguments Dopus5 was sending to DOpusRT5. However, I can't make Dopus5 call DOpusRT5 for anything and Snoopy (same as SnoopDOS on OS3) doesn't ever show it being called by Dopus5.

    Can you run SnoopDOS on your system to see if DOpusRT5 is even used by Dopus5?

     
  • tomsmart1
    tomsmart1
    2013-10-27

    I did a search for DOpus5 over my DOpus data and find this in the ReadMe of V5.11:

    '. The way "Workbench" processes are launched has changed. All
    programs are now launched by the one process which is established
    by the library. This means that there is not a copy of DOpusRT5
    sitting around for each workbench process you have run.'

    And the other hit i got is in the DirectoryOpus main program, so may you have a look at the source if the command is called any more.

     
    Attachments
  • kas1e
    kas1e
    2013-10-27

    @xenic
    dopusrt used by dopus, i will answer dwtailed tomorrow (how to check, how to use). but fir fast check you can launch it from shell manually with any wb programm as argumment (like calculator). but what for sure us that my port pure wrong as i mess poinetrs all wrong. so take original one again

     
  • xenic
    xenic
    2013-10-27

    @kas1e
    I looked at the original and there was no way to tell how it was getting the args from the SASC object file that it was linked with in the original makefile. That's why I wanted to see how the args were being sent to DOpusRT5 by Dopus5. As I pointed out to Tom, it doesn't seem to get called at all. I'll wait for the info from you before I investigate it any further.

     
  • kas1e
    kas1e
    2013-10-28

    @Xenic

    If we will check whole source code on "dopusrt" words, then Program/function_script.c have:

    static char const * const script_type_intro[]={
            0,              // INST_COMMAND
            0,              // INST_AMIGADOS
            "dopusrt5 ",    // INST_WORKBENCH
            "execute ",     // INST_SCRIPT
            "rx ",          // INST_AREXX
        };
    

    Then:

        // Write type introducer
        if (script_type_intro[type])
        {
            // Kludge to handle async workbench stuff
            if (type==INST_WORKBENCH && strnicmp(script_line,"run ",4)==0)
            {
                // Async workbench
                script_line+=4;
                WriteBuf(handle->script_file,"run >nil: <nil: ",-1);
            }
            WriteBuf(handle->script_file,script_type_intro[type],-1);
        }
    

    And so on, so it uses.

    Now, why we don't see it when we use dopus5 at all : because of those settings we do for "internal ELF handling" (which introduce some new problem about which Severin told you on amigans.net , but which i don't cover now normally to create a ticket for, but that i hope another story).

    Because of that, Severin use his own filetype for running programs, which looks like this:

    [15:24] <Severin> AmigaDOS, Program
    [15:25] <Severin> class:
    [15:26] <Severin> match $000003F3
    [15:26] <Severin> or
    [15:26] <Severin> match $7F454C46
    [15:26] <Severin> Event: double click
    [15:26] <Severin> [workbench] (f)
    [15:26] <Severin> cd source
    [15:27] <Severin> run asynchronously
    [15:27] <Severin> pri 20
    [15:27] <Severin> in the class
    

    I.e. to run them via "workbebch {f}".

    Then, with such settings, when you will just dbl-click on aos4 program (let's it be sys:utitliites/calculator for example), it will runs, and dopus5rt will "handle" it. Through there is problem: i wasn't able to reproduce running of dopus5rt at all on my system when do such filetype. After i have set it up, and just dbl-click on any amiga program, nothing happens, while, on Severin's setup with such filetype , dopus5rt is runs and run over itself that app on which user click. We try hard to make me able to reproduce it on my system, and while and him, and i, do tests on latest betas, it anyway was like this: for him it runs over dopus5rt when he have such a filetype settings for binaries, for me not. But it should, of course. Pretty possible that there is some other settings involved which we need to set for.

    To add, 68k version of dopus5rt works fine for Severin of course, while my sucking-messy port crashes. I just follow the way as Simon port loadwb from original (the same replace of main arguments, etc,etc), just i messy pointers.

    So, for first we need to make original 68k dopusrt runs with such filetype, then, when it will works (i assume it only some settings somewhere, maybe should be replacement mode , or kind), just report normally dopus5rt, and then we can back to that problem which Severin describe and because of which he forced to use such filetype (but that another story i hope, and i hope not related to dopus5rt problem).

     
  • xenic
    xenic
    2013-10-28

    @kas1e
    I was able to create a filetype like Severin's and discover why DOpusRT is not being called for our tests. Dopus5 creates a temporary script in the T: directory that contains a line like "dopusrt5 programname" and then calls AmigaDOS "execute" to run the script. The execute command looks in the system paths for the dopus5rt command and can't find it. The execute command doesn't know that dopusrt5 is in the Dopus5:C directory. I think the original Dopus5 installer copied dopusrt5 the the SYS:C directory where execute would find it. If you copy dopus5rt to SYS:C then Severin's filetype works.

    I see 2 choices for solving the problem of "execute" not finding dopus5rt. We can tell the users to copy dopusrt5 to SYS:C or we can change Program/function_script.c to look in Dopus5:C like this:

    static char const * const script_type_intro[]={
            0,              // INST_COMMAND
            0,              // INST_AMIGADOS
            "Dopus5:C/dopusrt5 ",    // INST_WORKBENCH
            "execute ",     // INST_SCRIPT
            "rx ",          // INST_AREXX
        };
    

    I tested changing "dopusrt5 " to "DOpus5:C/dopusrt5 " in function_script.c and it works.

    I rewrote DOpusrt5 and it works with the filetype and it works if you use it from a shell command line (if dopus5.library is loaded). I'll commit it today but I'll hold off on committing changed function_script.c to see if you want to tell the users to copy DOpusRT5 to SYS:C instead.

    then we can back to that problem which Severin describe and because of which he forced to use such filetype (but that another story i hope, and i hope not related to dopus5rt problem).

    There is no problem to get back to. Several users informed Severin that the Dopus5 manual explicitly states that you use double-click to start a command with AmigaDOS and use shift-double-click to start a WorkBench program. That's how it's always been in Dopus5 and it never "automatically" started a program as a Workbench program if there was an icon. There is no accurate way for Dopus5 to tell if a program is AmigaDOS or Workbench. Users can add an icon to an AmigaDOS command if they want and can delete the icon for a Workbench program (and have "DefIcons" show an icon). Severin can continue to use her filetype but that means that if she double-clicks an AmigaDOS program or command, nothing will happen.

     
  • kas1e
    kas1e
    2013-10-28

    @Xenic

    Cool !

    My bet is that we do "Dopus5:C/dopusrt5 " is the best way (so no one will notice anything, its all will just start to work for users without doing anything else).

    All in all if anything will go wrong, we always can rollback, as usual. So imho commit it , and i will ask Severin to do tests tomorrow, etc

     
  • xenic
    xenic
    2013-10-28

    @kas1e
    I'll commit the change later today. Tell Severin that it will no longer be necessary to copy dopusrt5 to SYS:C or other directory in the system command paths.

     
  • tomsmart1
    tomsmart1
    2013-10-28

    Only for info:
    The original Installerscript added the following to the "user-startup"

    ASSIGN >NIL: DOpus5: "...:DOpus5"
    PATH >NIL: DOpus5:c

    With the Path command the directory "Dopus5:C" was in the search path for shell and commands like EXECUTE.

     
  • kas1e
    kas1e
    2013-10-28

    @xenic
    all right! once you will commit changed function_script.c i wil try this out as well

     
  • xenic
    xenic
    2013-10-28

    @Tom
    That path addition shouldn't be necessary any more and the assignment isn't necessary unless you are using loadDB to start Dopus5 as WB replacement.

     
  • xenic
    xenic
    2013-10-28

    @kas1e
    I commited function_script.c and the source/makefile which adds the compiled dopusrt5 to the realeases again. I didn't remove trunk/archive/DOpusRT5 yet. As soon as we're positive that the compiled version works well, we can remove that file.

     
  • xenic
    xenic
    2013-10-28

    @kas1e
    Off Topic: At Amigans.net you told Trixie that AmigFig (ZuneFig) should compile out of the box but it doesn't for me. Check out the trunk and see if it compiles for you. I get MUI_NewObject undefined in most of the z_...c files.

     
  • kas1e
    kas1e
    2013-10-29

    @Xenic
    Tested DopusRT5 changes: all is fine, good !

    As for AmiFig, i got rev300 right now, and then do build it from scratch: all builds and links fine. That make me think, that you on old MUI SDK from old SDK. Easy way will be just grab from new SDK MUI3.9.lha archive and update it manually over old ones. Will be good if you will take a look at this too, it have pretty many os4 specific bugs (half of them i assume because i use -lauto, while should remove it and manually open all libs). Also in gradient_fill.c, and do not know how to deal with aros2be macro (currently just commented it out for os4, but maybe some swapping still need it).

     
    Last edit: kas1e 2013-10-29
  • xenic
    xenic
    2013-10-29

    @kas1e
    I have MUI 3.9 SDK installed but maybe I did something wrong. I need to investigate. AmiUpdate installs MUI as a seperate directory in my OS4 SDK. Did you move the includes into you system includes, local includes or change something to make GCC look in the MUI/C/Include directory for include files?

     
  • kas1e
    kas1e
    2013-10-29

    @Xenic
    I move them manually to system includes, yep.