On 26 Nov 2005 at 22:42, Johannes Gebauer wrote: > On 26.11.2005 Simon Troup wrote: > > I don't really think I need to explain why configuring an OS within > > an emulator in another OS is unattractive. I've used Virtual PC with > > Win 98 SE, Win XP and Win 2000 - it's buggy and has a tremendous > > performance hit, things don't work at anything like native windows > > speed. > > the whole point of Virtual PC on Intel Macs is that it will run in > native mode on the Mac processor, so the performance hit is not > present.
Well, if you think about it, it can't really do that. What if an OS X app and a VPC app try to access the same hardware or memory at the same time? VPC would always have to be a slave of OS X. Now, it could be that Intel underneath OS X could provide enough performance improvement to make VPC much snappier, but I don't think there'd ever be any real possibility of VPC being able to go direct to the hardware, since VPC wouldn't know anything about what OS X is doing. Of course, maybe it's possible to have a "traffic cop" layer between VPC and OS X, and have VPC say to the traffic cop "can I have access to the video interface so I can paint the screen?" and the VPC traffic cop layer would say "sure -- you can paint in these areas of the screen, and I'll tell your host OS to take a break until you're done". I don't know if that kind of thing would be possible or not, but it would be the only way to actually get the kind of benefit you seem to be thinking will be automatic for VPC. And, of course, when I say "direct to hardware" I'm being very loose with terminology, as no modern OS allows applications direct access to hardware in the first place (every modern OS has a hardware abstraction layer that the OS and apps communicate with, and the HAL runs at a very low level of the OS, communicating with the interfaces that talk to the actual hardware, which would be interrupts on Intel and who knows what approach on PPC). In any event, I can't see how there is any way that VPC would be anything other than a child process of OS X and, thus, restricted to the same hardware and memory restrictions as any other process running on OS X. That would mean no direct hardware access at all, and the need for the same translation layer under VPC to convert to OS X calls that is needed today when VPC is running on OS X on top of a PPC. > This whole discussion has begun to turn around in circles now. I think it's pretty clear what you've been saying. I just don't think it's very likely that VPC will benefit as much from the conversion as you suggest it might. In a certain sense, it's no different than the virus question -- viruses don't run on the hardware but on the OS, so MacIntel doesn't change OS X's level of vulnerability at all. Likewise, since VPC is still running on top of OS X, it won't be able to communicate directly with hardware, so there won't be any real change in its performance, except if OS X itself already gets a boost from running on Intel. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
