Hello, I had never actually had windows run out of resources before... I’m glad to say though that I was able to save and close everything cleanly, and safely reboot with out a hitch. I guess Win98SE isn’t that bad for stability after all 
Any ways, what I did, without realizing it is create a 280MB dynamic array using a user-defined type. I just never occurred to my DOS programming brain that my PB app could ever use up 128MB of ram and 160MB of the swap file. Normally I’d have gotten an out of memory message ages ago.
One of the reasons I am posting this is that what I saw is not what I expected. What I saw was a GPF. I then spent some time stripping my code down trying to find what was causing it. In the end I was able to cause a PGF with just this code:
What I found interesting is that the GPF happened after the MSGBOX. It then finally ran though my thick skull to add up how big this array really was… Well actually it was just for curiosity.
So, what PB does when you run out of memory is nothing. The DIM statement (or REDIM) returns normally with no form of message. Then the first time you try to access the dimensioned variable, you get a GPF.
Help File: “A PowerBASIC array may contain up to 4,294,967,295 elements, and the data may occupy as much as all available memory.”
I realize that PB does not expect us to be filling up all the memory, but a notice in the help file mentioning how PB handles running out of memory would be nice anyway
So, if you are playing with any real amount of data at all, you will probably want to perform a check after each and every DIM or REDIM to confirm that the dimension has been successful. To check this simply look at the return value from VARPTR(array(any element)) If the address returned is 0, then you have to know something is up!
And now my second justification for posting this is the following: Our little tiny PB EXEs are attractive to people with older computers. Let’s say someone with a 486 and 8MB of RAM is running your app on Win95a, do they want to see a GPF from you or a nice message saying “Time to upgrade!”
As for me, I guess I’ll be adding disk-caching-of-large-indexes to my database. To bad, it was moving quick in RAM
And that would be my 20 cents,
Colin Schmidt
-------------
Colin Schmidt & James Duffy, Praxis Enterprises, Canada

Any ways, what I did, without realizing it is create a 280MB dynamic array using a user-defined type. I just never occurred to my DOS programming brain that my PB app could ever use up 128MB of ram and 160MB of the swap file. Normally I’d have gotten an out of memory message ages ago.
One of the reasons I am posting this is that what I saw is not what I expected. What I saw was a GPF. I then spent some time stripping my code down trying to find what was causing it. In the end I was able to cause a PGF with just this code:
Code:
DIM a(150000, 34, 12) as LONG MSGBOX “DIM OK” a(0, 0, 0) = 1
So, what PB does when you run out of memory is nothing. The DIM statement (or REDIM) returns normally with no form of message. Then the first time you try to access the dimensioned variable, you get a GPF.
Help File: “A PowerBASIC array may contain up to 4,294,967,295 elements, and the data may occupy as much as all available memory.”
I realize that PB does not expect us to be filling up all the memory, but a notice in the help file mentioning how PB handles running out of memory would be nice anyway

So, if you are playing with any real amount of data at all, you will probably want to perform a check after each and every DIM or REDIM to confirm that the dimension has been successful. To check this simply look at the return value from VARPTR(array(any element)) If the address returned is 0, then you have to know something is up!
And now my second justification for posting this is the following: Our little tiny PB EXEs are attractive to people with older computers. Let’s say someone with a 486 and 8MB of RAM is running your app on Win95a, do they want to see a GPF from you or a nice message saying “Time to upgrade!”
As for me, I guess I’ll be adding disk-caching-of-large-indexes to my database. To bad, it was moving quick in RAM

And that would be my 20 cents,
Colin Schmidt
-------------
Colin Schmidt & James Duffy, Praxis Enterprises, Canada
Comment