I did some experimenting on this and it seems a basic 32-Bit PB app can allocate about 1,376,780,254 bytes of RAM. But not all at once. The only way I could come even close to that number was in incremental steps by allocating increasingly smaller blobs. The basic code block to create a single block looks like this. I used a new blob variable for each iteration.

ls_spaces = space( ll_spaces )
lblb_test = Blob(ls_spaces, EncodingUTF8!)
ls_spaces = ''

I used UTF8 because in case of spaces this will result in a blob exactly the size of ll_spaces in bytes. ANSI would probably work the same. I started out with one below the supposed maximum supported by Space (2147483646) but that would always error out with "Not enough memory to execute..."

Then I halved the amount with each step.

1073741823: "Not enough memory to execute..."

536870911: "Not enough memory to execute..."

268435455: NO error message so the string was created but it would just silently crash at the line creating the blob from the string.

134217727: This finally worked. But only three times, then I had to go down by half again. In the end it took the following to approach the apparent memory limit:

3x134217727
9x67108863
8x33554431
1x16777215
13x8388607
1x4194303
3x1048575

=~1.3GB RAM. After each allocation crashed I went down by half. No idea why at one point the 16MB allocation failed while 13 8MB blobs could still be created without issue. I mean there's obviously overhead from creating the string variable but it shouldn't be that much? I dunno.

I also tried compiling to 64bit and 64Bit PB Apps handle memory allocation a lot better but it STILL won't allow the supposed maximum for the Space function. The actual maximum seems to be 1053140931, because at 1053140932 it starts to give you the "Not enough memory to execute..." RTE.

In 64bit, the actually available RAM seems to be the limit, I could create 16 ~1GB blobs with no issues. Doing any concatenation etc. with strings this large still just silently crashes the app, though.

Hi Roland...I've been watching for an update on your ticket and Ken's latest reply yesterday still takes the position that the 2GB memory limit is the issue but looking at your latest update it feels like that may not be the case.

FWIW...I compiled a test app, 32 bit and then 64 bit, to see what my max would be on string length and number of strings that size. On the 32 bit app it was about 120MB and on the 64 bit app it was just over 1.053GB (only 20MB off PB's max string size). If I changed the 32 bit executable by turning on /LARGEADDRESSAWARE I was able to have a string as large as 1.053GB. I declared a variable string array and kept increasing the number of elements, filling each element of the array with 1GB of characters. Here's the code (not including variable declarations):

li_array_length = Integer(sle_array_length.Text)  //User-specified via sle
ll_string_size = Long(sle_string_size.Text)	//User-specified via sle
For li_counter = 1 to li_array_length
	mle_2.Text = String(li_counter)
	Yield()
	ls_spaces[li_counter] = Fill ('-', ll_string_size)  //approx. max string size for 64 bit exe in PB is 1,053,140,000 bytes
Next
MessageBox("", "Done.")
SetNull(ls_spaces)

In the 64 bit app, I tested as high as 25 elements in the array, each element 1GB in size and it handled it just fine. I didn't receive an error after 25 elements, I just decided not to test further. I have 32GB of ram on this machine and up around the 21st element it started paging to disk but other than that no issues. On the 32 bit side of things, it just seems to reach its maximum, then the memory error but never pages to disk.

You may be right, maybe the 32 bit limitation is not fixable but given what you were able to do, and that it appears the max string size for a 32 bit app can only hold a little over 10% of the stated maximum for a string under my configuration and the application used for testing, maybe there is something Appeon can do to improve this number. It may not be worth the effort though given there are workarounds. I was curious to see if the 32 bit app behaved differently on a 32 bit OS (versus SysWOW64), more so on the use of the pagefile, but ran out of time...maybe tomorrow.

All that being said, unless one does what you did to make it work or make the app large address aware, clearly a 64 bit app is the way to go if possible.

Regards...Mark

Hi Roland.

From what I see fill has the same problem... I guess you should open a support case. Normally this should not happen. In help it's clearly stated that n can be up to  2,147,483,647.

I've tested in PB 2021...

Andreas.

Hi Chris.

In Roland's case string isn't longer than 256 MB. So it should work. The only issue I can think of is that space is unicode and will produce a UTF16-LE string. I don't know what will be the actual size of produced string in bytes, but I guess it will be lower that 2 GB. I'm right at my consumption?

Andreas.