UDT alignment PB vs. VB

[Dennis Pearson]

RE: PB/DLL 6 and VB 5

The help for PB implies that VB aligns each member of a UDT by DWORD.
"The memory address for each member of the UDT must begin at a location evenly divisible by 4 (there are 4 bytes in a DWORD)."

I am seeing different results. To me, it appears the total size of a VB UDT must be divisible by 4 AND any needed padding is inserted after the first member in the UDT that is not divisible by 4 (remember that two VB integers are "packed").

The two are "equal" when passing a record ByRef between PB and VB.

TYPE PBType
  Mem_A   AS STRING * 10
  PAD     AS STRING * 2
  Mem_B   AS Currency
  Mem_C   AS Currency
  Mem_D   AS STRING * 5
  Mem_E   AS STRING * 32
  Mem_F   AS STRING * 14
  Mem_G   AS STRING * 32
  Mem_H   AS STRING * 32
  Mem_I   AS STRING * 32
  Mem_J   AS STRING * 27
  Mem_K   AS STRING * 4
  Mem_L   AS STRING * 10
  Mem_M   AS LONG
  Mem_N   AS LONG
  Mem_O   AS LONG
END TYPE


TYPE VBType
  Mem_A   AS STRING * 10
  Mem_B   AS Currency
  Mem_C   AS Currency
  Mem_D   AS STRING * 5
  Mem_E   AS STRING * 32
  Mem_F   AS STRING * 14
  Mem_G   AS STRING * 32
  Mem_H   AS STRING * 32
  Mem_I   AS STRING * 32
  Mem_J   AS STRING * 27
  Mem_K   AS STRING * 4
  Mem_L   AS STRING * 10
  Mem_M   AS LONG
  Mem_N   AS LONG
  Mem_O   AS LONG
END TYPE

Dennis

[E B Knoppert]

Type TypeName As DWORD ?

[Jim Karabatsos]

Dennis

It has been a long time since I last looked into it so I may be wrong, but as I recall VB's type alignment rules were as follows:

Integers are aligned on a 2-byte boundary. Longs, Currencies and all floats are aligned on a 4-byte boundary. Strings and bytes are simply aligned on bytes (that is, no padding is added before them).

[Mike Luther]

OK, but exactly what are the PB rules? Equally important, how
should one compose UDT's between PB 3.5 for DOS and this, so that
when it comes time to move to this, the same UDT will not trip
you up?



-------------
Mike Luther
[email protected]

[Lance Edmonds]

be sure to check out the faq on this: http://www.powerbasic.com/support/pb...hread.php?t=28

-------------
lance
powerbasic support
( mailto:[email protected][email protected]</a> )

[Dennis Pearson]

My conclusion agrees with Jim's. The FAQ just does not account for odd length strings. Using type DWORD causes all of the PB members to be aligned, which does not match VB's method.

My bringing up this topic is to come up with a better definition of VB's alignment process for inclusion in the PB docs.

Since PB is marketed as a companion to VB, adding a type option of VBALIGNED would be a helpful addition.

Dennis

[Lance Edmonds]

the information we have in the faq at http://www.powerbasic.com/support/pb...hread.php?t=28 is obsolete, and unfortunately so is our help file information on the subject.

the current printed manual for pb/dll does have an updated discussion on vb's curious "natural alignment" technique, in appendix a - visual basic. we will be updating the faq on the bbs as soon as time permits.

the brief version of the info is this:
vb uses dword alignment provisionally. elements are dword-aligned unless the next element(s) can fit entirely within the space that would've otherwise been used to pad out the dword. to match this in pb, the user needs to use byte alignment in the pb udt, and insert appropriate dummy variables in the pb udt, so as to pad it out accordingly.

-------------
lance
powerbasic support
( mailto:[email protected][email protected]</a> )

[Joseph W. Murphy]

For more information about VB 32-Bit Alignment problems you could look at the May 1997 Issue of Visal Basic Programmers Journal. The article is the Black Belt Programming column by Jonathon Wood.

There is also some free downloads on his web site
http://www.softcircuits.com/sw_tools.htm http://www.softcircuits.com/sw_vbsrc.htm


Joseph W. Murphy

[Dennis Pearson]

I still have that issue! Thank you for the tip!

Dennis

[Dennis Pearson]

The piece that seems to be missing from the PB docs is that fixed length strings are not aligned at all. My "theory" is that the cause is the way VB must convert strings from unicode to ansi.

Dennis

[gengle99]

I seem confused with the question we are debating over, why don't we just pass everything as a byte array... obviously VB6 stressed the advantages of this feature, its always recommended to pass a byte array to API's, so why wouldn't you do that to PB/DLL?

Greg Engle

[David Lloyd]

Originally posted by gengle99:
I seem confused with the question we are debating over, why don't we just pass everything as a byte array... obviously VB6 stressed the advantages of this feature, its always recommended to pass a byte array to API's, so why wouldn't you do that to PB/DLL?

Greg Engle

A byte array sounds workable, but is there an efficient way to "read" the byte array in VB6? It appears I'll have to loop through the array to build my VB string, and then I will have lost the speed advantage in having called PBDLL in the first place! I'm finding that unicode conversion is more of an issue than type alignment.


------------------

[John Petty]

quote
_____________________________________________________________
elements are dword-aligned unless the next element(s) can fit entirely within the space that would've otherwise been used to pad out the dword.
_____________________________________________________________
however remember all elements must be aligned to a "natural boundry" so integers must start at an even byte address, this gives optimal speed for the intel architecture (ai) as intel describe it, as any element not on a natural boundry requires two memory accesses to obtain the information rather than one. the vb udt gives equivalent speed to the pb udt with dword alignment but better packing.
there do appear to be problems with unicode conversions. http://www.powerbasic.com/support/pb...ad.php?t=17471
may be of some help


------------------

[David Lloyd]

Originally posted by John Petty:
The VB UDT gives equivalent speed to the PB UDT with DWORD alignment but better packing.
There do appear to be problems with unicode conversions.

It appears there is no good way to pass UDT's from VB to PB and back unless the types are carefully planned with all numeric fields or all strings. Unicode with partial DWORD alignment makes passing types nearly impossible. PB really needs to address this incompatibility.

I have solved my problem passing types to PB by defining a type using all string fields in VB with the actual type (not DWORD aligned) in PB. In VB I have to convert numbers to strings using the CopyMemory API call prior to calling PB, and on return I have to use CopyMemory to put the string values back to the numeric variables. VB's automatic conversion of Unicode when calling DLL's makes this possible. I know this is a tedious solution, but it works, and it's preferable to passing lots of individual variables. See the example below:

Type SampleType            'Used in VB and PB
   iInteger As Integer
   sString As String * 5
   lLong As Long
End Type
Type SampleTypeBuffer       'VB type passed to PB
   iInteger As String * 2
   sString As String * 5
   lLong As String * 4
End Type
Sub SetBuffer
   Dim Sample As SampleType
   Dim SampleBuf As SampleTypeBuffer
   CopyMemory Sample.iInteger, SampleBuf.iInteger, 2
   SampleBuf.sString = Sample.sString
   CopyMemory Sample.lLong, SampleBuf.lLong, 4
End Sub
Sub GetBuffer
   Dim Sample As SampleType
   Dim SampleBuf As SampleTypeBuffer
   CopyMemory SampleBuf.iInteger, Sample.iInteger, 2
   Sample.sString = SampleBuf.sString
   CopyMemory SampleBuf.lLong, Sample.lLong, 4
End Sub
Call SetBuffer
Call PowerBasic (SampleBuf As SampleTypeBuffer)
Call GetBuffer

------------------

[John Petty]

David
You are not doing any alignment!
Your simple
Type SampleType 'Used in VB
iInteger As Integer
sString As String * 5
lLong As Long
End Type
would be defined in PB as

Type PBSampleType
iInteger as Integer
sString as String * 5
bPadding as Byte
lLong as long
End Type
As VB does a unicode to ansi conversion on the string before passing it to PB then with the 1 byte padding all variables are on natural alignment, in particular in this case the lLong is now staring on a 4 byte boundary. I gues what PB forgets to point out is that all PB variables except internal members of a UDT are aligned to 4 byte boundries so the starting point of the PB UDT is always on a 4 byte boundry and padding can be easily worked out.
In the forum I referred to earlier you will see the the only Unicode - Ansi conversions I found problems with were fixed length string arrays.
Regards



------------------

[Doug McDonald]

posted June 09, 2000 05:25 AM
--------------------------------------------------------------------------------
I fully understand the alignmet issues for UDT's in VB and PB (and others).. But is this a really stupid idea.? What I've done is to open a file in a ram drive, 'Put' my VB UDT and then call PB. PB opens the file and reads it into a byte array and does the fast stuff. No alignment problems!! and as far as i can tell it's faster than passing a pointer of the UDT and "padding" it in PB and lots less work.
Just a thought
Doug



------------------