virtual pc for carbon
- Thread starter flaggrrl
- Start date
jove
Member
Those \"bunch of idiots\" are creating a version of VPC that will theorietically run similar to Classic in X. Imagine no more virtual monitor in a window!
In VPC4 you can execute multiple OS environments at once, i.e. Linux in one window, and Windows in another. Now imagine that architecture without the current window confines. We should be able to layer and work with docs and apps from various OSs at once in the same \"screen\"!
Yeah, bunch of idiots.
In VPC4 you can execute multiple OS environments at once, i.e. Linux in one window, and Windows in another. Now imagine that architecture without the current window confines. We should be able to layer and work with docs and apps from various OSs at once in the same \"screen\"!
Yeah, bunch of idiots.
That\'s even worse than not having it carbonized. How the hell are you supposed to tell you windows apart in three different OSs. And how are you supposed to do configuration of the Operating System? Classic does not have such a problem because you can get at control panels and usch on the hard disk. With Virtual PC using disk images, you cannot do this, based on what you have said. That is a system that makes no sense!
jove
Member
How is this any different than Classic in X?
Classic windows are Platinum, not Aqua. Similarly, and this is all conjecture, that Win32 windows will look like, well, M$ Windows.
Classic in X consists of two applications - the Classic App and TrueBlue. The Classic App has facilities to customize the emulation and TrueBlue, the emulator, gives access to the native control panels. Why can\'t VPC do something similar? They already are.
Connectix may decide not to create the fabled \"red box\" as I suggested. The only real issues are UI. Where does the \"Start Menu\" go or does it support Window\'s desktop pictures, and etc? If connective can figure out a reasonable solution to the task bar - then the user can access the control panels.
>With Virtual PC using disk images
Disk images, under X, will not limit functionality. It will behave no differently than the Sys9 partition most users have.
When all said and done - VPC may still sit in an emulator window. I believe X offers enough support where this is unnecessary.
Have you actually carbonized an application? Most high level apps are fairly easy. VPC does not run on that level. To gain the speed it needs, it most likely bypasses the now supported Carbon APIs. Carbonizing a tool like VPC is a major undertaking. They plan, like most companies, to ship native when X becomes final. Even Intuit is denying that Quicken 2001 is carbonized. Many companies do not want to support products for a beta OS.
VPC for X may even not be Carbon (speed reasons). If not, then it is a total rewrite. Calling the talented engineers at Connective idiots is, well, idiotic; especially when neither you nor I have any idea what the code looks like.
Classic windows are Platinum, not Aqua. Similarly, and this is all conjecture, that Win32 windows will look like, well, M$ Windows.
Classic in X consists of two applications - the Classic App and TrueBlue. The Classic App has facilities to customize the emulation and TrueBlue, the emulator, gives access to the native control panels. Why can\'t VPC do something similar? They already are.
Connectix may decide not to create the fabled \"red box\" as I suggested. The only real issues are UI. Where does the \"Start Menu\" go or does it support Window\'s desktop pictures, and etc? If connective can figure out a reasonable solution to the task bar - then the user can access the control panels.
>With Virtual PC using disk images
Disk images, under X, will not limit functionality. It will behave no differently than the Sys9 partition most users have.
When all said and done - VPC may still sit in an emulator window. I believe X offers enough support where this is unnecessary.
Have you actually carbonized an application? Most high level apps are fairly easy. VPC does not run on that level. To gain the speed it needs, it most likely bypasses the now supported Carbon APIs. Carbonizing a tool like VPC is a major undertaking. They plan, like most companies, to ship native when X becomes final. Even Intuit is denying that Quicken 2001 is carbonized. Many companies do not want to support products for a beta OS.
VPC for X may even not be Carbon (speed reasons). If not, then it is a total rewrite. Calling the talented engineers at Connective idiots is, well, idiotic; especially when neither you nor I have any idea what the code looks like.
Your notes about the start menu and such are exactly what i mean. You are not able to launch applications with disks set up the way that Virtual PC is set up now. You cannot mount the disk image, and therefore cannot double click an application in the Mac OS to open it. For this reason, you must have a desktop visible or a file browser of some sort. I retract my claims of these guys being idiots. I have nothing against this type of system, but this is a bit of a problem that needs to be worked out. If you can\'t launch applications, what\'s the point?
strobe
Puny Member
There are no \'speed reasons\' not to use Carbon. They use Carbon to interface with drag+drop so I\'ll bet they will still link with Carbon.
The idea of windows and OS X sharing the same windowing environment has been around for ages and I\'m still not sold if it would be productive. At least with Classic I can drag+drop between Carbon and Classic apps. I can also use the same command keys. I\'ve tried using Tenon\'s Xtools to run X11 apps but prefer a VNC window. It\'s just to confusing dealing with apps which aren\'t uniform in the same environment.
Win32 apps would have windows title bars and generally look like blue-gray crap (like they all do) so I wouldn\'t have difficulty reconigzing them, however I find it difficult to train myself to use ctrl-c to copy even with VirtualPC. I would imagine this would be more confusing if they shared the same environment.
There is one feature Classic has which VirtualPC ought to adopt. In Classic the OpenGL driver is a stub for the OS X-side OpenGL renderer (despite them being different versions of OpenGL!). Now if VirtualPC could do the same thing that would be usesul!
The idea of windows and OS X sharing the same windowing environment has been around for ages and I\'m still not sold if it would be productive. At least with Classic I can drag+drop between Carbon and Classic apps. I can also use the same command keys. I\'ve tried using Tenon\'s Xtools to run X11 apps but prefer a VNC window. It\'s just to confusing dealing with apps which aren\'t uniform in the same environment.
Win32 apps would have windows title bars and generally look like blue-gray crap (like they all do) so I wouldn\'t have difficulty reconigzing them, however I find it difficult to train myself to use ctrl-c to copy even with VirtualPC. I would imagine this would be more confusing if they shared the same environment.
There is one feature Classic has which VirtualPC ought to adopt. In Classic the OpenGL driver is a stub for the OS X-side OpenGL renderer (despite them being different versions of OpenGL!). Now if VirtualPC could do the same thing that would be usesul!
Tigger
Bring mich zum Licht!
Oh yes, there are speed reasons NOT to use carbon.
Cocoa will be much better for a program as Virtual PC. There are programs that are faster in Cocoa than Carbon.
Head over to Omniweb, and look what they have to say about Quake III.
They admit if they would have done Quake III in Cocoa, it would be about 20% faster (Would have been a great effort though, I think, to port in Cocoa).
And, the idea of windows and X sharing the same windowing environment has been around even longer!
Try: http://www.winehq.com/about.shtml
Are you an idiot? Look at how Virtual PC does things at it\'s current state. YOU CANNOT MOUNT THE WINDOWS C OR D VIRTUAL DRIVES ON THE MAC. YOU MUST BE LOOKING AT THEM IN A WINDOW FORM OR WITH A START MENU TO DOUBLE CLICK THEM. If you CAN\'T DO THIS UNDER MAC OS X and you DON\"T HAVE A START MENU, you CAN\"T LAUNCH APPLICATIONS. THINK!
IF the file is contained on a drive that you can double click it (a CD ROM for example, which you CAN mount on your Mac), then you can launch those. BUT the disk images that come with Virtual PC cannot be mounted on the Mac. Elimination of the Virtual PC Desktop without providing a way to mount their special disk images so that you can launch things inside is stupid. It is the only thing that needs to be resolved.
Long story short, the images on VPC can\'t be mounted. Other images, sure, run everthing you want off them, but some people store the info on the VPC images. If this is changing, well, that\'s fine.
jove
Member
>Are you an idiot?
Actually I had the same question about you but I wasn\'t rude enough to say it |-)
>YOU CANNOT MOUNT THE WINDOWS C OR D VIRTUAL DRIVES ON THE MAC
You are partially right. Up to and including version 3 you could. Double clicking the C drive would mount it on the Mac (but not sharable with VPC). I have tested the version 4 auto expanding drives - those do not mount. MacOS X handles drives and images VERY differently than MacOS 9. We cannot assume the same limitations are there.
>THINK!
I remember double clicking an exe file on a Mac mounted volume, VPC 3 loading up and launching the exe file. This is very similar to Classic in X.
>DON\\\"T HAVE A START MENU, you CAN\\\"T LAUNCH APPLICATIONS
Do not confuse windowing with process management. Different processes can share a windowing environment and NOT share drive images. With proper resource management you can create a system where VPC and the Mac share the same disk image. The bigger question is simply UI. Where does the start menu go? Does Windows have enough hooks to coerce it into another Windowing system?
Apple was able to coerce Classic into X via proxy. Many API calls have been turned into X calls. The Classic Finder API is a front to X\'s Finder and etc. Can Connectix replace the Window\'s \"desktop window\" with one that works with X and etc?
I am not saying this system would be easy to create - but very possible. As other posts have asked - is it worth it?
Users have to go through a shift with Classic under X (aesthetics, Apple Menu, and etc). Why not with the \"red box?\"
Actually I had the same question about you but I wasn\'t rude enough to say it |-)
>YOU CANNOT MOUNT THE WINDOWS C OR D VIRTUAL DRIVES ON THE MAC
You are partially right. Up to and including version 3 you could. Double clicking the C drive would mount it on the Mac (but not sharable with VPC). I have tested the version 4 auto expanding drives - those do not mount. MacOS X handles drives and images VERY differently than MacOS 9. We cannot assume the same limitations are there.
>THINK!
I remember double clicking an exe file on a Mac mounted volume, VPC 3 loading up and launching the exe file. This is very similar to Classic in X.
>DON\\\"T HAVE A START MENU, you CAN\\\"T LAUNCH APPLICATIONS
Do not confuse windowing with process management. Different processes can share a windowing environment and NOT share drive images. With proper resource management you can create a system where VPC and the Mac share the same disk image. The bigger question is simply UI. Where does the start menu go? Does Windows have enough hooks to coerce it into another Windowing system?
Apple was able to coerce Classic into X via proxy. Many API calls have been turned into X calls. The Classic Finder API is a front to X\'s Finder and etc. Can Connectix replace the Window\'s \"desktop window\" with one that works with X and etc?
I am not saying this system would be easy to create - but very possible. As other posts have asked - is it worth it?
Users have to go through a shift with Classic under X (aesthetics, Apple Menu, and etc). Why not with the \"red box?\"
That would explain the boy in macboy73.
You can\'t do this sort of thing currently, but there is no reason a kernel extension could not be written to do this. I can mount Toast images (just another FS in a file) on my Linux server and the server can also mount HFS, NTFS, FAT, FAT32, ISO9660, HPFS, UFS, NFS and ReiserFS volumes. This is all because of kernel extensions.
strobe
Puny Member
I think you mean OmniGroup and they never 'admit' to preferring Cocoa, they brag about using Cocoa (their whole business is based on Cocoa development.
The 20% speed gains have absolutely nothing to do with Cocoa. All Quake 3 does is use Cocoa to create the OpenGL port and gather mousing and keyboard events. Quake 3 will eventually use HID for that as well and thus can remove all Cocoa code as well.
There are no speed reasons to use Cocoa to setup an OpenGL port and gather mousing and keyboard events, you can do the same with Carbon events (not the event manager).
strobe
Puny Member
Originally posted by q And, the idea of windows and X sharing the same windowing environment has been around even longer!
Try: http://www.winehq.com/about.shtml
[/B]
Yes, we all know about WINE. No, I don't want to port WINE to OS X.
X11-based apps don't have the same potential problems I listed because X11 has no UI uniformity whatsoever. Talk to an X11 user and use words like UI uniformity he'll roll his eyes and start bitching about "you want GUI? I got your GUI right here!". Of course they are always dead wrong.
strobe
Puny Member
There seems to be a bit of FUD going around so I thought I would cleat the air.
1) I wouldn't be surprised if Apple didn't release drivers to mount Fat32 and NTFS volumes. This is basically what the MacOS 9 control panel "File Exchange" does. You can mount windows floppies and SCSI disks.
Even if Apple didn't implement such drivers any 3rd party could.
The "\" character in unix, cocoa, carbon, and classic file paths would look like ":" in windows so that's no problem.
2) The task bar is a non-issue as the winstep hack shows. You can replace the task bar and use the Dock for the same functionality (if you can interpret the disassembled code which uses the Dock in this manner, like Classic.app or appletviewer).
3) There is no reason not to use Carbon functions like the drag manager.
As far as I can see you can't reliably change the menus in windows applications so they match OS X menus. Using ctrl-c to copy in some apps and command-c in others will fry my brain. It's hard enough when windows is in a seperate window, but if they shared the same windowing environment I would go crazy. Connectix already implements drag+drop between environments, perhaps they could hack windows to implement drag+drop text from windows so people wouldn't have to use the clipboard commands.
Windows and mac apps mix like oil and water. I don't see many advantages to this idea, and I see many pitfalls.
1) I wouldn't be surprised if Apple didn't release drivers to mount Fat32 and NTFS volumes. This is basically what the MacOS 9 control panel "File Exchange" does. You can mount windows floppies and SCSI disks.
Even if Apple didn't implement such drivers any 3rd party could.
The "\" character in unix, cocoa, carbon, and classic file paths would look like ":" in windows so that's no problem.
2) The task bar is a non-issue as the winstep hack shows. You can replace the task bar and use the Dock for the same functionality (if you can interpret the disassembled code which uses the Dock in this manner, like Classic.app or appletviewer).
3) There is no reason not to use Carbon functions like the drag manager.
As far as I can see you can't reliably change the menus in windows applications so they match OS X menus. Using ctrl-c to copy in some apps and command-c in others will fry my brain. It's hard enough when windows is in a seperate window, but if they shared the same windowing environment I would go crazy. Connectix already implements drag+drop between environments, perhaps they could hack windows to implement drag+drop text from windows so people wouldn't have to use the clipboard commands.
Windows and mac apps mix like oil and water. I don't see many advantages to this idea, and I see many pitfalls.
I am calling a truce. Time to stop all the shouting. I think that we all have good points as to what needs to be done with VPC when ported to OS X, and we can all say we've contributed and call a stop to all the contradictions to each others opinions. We'll just have to see what Connectix does. They never fail to pull off a miracle.