C function translation

[Iain Johnstone]

I need to convert this C declaration in a VB dll so that I can use it with PB. The declaration is:-
EXPORT_DLL_FUNCTION(void) GetErrorString(char *errorString, int error);

My translation is:-
DECLARE FUNCTION GetErrorString LIB "myvb.dll" ALIAS "GetErrorString" (ErrorString AS STRING, errorflag AS INTEGER) AS ????????

The problem is that the DLL does not return an exit value - it just fills ErrorString depending on the value of errorflag. I cannot recompile this DLL (though I have all the required code) so I do not know where to go from here (except here, of course). What can I use instead of the 'void' statement? Have I overlooked something simple?

Iain Johnstone

[José Roca]

What can I use instead of the 'void' statement?

Declare it as a SUB instead of a function.

[Borje Hagsten]

Yes, plus int is typically LONG in 32-bit world and ErrorString should probably be ASCIIZ, I think..

Oh sorry, it's VB world. Then forget about ASCIIZ, but LONG should still be most correct.

[Iain Johnstone]

Tried the SUB route - it told me to go away in no uncertain terms!

I have chickened out and taken the error header file data into my own routine and disabled the call to the DLL. Having now got this function in PB-speak, I might try to convert the calls that I am using into a PB DLL.

Many thanks for your interest
Iain Johnstone

[José Roca]

Tried the SUB route - it told me to go away in no uncertain terms!

I'm not surprised, since errorflag AS INTEGER should be BYVAL errorflag AS LONG.

I need to convert this C declaration in a VB dll so that I can use it with PB. The declaration is:

I certainly don't understand what you want to do. Convert a C declaration in a VB dll so that I can use it with PB? PB can use C functions without having to use a VB dll as a middleman.

EXPORT_DLL_FUNCTION(void) GetErrorString(char *errorString, int error);

If this was in a C dll and had to be translated to PB, it will be:

DECLARE SUB GetErrorString LIB <name of the dll> ALIAS "GetErrorString" (BYREF errorString AS ASCIIZ,  BYVAL nError AS LONG)

But I have no idea of what are you doing in your VB dll.

[Jim Dunn]

Has anyone written a "C to PowerBASIC" converter?

I don't even know if it's possible to translate things like ZLIB.DLL or SQLITE.DLL from C to PowerBASIC... but thought I would at least plant the seed, in case someone could translate and then create an SLL of them...

(yes, I'm just Saturday PB10 dreamin')

[Iain Johnstone]

Sorry Jose, I am not explaining this very well.

I have to use a commercial DLL that was designed to be called by VB. The DLL is written in C. The Functions are already defined and I cannot alter them.

The function that I quoted is defined as a FUNCTION, not a SUB, but it has no return value as it is a void. I am trying to use this DLL with PB.

I have the C code and headers and could probably change the function to return a variable, but I have no C compiler to put it back together again. The Integers are also part of the function definitions. The dates on the files suggest that this code is about five years old.

Hope this is clearer,
Iain

[Eric Pearson]

José is correct. "Under the hood" everything is the same; in PB we call a FUNCTION that returns nothing a SUB. Declare it as a SUB and all will be right with the universe.

-- Eric

[Michael Mattias]

Jose gave you the right answer... or at least as right as anyone could give you sans documentation for the external function: You need to pass a buffer (BYREF ASCIIZ) to be filled by the function.

The integer param is also a mystery: you'd expect if the integer were the error code for which you are obtaining a literal it would be the first param, which makes for a little more "natural" syntax; AND, it is unusual to pass a buffer to be filled without passing the size of that buffer so the function does not try to write more characters than it will hold (result: instant stack corruption); that is, maybe that integer is supposed to be the buffer size; AND it's a pretty 'weak' function which returns VOID when there are obvious error codes which could be returned, eg "code not found" or "insufficient buffer size."

You get what you pay for, I guess.

[José Roca]

AND, it is unusual to pass a buffer to be filled without passing the size of that buffer so the function does not try to write more characters than it will hold.

Not so unusual in the C world. There are API functions and C runtime functions that work this way and has been the cause of endless buffer overruns problems in tools like Internet Explorer. These kind of functions assume that you will pass a sufficient buffer. Now, many of these functions have been superseded with safer ones in which you also have to pass the length of the buffer.

[Michael Mattias]

>Not so unusual in the C world [to not require buffer length]...

You get what you pay for.

(Deja vu all over again?)

[Borje Hagsten]

See also a good page in PB help file - Data Types - Comparative datatypes - C/C++

[Jim Dunn]

You get what you pay for

I would pay $$$ for a "C to PowerBASIC function/header translator (with source)" that could translate, say, the ZLIB.DLL source.

Then we could create a ZLIB SLL.

[ok, flame away]

[Iain Johnstone]

Borje - I found that but it was of no help in this situation.

I agree that this declaration leaves a lot to be desired, but I have to work with what I have been supplied with - I can make no changes to the code unless I rewrite it all in PB and compile it as a PB DLL. In fact, all of the functions in the C code pass integers or strings - there are no LONGs. It does use an 'int64' which I assume is a 64bit integer, so there's another problem if I rewrite it!

I do not know how old this code is apart from the file dates, which are around 2005 - this is ancient history in the programming world.

Iain Johnstone

[Larry Charlton]

I would pay $$$ for a "C to PowerBASIC function/header translator (with source)" that could translate, say, the ZLIB.DLL source.

Then we could create a ZLIB SLL.

[ok, flame away]

http://tangiblesoftwaresolutions.com...r_Details.html

It's not power basic and your mileage may vary, but it converts C++ source to VB source. Might be worth trying. There's a demo version.

Also found a web version:
http://code2code.net/Default.aspx

[José Roca]

In fact, all of the functions in the C code pass integers or strings - there are no LONGs.

a C INT or int is not a PB INTEGER, but a LONG.

It does use an 'int64' which I assume is a 64bit integer, so there's another problem if I rewrite it!

A C int 64 is a PB QUAD.

BTW there is not need to rewrite the DLL, just to use it correctly.

[Iain Johnstone]

I had assumed that I would need to use a QUAD, but I did not know about the C int being a PB LONG - thank you for this information.

Iain Johnstone

[Cliff Nichols]

José is correct. "Under the hood" everything is the same; in PB we call a FUNCTION that returns nothing a SUB. Declare it as a SUB and all will be right with the universe.

-- Eric

The long and short of it is if you need a reply? or ignore if you even get a reply? (pass it on if something needs a reply but your code does not care what the reply is)

[Eric Pearson]

The generic term for the thing we are talking about is a "procedure".

If a procedure returns "void" -- nothing -- in PB we call it a SUB. You will never get a response from that procedure. Ever.

If procedure returns a value, we call it a FUNCTION.

-- Eric