MASM Static and Dynamic Libraries in PB

[Logman]

I have been using PB for a number of years going back to DOS version 1.0. Recently I have been requested to update some old MASM 4.0 code I developed back in the late 80's early 90's to 32-bit protected mode to run under Vista and Windows 7. A couple months back I downloaded the latest MASM32 SDK and have been using it ever since.

I've noticed that Hutch has developed a number of tools, most notably the MASM to PB converter. I've searched the entire PB forum and MASM forum for answers to a question I have, but with no luck. This tells me there is either no way or there is a very difficult way to incorporate static/dynamic (DLL) libraries written in MASM for use by PB.

My question is this. Is there a way to incorporate static and/or dynamic (DLL) libraries in PB that have been coded in MASM? I've used PB's inline assembly capabilities, but they are very limiting for what I'd like to do and was just wondering if I could include MASM assembly code in PB in the from of static/dynamic libraries. I haven't been able to discover the "magic" way of doing this that works.

Thanks in advance.

Logman

[dedndave]

i am sure it isn't hard
i think Hutch is probably an expert in this area   :bg

[hutch--]

Logman,

What is the data format you want to contain in the exe file, a stored DLL that you write to disk or is it old 16 bit code that you want to include in an application ?

The former is easy to do, in MASM you put the data in an object module, in PB you use a tools to convert it to DB format and then with either, write it to disk then run the DLL like normal.

The latter is probably a complete re-write from 16 bit architecture to modern protected mode code.

[Logman]

Thanks for getting back Hutch.

I really want to be able to do two things here.

First, static libraries. I want to directly include assembled MASM 32-bit procedures inside PB code. I don't know how to get that code to be successfully included in PB when I compile a PB program. I've coded the procedures in MASM because PB's inline assembler doesn't implement some of Intel's mnuemonics or MASM's macros. I've tried .obj file formats, etc. using PB #include directives and so forth. I'm sure I am just missing some little technique and can't seem to get a handle on it. Since I have a lot of PB code that could benefit from the extended and faster MASM code, I don't want to give up. Maybe I'm not saving the MASM code in the correct format to be included in PB code when compiled.

Second, dynamic linked libraries. I have other sets of 32-bit procedures I assembled into DLLs using the latest version of MASM32 SDK, but don't know how to get PB to use MASM-produced DLLs properly.

Using MASM-developed DLLs in PureBasic, Emergence Basic, C, and other MASM programs is a no-brainer. However, I just can't seem to figure out how to get PB to correctly load/recognize and use procedures in MASM-type DLLs--something I should know how to do in PB.

Thanks again, Logman.

[hutch--]

You have no chance with static libraries as PB does not have a linker but you can work around it if you build it in MASM, locate the start and finish then copy the direct binary data to an external file. Then use the bin2db tool for PB (download it here) and create a DB format file with it then place it inside a PB sub or function. You must enter the function once to get the start address, store it as a global then you can call the function with push/call code.

The DLLs should not be a problem as long as they are 32 bit DLLs as both masm and PB handle both C and STDCALL. Just make sure the PB code is calling and/using the correct data types for the masm code.

The masm2pb converter works reasonably well on bare mnemonic code but high level masm notation cannot be translated to PB as the similar notation in PB will not handle registers. Stack frame procedures convert reasonably well but procedures with no stack frame are very messy to get working.

[Logman]

Hutch:

Thanks, you put me on the right track. Appreciate the help--I know what I have to do now given what you outlined.

Logman