PureBasic Forums - English

Posted: **Fri Jan 30, 2026 3:36 am**

When you call a Win32 API command with an underscore that's expecting a null terminated string (or unicode with 2 nulls) / or a pointer to a null terminated string does it all work seamlessly? I've not encountered any issues yet with testing. Is the int at the beginning of the string removed before passing it or does the architecture just completely handle it all behind the scenes. Thanks!

Posted: **Fri Jan 30, 2026 4:42 am**

Yes you are getting the address of the string as per normal but Internally the string structure is len.i,string.s
If you get a string back from an windows api that you don't need to size yourself you would have to PeekS on it to get the length as the api can't set it.
But most if not all win api will return the length or set a variable of the length so you can use that

Posted: **Fri Jan 30, 2026 4:49 am**

idle wrote: Fri Jan 30, 2026 4:42 am Yes you are getting the address of the string as per normal but Internally the string structure is len.i,string.s
If you get a string back from an windows api that you don't need to size yourself you would have to PeekS on it to get the length as the api can't set it.
But most if not all win api will return the length or set a variable of the length so you can use that

Thanks Idle. I've tested this on 55,000 lines of code with ProGUI V3 and nothing seems to have broken. I am a little worried about code such as:

Code: Select all

Procedure findChildHwnd(hwnd, className.s, nestedLevel = 0)
    
    class.s = Space(255)
    
    chwnd = GetWindow_(hwnd, #GW_CHILD)
    While chwnd
        
        GetClassName_(chwnd, @class, 255)
        
        ;Debug class
        If class = className
           
            ProcedureReturn chwnd
            
        EndIf
        
        result = findChildHwnd(chwnd, className, nestedLevel + 1)
        If result
            ProcedureReturn result
        EndIf
        
        chwnd = GetWindow_(chwnd, #GW_HWNDNEXT)
        
    Wend
 
EndProcedure

Will this still work correctly? I was looking at Fred's comments with the Space() command.

Posted: **Fri Jan 30, 2026 6:12 am**

Official way is PeekS on the string str= peeks(@str)
But GetClassname should also return the length copied into the string. So you can use left or PeekS with the len.

Posted: **Fri Jan 30, 2026 6:18 am**

idle wrote: Fri Jan 30, 2026 6:12 am Official way is PeekS on the string str= peeks(@str)
But GetClassname should also return the length copied into the string. So you can use left or PeekS with the len.

Sorry mate, my old brain is creaking - the string should have been passed 'unadulterated'. but when I try and read it, it might be butchered with an int at the beginning of the string?

Posted: **Fri Jan 30, 2026 6:33 am**

class = className

Posted: **Fri Jan 30, 2026 6:48 am**

If Fred could explain the mechanics behind using a Space() command with win32 calls in a bit more detail that would help a lot, suffice to say - my testing 50 thousand lines of code and it was all working with no problems

Posted: **Fri Jan 30, 2026 10:54 am**

diceman wrote: Tue Jan 27, 2026 8:56 pm Please, for really stupid people like me, can you explain in layman's terms what that actually means?

HeX0R wrote: Tue Jan 27, 2026 11:17 pm

Code: Select all

a$ = "1234567890"
PokeU(@a$ + 5 * SizeOf(CHARACTER), 0) ;write an end of string after the "5" to shorten the string by "cheating"/patching
Debug Len(a$)	;PB <6.40 will show 5, ;PB 6.40 will still show 10, because it doesn't care about the end of string character
   ;solution for PB6.40 here would be:
   ;a$ = PeekS(@a$) ;just uncomment it and see the difference
   ;because PeekS() looks for the first zero byte/word and the strings size will be corrected
a$ + "67890" ;concat
Debug a$ ;PB <6.40 will show 1234567890, PB 6.40 will show 12345, because in PB 6.40 the string is now in memory "12345" + chr(0) + "7890" + "67890" (+ chr(0))
ShowMemoryViewer(@a$, 32)
Debug Len(a$) ;PB <6.40 shows 10, PB 6.40 shows 15

Thank you!
It's a bit more clear now, what is going on here. And I think, I am safe! <3

Posted: **Fri Jan 30, 2026 8:36 pm**

this is good news; but perhaps a next step is 4 or 8 byte alignment for string buffers such that copy operations can work faster; as an idea. It's a trick I've used.

Posted: **Fri Jan 30, 2026 9:16 pm**

kinglestat wrote: Fri Jan 30, 2026 8:36 pm this is good news; but perhaps a next step is 4 or 8 byte alignment for string buffers such that copy operations can work faster; as an idea. It's a trick I've used.

That should already be the case. The default alignment for allocated memory is 8byte for x86 and 16byte for x64. Adding the space to store the length throws that off again but it will still remain 4/8 byte aligned in any case.

Posted: **Fri Jan 30, 2026 10:55 pm**

Hi! Dumb question, what about strings in structures? (I don't have a indows computer to test it yet)

Posted: **Sat Jan 31, 2026 12:01 am**

In structures, only the pointer to the string is stored. The string itself has again saved the length before the string. The assignment of the memory again manages the string management internally as before. So nothing changes for you.

Code: Select all

Structure sFoo
  iVal.i
  sVal.s
EndStructure

Define MyVal.sFoo

MyVal\iVal = 100
MyVal\sVal = "Hello"

Debug "Same as before"
Debug "Size Of Structure: " + SizeOf(sFoo)
Debug MyVal\iVal
Debug MyVal\sVal
Debug PeekS(@MyVal\sVal)

Debug "New string management save string len before the string"
Debug "Len: " + Len(MyVal\sVal)
Debug "Direct: " + PeekI(@MyVal\sVal - SizeOf(Integer))

Posted: **Sat Jan 31, 2026 12:04 am**

Naheulf wrote: Fri Jan 30, 2026 10:55 pm Hi! Dumb question, what about strings in structures? (I don't have a indows computer to test it yet)

There's no change really, you still need to either align the structure or pad the fields so the string is aligned within the structure and while the memory of the string structure is allocated on 16 bytes alignment the string address returned to you via @ will be on an 8 bytes alignment.

There's no reason strings can't be aligned but it can be wasteful see this example where it needs aligned memory
viewtopic.php?p=638681#p638681
it allocates and returns a pointer on the requested alignment but it's wasteful as it pads the allocation with an integer + the alignment + the overhead of memory size from the allocator so 32 bytes for 16 alignment.
since it doesn't know the offset, it stores the original pointer so it can be free'd, the same could be done with strings

Posted: **Sat Jan 31, 2026 1:02 am**

If you look at with the string length, all strings are aligned with 16 bytes

Code: Select all

Global Dim files.s(3)

files(0) = "0"
files(1) = "1"
files(2) = "2"
files(3) = "3"

For i = 0 To 3
  Debug Hex(@files(i) - SizeOf(integer))
Next

Posted: **Sat Jan 31, 2026 1:08 am**

Im not at pc but is the string address 16 aligned @str as far as I understood it's not it will be 8 aligned.

PureBasic Forums - English

PureBasic 6.40 alpha 3 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 1 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !

Re: PureBasic 6.40 alpha 2 is ready, surprise inside !