Can a 64bit O2 exe call a 32bit PB dll ?

[chrisc]

Hello all

My company is willing to use an O2 exe front end, but it needs to be able to call PB 32bits dlls.
The PB 32 bits dlls would then be converted stage by stage to O2 64bits dlls at a future date.
Can this be doable ?   

This will be the starting point to migrate from PB to O2 eventually
Thanxx

[José Roca]

A 64-bit executable can't call 32-bit DLLs, and a 32-bit executable can't call 64-bit DLLs.

If you need to use 32 DLLs then compile the EXE as 32 bit. If later you want to use 64 DLLs, recompile the EXE as 64 bit.

And before you ask, you can't call both 32 and 64-bit DLLs from the same executable.

[chrisc]

Thanxx Jose good to know this, as gonna need a way to circumvent 64/32 bits transfer of data

[Charles Pegge]

A warm welcome to José !

Yes, I would suggest starting with your smaller DLLs, converting to 32 bit O2, so that you can test the integrity of the new dlls one by one. Tackled individually, they will not defeat you.

Shifting to 64bit is mostly about following the rules, ensuring that handles and pointers are 64bit and that variable passed byref have matching widths (eg longs and dwords).

BTW O2 uses the same strings as PB and thinBasic (ole bstr strings)

[jcfuller]

BTW O2 uses the same strings as PB and thinBasic (ole bstr strings)

Charles,
  Would you elaborate a bit on this?
Are you saying we can use the O2 string type for any and all occasions that call for a bstr?

James

[Charles Pegge]

Yes, based on SysAllocStringBytelen and SysFreeString.

O2 uses these calls to implement dynamic memory allocation, and garbage collection.

O2 dlls with procedures that use string param are compatible with PB.

[jcfuller]

Charles,
  What is the difference between native O2 strings and bstrings?
James

[Charles Pegge]

O2 strings have an additional level of indirection, which points to an entry in a garbage collector's list. Each entry contains a bstring. Similar to Zale strings, I believe

[Charles Pegge]

When strings are passed byval in a function call, they go as bstrings, and are used by the function directly in this form.

They are also passed in this dereferenced way to functions requiring char* strings, and to unprototyped functions

[jcfuller]

Charles,
  Is there a need for any string types other than O2 string and wstring?
If so what would be that scenario?

James

[Charles Pegge]

Yes, objects may 'prefer' to do their own garbage collection within a destructor. It's more efficient to use bstrings directly.

Also, Ported C code and most APIs use char*, so we have to support that too.

[jcfuller]

Charles,

When strings are passed byval in a function call, they go as bstrings, and are used by the function directly in this form.

They are also passed in this dereferenced way to functions requiring char* strings, and to unprototyped functions

Yes, objects may 'prefer' to do their own garbage collection within a destructor. It's more efficient to use bstrings directly.

Also, Ported C code and most APIs use char*, so we have to support that too.

Could you pass an O2 string to a c++ prototype in a function that uses const char* ??
How would you prototype that in O2 parlance?

Yes I see where we need char/wchar buffers for retrieving info from c/c++ apis.

James

[Charles Pegge]

Yes, char* is downwards compatible with bstring. You can use a bstring wherever a char* is expected, but notvice-versa.

A bstring has null terminators after the end of its chars, and a 32bit length field before the start of its chars.