additional callin convention

[jklwn4]

Hi Nidud,

would it be possible to add another calling convention for PowerBasic dlls?

I couldn´t find a combination of calling convention and switches, which makes the linker happy. PowerBasic´s calling convention is like standard call but without decorated names, or like C, but without caller stack cleanup. PowerBasic exports blank names, stack is filled from right to left and procedures cleanup the stack before returning.

So i tried to add this kind of convention to asmc by modifying and adding code and indeed i got it working. I could supply the modified sources, Unfortunately these sources are from an older version. I see you made changes, fixes and additions in the meantime, so it´s not possible to use a simple diff tool. PowerBasis is 32 bit only and doesn´t use .lib files, but it is possible to create a .lib file from a dll, i could supply such a dll and lib for testing on your own.

... seems i cannot edit the title anymore - should of course have been "... calling ..."

[nidud]

-zt<0|1|2> Set STDCALL decoration

It should be -zt0 but there seems to be a mix-up there.

foo proc a:ptr, b:ptr
    ret
foo endp

bar proc basic a:ptr, b:ptr
    ret
bar endp

The default here is _foo@8 and BAR
-st0 is _foo@8, -st1 is foo, and -st2 is _foo

[nidud]

The implementation seems to follow the definition here so I'm not sure what to make of this.

.enum stdcall_decoration {
    STDCALL_FULL,
    STDCALL_NONE,
    STDCALL_HALF
    }

I will assume this apply to all versions of Asmc so I think it's better to just leave it as it is, and update the documentation for the switches.

[jklwn4]

Even if i cold make it work with the correct switch, this will arise the next problem. What, if i want to import procedures from a PowerBasic dll (for this i would have to set switches) and at the same time import from a dll with decorated names. The switch would apply to all procedures, but i want a special handling only for imported PowerBasis procedures. Having a special calling convention ("proto myPBproc pbcall ...") makes it work, even in this case.

My additions are not very complicated and don´t change anything of the inner working of asmc. Currently with every update i would have to apply my changes again and again, unless i want to loose further development of asmc. So i just ask, would you be willing to include it as a new feature for me? I can supply the code, what and how i did it.

[nidud]

I will assume PB needs to interact with Windows API calls in order to produce a Windows application (it sort-of have to), which means there's a method to define external calling conventions (STDCALL in this case) within PB.

As for using dll's are there any difference between BASIC and PB in that regard? If the only difference is that PB is case sensitive and BASIC is not, this could easily be fixed.

Have you tried using proto myPBproc basic ?

If this don't work you may test the above assumption by adding these changes to mangle.asm from:

    .case LANG_PASCAL
    .case LANG_FORTRAN
    .case LANG_BASIC
        lea rsi,UCaseMangler
        .endc

to:

    .case LANG_BASIC
        .endc ;.if ( Options.power_basic )
    .case LANG_PASCAL
    .case LANG_FORTRAN
        lea rsi,UCaseMangler
        .endc

[nidud]

Seems the standard calling convention for PB is STDCALL.

[nidud]

It could be that the actual problem here is the creation of the library from the DLL. As the decoration can't be extracted from the DLL the DEF file needs to be written manually.

If you look at how the system libraries are created in 64-bit the function names are simply extracted from the DLL, but the 32-bit version needs a decorated name list.

I use a simple program that loads the 32-bit DLL, extract the undecorated names and scan the function for the RET statement. In STDCALL this will coded as 0xC2 (RET) followed by a WORD indicating the number of bytes returned.

; build: asmc -pe dlldef32.asm

include io.inc
include stdio.inc
include stdlib.inc
include winbase.inc
include tchar.inc

    .data
     dll    char_t 256 dup(0)
     fp     LPFILE NULL
     module HMODULE NULL
     exdir  dd 0

    .code

GetExportDirectory proc uses esi edi ebx dll_name:string_t

    lea edi,dll

    .if !strrchr(strcpy(edi, dll_name), '.')

        strcat(edi, ".dll")
    .endif

    .if !LoadLibrary(edi)

        perror(edi)
       .return( NULL )
    .endif

    mov module,eax
    mov ecx,eax
    mov eax,[ecx].IMAGE_DOS_HEADER.e_lfanew
    mov eax,[ecx+eax].IMAGE_NT_HEADERS.OptionalHeader.DataDirectory.VirtualAddress
    add eax,ecx
    mov exdir,eax
    ret

GetExportDirectory endp


GetExportName proc uses esi edi ebx id:int_t

   .new name[256]:char_t
   .new args[16]:char_t = 0

    mov esi,exdir
    mov ebx,[esi].IMAGE_EXPORT_DIRECTORY.AddressOfNames
    add ebx,module
    mov edi,id
    mov ecx,[ebx+edi*4]
    add ecx,module
    strcpy( &name, ecx )

    mov ebx,[esi].IMAGE_EXPORT_DIRECTORY.AddressOfFunctions
    add ebx,module
    mov ebx,[ebx+edi*4]
    .if ( ebx )

        add ebx,module
        mov esi,module

        .if ( GetProcAddress(esi, &name) )

            mov edi,eax
            mov edx,[esi].IMAGE_DOS_HEADER.e_lfanew
            mov ecx,[esi+edx].IMAGE_NT_HEADERS.OptionalHeader.SizeOfImage

            sub eax,esi
            .ifs
                .return( false )
            .endif
            sub ecx,eax
            .ifs
                .return( false )
            .endif
            mov eax,0xC2 ; ret

            .while 1

                repnz scasb
                .break .ifnz

                mov edx,[edi]
                .continue .if ( dh || ( dl & 3 ) )

                movzx ecx,byte ptr [edi]
                sprintf( &args, "@%d", ecx )
               .break
            .endw
        .else
            .return( false )
        .endif
    .endif
    fprintf( fp, "%s%s\n", &name, &args )
   .return( true )

GetExportName endp

main proc argc:int_t, argv:array_t

    .if ( argc != 2 )

        printf("\nUsage: DLLDEF32 <dllname>\n\n")
       .return 1
    .endif

    mov edx,argv
    .if ( GetExportDirectory( [edx+4] ) == NULL )
        .return 1
    .endif
    mov esi,eax

   .new def[256]:char_t
    strcpy( strrchr( strcpy( &def, &dll ), '.' ), ".def" )
    ;_strupr( &dll )

    mov fp,fopen( &def, "wt" )
    .if ( fp == NULL )

        perror( &def )
       .return 1
    .endif
    fprintf( fp, "LIBRARY %s\nEXPORTS\n", &dll )

    .for ( esi = exdir, edi = 0 : edi < [esi].IMAGE_EXPORT_DIRECTORY.NumberOfNames : edi++ )
        GetExportName( edi )
    .endf
    fclose( fp )
    FreeLibrary( module )
   .return( 0 )

main endp

    end _tstart

This may not work for all functions so you still need to edit the DEF file to match the prototypes.

[jklwn4]

PB´s calling convention is like STDCALL but without decoration, so "... proto BASIC ..." should do. The problem is in fact creating an import library for the linker (PB doesn´t need import libraries nor does it create import libraries for dlls).

I use a similar approach like you suggested to create a .def file from a PB dll with undecorated names, but then MS lib.exe adds a leading underscore to the procedure names in the import library. Therefore "... proto BASIC ..." doesn´t work, because the linker cannot resolve it: "myproc" vs. "_myproc".

And i couldn´t find a way of creating an import library with procedure names without a leading underscore. There seems to be no appropriate option for lib.exe. But finally i found a lib tool, which can optionally create import libraries without those offending leading underscores. Initial tests show, that these import libraries work with "... proto BASIC ....".

This seems to solve my problem - no need to add/change code in asmc

Thanks

JK

[nidud]

PB´s calling convention is like STDCALL but without decoration, so "... proto BASIC ..." should do.

BASIC push arguments in the opposite direction (like PASCAL) so that will fail (with arg-cout > 1). I also think the assumption about decoration is wrong as this will not be exported to the DLL.

This means the calling convention is STDCALL with standard decoration in OBJ and LIB files but without decoration in the DLL.

It's possible to test this logic by linking directly to the PB DLL file (using the -pe switch).

i could supply such a dll and lib for testing on your own.

Yes, that would be helpful.

[jklwn4]

my bad, i think you are right, "BASIC" pushes arguments in wrong order. I think i already have been there som time ago, therefore as a last resort, i tried tweaking asmc.

here is my test code

include <windows.inc>   

includelib "kernel32.lib"
includelib "pb_dll.lib"


txt Db "hello", 0
caption db "test from asmc", 0


TESTME proto basic :dword, :dword


.code



start proc
;***************************************************************************
;
;***************************************************************************

  mov esi, esp
  invoke TESTME, addr txt, addr caption
int 3  
  
  
  

start endp


;***************************************************************************

end start

and as an attachment the called PB dll and two versions of an import library

The "nounderscore" version works with "BASIC", but caption and test get mixed up, the "underscore" version works with "C", but oviously the stack is not correct after the procedure returns.
pb.zip

"testme" calls MessageBoxA and returns -1

[nidud]

A bit puzzled by the whole lib-creating thing here, but whatever is in the DLL file works as follows:

; asmc -pe testme.asm
include windows.inc

.pragma comment(lib, pb_dll)

TESTME proto stdcall :ptr, :ptr

.code

start proc
  TESTME("hello", "test from asmc")
  ExitProcess(0)
start endp

end start

Point is, it should work if you use STDCALL.

pb_dll.def:

LIBRARY pb_dll
EXPORTS
testme

pb_dll.dll:

asmc -coff pb_dll.asm
link /dll /def:pb_dll.def pb_dll.obj

LINK will not add any decoration here so now you may access the external function as follow:

include windows.inc
include tchar.inc

.pragma comment(lib, pb_dll)
testme proto stdcall :ptr, :ptr

.code

_tWinMain proc WINAPI hInstance:HINSTANCE, hPrevInstance:HINSTANCE, lpCmdLine:LPTSTR, nShowCmd:SINT
  testme("hello", "test from asmc")
  ret
_tWinMain endp

end _tstart

This will now work directly using the DLL:

asmc -pe testme.asm

Or indirectly using the import library

asmc -coff testme.asm
link testme.obj

[nidud]

To build the DLL and import library using LINKW and LIBW the switch -zze (No export symbol decoration) may be used.

include windows.inc

    .code

testme proc stdcall export message:ptr, caption:ptr

    MessageBox(NULL, message, caption, MB_OK)
    ret

testme endp

DllMain proc stdcall hinstDLL:HINSTANCE, fdwReason:DWORD, lpvReserved:ptr

    mov eax,TRUE
    ret

DllMain endp

    end DllMain

pb_dll.obj: asmc -q -coff -zze pb_dll.asm
pb_dll.dll: linkw sys dll_32 file pb_dll
pb_dll.lib: libw -n -q -fac -c -b -ii pb_dll.lib ++_testme@8.pb_dll

[jklwn4]

Creating dlls and invoking exported procedures with asmc isn´t a problem, this works like a charm. The problem here is, PB doesn´t create .obj files, it creates the final dlls and i have absolutely no influence on the linking process. PB is a compiler and linker all in one. I can take dlls from PB only as they are. The next problem is, PB doesn´t create import libraries, in fact PB doesn´t need import libraries at all. It´s linker can link to whatever dll without a .lib file.

So i must take those dlls as they are, and i must create my own .lib (import library) from such a dll somehow. I´m going to try your approch for creating a .def file with decorated names, all it takes is getting the x from "ret x", then i could create a .lib file, which makes STDCALL linking possible.

I´m going to try this and report about the results

[nidud]

in fact PB doesn´t need import libraries at all. It´s linker can link to whatever dll without a .lib file.

Same as the Asmc built-in linker (-pe).

The problem here is, PB doesn´t create .obj files, it creates the final dlls and i have absolutely no influence on the linking process.

It is sort of the same problem with the tools used here (LIB[W] and LINK[W]). It works fine when a DLL is created as the linker then knows the type of the exported functions and handle the import library accordingly. The problem occur when a DEF file is used as the type is then unknown.

This is however exclusively a 32-bit STDCALL problem.

I´m going to try your approch for creating a .def file with decorated names, all it takes is getting the x from "ret x", then i could create a .lib file, which makes STDCALL linking possible.

You will need a header file for these functions anyway so it may be more convenient to do that first. The linker within Asmc needs to know the name of the DLL for each function:

option dllimport:<msvcrt>
strlen proto c :ptr
...
option dllimport:<pb_dll>
testme proto stdcall :ptr, :ptr
...

Otherwise (with a linker and import library) the INLUDELIB directive is used. The .pragma directive sort this out based on the link switch (-pe).

.pragma comment(lib, pb_dll)
testme proto stdcall :ptr, :ptr

Well, the point is that it may be simpler to just copy the prototypes to an ASM file (with the same name as the DLL) and just build a dummy DLL.

include windows.inc
.code
testme proc stdcall export a:ptr, b:ptr
    ret
testme endp
DllMain proc stdcall hinstDLL:HINSTANCE, fdwReason:DWORD, lpvReserved:ptr
    ret
DllMain endp
end DllMain

Build the dummy:

asmc -coff pb_dll.asm
link /dll pb_dll.obj

LINK will now produce a (dummy) DLL and LIB file: no DEF file needed.

[jklwn4]

How could i create a .lib file from a .def file using LIBW? I need a sample commandline for this. Ok - there is some basic documentation, if you just run it, but where to find a more comprehensive documentation with more explanations and samples?

The same applies to LINKW - seems capable, but very hard to find out how it works ...

[nidud]

How could i create a .lib file from a .def file using LIBW?

Same as the sample above by moving the ++proc_name.dll_name to a DEF file.

libw -n -q -fac -c -b -ii pb_dll.lib @pb_dll.def

where to find a more comprehensive documentation with more explanations and samples?
The same applies to LINKW - seems capable, but very hard to find out how it works ...

LINKW/LIBW is used for most things here: Libraries, imports, applications and tests. The system configuration used are defined in the linkw.cfg file and some more details in the Open Watcom Linker User's Guide.

[jklwn4]

Thanks!
I think i found a way of creating an import library for PB dlls, so that protos with STDCALL for PB procedures work. The trick is (following your proposal above) getting not only the exported names, but also the number of bytes to add to the stack (a word after C2, could be C3 too in case of no arguments), which equals the number of bytes needed for arguments. The rest is as easy as putting things together and passing it to a lib tool. Works with polib.exe, MS´s Lib.exe and (with your help) with LIBW as well.