I think I have to debunk a few of these myths here :)

Quote - Basically, the 1st problem is that Poser was initially written for the original Mac. Then Ported over to Win 3.1. So you have all the issues that any application had spanning those two very different operating environments.

Poser was never ported to Windows 3.1. If you happen to have a Poser 1 box around, it states Windows 95 as minimum requirement. The problems of covering two different operating systems are not what one might think they are - they're mostly UI differences (like Window focus, menu handling etc) and have barely anything to do with memory management. Besides, we're in good company - most other 3d programs out there didn't even originate on Windows or the Mac to begin with. Cinema4D and Lightwave were originally Amiga programs, Maya comes from IRIX. > Quote - 2nd problem is that Poser was conceived as a virtual artist's woody; so from an architectural standpoint, it was never meant to do a fraction of the things that people try to do with it.

Be aware that programs are not buildings. While you can't change a building's fundaments without tearing the whole thing down, you can change a program's fundaments sometimes without even touching the upper levels. Look at Windows 95 vs Windows NT 4: Almost identical UI, many programs run on both systems, but fundamental layers of these systems are vastly different. > Quote - The P4 .bum file is actually a multicolor displacement map, not a grayscale jpg bump map (and ate memory accordingly).

.bum files are actually normal maps. Very hip right now for games, and are used there for the main reason why they were used in P4: They require less computation to render (no derivatives), compared to gray scale bumps. > Quote - So while it was tweaked a bit, the memory management system was still the same one from the Mac/Dos/Win era.

Now here's a fun fact: Memory management, as seen from an application, hasn't changed over the last 20 years or so, it's mostly the same as it was on the first Unix systems. You call malloc() or new when you need memory, you call free() or delete when you don't need the memory any more. That's all there is (garbage collectors or reference counters are just ways of automating those calls, and the old MacOS NewPtr() and DisposePtr() are just malloc/free wrappers on OS X). Where the operating system gets (or doesn't get) that memory from (real RAM, disk space, space alien mutant ninja turtles jelly beans) is none of the application's concern. So where do Poser 5 and 6 get the out of memory message from? Whenever it the OS rejects such a memory request. Usually because all of Poser's address space is taken by a dozen of SAT filtered textures, and that is something that happens to other, more epxensive applications as well when you try the same thing there. I won't tell you about Poser 7...yet.