Operations with `Win32WideString` should ideally not leave objects pinned in memory
Currently operations in Win32WideString leave objects pinned in memory. This is not an issue in terms of behaviour as all works ok. These objects will eventually be garbaged collected but can lead to memory fragmentation (especially if stored for longer) and in an ideal case they should be unpinned.
Methods that end up pinning objects:
Win32WideString>>#asStringpins a temporary variable (out)and also pins the handle of the current objectWin32WideString class>>#fromString:create an intermediary pined in memory array (anUTF8String) and also pins the handle of the wide string
Also WinPlatform>>#getEnvironmentVariable:into:size: has the side-effect of pinning lpName and lpBuffer.
This for example will return true:
string := String streamContents: [:aStream |
aStream nextPutAll: 'USERNAME'].
((Win32WideString fromString:string)
getHandle) isPinnedInMemory
This can be called indirectly from:
string := String streamContents: [:aStream |
aStream nextPutAll: 'USERNAME'].
OSEnvironment current at: string ifAbsent: [''].
or:
string := String streamContents: [:aStream |
aStream nextPutAll: 'USERPROFILE'].
Smalltalk os environment at: string ifAbsent: [ nil ]
These objects could be unpinned after the operation is completed. A larger change would be to use primitives that do not require pinning, but maybe too big of a change.
Checked in windows with the latest version of Pharo 11, 12 and 13