Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs

On 2020-07-03 3:46 p.m., sms wrote:
On 6/23/2020 10:10 PM, Your Name wrote:

snip

With an ARM Mac, it's going to have to be emulation rather than
virtualisation. Code will have to be translated on the run, which
means it will be slower. Whether that noticeable to the user will
depend on what they're doing and how much more powerful the ARM Macs are.

Ah, shades of CMS (Code Morphing Software) to emulate an x86 on a low
powe RISC processor. Definitely a performance hit, but if you can throw
enough CPU power at it then the performance hit may be of no consequence
https://courses.cs.washington.edu/courses/cse548/08wi/papers/transmeta.pdf.


Besides performance, another issue is compatibility. I recall being at a
class where the development platform, Windows-only, was being run by
some Mac users using Bootcamp, and by some Mac users running Windows in
a virtual machine with Parallels. The latter had significant
compatibility issues in terms of the I/O ports (USB). The next time the
class was held they informed people in advance, "Windows 7 or 8 running
natively, not in a virtual machine."

The bottom line is that if you're running Windows on a Mac, using
Bootcamp is a much better solution that using a Virtual Machine.
Obviously that is going away on ARM-based Macs.

That would very much hinge on the definition of "better" for a given
purpose.

Is a Mac booted into Windows using Bootcamp going to be more perfectly
compatible with access to things such as USB ports? Of course.

But that leaves the question of whether that compatibility is important
for the purposes for which the user wants to run Windows in the first
place. For some users, the complete integration of a Windows application
into an otherwise all Mac OS environment will be much more important.

In article , sms
wrote:

With an ARM Mac, it's going to have to be emulation rather than
virtualisation. Code will have to be translated on the run, which means
it will be slower. Whether that noticeable to the user will depend on
what they're doing and how much more powerful the ARM Macs are.

Ah, shades of CMS (Code Morphing Software) to emulate an x86 on a low
powe RISC processor. Definitely a performance hit, but if you can throw
enough CPU power at it then the performance hit may be of no consequence
https://courses.cs.washington.edu/courses/cse548/08wi/papers/transmeta.pdf.

not only is that nearly two decades old, but it's not applicable to
anything apple is doing with rosetta 2.

Besides performance, another issue is compatibility. I recall being at a
class where the development platform, Windows-only, was being run by
some Mac users using Bootcamp, and by some Mac users running Windows in
a virtual machine with Parallels. The latter had significant
compatibility issues in terms of the I/O ports (USB). The next time the
class was held they informed people in advance, "Windows 7 or 8 running
natively, not in a virtual machine."

that story (assuming it's even true as described) is omitting a *lot*
of key details, such as what usb peripherals were being used and what
the 'compatibility issues' actually were.

regardless, any issues would be with parallels or its configuration,
not virtualization itself.

vmware has always worked much better with regards to compatibility.

The bottom line is that if you're running Windows on a Mac, using
Bootcamp is a much better solution that using a Virtual Machine.

not always. needing to reboot is a major inconvenience, which is why so
few people bother.

there are *very* few scenarios where virtualization won't work and boot
camp will, and that number continues to get smaller.

Obviously that is going away on ARM-based Macs.

for now.

windows on arm exists, and it's now up to microsoft to update it for
apple silicon and license it appropriately, assuming they see a demand
for it.

the number of people who actually use boot camp on a regular basis is
very low, so it's possible that they *don't* see sufficient demand to
justify it.

On 2020-07-03 22:46:06 +0000, sms said:

On 6/23/2020 10:10 PM, Your Name wrote:

snip

With an ARM Mac, it's going to have to be emulation rather than
virtualisation. Code will have to be translated on the run, which means
it will be slower. Whether that noticeable to the user will depend on
what they're doing and how much more powerful the ARM Macs are.

Ah, shades of CMS (Code Morphing Software) to emulate an x86 on a low
powe RISC processor. Definitely a performance hit, but if you can throw
enough CPU power at it then the performance hit may be of no
consequence
https://courses.cs.washington.edu/courses/cse548/08wi/papers/transmeta.pdf.


Besides performance, another issue is compatibility. I recall being at
a class where the development platform, Windows-only, was being run by
some Mac users using Bootcamp, and by some Mac users running Windows in
a virtual machine with Parallels. The latter had significant
compatibility issues in terms of the I/O ports (USB). The next time the
class was held they informed people in advance, "Windows 7 or 8 running
natively, not in a virtual machine."

The bottom line is that if you're running Windows on a Mac, using
Bootcamp is a much better solution that using a Virtual Machine.
Obviously that is going away on ARM-based Macs.

It depends on what you're trying to do, and the latest versions of
Parallels and Fusion are much better virtualisation than the early ones.

The bonus with virtualisation and emulation is that you can easily
access both Windows and Mac apps at the same time without rebooting, as
well as copy-paste information between the two. Both current
virtualisation solutions on Intel Macs even let you run Windows apps so
that they look like normal Mac apps (rather than running inside a
virtualisaed Windows PC).

As has been said, an ARM version of Windows does exist, so running that
may be a future possibility via either virtualisation and / or Boot
Camp-style, although not from Apple themselves.

On 2020-07-03 22:53:28 +0000, Alan Baker said:
On 2020-07-03 3:46 p.m., sms wrote:
On 6/23/2020 10:10 PM, Your Name wrote:

snip

With an ARM Mac, it's going to have to be emulation rather than
virtualisation. Code will have to be translated on the run, which means
it will be slower. Whether that noticeable to the user will depend on
what they're doing and how much more powerful the ARM Macs are.

Ah, shades of CMS (Code Morphing Software) to emulate an x86 on a low
powe RISC processor. Definitely a performance hit, but if you can throw
enough CPU power at it then the performance hit may be of no
consequence
https://courses.cs.washington.edu/courses/cse548/08wi/papers/transmeta.pdf.


Besides performance, another issue is compatibility. I recall being at
a class where the development platform, Windows-only, was being run by
some Mac users using Bootcamp, and by some Mac users running Windows in
a virtual machine with Parallels. The latter had significant
compatibility issues in terms of the I/O ports (USB). The next time the
class was held they informed people in advance, "Windows 7 or 8 running
natively, not in a virtual machine."

The bottom line is that if you're running Windows on a Mac, using
Bootcamp is a much better solution that using a Virtual Machine.
Obviously that is going away on ARM-based Macs.

That would very much hinge on the definition of "better" for a given purpose.

Is a Mac booted into Windows using Bootcamp going to be more perfectly
compatible with access to things such as USB ports? Of course.

But that leaves the question of whether that compatibility is important
for the purposes for which the user wants to run Windows in the first
place. For some users, the complete integration of a Windows
application into an otherwise all Mac OS environment will be much more
important.

I can't say I've ever run into port problems either for myself or when
helping customers, but then I haven't used Parallels or Fusion that
much and the latest versions capable of running Windows 10 will be much
better.

On 7/3/2020 3:53 PM, Alan Baker wrote:

snip

But that leaves the question of whether that compatibility is important
for the purposes for which the user wants to run Windows in the first
place. For some users, the complete integration of a Windows application
into an otherwise all Mac OS environment will be much more important.

Perhaps. But the people I know running Windows applications on a Mac are
running apps that need a lot of compute power. Autocad for Windows
(better than the Mac version). AVID Media Composer for Windows (better
than the Mac version). Solidworks (no Mac version). Altium (no Mac
version). There's also the question of whether the VM is able to make
full use of high-end graphics chips. "graphics performance in a VM
suffers because Windows is unable to use the native drivers and instead
has to pass everything through virtualized graphics adapters."

The bottom line is that users that bought a Macbook Pro with the intent
of running high-resource Windows applications are probably not going to
buy an ARM Macbook. Back when that whole trend started there were slim
pickings for well-designed Windows laptops, now that's no longer the
case, so it's not a big deal for most of those users. The one exception
is those that do NLE and want to use Final Cut Pro under OS-X and AVID
Media Composer under Windows.

On 2020-07-04 12:49 a.m., sms wrote:
On 7/3/2020 3:53 PM, Alan Baker wrote:

snip

But that leaves the question of whether that compatibility is
important for the purposes for which the user wants to run Windows in
the first place. For some users, the complete integration of a Windows
application into an otherwise all Mac OS environment will be much more
important.

Perhaps. But the people I know running Windows applications on a Mac are
running apps that need a lot of compute power. Autocad for Windows
(better than the Mac version). AVID Media Composer for Windows (better
than the Mac version). Solidworks (no Mac version). Altium (no Mac
version). There's also the question of whether the VM is able to make
full use of high-end graphics chips. "graphics performance in a VM
suffers because Windows is unable to use the native drivers and instead
has to pass everything through virtualized graphics adapters."

The bottom line is that users that bought a Macbook Pro with the intent
of running high-resource Windows applications are probably not going to
buy an ARM Macbook. Back when that whole trend started there were slim
pickings for well-designed Windows laptops, now that's no longer the
case, so it's not a big deal for most of those users. The one exception
is those that do NLE and want to use Final Cut Pro under OS-X and AVID
Media Composer under Windows.

You tell yourself whatever you need to...

....but learn that Apple doesn't design their product strategy around the
relatively few people who want to run high-performance Windows software
on their machines.

In article , sms
wrote:

But that leaves the question of whether that compatibility is important
for the purposes for which the user wants to run Windows in the first
place. For some users, the complete integration of a Windows application
into an otherwise all Mac OS environment will be much more important.

Perhaps. But the people I know running Windows applications on a Mac are
running apps that need a lot of compute power.

what matters is what most users do, not what people you supposedly know
might do.

Autocad for Windows
(better than the Mac version). AVID Media Composer for Windows (better
than the Mac version). Solidworks (no Mac version). Altium (no Mac
version). There's also the question of whether the VM is able to make
full use of high-end graphics chips. "graphics performance in a VM
suffers because Windows is unable to use the native drivers and instead
has to pass everything through virtualized graphics adapters."

speculation. nobody knows how well apple silicon macs will be with a vm.

The bottom line is that users that bought a Macbook Pro with the intent
of running high-resource Windows applications are probably not going to
buy an ARM Macbook.

the bottom line is you're full of ****.

people who need to run 'high-resource windows applications' buy a high
end windows desktop pc, not a laptop of any kind.

In article , JF Mezei
wrote:


not only is that nearly two decades old, but it's not applicable to
anything apple is doing with rosetta 2.

Rosetta 2 will only work to convert OS-X 64 bit libraries and map/link
system calls to a Rosetta OS-X library which will convert the Intel
calls format to ARM ad then invoke the correcpoding ARM based OS-X
system call.

you snipped to alter context again.

my comment was for paul, who has a g4 powermac from 2001 or
thereabouts, which is not in any way relevant to rosetta 2 or even the
original rosetta.