For what it's worth, I'm running 10.2.8 and Poser 5 with no problems at all. Muchly improved over running Poser 4 in Classic! You might also try running the Disk Utility, switch to the "First Aid" tab, and repair the permissions on your disk. That has been known to solve some odd pickles into which applications can get themselves.

"The new G5 is out of the question too because it won't support OS9."

So who needs OS9, anyway? Even Poser, the behindest of the behind, has finally entered the 21st century. (Although I'm holding out until I can get media.) In any case, most OS9 apps (including Poser 4) run fine in Classic; and should be just fine on the new systems.

(Although, if this is an elementary school, there might be ancient "educational" games, many of which were really cheaply and poorly coded and don't work in Classic... which is why my 6 year old's iMac is still booted in OS9 while the rest of the house is OSX.)

took me 15 mins to download poser 5 on comcast cable.

The CL readme estimates 66 minutes for the whole thing at 1500Kbs, which is a pretty good cable/DSL speed. I haven't bothered to check the math. In any case, you obviously have a wider pipe than most people. Nice for you, but I've never measured my Adelphia cable at more than about 800Kbs. Besides, I do like having a printed manual to read away from the computer, and I'm not about to print the PDF on my inkjet.

Yeah... but only "electronic delivery". Even with cable Internet, an 800Mb download (install + content "CD") is a bit on the heavy side!

Maybe I'll wait for the box...

"Sometimes you have to trick Poser into letting you open other apps" I just accidentally found a nice workaround for this. I recently started using the iPulse performance monitor, which can be set to stay above all application windows (and, on my system, is so set). This works even for Classic apps like Poser, and always gives me a non-Classic window on which I can click. That make the dock visible and active, and switching away from Poser is now trivial. iPulse is shareware in which you might not want to invest just to solve this problem if it doesn't otherwise intrigue you. On the other hand, anything that can manage a window that stays in front ought to provide the same benefit.

Hmm. I've been using Poser all along. Originally, I added Mac OS X onto an existing system, with a pre-existing Poser install. I did install Mac OS X onto a new partition rather than over the existing Mac OS 9 partition, though that "shouldn't" make any difference.

Now I'm using it on a new system that came with Mac OS X. However, I never actually "installed" Poser on it, which may or may not make a difference. I just copied the entire Poser 4 folder tree onto the new system. (I, too, wasn't willing to try to reinstall all the stuff I've accumulated over the years!)

Do you have OTHER Classic applications that are working, or do you perhaps have some more general problem with your Classic setup?

"What methods are other people who have switched to OSX for most of their programs using to still be able to use Poser 4"

Poser 4 runs fine in Classic mode under Mac OS X, despite not being formally supported. Poser was never a "well behaved" OS 9 application anyway, and that makes it an even quirkier Classic citizen. But it works. The only oddity I've encountered is that switching away from Poser during a render is "awkward". It tries hard to pretend you're running OS 9, though I can usually manage when I fiddle. (And Poser won't refresh the window, if you switch back, until the render is done.)

"There's no problem with ansi C in windows"

Nor on any platform with an ANSI C compiler environment, if you're only interested in API. But that wasn't my point. It's EASY to port that way, but it's usually not the most EFFICIENT port on any system that's not inherently a POSIX/ANSI C environment. Linux, Mac OS X, Solaris, IRIX, HP-UX, Tru64 UNIX, Free/Net BSD, and so forth ARE, and most code can't do better than the ANSI/POSIX interfaces.

On most other systems, like Windows, Mac OS 9, OpenVMS, OS/400, and so forth, the standard API is usually a wrapper that adds overhead to the basic function and may involve expensive and tedious translation, or multiple native OS calls that are needed to meet the portable API but NOT needed to achieve what you're actually trying to do.

If the call isn't critical to application performance, some overhead may be fine. If it is critical the portable interfaces may be a bad porting strategy.

Again... I'm speaking in general, not specific, and this argument is getting increasingly pointless and off track. ;-)

"This part is a very easy one (compared to the 3d processing)."

Most people who think that tend to develop really bad interfaces. But yes, in this context my answer was probably overly general. Your statement may be more nearly true for an "oddball" program like Poser, with the Metacreations "unique" style interface. They still define system menus, but virtually everything else is custom, presumably built on lower level graphics operations.

While you CAN use standard ANSI C or C++ runtime functions for I/O and memory management, that's not always the best choice for systems that aren't inherently standard-based. On Windows and Mac OS 9, for example, those functions have to be EMULATED by building standard-interface wrapper functions around the proprietary equivalents. The equivalents are never quite close enough, and often the wrappers end up being complicated and expensive. Not necessarily the best choice for an application that's already resource hungry.

This wouldn't be an issue for a UNIX API app that might run on Mac OS X and other UNIX systems, since they are standard-based; but as I said, the CL statements so far suggest they're likely to go with Carbon interfaces. While they might reconsider that in the wake of recent Apple announcements, they are presumably starting from the Poser 4 Mac OS 9 code, which is essentially Carbon, and they're unlikely to start over again from scratch. (Consider already the complaints that Poser 5 Windows is a "retread" of Poser 4 with some plugins. True or not, it suggests that much of the central code has been retained.)

The problem is that the biggest part of the port isn't in the basic platform code, it's in the GUI.

Yes, Mac OS X is a BSD-based UNIX, and Poser could in theory use straight UNIX coding for file I/O, memory management, and all the other utility functions. However, to run on Linux or FreeBSD (or even a straight Darwin) they'd need to build their GUI around an X11 model; while to run on Mac OS X they'd be using Quartz (and ideally OpenGL, but from what we've heard they're not initially doing real 3D screen output).

[You can run X11 on Mac OS X, but it looks really poor next to native Aqua applications, and it'd be foolish for any commercial Mac product to go that way. It does make sense for free Open Source applications, in some cases, but only because it's easier to port the code that way and in most cases nobody's going to invest the time and money to do it right.]

Furthermore, going "UNIX" would mean abandoning support for Mac OS 9 -- or supporting yet another substantially different code base to do it differently.

So far, the writing on the wall seems to be that the Mac Poser (if it ever really happens) will be Carbon, not Cocoa or UNIX -- that is, it'll use the improved versions of the traditional Mac toolbox that can be made to work both on Mac OS 9 and Mac OS X. A Carbon application cannot be made to work on Darwin, Linux, *BSD, Sun, etc. It's Mac-specific just as the Windows version is Windows-specific.

They could certainly do a third UNIX/X11 version, if there's enough demand. If they stick with POSIX and portable X11 interfaces, they should be able to build it for just about any UNIX. It's not a trivial job, though; and adding extra UNIX versions isn't just about recompiling... the big cost is in testing and deployment.

"There are a number of entities that appear to be convinced that M$ is a Monopoly." First, that's not at issue. It's been proven in court that Microsoft IS a Monopoly; and anyone with any knowledge at all of the market has to agree. It's simply common sense. There's nothing inherently illegal about BEING a Monopoly; but it's also been proven in court that Microsoft has ILLEGALLY used its Monopoly power to advance its own fortunes at the expense of others. The only problem is that they hold so much political power that the government isn't willing to stop them. The Mac represents a big profit center for Microsoft. They realised that sales were slipping because Microsoft products for the Mac had become trivial ports of the Windows versions; and that's simply unacceptable in the Mac market where usability and interface elegance are far more important. So they created an entire Mac product group to focus on developing Microsoft technologies into Mac native products that are equal to (and by many reports sometimes better than) the Windows versions. That's just not the behavior of someone who'd like to abandon a market, so you can forget about that story. If they were supporting the Mac under duress, or didn't believe they were recouping their investment, you can be certain a business savvy company like Microsoft would be, at best, continuing to ship cheap Windows knockoff ports. This is all just basic business -- it's got nothing to do with platform religion. Apple might do something that violated common business sense, but it's highly unlikely that Microsoft ever would; their entire company has been based on business and nothing but. Besides, Chimera is a better web browser, and OpenOffice.org is a far better office environment. The "need" for Microsoft is smoke and mirrors. Losing the Mac market won't hurt Microsoft much -- but ultimately losing Microsoft won't hurt Apple much, either. In the meantime, the "uneasy peace" is good for both of them, and they know it. Apple sure does need a faster machine -- but the ones out are plenty fast for nearly any application; and the next move is up to Motorola -- or perhaps IBM, which has shown much more commitment to the PowerPC. (And PowerPC is a far better architecture than than X86 or even IPF... the problems have been in chip production technology.) The latest Apple machines do DDR RAM -- but are hamstrung by the PowerPC chip interfaces to far less throughput than that should represent. New versions of G4 will solve the problem. It's amazing how anytime someone says the word "Macintosh" hordes of Wintel people charge to the attack. Feeling defensive? If not, just leave it alone, OK? You're not going to convince anyone, and you're just making yourselves look silly.

CL has been saying all along that they were going to do a Mac version that will run on Mac OS X and Mac OS 9. The current announcement is that they expect to announce "soon" when it will be available. They've been saying that for quite a while now, so "soon" is clearly a fairly relative and unbounded time. Still, they at least have basically good intentions. They've passed out some suggestions that they don't have programmers familiar with Carbon interfaces (which are slightly different from the old OS 9 toolbox) and that they were having some difficulties with their porting efforts. (With no details, it's hard to know how to take that.) A month ago, remember, (or at least I do), that the Windows people were expressing the same concerns about the Windows version. CL kept saying "soon", and "trust me", and at that point the CL web site hadn't even been updated in over a year. Clearly CL has been going through some difficult times. What they're trying to accomplish is ambitious in the first place. They've got lots of Windows version bugs to find and fix, and I won't mind at all having them finish that before they release the Mac version. (It's bad enough we have to wait: but I'd hate to have to wait and then go through all the same initial problems the Windows guys had because CL did the Mac port before fixing them.) So just hang on a bit, and we'll see what happens.

Or that if they had to format their HD and do a re-install they would have to re-activate; which while technically correct, they would already have the code to activate without ANY contact with CL.

Yes, but the "challenge" is tied to the disk. (Perhaps using its hardware serial number?). You don't need to get a new response code from CL after reformatting, but you do if you replace the drive. Even if you keep the same computer for a few years that tiny 120Gb drive is likely to start feeling cramped after all those hi-rez raytraced Poser pics you've generated. ;-)
I can understand a concern over what happens if CL goes under. On the other hand, there's already evidence that the code has been cracked... in which case options remain. (If CL does go under, and you bought a copy, then using a cracked version could hardly be called illegal -- or even immoral.)

In the "big software" world, where large companies are betting their business on software from some vendor whose future they doubt, the critical info (often including the full product source code, and certainly information to get around security measures) are escrowed somewhere, to be released "in the event". Now, if CL is strapped for cash they probably wouldn't consider that now. On the other hand, if they're serious, this is something that would ease many of the legitimate concerns.

Meanwhile, despite how much I'd love to get my hands on P5, I get the luxury of just sitting around and watching how all the hubbub settles out. They don't even want my money yet, because they aren't taking Mac preorders.

"memory priority"

Sorry; I'm not a Windows person, which is why I was able to guess wrong about the meaning of the summary information. I know a lot about virtual memory from my experience with UNIX kernels. (Poser is a hobby; I'm a UNIX system software developer in "real life".) The performance of Poser 5 has been a subject of several discussions recently here on Renderosity, though, and several people have claimed success with "increasing the memory priority". So I just repeated that. If that's wrong, I could apologize for passing it on without caveats, but there's not much point in that.

Perhaps those people were misinterpreting the significance of raising the "priority" (general purpose) of the Poser task. On the other hand, it's equally possible that Windows does give higher "memory priority" to tasks with generally higher priority. It'd make some sense, since "raising priority" is something one generally does for realtime applications, where response latency is critical. In conjunction with that, on UNIX, one typically "locks" the application into the working set (and the working set into physical memory). "Memory priority" would actually be a pretty good way to approximate some of that with less system impact.

In any case; as I said, it's worth a try.

"INVALID page faults, on the other hand, make your application or system crash."

Well, yeah; but then they're GPC faults, not "page faults", and they don't get counted the same way! > "This systems has 1/2 GB RAM and two 1GB page files."

Ah; OK, I misinterpreted the summary. Looks in that case like you're probably using all your physical memory; but Poser only has about half of that. Raising the memory priority may well convince Windows to give that process "more than its share". Worth trying, anyway. Of course -- you might also consider buying another 512Mb RAM. It's not that expensive now, and well worthwhile.