• calling tool version function outside the the normal calling

    From Chris Vavruska@21:1/5 to All on Fri Jul 17 09:41:47 2020
    I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the version of the tool. The following code always returns zero. put a BRK in it to trace into the function call and it appears it is calling the right function but something on the
    return stack is being messed up and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.

    word getToolVersion(GSString255Ptr path) {
    InitialLoadOutputRec loadInfo;
    word userID;
    WordProcPtr getVer;
    ptr *funcs;
    word toolVersion;

    userID = GetNewID(0x5000);
    loadInfo = InitialLoad2(userID, (ptr) path, 1, 1);
    funcs = (ptr*) (loadInfo.startAddr);
    getVer = (WordProcPtr*) (funcs[4]+1);
    toolVersion = getVer();

    DisposeAll(userID);
    DeleteID(userID);

    return toolVersion;
    }

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Vavruska@21:1/5 to Steven Hirsch on Fri Jul 17 11:04:33 2020
    On Friday, July 17, 2020 at 1:34:19 PM UTC-4, Steven Hirsch wrote:
    On 7/17/20 12:41 PM, Chris Vavruska wrote:
    I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the version of the tool. The following code always returns zero. put a BRK in it to trace into the function call and it appears it is calling the right function but something on the return stack is being messed up and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.

    word getToolVersion(GSString255Ptr path) { InitialLoadOutputRec loadInfo; word userID; WordProcPtr getVer; ptr *funcs; word toolVersion;

    userID = GetNewID(0x5000); loadInfo = InitialLoad2(userID, (ptr) path, 1, 1); funcs = (ptr*) (loadInfo.startAddr); getVer = (WordProcPtr*) (funcs[4]+1); toolVersion = getVer();

    DisposeAll(userID); DeleteID(userID);

    return toolVersion; }


    What happens when you query the version inside the LoadOneTool/ToolStartUp environment?

    Good question....quickly verifies...It returns the correct version.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steven Hirsch@21:1/5 to Chris Vavruska on Fri Jul 17 13:34:13 2020
    On 7/17/20 12:41 PM, Chris Vavruska wrote:
    I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the version of the tool. The following code always returns zero. put a BRK in
    it to trace into the function call and it appears it is calling the right function but something on the return stack is being messed up and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.

    word getToolVersion(GSString255Ptr path) { InitialLoadOutputRec loadInfo; word userID; WordProcPtr getVer; ptr *funcs; word toolVersion;

    userID = GetNewID(0x5000); loadInfo = InitialLoad2(userID, (ptr) path, 1,
    1); funcs = (ptr*) (loadInfo.startAddr); getVer = (WordProcPtr*) (funcs[4]+1); toolVersion = getVer();

    DisposeAll(userID); DeleteID(userID);

    return toolVersion; }


    What happens when you query the version inside the LoadOneTool/ToolStartUp environment?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From vavruska@gmail.com@21:1/5 to Steven Hirsch on Fri Jul 17 12:15:03 2020
    On Friday, July 17, 2020 at 2:46:33 PM UTC-4, Steven Hirsch wrote:
    On 7/17/20 2:04 PM, Chris Vavruska wrote:
    On Friday, July 17, 2020 at 1:34:19 PM UTC-4, Steven Hirsch wrote:
    On 7/17/20 12:41 PM, Chris Vavruska wrote:
    I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the
    version of the tool. The following code always returns zero. put a BRK in >>> it to trace into the function call and it appears it is calling the right >>> function but something on the return stack is being messed up and the value
    is set to zero. My assembly skills are non existent so if anyone has some >>> pointers I'd appreciate it.

    word getToolVersion(GSString255Ptr path) { InitialLoadOutputRec loadInfo; >>> word userID; WordProcPtr getVer; ptr *funcs; word toolVersion;

    userID = GetNewID(0x5000); loadInfo = InitialLoad2(userID, (ptr) path, 1, >>> 1); funcs = (ptr*) (loadInfo.startAddr); getVer = (WordProcPtr*)
    (funcs[4]+1); toolVersion = getVer();

    DisposeAll(userID); DeleteID(userID);

    return toolVersion; }


    What happens when you query the version inside the LoadOneTool/ToolStartUp >> environment?

    Good question....quickly verifies...It returns the correct version.
    Is there any reason you cannot query versions at initial load and cache them if needed later?
    The application may or may not already have another version of the tool already loaded. I want to be able to compare the versions of two tool files.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steven Hirsch@21:1/5 to Chris Vavruska on Fri Jul 17 14:46:28 2020
    On 7/17/20 2:04 PM, Chris Vavruska wrote:
    On Friday, July 17, 2020 at 1:34:19 PM UTC-4, Steven Hirsch wrote:
    On 7/17/20 12:41 PM, Chris Vavruska wrote:
    I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the >>> version of the tool. The following code always returns zero. put a BRK in >>> it to trace into the function call and it appears it is calling the right >>> function but something on the return stack is being messed up and the value >>> is set to zero. My assembly skills are non existent so if anyone has some >>> pointers I'd appreciate it.

    word getToolVersion(GSString255Ptr path) { InitialLoadOutputRec loadInfo; >>> word userID; WordProcPtr getVer; ptr *funcs; word toolVersion;

    userID = GetNewID(0x5000); loadInfo = InitialLoad2(userID, (ptr) path, 1, >>> 1); funcs = (ptr*) (loadInfo.startAddr); getVer = (WordProcPtr*)
    (funcs[4]+1); toolVersion = getVer();

    DisposeAll(userID); DeleteID(userID);

    return toolVersion; }


    What happens when you query the version inside the LoadOneTool/ToolStartUp >> environment?

    Good question....quickly verifies...It returns the correct version.

    Is there any reason you cannot query versions at initial load and cache them
    if needed later?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Heumann@21:1/5 to Chris Vavruska on Fri Jul 17 19:08:31 2020
    On 2020-07-17 16:41:47 +0000, Chris Vavruska said:

    I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get
    the version of the tool. The following code always returns zero. put a
    BRK in it to trace into the function call and it appears it is calling
    the right function but something on the return stack is being messed up
    and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.

    Your code is trying to call the tool's version call using the ORCA
    calling convention, which is different from the calling convention for
    tool calls. I think you'll need to use at least some assembly language
    to call it properly. Here's a version using inline assembly that I
    think should work:

    word getToolVersion(GSString255Ptr path) {
    InitialLoadOutputRec loadInfo;
    word userID;
    WordProcPtr getVerMinus1;
    ptr *funcs;
    word toolVersion = 0;

    userID = GetNewID(0x5000);
    loadInfo = InitialLoad2(userID, (ptr) path, 1, 1);
    funcs = (ptr*) (loadInfo.startAddr);
    getVerMinus1 = (WordProcPtr*) (funcs[4]);

    asm {
    pea 0x0000 //result space
    phk //extra return address space (not used)
    pea ret-1
    phk //return address
    pea ret-1
    sep #0x20 //address to call (minus 1)
    lda getVerMinus1+2
    pha
    rep #0x20
    pei getVerMinus1
    rtl //call it
    ret: phk //clean up stack
    pla
    pla
    pla //get return value
    sta toolVersion
    }

    DisposeAll(userID);
    DeleteID(userID);

    return toolVersion;
    }

    --
    Stephen Heumann

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Vavruska@21:1/5 to Chris Vavruska on Fri Jul 17 17:45:46 2020
    On Friday, July 17, 2020 at 12:41:48 PM UTC-4, Chris Vavruska wrote:
    I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the version of the tool. The following code always returns zero. put a BRK in it to trace into the function call and it appears it is calling the right function but something on
    the return stack is being messed up and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.

    word getToolVersion(GSString255Ptr path) {
    InitialLoadOutputRec loadInfo;
    word userID;
    WordProcPtr getVer;
    ptr *funcs;
    word toolVersion;

    userID = GetNewID(0x5000);
    loadInfo = InitialLoad2(userID, (ptr) path, 1, 1);
    funcs = (ptr*) (loadInfo.startAddr);
    getVer = (WordProcPtr*) (funcs[4]+1);
    toolVersion = getVer();

    DisposeAll(userID);
    DeleteID(userID);

    return toolVersion;
    }
    Hi Stephen,

    thanks for the code. Getting the following trying to compile.

    134 phk //return address
    ^ invalid operand
    136 sep #0x20 //address to call (minus 1)
    ^ invalid operand

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Heumann@21:1/5 to Chris Vavruska on Fri Jul 17 20:07:54 2020
    On 2020-07-18 00:45:46 +0000, Chris Vavruska said:
    Hi Stephen,

    thanks for the code. Getting the following trying to compile.

    134 phk //return address
    ^ invalid operand
    136 sep #0x20 //address to call (minus 1)
    ^ invalid operand

    It looks like the assembler in ORCA/C isn't accepting the operand
    "ret-1" (on the lines above the ones shown). I think it should accept
    them, but if it doesn't you could move the "ret:" label up a line (to
    the rtl), and then change both of those operands to just "ret".

    --
    Stephen Heumann

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Heumann@21:1/5 to Kelvin Sherlock on Fri Jul 17 22:14:40 2020
    On 2020-07-18 02:19:51 +0000, Kelvin Sherlock said:

    asm { pha }
    getVer();
    asm { pla sta toolVersion }

    I don't think that will quite work, because Chris is trying to call a
    tool call without using the tool dispatcher, so it is expecting space
    on the stack for an extra return address. If you push/pull three extra
    bytes to account for that, this approach may work, but it's a hack.

    Chris, I tried the code I posted and it worked, so I'm not sure why
    it's giving you problems (maybe issues with line endings?), but an
    alternative is to replace the "pea ret-1" instructions with:

    lda #ret-1 // or "lda #ret", if you changed the label location
    pha

    --
    Stephen Heumann

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Vavruska@21:1/5 to Chris Vavruska on Fri Jul 17 19:16:30 2020
    On Friday, July 17, 2020 at 12:41:48 PM UTC-4, Chris Vavruska wrote:
    I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the version of the tool. The following code always returns zero. put a BRK in it to trace into the function call and it appears it is calling the right function but something on
    the return stack is being messed up and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.

    word getToolVersion(GSString255Ptr path) {
    InitialLoadOutputRec loadInfo;
    word userID;
    WordProcPtr getVer;
    ptr *funcs;
    word toolVersion;

    userID = GetNewID(0x5000);
    loadInfo = InitialLoad2(userID, (ptr) path, 1, 1);
    funcs = (ptr*) (loadInfo.startAddr);
    getVer = (WordProcPtr*) (funcs[4]+1);
    toolVersion = getVer();

    DisposeAll(userID);
    DeleteID(userID);

    return toolVersion;
    }

    I had tried that. It does not like pushing the label.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kelvin Sherlock@21:1/5 to All on Sat Jul 18 02:19:51 2020
    Stephen gave the proper way to do it but the quick and easy (and
    disgusting) thing to do is:

    asm { pha }
    getVer();
    asm { pla sta toolVersion }

    -------
    ProLine: kelvin@pro-kegs

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Vavruska@21:1/5 to Stephen Heumann on Sat Jul 18 05:19:32 2020
    On Friday, July 17, 2020 at 11:14:42 PM UTC-4, Stephen Heumann wrote:
    On 2020-07-18 02:19:51 +0000, Kelvin Sherlock said:

    asm { pha }
    getVer();
    asm { pla sta toolVersion }

    I don't think that will quite work, because Chris is trying to call a
    tool call without using the tool dispatcher, so it is expecting space
    on the stack for an extra return address. If you push/pull three extra
    bytes to account for that, this approach may work, but it's a hack.

    Chris, I tried the code I posted and it worked, so I'm not sure why
    it's giving you problems (maybe issues with line endings?), but an alternative is to replace the "pea ret-1" instructions with:

    lda #ret-1 // or "lda #ret", if you changed the label location
    pha

    --
    Stephen Heumann

    That did it. Thank you so much.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)