Yes, but Norman’s point was that they throw the exception before they actually use the memory. Ie., if your app can access a max of 3GB and you’re currently using 1GB, and the picture is going to be 4GB, there’s no point in actually trying to create it.
[quote=23655:@Norman Palardy]You can thank Windows & its memory management for that[/quote]What’s wrong with memory management on windows?
Does Xojo access over 4GB in other operating systems but not in windows? Besides, windows 4GB limit is restricted to it’s older OSes for home systems only, Servers were actually capable of addressing more (i.e. 4GB was an intentional limitation coded in to windows)
The only other issue limiting RAM to a single process were memory mapped files used in other processes physically reducing the addressing space available due to a 1:1 correspondence by hardware, but this shouldn’t be an issue on modern windows.
Of course not. Xojo produces 32-bit apps on all platforms.
No version of 64-bit Windows I know of has this limit, intentional or otherwise. Xojo apps are limited to 4GB because that’s how much of the address space is available to 32 bit apps.
Why would it attempt to create a picture with 0x0 dimensions? It seems to me that a NilObjectException would be more logical in that case rather than an OutOfMemoryException.
[quote=23909:@Andrew L.]No version of 64-bit Windows I know of has this limit, intentional or otherwise. Xojo apps are limited to 4GB because that’s how much of the address space is available to 32 bit apps.[/quote]32bit windows.
32bit windows can be extended to a 64GB ram addressing capability. A single process is limited to 4GB still, but that 4GB is not shared with other running processes so it means you can access 4GB realistically vs say 2GB due to other processes running at the same time.
that aside, I dont see how a 4GB addressing limit on windows is any different to any other OS unless he was referring to that 4GB OS imposed limit on selective windows OSes which, dare I say few use.
[quote=23897:@Tony Stark]What’s wrong with memory management on windows?
[/quote]
On a 32 bit system you cant access the full 32 bit address space in a process because of how they do memory mapped I/O
XP’s was terrible - never ending issues with mean restarting the IDE because we could not allocate a single block of sufficient size because of how it allocated memory whether we had enough available RAM or not - no such issue on OS X as it manages this differently.
Vista improved that but there can still be issues where a 32 bit process has lots of free RAM but cannot satisfy a single large request - again its just how tMS does things which is different than OS X and Linux.
I have been researching the issues regarding identifying a picture file before attempting to open it and the consensus seems to be that the first byte of the string (or more, depending on the format) should be hex values that identify what the picture file is. A text signature can be appended to a picture file but should never be prepended to it. Thus, it seems that checking for a leading alphanumeric character should work.
In the testing I’ve done thus far it has been working reliably. The worst thing that can happen if it misidentifies a picture as text is that it will display in the listbox as a string rather than a thumbnail. At this point, that’s preferable to having it throw an OutOfMemoryException error or the other funkiness that appears to be going on with RecordSet.PictureValue in Windows versions prior to Windows 8 (like misidentifying a text string as a bitmap if the string begins with the letters BM).
[quote=23943:@Norman Palardy]On a 32 bit system you cant access the full 32 bit address space in a process because of how they do memory mapped I/O
XP’s was terrible - never ending issues with mean restarting the IDE because we could not allocate a single block of sufficient size because of how it allocated memory whether we had enough available RAM or not - no such issue on OS X as it manages this differently.
Vista improved that but there can still be issues where a 32 bit process has lots of free RAM but cannot satisfy a single large request - again its just how tMS does things which is different than OS X and Linux.[/quote]Sadly, the same issue applied to some earlier Macs too.
The issue had nothing to do with how MS manages memory, it was related to hardware issues MS has no control over, baring in mind they support practically every piece of hardware on the market and Apple uses only their own.
I just ran into an issue with GIF89 files where the string begins with GIF89, which caused the picture to be misidentified as a text file, so I think I’m going to have to match for specific file types rather than just look for a leading alphanumeric character.
[quote=23987:@Tony Stark]Sadly, the same issue applied to some earlier Macs too.
[/quote]
Yes - early MacBooks (1 years worth) http://en.wikipedia.org/wiki/3_GB_barrier#Address_remapping
But the follow ing section points out that Windows machines could be caught by it either in actual hardware OR by using a client version of windows that basically had the limit hard coded into it. Thats one of the issues that still exists if you’re using 32 bit versions of Windows - surprising numbers still are.
XP’s memory manager is notably bad (esp for using Real Studio & Xojo) since we use & free a lot of small blocks esp and this is what results in XP only being able to do a couple compiles before needing to restart the IDE. Turning on the Large Address Aware flag helps a bit.
From my understanding (from our engineer at the time) Vista revamped the memory manager to handle lots of small allocations better - and so from Vista onwards Real Studio & Xojo have not had as many significant issues with memory management issues on Windows as far as compiling is concerned.
a decent article on the topic is http://bugslasher.net/2011/01/15/memory-exhaustion-even-if-a-large-enough-free-memory-segment-is-available/
I believe I finally came up with a reasonably decent solution to the problem. I first check the string header for the hex values of the major image file formats except for bitmaps and get the PictureValue if any are found. If not, I then check for a leading alphanumeric character, which eliminates the string as a picture if present. If an appropriate hex code is not found and the leading character is not alphanumeric I then test for a nil picture.
In doing all of this, I could not find any effective method for checking for bitmaps more directly other than to check for a leading alphanumeric character. Any picture operation that is done in Windows 7 or earlier on a text string that begins with the letters BM or the hex equivalent always results in an OutOfMemoryException error whereas any other text string results in a nil picture. I don’t know if it’s a Windows problem or an IDE problem but the picture functions cannot distinguish between a text string that begins with BM and an actual bitmap.