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

On 2020-06-24 6:53 p.m., Arlen Holder wrote:
On Wed, 24 Jun 2020 14:40:57 -0000 (UTC), Arlen Holder wrote:

The only native known alternative is payware to do the same thing.

Correction:

I should note that even the payware described in the news article for the
new Mac ARM, doesn't do the same thing as did the freeware on the old Mac
(they're quite different functionalities, actually).

No, actually.

In functionality they are virtually (see what I did there?) identical.


Hence, in this case, until/unless a freeware solution is found for the new
Mac ARM, the article's lament appears to be valid that the new Mac ARM will
simply lose this freeware functionality that was ubiquitous on the old Mac.

Having had freeware dual boot capabilities on Windows/Linux for so long I
can't remember, I can't imagine that the Mac ARM users are happy losing
basic functionality that puts Mac ARM users back in the Stone Age of
computing without it.

And they're not losing it.

On 2020-06-24 9:46 p.m., Paul wrote:
Char Jackson wrote:
On Wed, 24 Jun 2020 20:17:57 -0400, Paul wrote:

Alan Baker wrote:
On 2020-06-24 7:38 a.m., Arlen Holder wrote:
On Wed, 24 Jun 2020 10:24:50 -0400, nospam wrote:

apple didn't orphan anything.
Hi nospam,

As Paul just now eloquently exasperated...
o *In one swoop, _all_ your software no longer runs native on the
ARM Mac.*
But if it runs just as well...

...why would you care?
If you've ever run heterogenous VMs, you'll know
what to expect.

They can run at 0.1x to 0.01x of the native clock speed.

Huh?? Wow, if that's your experience, it's no wonder that you have a dim
view of the situation. That's not my experience at all. I wonder if that
poor performance is limited to VirtualBox or something.

This would be running an x86 Windows OS on a PowerPC platform.
Yes, it's slow.

Â*Â* Paul


That was done with a product called "VirtualPC" was it not?

In article , Alan Baker
wrote:

On 2020-06-24 9:46 p.m., Paul wrote:
This would be running an x86 Windows OS on a PowerPC platform.
Yes, it's slow.



That was done with a product called "VirtualPC" was it not?

in another post, he mentioned softpc, which was slower than virtual pc.

it's also not relevant for running mac apps on a mac with a different
processor.

On 2020-06-25 11:37 a.m., nospam wrote:
In article , Alan Baker
wrote:

On 2020-06-24 9:46 p.m., Paul wrote:
This would be running an x86 Windows OS on a PowerPC platform.
Yes, it's slow.



That was done with a product called "VirtualPC" was it not?

in another post, he mentioned softpc, which was slower than virtual pc.

Either way, they both suffered from the fact that they did emulation
on-the-fly...

....and they were emulating a processor which was typically faster than
the processor on which they were being run.

:-)


it's also not relevant for running mac apps on a mac with a different
processor.


Agreed.

Alan Baker wrote:
On 2020-06-25 11:21 a.m., Frank Slootweg wrote:
JF Mezei wrote:
On 2020-06-24 15:12, nospam wrote:

windows on arm already exists, although x86 emulation sucks.

Windows NT was also available on Alpha. and Windows was available on
Itanic as well. Application ecosystem never materialized and the
platforms were dropped. (and Itanic never gave performance edge )

As you say, Windows on non-x86/non-x64 has never materialized to any
relevant extent. (The HP-PA version was another failure missing on your
list. Or did you mean HP-PA when you mentioned Itanium?)

Not sure how well/complete the port of Windows 10 to ARM is. But if
Apple gets a serious performance edge on its own chip vs 8086, you'll
see Qualcomm and perhaps AMD start to make desktop version of ARM chips
and Microsoft deciding that this is the new standard.

I think an ARM-only Windows is extremely unlikely to happen. There's
way too much 'legacy' code out there. And no, re-compiling, let alone
porting, is not going to cut the mustard.

There already is a version of Windows for ARM:

https://docs.microsoft.com/en-us/windows/arm/

A quick look shows only 'How x86 emulation works on ARM'. What about
x64? And what about x64 UWP apps (assuming there are such beasts (I'm
not into UWP apps))?

And if you don't mind, I've seen similar documentation for the
earlier non-x86/non-x64 platforms mentioned above. Until I see it and
see reports from users with x86/x64 'legacy' code, I go by the (below
mentioned) (non-)track record.

But yeah, that will depend on MS having a good translator for apps.

I hope that with 'translator' you mean a run-time environment which
can run unchanged non-x86/non-x64 code (i.e. things like .exe, .dll,
etc.).

Their 'track record' for the last 20 odd years has been 'sub-optimal'
to put it mildly. But yes, it *can* be done. The question is, can
Microsoft do it?

On 2020-06-25 12:14 p.m., Frank Slootweg wrote:
Alan Baker wrote:
On 2020-06-25 11:21 a.m., Frank Slootweg wrote:
JF Mezei wrote:
On 2020-06-24 15:12, nospam wrote:

windows on arm already exists, although x86 emulation sucks.

Windows NT was also available on Alpha. and Windows was available on
Itanic as well. Application ecosystem never materialized and the
platforms were dropped. (and Itanic never gave performance edge )

As you say, Windows on non-x86/non-x64 has never materialized to any
relevant extent. (The HP-PA version was another failure missing on your
list. Or did you mean HP-PA when you mentioned Itanium?)

Not sure how well/complete the port of Windows 10 to ARM is. But if
Apple gets a serious performance edge on its own chip vs 8086, you'll
see Qualcomm and perhaps AMD start to make desktop version of ARM chips
and Microsoft deciding that this is the new standard.

I think an ARM-only Windows is extremely unlikely to happen. There's
way too much 'legacy' code out there. And no, re-compiling, let alone
porting, is not going to cut the mustard.

There already is a version of Windows for ARM:

https://docs.microsoft.com/en-us/windows/arm/

A quick look shows only 'How x86 emulation works on ARM'. What about
x64? And what about x64 UWP apps (assuming there are such beasts (I'm
not into UWP apps))?


https://www.techradar.com/news/windows-10-on-arm-is-set-to-become-more-useful-with-emulation-for-traditional-64-bit-apps

And if you don't mind, I've seen similar documentation for the
earlier non-x86/non-x64 platforms mentioned above. Until I see it and
see reports from users with x86/x64 'legacy' code, I go by the (below
mentioned) (non-)track record.
But yeah, that will depend on MS having a good translator for apps.

I hope that with 'translator' you mean a run-time environment which
can run unchanged non-x86/non-x64 code (i.e. things like .exe, .dll,
etc.).

Their 'track record' for the last 20 odd years has been 'sub-optimal'
to put it mildly. But yes, it *can* be done. The question is, can
Microsoft do it?


You said:

'I think an ARM-only Windows is extremely unlikely to happen.'

You were clearly wrong.

Not only because of what I already showed you...

....but because there is already at least one machine you can buy that is
running Windows 10 on ARM:

https://www.microsoft.com/en-us/surface/business/surface-pro-x/processor

Now do the mature thing, and just admit you were wrong.

On 2020-06-25 18:34:55 +0000, Alan Baker said:
On 2020-06-24 9:46 p.m., Paul wrote:
Char Jackson wrote:
On Wed, 24 Jun 2020 20:17:57 -0400, Paul wrote:
Alan Baker wrote:
On 2020-06-24 7:38 a.m., Arlen Holder wrote:
On Wed, 24 Jun 2020 10:24:50 -0400, nospam wrote:

apple didn't orphan anything.
Hi nospam,

As Paul just now eloquently exasperated...
o *In one swoop, _all_ your software no longer runs native on the ARM Mac.*
But if it runs just as well...

...why would you care?
If you've ever run heterogenous VMs, you'll know
what to expect.

They can run at 0.1x to 0.01x of the native clock speed.

Huh?? Wow, if that's your experience, it's no wonder that you have a dim
view of the situation. That's not my experience at all. I wonder if that
poor performance is limited to VirtualBox or something.

This would be running an x86 Windows OS on a PowerPC platform.
Yes, it's slow.

** Paul

That was done with a product called "VirtualPC" was it not?

Even back in the 68K Mac era there was SoftPC (later renamed RealPC),
but VirtualPC was the best known product for Windows emulation.

There also used to be add-on cards to give Windows capability (Apple
even sold a Mac with one built-in) - basically a whole PC on a card.

On 2020-06-25 1:40 p.m., Your Name wrote:
On 2020-06-25 18:34:55 +0000, Alan Baker said:
On 2020-06-24 9:46 p.m., Paul wrote:
Char Jackson wrote:
On Wed, 24 Jun 2020 20:17:57 -0400, Paul wrote:
Alan Baker wrote:
On 2020-06-24 7:38 a.m., Arlen Holder wrote:
On Wed, 24 Jun 2020 10:24:50 -0400, nospam wrote:

apple didn't orphan anything.
Hi nospam,

As Paul just now eloquently exasperated...
o *In one swoop, _all_ your software no longer runs native on the
ARM Mac.*
But if it runs just as well...

...why would you care?
If you've ever run heterogenous VMs, you'll know
what to expect.

They can run at 0.1x to 0.01x of the native clock speed.

Huh?? Wow, if that's your experience, it's no wonder that you have a
dim
view of the situation. That's not my experience at all. I wonder if
that
poor performance is limited to VirtualBox or something.

This would be running an x86 Windows OS on a PowerPC platform.
Yes, it's slow.

Â*Â* Paul

That was done with a product called "VirtualPC" was it not?

Even back in the 68K Mac era there was SoftPC (later renamed RealPC),
but VirtualPC was the best known product for Windows emulation.

There also used to be add-on cards to give Windows capability (Apple
even sold a Mac with one built-in) - basically a whole PC on a card.



Yup.

Since I worked as a sales rep at a Mac dealer during those days, I know
all of it very well.

:-)

Alan Baker wrote:
On 2020-06-25 12:14 p.m., Frank Slootweg wrote:
Alan Baker wrote:
On 2020-06-25 11:21 a.m., Frank Slootweg wrote:
JF Mezei wrote:
On 2020-06-24 15:12, nospam wrote:

windows on arm already exists, although x86 emulation sucks.

Windows NT was also available on Alpha. and Windows was available on
Itanic as well. Application ecosystem never materialized and the
platforms were dropped. (and Itanic never gave performance edge )

As you say, Windows on non-x86/non-x64 has never materialized to any
relevant extent. (The HP-PA version was another failure missing on your
list. Or did you mean HP-PA when you mentioned Itanium?)

Not sure how well/complete the port of Windows 10 to ARM is. But if
Apple gets a serious performance edge on its own chip vs 8086, you'll
see Qualcomm and perhaps AMD start to make desktop version of ARM chips
and Microsoft deciding that this is the new standard.

I think an ARM-only Windows is extremely unlikely to happen. There's
way too much 'legacy' code out there. And no, re-compiling, let alone
porting, is not going to cut the mustard.

There already is a version of Windows for ARM:

https://docs.microsoft.com/en-us/windows/arm/

A quick look shows only 'How x86 emulation works on ARM'. What about
x64? And what about x64 UWP apps (assuming there are such beasts (I'm
not into UWP apps))?

https://www.techradar.com/news/windows-10-on-arm-is-set-to-become-more-useful-with-emulation-for-traditional-64-bit-apps

Thanks.

That leaves the x64 (and x86?) UWP apps. (What the article talks about
are traditional x64 programs (the example given was Adobes Premiere Pro),
not UWP apps).

And, as we don't know anything about the rest of the architecture of
this "new standard" - i.e. ARM is just the CPU -, there's the tiny issue
of the HAL (if that still is used), drivers, etc., etc.. (AFAIK, an ARM
processor does not automatically define a certain I/O system, etc..)

And if you don't mind, I've seen similar documentation for the
earlier non-x86/non-x64 platforms mentioned above. Until I see it and
see reports from users with x86/x64 'legacy' code, I go by the (below
mentioned) (non-)track record.
But yeah, that will depend on MS having a good translator for apps.

I hope that with 'translator' you mean a run-time environment which
can run unchanged non-x86/non-x64 code (i.e. things like .exe, .dll,
etc.).

Their 'track record' for the last 20 odd years has been 'sub-optimal'
to put it mildly. But yes, it *can* be done. The question is, can
Microsoft do it?


You said:

'I think an ARM-only Windows is extremely unlikely to happen.'

You were clearly wrong.

Nope. You again read out-of-context/not-for-comprehension.

Not only because of what I already showed you...

...but because there is already at least one machine you can buy that is
running Windows 10 on ARM:

https://www.microsoft.com/en-us/surface/business/surface-pro-x/processor

Now do the mature thing, and just admit you were wrong.

And because you are again acting like an obnoxious pompous prat, I'm
not going to explain your misinterpretation.

OTOH, being the nice guy that I am, I already gave you another clue.

On 2020-06-26 5:22 a.m., Frank Slootweg wrote:
Alan Baker wrote:
On 2020-06-25 12:14 p.m., Frank Slootweg wrote:
Alan Baker wrote:
On 2020-06-25 11:21 a.m., Frank Slootweg wrote:
JF Mezei wrote:
On 2020-06-24 15:12, nospam wrote:

windows on arm already exists, although x86 emulation sucks.

Windows NT was also available on Alpha. and Windows was available on
Itanic as well. Application ecosystem never materialized and the
platforms were dropped. (and Itanic never gave performance edge )

As you say, Windows on non-x86/non-x64 has never materialized to any
relevant extent. (The HP-PA version was another failure missing on your
list. Or did you mean HP-PA when you mentioned Itanium?)

Not sure how well/complete the port of Windows 10 to ARM is. But if
Apple gets a serious performance edge on its own chip vs 8086, you'll
see Qualcomm and perhaps AMD start to make desktop version of ARM chips
and Microsoft deciding that this is the new standard.

I think an ARM-only Windows is extremely unlikely to happen. There's
way too much 'legacy' code out there. And no, re-compiling, let alone
porting, is not going to cut the mustard.

There already is a version of Windows for ARM:

https://docs.microsoft.com/en-us/windows/arm/

A quick look shows only 'How x86 emulation works on ARM'. What about
x64? And what about x64 UWP apps (assuming there are such beasts (I'm
not into UWP apps))?

https://www.techradar.com/news/windows-10-on-arm-is-set-to-become-more-useful-with-emulation-for-traditional-64-bit-apps

Thanks.

That leaves the x64 (and x86?) UWP apps. (What the article talks about
are traditional x64 programs (the example given was Adobes Premiere Pro),
not UWP apps).

And, as we don't know anything about the rest of the architecture of
this "new standard" - i.e. ARM is just the CPU -, there's the tiny issue
of the HAL (if that still is used), drivers, etc., etc.. (AFAIK, an ARM
processor does not automatically define a certain I/O system, etc..)

And if you don't mind, I've seen similar documentation for the
earlier non-x86/non-x64 platforms mentioned above. Until I see it and
see reports from users with x86/x64 'legacy' code, I go by the (below
mentioned) (non-)track record.
But yeah, that will depend on MS having a good translator for apps.

I hope that with 'translator' you mean a run-time environment which
can run unchanged non-x86/non-x64 code (i.e. things like .exe, .dll,
etc.).

Their 'track record' for the last 20 odd years has been 'sub-optimal'
to put it mildly. But yes, it *can* be done. The question is, can
Microsoft do it?


You said:

'I think an ARM-only Windows is extremely unlikely to happen.'

You were clearly wrong.

Nope. You again read out-of-context/not-for-comprehension.

There is no context or interpretation that will make something that has
already happened into something "extremely unlikely to happen."

Sorry.


Not only because of what I already showed you...

...but because there is already at least one machine you can buy that is
running Windows 10 on ARM:

https://www.microsoft.com/en-us/surface/business/surface-pro-x/processor

Now do the mature thing, and just admit you were wrong.

And because you are again acting like an obnoxious pompous prat, I'm
not going to explain your misinterpretation.

That is a convenient excuse for you, yes.


OTOH, being the nice guy that I am, I already gave you another clue.

Update: (dateline today) (all verbatim)

"No more Windows on Mac, for now"

o *Apple will kill off Boot Camp with new ARM-based Macs*
https://thenextweb.com/plugged/2020/06/26/apple-will-kill-off-boot-camp-with-new-arm-based-macs/

"Apple revealed it does not plan to support Boot Camp
on its upcoming ARM-based Macs."

Apple claims "the need to direct boot shouldn't really be the concern"

"you won't be able to run them [Windows] natively upon boot"

"if you regularly have to run Windows on your Mac for work or otherwise,
you'll want to think twice before ponying up the dough for
[the Mac ARM]"
--
The lack of this freeware knocks the Mac ARM back into the Stone Age.

UPDATE: Dateline today (all verbatim).

"You'll no longer be able to dual-boot Windows 10 on your Mac."

o *You Can Forget About Dual-Booting Windows on ARM-Based Macs, For Now*
https://www.tomshardware.com/news/you-can-forget-about-dual-booting-windows-on-arm-based-macs-for-now

"Microsoft only licenses Windows 10 on ARM to OEMs."

"If you're thinking "Okay, so Microsoft won't license it, but I can just
tinker it together, right?" -- let us stop you in your tracks too."
--
The Mac ARM puts users back into the Stone Age of dual-boot functionality.

On 2020-06-26 5:39 p.m., Arlen Holder wrote:
UPDATE: Dateline today (all verbatim).

"You'll no longer be able to dual-boot Windows 10 on your Mac."

o *You Can Forget About Dual-Booting Windows on ARM-Based Macs, For Now*
https://www.tomshardware.com/news/you-can-forget-about-dual-booting-windows-on-arm-based-macs-for-now

"Microsoft only licenses Windows 10 on ARM to OEMs."

"If you're thinking "Okay, so Microsoft won't license it, but I can just
tinker it together, right?" -- let us stop you in your tracks too."


"For Now"

"Of course, today's plans don't set a precedent for future plans. It's
very possible that Apple will port Boot Camp to ARM at some point, or
that someone from the community will create a bootloader for the
ARM-based Macs."

Why is it you always omit the bits that contradict your narrative?

On 2020-06-26 5:33 p.m., Arlen Holder wrote:
Update: (dateline today) (all verbatim)

"No more Windows on Mac, for now"

o *Apple will kill off Boot Camp with new ARM-based Macs*
https://thenextweb.com/plugged/2020/06/26/apple-will-kill-off-boot-camp-with-new-arm-based-macs/

"Apple revealed it does not plan to support Boot Camp
on its upcoming ARM-based Macs."

Apple claims "the need to direct boot shouldn't really be the concern"

"you won't be able to run them [Windows] natively upon boot"

"if you regularly have to run Windows on your Mac for work or otherwise,
you'll want to think twice before ponying up the dough for
[the Mac ARM]"


Yes: "for now".

'In the podcast, Apple exec Craig Federighi said “purely virtualization
is the route, but these hypervisors can be very efficient, so the need
to direct boot shouldn’t really be the concern.� In other words, you’ll
be able to run some operating systems with software like Parallels, but
you won’t be able to run them natively upon boot. As far as we can tell,
Boot Camp will be no more.'

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.