Smalltalk › Instantiations

stupid question on OSStructure in 64 Bits

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

jtuchel

stupid question on OSStructure in 64 Bits

Hi,

I'm going to tell you a secret now: I've spent more than 25 years programming without understanding the very basics of computing.

There's no point in trying to keep this a secretm because even without this introduction you'll realize immediately if you continue reading this stupid beginner#s question.

Let's say I am trying to port a program from VAST 32Bits to 64Bits and I have an OSStructure that needs to be passed to an external DLL.

In 32 bits, the definition looked like this:

initializeAfterLoad

    self
        fixedSize: 24;
        members: #(version vorschau ersteSeite duplexDruck pdfName fussText)

For some reason, calls to the DLL end with a GPF if I don't change this. My first guess would be that this is due to the fact that I now have to give a hint as to what size the fields have, In the documentation of the dll the first 4 parameters are (uint32)'s and the last two are (const char *).

So I thought I'd try this:

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

(I'm passing the Strings with #asPSZ, like in 'test.pdf' asPSZ)

This still is not good enough, I still get GPFs. So I guess what's needed in addition is a fixedSize to make this right.

My naive understanding of all this is that this structure uses 8 bytes per uint32 ("wasting" the uper 32 bits for each uint32) and 8 bits per pointer. This would be 6*8=48 bits.

So I tried this:

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

I am not sure if the GPF I am now getting is the same one as before, but maybe that doesn't really matter ;-)

Then I thought "Okay, I am not clever enough for this, maybe that alignment thing is somewhat completely different than I think" and tried this:

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

The theory behind that being that I possibly don't have to worry and just count the bytes I really need - against all odds that my little knowledge of computing offers...

Of course, I still get a GPF when I call the DLL.

Seems it's time to ask people who understand this DLL communication stuff for help... I am quite sure this structure is 48 Byte in size, isn't it?

Any hints or tips?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Marten Feldtmann-5

Re: stupid question on OSStructure in 64 Bits

Do you have the low-level C code, which defines the stuff ?

Marten

Am Montag, 26. November 2018 10:50:49 UTC+1 schrieb Joachim Tuchel:

Hi,

I'm going to tell you a secret now: I've spent more than 25 years programming without understanding the very basics of computing.
There's no point in trying to keep this a secretm because even without this introduction you'll realize immediately if you continue reading this stupid beginner#s question.

Let's say I am trying to port a program from VAST 32Bits to 64Bits and I have an OSStructure that needs to be passed to an external DLL.

In 32 bits, the definition looked like this:

initializeAfterLoad

    self
        fixedSize: 24;
        members: #(version vorschau ersteSeite duplexDruck pdfName fussText)

For some reason, calls to the DLL end with a GPF if I don't change this. My first guess would be that this is due to the fact that I now have to give a hint as to what size the fields have, In the documentation of the dll the first 4 parameters are (uint32)'s and the last two are (const char *).

So I thought I'd try this:

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

(I'm passing the Strings with #asPSZ, like in 'test.pdf' asPSZ)

This still is not good enough, I still get GPFs. So I guess what's needed in addition is a fixedSize to make this right.
My naive understanding of all this is that this structure uses 8 bytes per uint32 ("wasting" the uper 32 bits for each uint32) and 8 bits per pointer. This would be 6*8=48 bits.

So I tried this:

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

I am not sure if the GPF I am now getting is the same one as before, but maybe that doesn't really matter ;-)

Then I thought "Okay, I am not clever enough for this, maybe that alignment thing is somewhat completely different than I think" and tried this:

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

The theory behind that being that I possibly don't have to worry and just count the bytes I really need - against all odds that my little knowledge of computing offers...

Of course, I still get a GPF when I call the DLL.

Seems it's time to ask people who understand this DLL communication stuff for help... I am quite sure this structure is 48 Byte in size, isn't it?

Any hints or tips?

Joachim

jtuchel

Re: stupid question on OSStructure in 64 Bits

not the full source code, just includes and a bunch of documentation

jtuchel

Re: stupid question on OSStructure in 64 Bits

Okay,

this is very surprising to me and I have no idea if this is related.

BUT:

some of the parameters of my function are (const char *) and the way I pass them in is sending asPSZ to them in order to make them NUL-terminated...

now an interesting difference between VAST 9.1 32 bits and 64 bits is that asPSZ returns a different result:

32 bits: 'Test' asPSZ returns a String containing 'Test' and a trailing <Nul>

64 bits: 'Test' as PSZ returns the String 'Test' and no trailing <Nul>

32 bits: 'Test' asPSZ asByteArray --> [84 101 115 116 0]

64 bits: 'Test' asPSZ asByteArray --> [84 101 115 116]

Could this be (part of) my problem?

Joachim

Am Montag, 26. November 2018 11:19:42 UTC+1 schrieb Joachim Tuchel:

not the full source code, just includes and a bunch of documentation

Seth Berman

Re: stupid question on OSStructure in 64 Bits

Hi Joachim,

One needs to know the definition of the structure. You don't need fixedSize. Only memeber:types: (and potentially members:types:alignment:)
The 64-bit version of the structure could have variations in data types, packing rules, struct alignment, number of fields. We have to know what's its definition is.

asPSZ is optimized with the knowledge about EsObject alignment...this can avoid a copy if it knows that implicit padding exists.
Objects are 4-byte aligned in 32-bit...so an explicit 0 is needed for that specific 4 character string in order to have a trailing null.
Objects are 8-byte aligned in 64-bit...so the 4-character byte array is already implicitly padded with 4 additional 0s...so you don't need an explicit null

- Seth

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

Okay,

this is very surprising to me and I have no idea if this is related.

BUT:

some of the parameters of my function are (const char *) and the way I pass them in is sending asPSZ to them in order to make them NUL-terminated...

now an interesting difference between VAST 9.1 32 bits and 64 bits is that asPSZ returns a different result:

32 bits: 'Test' asPSZ returns a String containing 'Test' and a trailing <Nul>
64 bits: 'Test' as PSZ returns the String 'Test' and no trailing <Nul>

32 bits: 'Test' asPSZ asByteArray --> [84 101 115 116 0]
64 bits: 'Test' asPSZ asByteArray --> [84 101 115 116]

Could this be (part of) my problem?

Joachim

Am Montag, 26. November 2018 11:19:42 UTC+1 schrieb Joachim Tuchel:
not the full source code, just includes and a bunch of documentation

jtuchel

Re: stupid question on OSStructure in 64 Bits

In reply to this post by jtuchel

Well,

not using asPSZ but handling Strings as the result of:

'test', (0 asCharacter asString)

does not solve my gpf problems...

Seth Berman

Re: stupid question on OSStructure in 64 Bits

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 setting pdfName and/or fussText incorrectly, and might writing the bytes of the string to those fields instead of the pointer address.
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...

Louis LaBrunda

Re: stupid question on OSStructure in 64 Bits

In reply to this post by jtuchel

Hi Joachim,

You need to post the .h file (or at least the part) that defines the structure you are trying to map/define. With that, someone, probably Seth, will quickly be able to define the structure.

I am far from an expert in this area but i can generally muddle through. Things with "*"s in them are pointers, strings are almost always (if not always) pointers. Things like this can make it all very confusing. A knowledge of C (I have very little) helps a lot. Hang in there.

Lou

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...

jtuchel

Re: stupid question on OSStructure in 64 Bits

In reply to this post by Seth Berman

Seth,

I will gather as much as I can about this and will come back to you later. Thanks for looking into this.

Joachim

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

Hi Joachim,

One needs to know the definition of the structure. You don't need fixedSize. Only memeber:types: (and potentially members:types:alignment:)
The 64-bit version of the structure could have variations in data types, packing rules, struct alignment, number of fields. We have to know what's its definition is.

asPSZ is optimized with the knowledge about EsObject alignment...this can avoid a copy if it knows that implicit padding exists.
Objects are 4-byte aligned in 32-bit...so an explicit 0 is needed for that specific 4 character string in order to have a trailing null.
Objects are 8-byte aligned in 64-bit...so the 4-character byte array is already implicitly padded with 4 additional 0s...so you don't need an explicit null

- Seth

On Monday, November 26, 2018 at 8:28:31 AM UTC-5, Joachim Tuchel wrote:
Okay,

this is very surprising to me and I have no idea if this is related.

BUT:

some of the parameters of my function are (const char *) and the way I pass them in is sending asPSZ to them in order to make them NUL-terminated...

now an interesting difference between VAST 9.1 32 bits and 64 bits is that asPSZ returns a different result:

32 bits: 'Test' asPSZ returns a String containing 'Test' and a trailing <Nul>
64 bits: 'Test' as PSZ returns the String 'Test' and no trailing <Nul>

32 bits: 'Test' asPSZ asByteArray --> [84 101 115 116 0]
64 bits: 'Test' asPSZ asByteArray --> [84 101 115 116]

Could this be (part of) my problem?

Joachim

Am Montag, 26. November 2018 11:19:42 UTC+1 schrieb Joachim Tuchel:
not the full source code, just includes and a bunch of documentation

Louis LaBrunda

Re: stupid question on OSStructure in 64 Bits

Hi Joachim,

Let me ask you a stupid question. I think you said you are porting a 32 bit program to 64 bits. I assume you were calling a 32 bit lib. Are you still calling the same 32 bit lib or are you calling a 64 bit lib? If you are calling the same 32 bit lib, I don't think you need to change the structure. If you are calling a new 64 bit lib, then you do.

Lou

On Monday, November 26, 2018 at 9:20:26 AM UTC-5, Joachim Tuchel wrote:

Seth,

I will gather as much as I can about this and will come back to you later. Thanks for looking into this.
given that the call works on 32 bits, I think some of what you say can be ruled out, no? I mean, I haven't changed the way I stuff bytes into the Strings and such...

Good, to know, however that fixedSize: is not necessary.

Joachim

Am Montag, 26. November 2018 14:42:20 UTC+1 schrieb Seth Berman:
Hi Joachim,

One needs to know the definition of the structure. You don't need fixedSize. Only memeber:types: (and potentially members:types:alignment:)
The 64-bit version of the structure could have variations in data types, packing rules, struct alignment, number of fields. We have to know what's its definition is.

asPSZ is optimized with the knowledge about EsObject alignment...this can avoid a copy if it knows that implicit padding exists.
Objects are 4-byte aligned in 32-bit...so an explicit 0 is needed for that specific 4 character string in order to have a trailing null.
Objects are 8-byte aligned in 64-bit...so the 4-character byte array is already implicitly padded with 4 additional 0s...so you don't need an explicit null

- Seth

On Monday, November 26, 2018 at 8:28:31 AM UTC-5, Joachim Tuchel wrote:
Okay,

this is very surprising to me and I have no idea if this is related.

BUT:

some of the parameters of my function are (const char *) and the way I pass them in is sending asPSZ to them in order to make them NUL-terminated...

now an interesting difference between VAST 9.1 32 bits and 64 bits is that asPSZ returns a different result:

32 bits: 'Test' asPSZ returns a String containing 'Test' and a trailing <Nul>
64 bits: 'Test' as PSZ returns the String 'Test' and no trailing <Nul>

32 bits: 'Test' asPSZ asByteArray --> [84 101 115 116 0]
64 bits: 'Test' asPSZ asByteArray --> [84 101 115 116]

Could this be (part of) my problem?

Joachim

Am Montag, 26. November 2018 11:19:42 UTC+1 schrieb Joachim Tuchel:
not the full source code, just includes and a bunch of documentation

jtuchel

Re: stupid question on OSStructure in 64 Bits

Lou,

thanks for asking. It is not a stupid question. As obvious as it sounds, this is the kind of error I make much more often than I'd like. But following your mail I just double checked ;-)

It is in fact the 64 bits version, at least according to the PATH settings in Windows ;-)

Some calls work, and have been from the very beginning when I fired up the 64 bits image. I was very enthusiastic about that ;-)

Joachim

jtuchel

Re: stupid question on OSStructure in 64 Bits

In reply to this post by Seth Berman

Seth,

I think you gave an important hint with the question about the setters:

fussText: einString

    einString isEmpty
        ifTrue: [self uint32At: 20 put: OSPtr null]
        ifFalse: [self uint32At: 20 put: einString asPSZ copyToOSMemory]

pdfName: einString

self uint32At: 16 put: einString asPSZ copyToOSMemory.

These offsets in getters and setters need to be changed as well, of course !!!!

I'll take a look into this and keep you updated.

The .h and other files do not give any hint as to what the alignment could be, so I assume it is the standard (lower 4 bytes for the uint32, upper four bytes irrelavant)....

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...

Seth Berman

Re: stupid question on OSStructure in 64 Bits

Hi Joachim,

The vast doc is worth a read in this area
https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html

The definition of your setter should use symbolic references these days...not integer offsets.
The OSStructure has an platform-dependent offset/alignment calculator when we went to 64-bit,

so while the old way is still supported where you hand compute field offsets...I would personally stay away from that.

fussText: einString

einString isEmpty
ifTrue: [self pointerAt: #fussText put: OSPtr null]
ifFalse: [self pointerAt: #fussText put: einString asPSZ copyToOSMemory]

pdfName: einString

self pointerAt: #pdfName put: einString asPSZ copyToOSMemory.

- Seth
On Monday, November 26, 2018 at 10:28:58 AM UTC-5, Joachim Tuchel wrote:

Seth,

I think you gave an important hint with the question about the setters:

fussText: einString

    einString isEmpty
        ifTrue: [self uint32At: 20 put: OSPtr null]
        ifFalse: [self uint32At: 20 put: einString asPSZ copyToOSMemory]

pdfName: einString

    self uint32At: 16 put: einString asPSZ copyToOSMemory.

These offsets in getters and setters need to be changed as well, of course !!!!

I'll take a look into this and keep you updated.

The .h and other files do not give any hint as to what the alignment could be, so I assume it is the standard (lower 4 bytes for the uint32, upper four bytes irrelavant)....

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...

jtuchel

Re: stupid question on OSStructure in 64 Bits

In reply to this post by Seth Berman

Seth,

thanks for the tip on inspecting the result of the initialization of the members.

As far as I understood what you wrote, there was some hope sparkling in me that I understnad at least some basics here.

Unfortunately, that is not the case.

When I inspect that result of that expression, I see this:

I tried without alignmentType as well as alignmentTypes Align8 and AlignDefault. I even double checked in my Transcript that it is indeed a 64 bit image:

VA Smalltalk V9.1 (64-bit); Image: 9.1 [413]
VM Timestamp: 4.0, 07/18/18 (100)

I would have expected to see offsets at multiples of 8 and a fixedSize of 48.

Here's what I executed and inspected to see the screenshot above:

initializeAfterLoad

   "self initializeAfterLoad"

   super initializeAfterLoad .

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

(see: no fixedSize: anymore, I added the super call to make sure that #initializeDefaultTypeMappings in OSStructure is also running, just to be sure...).

Does that mean I need to setup the structure for uint64s and use the uint32At: and uint32At:put: methods to get/set the values in the structure?

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...

jtuchel

Re: stupid question on OSStructure in 64 Bits

In reply to this post by Seth Berman

Hi Seth,

Am Montag, 26. November 2018 16:44:28 UTC+1 schrieb Seth Berman:

Hi Joachim,

The vast doc is worth a read in this area
<a href="https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.instantiations.com%2Fdocs%2F91%2Fwwhelp%2Fwwhimpl%2Fjs%2Fhtml%2Fwwhelp.htm%23href%3Dpr%2Fstpr451.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbWB1GpGcZwVjAM2QV-NuciievaA';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.instantiations.com%2Fdocs%2F91%2Fwwhelp%2Fwwhimpl%2Fjs%2Fhtml%2Fwwhelp.htm%23href%3Dpr%2Fstpr451.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbWB1GpGcZwVjAM2QV-NuciievaA';return true;">https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html

shame on me. You are right, this is worth a read. Thanks for the pointer.

fussText: einString

einString isEmpty
        ifTrue: [self pointerAt: #fussText put: OSPtr null]
        ifFalse: [self pointerAt: #fussText put: einString asPSZ copyToOSMemory]

pdfName: einString

    self pointerAt: #pdfName put: einString asPSZ copyToOSMemory.

changed it and that feels much better now. Just one place to change when you are trying to define a structure. A small but big improvement over what it worked like before.

Joachim

jtuchel

Re: stupid question on OSStructure in 64 Bits

In reply to this post by Seth Berman

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...

Noschvie

Re: stupid question on OSStructure in 64 Bits

In reply to this post by Seth Berman

Hi Seth

The vast doc is worth a read in this area
<a href="https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.instantiations.com%2Fdocs%2F91%2Fwwhelp%2Fwwhimpl%2Fjs%2Fhtml%2Fwwhelp.htm%23href%3Dpr%2Fstpr451.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbWB1GpGcZwVjAM2QV-NuciievaA';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.instantiations.com%2Fdocs%2F91%2Fwwhelp%2Fwwhimpl%2Fjs%2Fhtml%2Fwwhelp.htm%23href%3Dpr%2Fstpr451.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbWB1GpGcZwVjAM2QV-NuciievaA';return true;">https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html

have changed one of our classes, works fine for integers and pointers.

But for this example:

self members: #(szVendorName szVendorEMail) types: #('char8[80]' 'char8[80]').

how have the getter for szVendorName to be instead of "^self abtCharArrayAt: 0 length: 80" ?

thanks

Norbert

Seth Berman

Re: stupid question on OSStructure in 64 Bits

In reply to this post by jtuchel

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:

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...

jtuchel

Re: 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" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FData_structure_alignment\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg7SdzXFAd-vlGW01NvyOKokoUBw';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FData_structure_alignment\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHg7SdzXFAd-vlGW01NvyOKokoUBw';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...

Seth Berman

Re: stupid question on OSStructure in 64 Bits

In reply to this post by Noschvie

Hi Norbert,

Is this an instance of AbtForeignOSObject?
Normally, we use the OSStructure defined
arrayAt:*

byteArrayAt:*
stringAt:* (subtle differences relating to leading Nul)
dbStringAt:* (subtle differences relating to leading Nul)

...to handle these situations depending on if you want a typed reference to the memory location or a Smalltalk heap copy of it.

In the case you showed, I would use something like:

self arrayAt: #szVendorName size: 80 type: OSChar8.

The AbtForeignOSObject has some sort of internal code page conversion tracking that an OSStructure doesn't have.
So then I would memcpy the OSChar8 into a String or DBString depending on some condition.

What looks appropriate is to change those abtChar methods (and anything else I see in there) in AbtForeignOSObject to be symbolic reference aware.

-- Seth

On Tuesday, November 27, 2018 at 5:08:11 AM UTC-5, Norbert Schlemmer wrote:

Hi Seth

The vast doc is worth a read in this area
<a href="https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html" rel="nofollow" target="_blank" onmousedown="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.instantiations.com%2Fdocs%2F91%2Fwwhelp%2Fwwhimpl%2Fjs%2Fhtml%2Fwwhelp.htm%23href%3Dpr%2Fstpr451.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbWB1GpGcZwVjAM2QV-NuciievaA';return true;" onclick="this.href='https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.instantiations.com%2Fdocs%2F91%2Fwwhelp%2Fwwhimpl%2Fjs%2Fhtml%2Fwwhelp.htm%23href%3Dpr%2Fstpr451.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbWB1GpGcZwVjAM2QV-NuciievaA';return true;">https://www.instantiations.com/docs/91/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html

have changed one of our classes, works fine for integers and pointers.

But for this example:
self members: #(szVendorName szVendorEMail) types: #('char8[80]' 'char8[80]').

how have the getter for szVendorName to be instead of "^self abtCharArrayAt: 0 length: 80" ?

thanks
Norbert