stupid question on OSStructure in 64 Bits

Seth

I can read the message between the lines ;-)

But I will also read the article on Wikipedia, just to be prepared for the next time I need to use external libraries...

I really appreciate your time and energy for listening and helping, even hough in this case there obviously was mostly ignorance at work...

Joachim

Am Dienstag, 27. November 2018 14:11:54 UTC+1 schrieb Seth Berman:

Hello Joachim,

Glad the issue is resolved.
What you're seeing is not strange, but is how natural alignment of data within c structures works.

That is, they are aligned according to their data type.The following wikipedia page gives a decent description:

<a href="https://en.wikipedia.org/wiki/Data_structure_alignment" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FData_structure_alignment\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg7SdzXFAd-vlGW01NvyOKokoUBw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FData_structure_alignment\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg7SdzXFAd-vlGW01NvyOKokoUBw&#39;;return true;">https://en.wikipedia.org/wiki/Data_structure_alignment.

- Seth

On Tuesday, November 27, 2018 at 4:26:15 AM UTC-5, Joachim Tuchel wrote:

So it seems the DLL I am using here is a strange beast.

After playing with all kinds of combinations, it turns out this 64 bit Library still expects uint32 as 4 bytes and pointers as 8 bytes...

example of a working structure:

fixedsize: 32  (not set by me)
members: (#version #vorschau #ersteSeite #duplexDruck #pdfName #fussText)
types: (#uint32 #uint32 #uint32 #uint32 #pointer #pointer)
offsets: EsOrderedDictionary(0 4 8 12 16 24 )

The cool thing here is that even this does work with uint32At: #version ...

So even if this was a long and frustrating ride, it seems not much has changed in comparison with the 32 bits DLL... . The problem most likely were my fixedSize: statements because the length of pointers is now 8 really bytes, while uint32 still uses 4 bytes and are not aligned to 8 bytes...

Thanks to all who provided help. I am tired now but also glad the DLL calls work now.

I am almost sure my Application is now a pure 64 bit application and will test drive this on Linux 64 (with no 32 bit packages installed)...

Joachim

Am Montag, 26. November 2018 14:55:55 UTC+1 schrieb Seth Berman:

Based on what you said about the first 4 fields being unsigned ints and the last 2 being char *...then the following *should* be correct assuming there are no additional struct specifications.

self
        members: #(version vorschau ersteSeite duplexDruck pdfName fussText)
            types: #(uint32 uint32 uint32 uint32 pointer pointer)

You can swipe this expression and then inspect the OSStructure class that you're using.
There are a bunch of class instance variables giving you information like fixedSize and field types and offsets.
fixedSize should show 32 in 64-bit and 24 in 32-bit.

If your getting a gpf, the most likely scenario is that you're setting pdfName and/or fussText incorrectly, and might be writing the bytes of the string to those fields instead of the pointer address...which would give an invalid address for pdfName and fussText.
The other possibility is that you did not update the getters/setters to reflect the new offsets that would be true in 64-bit vs 32-bit.

What is your code for the setters for pdfName and fussText?

-- Seth

On Monday, November 26, 2018 at 8:43:49 AM UTC-5, Joachim Tuchel wrote:

Well,

not using asPSZ but handling Strings as the result of:

'test', (0 asCharacter asString)

does not solve my gpf problems...