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

[Arlen Holder]

Dateline today...

"*Boot Camp Is Dead On [all new ARM-based Macs]*"

o *Boot Camp Is Dead on New Macs and 8 Other Things Apple Didn't Say at WWDC*
<https://gizmodo.com/boot-camp-is-dead-on-new-macs-and-8-other-things-apple-1844126342>

"Apple is making a family of custom ARM-based processors for Macs,
which is a huge shift that brings with it rippling effects.

One change that some might not be too pleased about is that Boot Camp,
the free utility that allows you to dual-boot Windows and macOS,
is going away on the new Macs powered by [licensed ARM technology].

Intel-based Macs running Big Sur will still support Boot Camp,
and Apple's chips will still allow you to run virtualization technology
like Parallels to use Windows and macOS, but Parallels is not free and
runs on top of the OS while Boot Camp costs nothing and allows you to
dual, and even triple, boot on a Mac. RIP."

See also:
o Apple Plans to Announce Move to Its Own Mac Chips at WWDC [ARM, TSMC, 5nm, A14]
<https://groups.google.com/forum/#!topic/comp.sys.mac.advocacy/VFO_VL0Fwvw>
--
Keeping abreast of the news affecting users on this newsgroup.

[Alan Baker]

I've used both, and except in some very extreme edge cases, using a VM
is far, far better than using Boot Camp.

[Your Name]

On 2020-06-24 04:45:09 +0000, Alan Baker said:
> On 2020-06-23 9:38 p.m., Arlen Holder wrote:
>> Dateline today...
>>
>> "*Boot Camp Is Dead On [all new ARM-based Macs]*"
>>

<snip the usual Arlen troll anti-Apple biased garbage>

>
> I've used both, and except in some very extreme edge cases, using a VM
> is far, far better than using Boot Camp.

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.

There is a version of Windoze that runs on ARM already, which could be
a better choice since it could be virtualised ... but most reports say
the ARM Windoze isn't as good as x86 Windoze.

[Paul]

Amazing. And Magical.

Paul

[Alan Baker]

That Apple has pretty seamlessly managed:

Transitioning from Motorola...

...to PowerPC...

...to Intel...

...and now to the ARM instruction set?

Yeah... ...it is.

:-)

[Arlen Holder]

On Wed, 24 Jun 2020 02:05:40 -0400, Paul wrote:

> Amazing. And Magical.

Hi Paul,

I'm only now learning about the ARM-Mac differences from Intel-Mac.

Specificically, I'm not familiar with this now-dead "boot camp" freeware.
o However, I'm very familiar with booting to any number of OS's via Grub.

*Is this now-dead-on-ARM-Macs BootCamp freeware similar to Grub?*
o Can it boot to any number of operating systems like Grub can?

I've used Grub for many years to dual boot Windows & Linux.
o You punch in a number to boot to any number of operating systems

When you boot to Linux in a Windows/Linux configuration, you have full
access to the Windows file system (after turning off hibernation & quick
boot at initial setup) from Linux.

This complete read/write access from any number of operating systems to the
Windows file system is _extremely_ useful (e.g., to read/write the full
visible iOS file system to Windows).

*Are Grub & Boot Camp freeware essentially equivalent functionalities?*
--
MARKETING affects everyone... some far more than others.

[Alan Browne]

On 2020-06-24 01:10, Your Name wrote:
> On 2020-06-24 04:45:09 +0000, Alan Baker said:
>> On 2020-06-23 9:38 p.m., Arlen Holder wrote:
>>> Dateline today...
>>>
>>> "*Boot Camp Is Dead On [all new ARM-based Macs]*"
>>>
> <snip the usual Arlen troll anti-Apple biased garbage>
>>
>> I've used both, and except in some very extreme edge cases, using a VM
>> is far, far better than using Boot Camp.
>
> 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.

Or, at the VM level a company like Fusion or Parallels could develop
their own Rosetta like process that translates the code once only to
replace the x86 code with ARM code and load that thereafter.

In the presentation they had Parallels (x86) hosting Linux running
Apache. (Admittedly not a CPU heavy task serving up a webpage ...).

https://youtu.be/GEZhD3J89ZE?t=6111

It's not clear to me how that was stacked up (was it x86 code throughout
the parallels VM? Should be...). But it is clear that it worked.

>
> There is a version of Windoze that runs on ARM already, which could be a
> better choice since it could be virtualised ... but most reports say the
> ARM Windoze isn't as good as x86 Windoze.

MS' implementation of ARM Windows on the latest Surface Pro has been a
flop in several ways. Classic MS "get it out there...".

[nospam]

In article <%KIIG.33204$pC....@fx19.iad>, Alan Browne

<bitb...@blackhole.com> wrote:

>
> In the presentation they had Parallels (x86) hosting Linux running
> Apache. (Admittedly not a CPU heavy task serving up a webpage ...).
>
> https://youtu.be/GEZhD3J89ZE?t=6111
>
> It's not clear to me how that was stacked up (was it x86 code throughout
> the parallels VM? Should be...). But it is clear that it worked.

an arm version of linux.

[Paul]

Alan Browne wrote:

>
> MS' implementation of ARM Windows on the latest Surface Pro has been a
> flop in several ways. Classic MS "get it out there...".

There was a Win10 objective though. To justify a Cloud orientation,
you have to cover all the users devices, from x86 desktops, laptops,
to ARM tablets or Windows Phone. They even have a version that
runs on the RPi (although graphics are gimped to a static image,
as the OS in that case was for "running the hardware" and not
intended as a replacement for a regular desktop).

I think Windows 10 was also offered as an installable option
on one of the Android smartphones.

Could I run a legacy win32 application in every case ?

Well, that's where the users aspirations come in.
Damn those users for expecting stuff to work for them.

*******

The transition for Apple, from x86 to ARM, is great for
their business plan, disruptive for their users. Take
me as an example. Sitting right next to me, right now,
is a PowerPC Mac, a G4. Now, look in the room. Do you
see an x86 Mac ? No. Why ? "Disruptive". How do I feel
today about an ARM version ? Are there enough adjectives ?

There are actually three Macintosh computers in this room.
What do they have ? All have PowerPC. Continuity. Continuity
helped make the sale.

So while Apple can change CPU families and "manage the transition",
guess what they lose when they do that ? They lost *at least*
one customer... By making an orphan of my software collection,
what else would you expect me to do ? There's not enough
reality distortion field for that.

Paul

[nospam]

In article <rcvmdv$s9e$1...@dont-email.me>, Paul <nos...@needed.invalid>
wrote:

> The transition for Apple, from x86 to ARM, is great for
> their business plan, disruptive for their users.

it's not disruptive at all. quite the opposite, actually.

> Take
> me as an example. Sitting right next to me, right now,
> is a PowerPC Mac, a G4. Now, look in the room. Do you
> see an x86 Mac ? No. Why ? "Disruptive". How do I feel
> today about an ARM version ? Are there enough adjectives ?

what disruption? powerpc apps ran unmodified on intel macs without the
user needing to do anything special. just double-click the app as usual
and it 'just worked'.

one exception was virtual pc, which emulated x86 on powerpc processors
and was no longer needed since it could now run virtualized and at
native speeds.

> There are actually three Macintosh computers in this room.
> What do they have ? All have PowerPC. Continuity. Continuity
> helped make the sale.

those are all 15+ years old.

> So while Apple can change CPU families and "manage the transition",
> guess what they lose when they do that ? They lost *at least*
> one customer...

and gained millions more customers.

> By making an orphan of my software collection,
> what else would you expect me to do ? There's not enough
> reality distortion field for that.

apple didn't orphan anything.

what they did was go out well of their way so that existing powerpc
software continued to work unmodified on an intel mac, without the user
even noticing.

apple did the same thing with the 68->powerpc transition, which was
*so* effective that the the slowest powermac ran 68k apps faster than
an actual 68k mac.

for powerpc->intel, windows could run unmodified, and apple even
provided the necessary drivers and a simple install assistant.

[Arlen Holder]

On Wed, 24 Jun 2020 10:02:42 -0400, Paul wrote:

> By making an orphan of my software collection,
> what else would you expect me to do ? There's not enough
> reality distortion field for that.

Hi Paul,

The loss of this freeware on the ARM Mac is the harbinger of the future.
(IMHO)

BTW, you should have been a writer, as you're rather eloquent at getting
your thoughts across, in a way that, like I am, is open and honest.

And brutal.
o No bullshit.

I think the loss of this one freeware on the new ARM Mac is a harbinger of
what's to come, as Apple MARKETING is one of the most profitable companies
on the planet, not due to R&D, but due to its brilliant MARKETING schemes.
o *Does it surprise you Apple spends the least in R&D in all of high tech?*
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/STrAkx09VYk>

If Apple can turn a dead Chinese lady into a MARKETING COUP, they can turn
this transition to ARM Mac into another MARKETING COUP, given that Apple is
essentially all MARKETING and very little R&D (the lowest R&D spend % in
all of high tech, in fact).
o *What is the most brilliant marketing move Apple ever made?*
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/wW-fu0jsvAU>

To your point of having to replace all your software, notice that, one by
one, the _freeware_ opportunities "can" (as is happening in this case) also
transition the user into money-making "payware".

In the end, this move to ARM-Mac is a money maker, in that not only is your
entire software collection instantly rendered useless for running native on
the ARM Mac, but it provides an opportunity to "upgrade" software (freeware
or payware) to the "special" version that runs on the ARM Mac.

In the end, I suspect, this demise of this one freeware on ARM Mac...
o Is a harbinger of what's to come for much more freeware on the Mac.
--
The loss of this freeware on the ARM Mac is the harbinger of the future.

[Arlen Holder]

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.*

This loss of this one freeware tool "could be" the harbinger of the demise
of freeware & 99-year licenses on ARM Mac.

Time will tell on that prediction, but what we know for sure
with respect to software running native on the new ARM Mac...
o Apple effectively orphaned _everything_ (AFAICT) in one fell swoop!

That means, if you want your software to run native on the ARM Mac
o You have to buy _new_ payware (which may likely be subscription based)

Worse...
o *You now have to buy payware to replace your freeware* (e.g., boot camp).

In one swoop, _all_ your software no longer runs native on the ARM Mac.

While Apple has the lowest R&D % spend in all of high tech, never
underestimate the power of their MARKETING schemes, as Apple has a very
high profit margin indeed - and that's clearly not due to its R&D
expenditures.
--
This is a harbinger of a demise of freeware & 99-year licenses on ARM Mac.

[Arlen Holder]

On Wed, 24 Jun 2020 14:38:11 -0000 (UTC), Arlen Holder wrote:

> o *In one swoop, _all_ your software no longer runs native on the ARM Mac.*

I should have noted this was all your current "Mac" software (freeware and
payware) no longer runs native on the ARM Mac.

Where the point of this thread is the demise of Boot Camp freeware.
o The only native known alternative is payware to do the same thing.
--
The iOS software very well might (and probably will) run native (AFAIK).

[Alan Browne]

I wouldn't think so. Parallels is an x86 gig. So while it can be
Rosetta 2'd itself, it's made to host x86 OS'. Can Rosetta 2 do the
VM'd portion as well? Possibly. Indeed the icon for Mac 11
Virtualization has three heads ...

Possibly Parallels and Apple worked together and Parallels have an ARM
version hosting ARM Linux.

[Alan Browne]

On 2020-06-24 10:02, Paul wrote:


> The transition for Apple, from x86 to ARM, is great for
> their business plan, disruptive for their users. Take
> me as an example. Sitting right next to me, right now,
> is a PowerPC Mac, a G4. Now, look in the room. Do you
> see an x86 Mac ? No. Why ? "Disruptive". How do I feel
> today about an ARM version ? Are there enough adjectives ?
>
> There are actually three Macintosh computers in this room.
> What do they have ? All have PowerPC. Continuity. Continuity
> helped make the sale.

That's beyond silly even for me and I run WinXP under Fusion on 1 Mac
and several Win7/Win10's at work under Fusion Macs (minis/laptops)
there. Indeed ordered another Mini yesterday for a work station and it
will have Fusion/Win10 as well. (Replacing an old 2013 Macbook Air for
which Apple will refund me $250 ... so the new mini comes to CAD$750).

Certainly the graphics on those machines is not up to any sober workload
in the era of 1080p and faggedabout 4k.

As to integration with the Apple ecosystem even less so. The era of my
Notes/Messages/Reminders/Mail/iCloud-Drive all being in sync all of the
time is marvelous.

When was the last PPC Mac shipped anyway? A quick Google says Nov 2015.

> So while Apple can change CPU families and "manage the transition",
> guess what they lose when they do that ? They lost *at least*
> one customer... By making an orphan of my software collection,

Many developers (those worth it) transitioned to x86 painlessly enough.
Some got mired in Carbon and refused to Cocoa. To be fair many had
valid business reasons to do so.

Apple provided 3 OS rounds of Rosetta support as well. (Well 1 partial
round (Tiger), full round (Leopard) and optional in Snow Leopard).
Stretch SL out a few years and one was covered for a 4 - 5 year period.

> what else would you expect me to do ? There's not enough
> reality distortion field for that.

In the time that you stuck to PowerPC Apple have sold well over 200M
Macs on intel. I'd say the reality distortion is closer to you than Apple.

Indeed going to intel gave them a huge market boost, most especially in
portables.

I'm debating buying a last round intel iMac this fall (for home - this
i7 is a 2012 model purchased in 2013) or waiting for an Apple chipped
version. I had an early round iMac intel (Core 2 Duo, 2.8 GHz IIRC with
6 GB of RAM. It was okay, but nothing like a 4 core HT i7 with 24 GB).

The compiler I use most is already ARM'd, just needs to be 'hooked' to
Mac OS 11 which shouldn't be a big deal.

[Alan Browne]

On 2020-06-24 13:41, Alan Browne wrote:

> When was the last PPC Mac shipped anyway? A quick Google says Nov 2015.

Doh! 2005.

[nospam]

In article <COLIG.27666$hQ4....@fx39.iad>, Alan Browne

<bitb...@blackhole.com> wrote:

> >> It's not clear to me how that was stacked up (was it x86 code throughout
> >> the parallels VM? Should be...). But it is clear that it worked.
> >
> > an arm version of linux.
>
> I wouldn't think so.

it is.

> Parallels is an x86 gig.

more accurately, they're a hypervisor gig, using the hypervisor on x86.

part of the apple processors is also a hypervisor making it relatively
easy to virtualize another arm os.

> So while it can be
> Rosetta 2'd itself, it's made to host x86 OS'. Can Rosetta 2 do the
> VM'd portion as well? Possibly. Indeed the icon for Mac 11
> Virtualization has three heads ...

it might be possible to do that, but it would not work well.

> Possibly Parallels and Apple worked together and Parallels have an ARM
> version hosting ARM Linux.

yep.

[nospam]

In article <SeMIG.10594$Li1....@fx11.iad>, Alan Browne

<bitb...@blackhole.com> wrote:

>
> When was the last PPC Mac shipped anyway? A quick Google says Nov 2015.

i saw your correction to 2005, but that is wrong.

apple announced the intel transition in june, 2005, with the first
intel mac shipping in january, 2006.

the entire mac lineup transitioned to intel by august, 2006, at which
point apple stopped making powerpc macs.

existing stock was sold until it was gone, with refurb powerpc macs
selling for year or so after that.

several versions of the operating system fully supported both powerpc
and intel macs through 2011, six years after the transition was first
announced.

> > So while Apple can change CPU families and "manage the transition",
> > guess what they lose when they do that ? They lost *at least*
> > one customer... By making an orphan of my software collection,
>
> Many developers (those worth it) transitioned to x86 painlessly enough.

for many developers, the transition was little more than a recompile.

some had to deal with endian issues because they chose not to write
endian-neutral code and it came back to bite them.

> Some got mired in Carbon and refused to Cocoa. To be fair many had
> valid business reasons to do so.

intel macs support both carbon and cocoa. many apps use both.

catalina (sep, 2019) is the first version to drop support of carbon
ahead of the arm transition which is also only cocoa. that's ~15 years
after the intel transition began.

> Apple provided 3 OS rounds of Rosetta support as well. (Well 1 partial
> round (Tiger), full round (Leopard) and optional in Snow Leopard).
> Stretch SL out a few years and one was covered for a 4 - 5 year period.

lion (2011) was the first version to not include rosetta, which turned
out to be somewhat of a dud and many people skipped it, so it was
really mountain lion (2012) until powerpc apps could no longer be used
for most people, about 7 years from when the intel transition was first
announced.

but the story goes much deeper than that.

apple licensed rosetta from a company called transitive, which was
later bought by ibm, who had no interest in licensing it to apple or
anyone else.

<https://www-03.ibm.com/press/us/en/pressrelease/26106.wss>
ARMONK, NY - 18 Nov 2008: IBM (NYSE: IBM) today announced it
plans to acquire Transitive Corporation...
...
Transitive is a leader in cross-platform virtualization and a pioneer
in developing technologies that allow applications written for one
type of microprocessor and operating system to run on multiple
platforms -- with little or no modification. As a result, the
technology will enable customers to consolidate their Linux-based
applications onto the IBM systems that make the most sense for
their business needs.

rosetta 2 for arm is apple's own design and written in house, thus
*not* subject to the whims of another company.

it will last until there is no longer demand for it, at least 5 years.

[JF Mezei]

On 2020-06-24 00:38, Arlen Holder wrote:
> Dateline today...
>
> "*Boot Camp Is Dead On [all new ARM-based Macs]*"

Initially true. But if Microsoft starts to market ARM based Windows 10
that includes a Rosetta equivalent to run 8086 binaries, due boot might
return.


Have there been any hints on what boot console will be used ? Will Apple
stick with EFI for its ARM based chips or use whatever it has developped
for ita Axx chips for iPhone/iPad/AppleTV ?

[nospam]

In article <8tNIG.16028$GQ4....@fx02.iad>, JF Mezei

<jfmezei...@vaxination.ca> wrote:

> > "*Boot Camp Is Dead On [all new ARM-based Macs]*"
>
>
> Initially true. But if Microsoft starts to market ARM based Windows 10
> that includes a Rosetta equivalent to run 8086 binaries, due boot might
> return.

windows on arm already exists, although x86 emulation sucks.

> Have there been any hints on what boot console will be used ? Will Apple
> stick with EFI for its ARM based chips or use whatever it has developped
> for ita Axx chips for iPhone/iPad/AppleTV ?

there's no reason to use efi.

[JF Mezei]

On 2020-06-24 00:45, Alan Baker wrote:

> I've used both, and except in some very extreme edge cases, using a VM
> is far, far better than using Boot Camp.

The VM in this case will have to be like Sheepshaver and provide a
platform emulation (complete with booting support).

From what Apple provided in Monday, Rosetta is more of a utility to do a
one time convert of a file that contains 8086 binary to create another
file that contains ARM binary. (both allegedly packaged under the same
.APP directory structure to create that "Universal 2").

There was mention of JIT file support, and I have to wonder if that too
will see the JIT executable fully received, converted and then launched.
(would need more details to confirm).


Launching 8086 Windows in a 8086 emulator will result in the emulator
application (an ARM binary) reading data from an OS-X data file. (that
file contains the Windows system disk in Windows's native disk format).

Rosetta has no means to convert the content of that data file because it
seen jibberish instead of an OS-X .APP firectory structure.

**IF** the JIT feature allows an app (the VM) to ask Rosetta to
translate 8086 code store in memory to ARM, then the VM could provide
location in memory of 8086 code loaded by the Windows logic and ask it
tto translate it to ARM and then branch to it. For DLLs this would also
imply updating the pointers in the list of DLLs so apps can dynamically
link to the translated code version.

or you can do opcode by opcode translation to emulatr an 8086 computer,
Not as efficient for running apps, but much simpler to implemnent.

[nospam]

In article <wcOIG.9486$Vp4....@fx44.iad>, JF Mezei

<jfmezei...@vaxination.ca> wrote:

>
> > I've used both, and except in some very extreme edge cases, using a VM
> > is far, far better than using Boot Camp.
>
>
> The VM in this case will have to be like Sheepshaver and provide a
> platform emulation (complete with booting support).

no.

> From what Apple provided in Monday, Rosetta is more of a utility to do a
> one time convert of a file that contains 8086 binary to create another
> file that contains ARM binary. (both allegedly packaged under the same
> .APP directory structure to create that "Universal 2").

no.

> There was mention of JIT file support, and I have to wonder if that too
> will see the JIT executable fully received, converted and then launched.
> (would need more details to confirm).

you always need more details, but that doesn't stop you from rambling.

[JF Mezei]

On 2020-06-24 14:42, nospam wrote:

> existing stock was sold until it was gone, with refurb powerpc macs
> selling for year or so after that.

Suspect that discontinued models that are still in stock and don't sell
eventually go to "refurb" where Apple can price them low to get rid of
them without influencing published prices for new computers.

While Apple stated 2 year transition, I suspect that it will be much
faster, as was the case for the PowerpC to Intel transition as you
pointed out.

For one thing, people will stop buying Macs now, awaiting the newer
ones. Secondly, Consider that the current lineup of Macs has seen recent
refreshes. So they are good to go without a new Intel model until the
ARM based ones come out.

So it is in Apple's own interest to go wuickly on this.

The bigger question in my mind is how the first ARN chip will be
positioned. They produced the A12 based Mac Mini for developpers. Will
the first "real" one be a truly impressive high performance one for the
"Pro" models, or would it be an iPad class chip for the MacBook/Air and
normal iMacs?

Assuming Apple comes out with the A14 for iPhones in September. From a
"wow" factor, releasing the A14-Pro chip soon after to power MacbookPro
and iMacPro and MacMini (and possibly a card for the $60,0000 cheese
grater) could impress a lot of people to show that Apple really can make
how powered chips, and 6 months later, comes out with the iPad class
clip to power new iPad and the norml MacBook and Imac.
Or it can do reverse, come out with the "normal" dericvative this fall,
and the "pro" model of the chip later.

In the end, it is all about chip FAB and what yields they get from the
design. A chip with no defects will be sold as a 3gbh chip with 4 cores.
A chip with a deffectoive code may be sold as a 3ghz chip with only 2
cores, and a chip with more defects will be sold as a 1,5ghz chip with
whatever cores.

> some had to deal with endian issues because they chose not to write
> endian-neutral code and it came back to bite them.

In many cases, you have no choice because of what your code interfaces
with. Not all devices talk "text" in XML. And many older databases
stored data in binary to space space. Many config files are in binary to
prevent users editing them. Anything that is binary and stored in file
becomes endian sensitive.

> apple licensed rosetta from a company called transitive, which was
> later bought by ibm, who had no interest in licensing it to apple

I was puzzled by Apple's use of the erm "Rosetta". So did a big of googling.

"Rosetta" was not Transitive's (so not IBM). Apple Licenced
QuickTransit from Transitive and created its own brand "Rosetta" for its
implemnentation.


But I suspect Rosetta2 is far more simpler as a file coverter as opposed
to converting machine code in-memory while it executes.

The file converter has the luxury of relinking the image and resolving
all exeternal references to point to the ARM versions of external
binaries. So when the translated app is launched, it truly launches as
a native app with all references to external subroutinesdynamic
libraries resolved to ARNM code right at launch time and no need to trap
any attempt to access untranslated code.

However, consider (whcih is now very rare and impossible on many
architvetures) a self modifying app that builds in memory some code to
which it then branches. Such an app would be translated and launch
normally, but when it writes to RAM code to which it intends to brand,
that code would still be x86 and it would then crash when it tries to
branch to it. (assuming it runs on a platform that allows one to branch
to data memory).

In am emulated environment, this would work because every instruction is
translated on the fly. However, the use of self modifying code is long
gone, except in virus attacks where buffer overloads attem,pt to insert
specific machine code that the attacker hopes the victim will branch to.
So by moving to Arm, it means those types of attacks will need to insert
ARM opcodes instead of 8086 ones.
#

[nospam]

In article <5oPIG.51075$AN2....@fx46.iad>, JF Mezei

<jfmezei...@vaxination.ca> wrote:

>
> > existing stock was sold until it was gone, with refurb powerpc macs
> > selling for year or so after that.
>
> Suspect that discontinued models that are still in stock and don't sell
> eventually go to "refurb" where Apple can price them low to get rid of
> them without influencing published prices for new computers.

that doesn't change anything.

powerpc macs ceased being made in late 2006 and within a year or so,
all new and refurbs had been sold.

> While Apple stated 2 year transition, I suspect that it will be much
> faster, as was the case for the PowerpC to Intel transition as you
> pointed out.

yep. a year from now, most, if not all macs, will be apple silicon,
except maybe the mac pro, which is a high end niche system.

> For one thing, people will stop buying Macs now, awaiting the newer
> ones. Secondly, Consider that the current lineup of Macs has seen recent
> refreshes. So they are good to go without a new Intel model until the
> ARM based ones come out.

sales will slow down, but they won't stop.

> So it is in Apple's own interest to go wuickly on this.
>
> The bigger question in my mind is how the first ARN chip will be
> positioned. They produced the A12 based Mac Mini for developpers. Will
> the first "real" one be a truly impressive high performance one for the
> "Pro" models, or would it be an iPad class chip for the MacBook/Air and
> normal iMacs?

the developer transition mac is for testing and not representative of
what future macs might be.

> > some had to deal with endian issues because they chose not to write
> > endian-neutral code and it came back to bite them.
>
> In many cases, you have no choice because of what your code interfaces
> with. Not all devices talk "text" in XML. And many older databases
> stored data in binary to space space. Many config files are in binary to
> prevent users editing them. Anything that is binary and stored in file
> becomes endian sensitive.

that doesn't change the fact that some developers took shortcuts, which
came back to bite them in the ass.

> > apple licensed rosetta from a company called transitive, which was
> > later bought by ibm, who had no interest in licensing it to apple
>
> I was puzzled by Apple's use of the erm "Rosetta". So did a big of googling.
>
> "Rosetta" was not Transitive's (so not IBM). Apple Licenced
> QuickTransit from Transitive and created its own brand "Rosetta" for its
> implemnentation.

you're contradicting yourself.

> But I suspect Rosetta2 is far more simpler as a file coverter as opposed
> to converting machine code in-memory while it executes.

you suspect all sorts of things, very few of which have any relevance
to reality.

> The file converter has the luxury of relinking the image and resolving
> all exeternal references to point to the ARM versions of external
> binaries. So when the translated app is launched, it truly launches as
> a native app with all references to external subroutinesdynamic
> libraries resolved to ARNM code right at launch time and no need to trap
> any attempt to access untranslated code.
>
> However, consider (whcih is now very rare and impossible on many
> architvetures) a self modifying app that builds in memory some code to
> which it then branches. Such an app would be translated and launch
> normally, but when it writes to RAM code to which it intends to brand,
> that code would still be x86 and it would then crash when it tries to
> branch to it. (assuming it runs on a platform that allows one to branch
> to data memory).
>
> In am emulated environment, this would work because every instruction is
> translated on the fly. However, the use of self modifying code is long
> gone, except in virus attacks where buffer overloads attem,pt to insert
> specific machine code that the attacker hopes the victim will branch to.
> So by moving to Arm, it means those types of attacks will need to insert
> ARM opcodes instead of 8086 ones.
> #

you call that simpler????

[JF Mezei]

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 )

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.

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

> there's no reason to use efi.

EFI is already there , already written, no need to re-invent the wheel.
Rember that desktops require more boot functionality than a single drive
iphone, have wide variety of displays, graphic cards and need to be able
to boot from external disks of various interfaces (USB, thunderbolt etc(


EFI already has that.

Dropping EFI does allow Apple to drop the GPT/GUID partioning scheme and
be native APFS with its own in-partition partitioning.

Keeping EFI means that the boot code gets to keep large chunks of code
with the existing structures for system information, early access to
devices etc.

[nospam]

In article <J8QIG.30829$0W4....@fx42.iad>, JF Mezei

<jfmezei...@vaxination.ca> 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.

win nt was available for power pc too.

<https://en.wikipedia.org/wiki/Windows_NT_3.51#Overview>
The release of Windows NT 3.51 was dubbed "the PowerPC release"
at Microsoft. The original intention was to release a PowerPC edition
of NT 3.5, but according to Microsoft's David Thompson, "we basically
sat around for 9 months fixing bugs while we waited for IBM to finish
the Power PC hardware". Editions of NT 3.51 were also released for
the x86, MIPS, and Alpha architectures

win nt has nothing to do with windows on arm today.

> > there's no reason to use efi.
>
>
> EFI is already there , already written, no need to re-invent the wheel.

efi is *not* already there for apple silicon macs.

> Rember that desktops require more boot functionality than a single drive
> iphone, have wide variety of displays, graphic cards and need to be able
> to boot from external disks of various interfaces (USB, thunderbolt etc(

that doesn't require efi.

[Alan Baker]

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?

>
> This loss of this one freeware tool "could be" the harbinger of the demise
> of freeware & 99-year licenses on ARM Mac.

What are you even talking about?

>
> Time will tell on that prediction, but what we know for sure
> with respect to software running native on the new ARM Mac...
> o Apple effectively orphaned _everything_ (AFAICT) in one fell swoop!

Ummm.... ...no.

They didn't.

>
> That means, if you want your software to run native on the ARM Mac
> o You have to buy _new_ payware (which may likely be subscription based)

Ummmmm... ...no.

>
> Worse...
> o *You now have to buy payware to replace your freeware* (e.g., boot camp).

Ummmm... ...no.

>
> In one swoop, _all_ your software no longer runs native on the ARM Mac.

Ummm... ...wrong.

[Alan Baker]

On 2020-06-24 7:40 a.m., Arlen Holder wrote:
> On Wed, 24 Jun 2020 14:38:11 -0000 (UTC), Arlen Holder wrote:
>
>> o *In one swoop, _all_ your software no longer runs native on the ARM Mac.*
>
> I should have noted this was all your current "Mac" software (freeware and
> payware) no longer runs native on the ARM Mac.

And I noted that there was no reason for you to care.

>
> Where the point of this thread is the demise of Boot Camp freeware.
> o The only native known alternative is payware to do the same thing.
>

VirtualBox from Oracle...

[Alan Baker]

On 2020-06-24 12:55 p.m., JF Mezei wrote:
> On 2020-06-24 00:45, Alan Baker wrote:
>
>> I've used both, and except in some very extreme edge cases, using a VM
>> is far, far better than using Boot Camp.
>
>
> The VM in this case will have to be like Sheepshaver and provide a
> platform emulation (complete with booting support).

Stop attempting to talk about things you don't understand.

[Paul]

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.

VirtualBox in a homogenous ("untranslated") situation,
runs at around 0.9x. Giving you most of the CPU core you're
using. What VirtualBox doesn't always do a good job of,
is running multiple cores smoothly. There are some rough
edges under the hood. In some instances, it even rails
a core due to some sort of tasking issue.

Who wants to go from an Intel processor that turbos up
to 5GHz on a single thread, to some 2GHz ARM core doing
translation to make some legacy item run ?

I've been through all of this before. And have
no interest in "trying it" or anything else.

I used to run SoftWindows on PowerPC, as well
as VirtualPC (Connectix) back when it was its
own company.

Today, it's "native", "x86-on-x86", or "get outta town".
That's why I gave the "Magical" comment, not wanting
to waste the time explaining it.

Paul

[Your Name]

Your software collection wasn't "orphaned". Apple and most developers
did an exceptional job at keeping most of it usable during the past CPU
changeovers, and all signs point to the Intel to Apple Silicon
chageover being equally as "smooth".

The change from PowerPC to Intel had Rosetta which translated apps
on-the-fly. The change from Intel to Apple Silicon will have Rosetta 2
which translates apps on installation and in some cases on-the-fly.

There was alos the Fat / Universal binaries which allowed apps to run
on both 68K Macs and PowerPC Macs, and then PowerPC Macs and Intel Macs

All of that means you could still use almost all your old apps until
you upgraded them. (There are of course always apps that don't work,
often due to the developers not following Apple's programming rules
and/or directly accessing the hardware.)

Of course, if you're happy with your current hardware and software
set-up, then there's no enforced requirement to update at all. I used a
G3 PowerMac for about 20 years until it died with a motherboard
failure. I only upgraded it to MacOS X because my useless ISP refused
to fix issues with their servers that meant MacOS 9 users could no
longer log onto the internet via dial-up conenctions.

[Arlen Holder]

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).

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.
--
A freeware solution for the Mac ARM will perhaps be found in the future.

[Arlen Holder]

On Wed, 24 Jun 2020 20:17:57 -0400, Paul wrote:

> If you've ever run heterogenous VMs, you'll know
> what to expect.

Hi Paul,

Anyone who suggests a VM to replace BootCamp/Grub, doesn't understand either.

As a purposefully helpful poster (unlike Alan Baker, who simply wants to
claim the Mac does everything better than does Windows), you need to
realize, if you don't already, that Alan Baker has an IQ of around 40 or 50
IMHO, so it's completely over his head that a VM isn't even close to the
functionality gained simply by "booting" to that 2nd operating system.

You'll have to explain that simple fact to him _multiple_ times...
o And, since he's an AppleSeed cultist, he _still_ won't get it.

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.

> I've been through all of this before. And have
> no interest in "trying it" or anything else.

Like you, and many others, I've been through the VM hassle before also.
o It's not even close to the functionality of booting directly to the OS.

As you're well aware, I've written tutorials on how to set up VMs in
Windows, and it's just horrid (particularly when you deal with the
hardware).

As such, like you, I'm done with classic VMs (and emulation also), which is
well known as I openly described why I'm done with VMs in detail on the
recent thread using WSL inside of Windows:
o *Tutorial for setting up Ubuntu as a Windows Subsystem for Linux WSL in Windows 10*
<https://groups.google.com/forum/#!topic/alt.comp.freeware/rOT8xBWo9dk>

Anyone who suggests a VM to replace BootCamp/Grub, doesn't understand either

[Arlen Holder]

On Thu, 25 Jun 2020 13:06:35 +1200, Your Name wrote:

> Your software collection wasn't "orphaned". Apple and most developers
> did an exceptional job at keeping most of it usable during the past CPU
> changeovers, and all signs point to the Intel to Apple Silicon
> chageover being equally as "smooth".

Hi Your Name,

*Nobody should be happy losing all their existing software functionality.*

I realize you're a well-known Type III apologist, so I simply remind you
that the topic is that the demise of the ability to multi boot on the new
Mac ARM is a pretty big hit in loss of basic boot functionality, which is
the topic of this thread after all.

*The new Mac ARM puts users back in the Stone Age of boot functionality.*

Given this loss of basic functionality on the new Mac ARM puts users in the
unenviable position of being slammed back to the Stone Age of computing,
Paul additionally rightly noted the loss of all prior Mac apps on the new
Mac ARM puts them even further backward in terms of their current
capabilities.

Since you're a well known apologist, none of those facts will have any
impact on you given that you justify Apple's actions in all cases, where
the scary _difference_ between Type III apologists is what scares me:
o Type I apologists === nospam: simply parrots Apple MARKETING always
o Type II apologists === Alan Browne: not malicious, just ill informed.
o Type III apologists === Your Name: actually _believes_ Apple MARKETING

Notice the key differences:
o Type I apologists don't believe a word they, themselves, say
o Type II apologists think for themselves but often filter out facts
o Type III apologists can't think for themselves - they believe the bullshit.

The facts appear to be, whether you can comprehend them or not:
o While the Mac ARM may help Apple in _their_ brilliant business plans...
o The new Mac ARM instantly causes _loss_ of critical user functionality.

Only an apologists would be happy with that as the obvious 1st step.
--
Nobody should be happy losing all their existing software functionality.

[Char Jackson]

On Wed, 24 Jun 2020 20:17:57 -0400, Paul <nos...@needed.invalid> 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.

[Paul]

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

Paul

[Arlen Holder]

On Wed, 24 Jun 2020 23:34:20 -0500, Char Jackson wrote:

> 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.

Performance aside... you still have _huge_ problems with VM guest OS's...
o e.g., does the VM guest OS interact well with the real host hardware?

The point is that a VM guest OS is quite different from a boot host OS.
o As far as has been proposed in this thread, there is no solution.

Hence, with respect to prior functionality, this is a step back for Mac
users, who lose functionality for booting to other OS's with the Mac ARM.
--
This new Mac ARM is a step backward for the poor Apple software users.

[Arlen Holder]

On Thu, 25 Jun 2020 00:46:05 -0400, Paul wrote:

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

First off, Char Jackson is a well known troll who has added almost nothing
of value to Usenet in his entire life, so, for Char to question Paul's
figures, without Char even proposing a _single_ iota of factual data, is,
well, it's what trolls do.

Trolls like Char Jackson make up _everything_ that they post.
o It's all complete and total bullshit from trolls like Char Jackson is.

Trolls dispute facts that they themselves don't bother to back up with any
facts themselves... they just bullshit everyone, wasting all our time.

It's amusement for them.

In concurrence with Paul's experiences, I've written tutorials on setting
up VMs in the past, and it's NOTHING like the dual-boot experience.

Not even close.
o Anyone who proposes them as equivalents, doesn't understand either.

Like Paul, I've had horrid experiences with VirtualBox on Windows in the
past such that I gave up on VMs in favor of a simple dual boot (via Grub)
to Linux where Linux has full and complete access to the Windows file
system.
o *Simultaneously slide Windows Linux iOS Android files back and forth*
*over USB at 7GB per minute speeds using 100% native devices*
*(no proprietary software needed)*
<https://groups.google.com/forum/#!topic/alt.comp.freeware/K0NZ0nb1pWw>

VMs are NOT the same functionality as a multi-boot configuration.
o Not even close.
--
The point is that if there is no equivalent solution to Boot Camp, then the
new ARM Macs push the poor Mac ARM users back to the computer stone age.

[Your Name]

It greatly depends what you're emulating and on what host. For example,
Commodore VIC 20 emulation on an Intel Mac is so fast that games would
be completely unplayable if not for some sort of "slow down" built into
the emulator.

Emaulting, say, Windows 95 on a Apple Silicon Mac should be fine, but
emulating x86 Windows 10 on an Apple Silicon Mac is going to be slower
than virtualising x86 Windows 10 on an Intel Mac, which in turn is
slower than running x86 Windows 10 on an Intel Mac via Boot Camp.

Both Parallels and VMWare are already said to be working on solutions
for Apple Silicon Macs to run Windows.

[Paul]

The purpose of VMs, is to do more than one thing at once.
And in a semi-isolated environment.

As an example, say Windows 10 doesn't support your USB scanner.
But Windows 7 does. You can set up a VM with passthru, pass the
USB scanner to the Guest, and do a paper document scan without
rebooting. Two OSes running. The Guest OS doing something that
the Host would not have supported.

That's a typical reason I might do it here.

When a VM does not do a faithful emulation, then the utility
is reduced. For example, I can't really do UEFI experiments
in VirtualBox, because the UEFI shell in there doesn't behave
the way I think it should behave. The UEFI in my Asus motherboard
BIOS is much better for that sort of thing. If I needed to do
an entire multiboot setup inside a VM (which I've done, more than
once), then the VirtualBox UEFI is not good enough to prove
or disprove anything. If doing VirtualBox legacy multiboot,
the emulation there is fine and dandy. There is more call for
UEFI setups now (as your HP or Acer arrives with UEFI/GPT
setups out of the box, and people add stuff to them as is).

Paul

[JF Mezei]

On 2020-06-24 17:56, nospam wrote:

> yep. a year from now, most, if not all macs, will be apple silicon,
> except maybe the mac pro, which is a high end niche system.

The Mac Pro is used to run Adobe software. (render movies etc). The
keynote mentioned pretty loudly how Adobe had alread ported its software
to ARM and that it was performing blazingly fast.

Apple hinted that it will be using its own GPUs that came off from
iPhone/iPad development. The unaffordable cheese grater Mac Pro comes
with high end GPUs. Whether Apple's new GPUs will match,outperform those
remains to be seen If it does, I could see an upgrade kit for the
machines that improve performance running Adobe software and that would
be a big sell.

The $60,000 mac pro was designed knowing full well Apple was moving to
ARM. So I have to assume they thought about upgrade kits for a machine
that sells for such a high price.

> sales will slow down, but they won't stop.

If a machine breaks, yeah, you replace it. But upgrades for upgrade's
sake will wait.

> the developer transition mac is for testing and not representative of
> what future macs might be.

Wouldn't you agree that the lineup will remain pretty much the same:

Mac Mini, Mac Pro
iMac, iMacPro
MacBook, MacBookPro (perhaps MacBook Air)

> that doesn't change the fact that some developers took shortcuts, which
> came back to bite them in the ass.

By now, the only software that runs on modern Macs is 64 bits and was
compiled recently. And the move from Intel to ARM has no endianness
issues, so going from 64 bits little endian to 64 bit little endian has
no change.

(remember that there are also issues going from 32 to 64 bits when
manipulating individual bits).

[JF Mezei]

On 2020-06-24 18:27, nospam wrote:

> win nt has nothing to do with windows on arm today.

Actually it does. I beleive that with Windows XP they used the Windows
NT core and just added the retail client windows GUI to it.

Windows NT was designed to be portable (since it originally booted off
Aloha, x86 and pthers (you mentioned PowerPC)

And Apple already has had Widnows on ARM. Still a lot of work to
productize Windows on ARM machines and market it, provide solid 8086
translator/emulator in it etc.

>> EFI is already there , already written, no need to re-invent the wheel.
>
> efi is *not* already there for apple silicon macs.

But EFI ios already there in OS-X.

Ovbiously, this is a decision Apple has already made because OS-11 has
support for whatever booting console the ARM based Macs will have.

> that doesn't require efi.

PowerPCs had Apple's own boot console. (forget the name). But modern
OS-X supports EFI already. So it would make sense to just make the
hardware that has EFI as boot console instead of writing both your own
boot console fopr the CPU, AND updating OS-X to support that new boot
console in the OS.

[JF Mezei]

On 2020-06-25 01:47, Your Name wrote:

> Emaulting, say, Windows 95 on a Apple Silicon Mac should be fine, but
> emulating x86 Windows 10 on an Apple Silicon Mac is going to be slower
> than virtualising x86 Windows 10 on an Intel Mac, which in turn is
> slower than running x86 Windows 10 on an Intel Mac via Boot Camp.

The unknown variable here is what sort of performance Apple's ARM chip
will get. With Intel fairly slow with updates of its 8086s, it is quite
possible that Apple will be able to surpass the 8086's performance
sufficiently that running Windows in emulation will be quite palatable.

Another aspect of the keynote talking about Adobe: right now, many run a
version of Windows (Parraleles, Bootcamp) to run one or two apps not
available on the Mac. If all your existint software moves from Intel
Mac to ARM Mac, you might still need Windows for that one or two apps
and it is likely those apps don'ta ctually require much performance.

I beleive Microsoft also recompiled Office for OS_X/ARM


People won't be buying Macs to run windows. But they may buy Macs to run
OS_X and Windows for that one or 2 apps they don't have on oS_X.

[nospam]

In article <6GXIG.27685$hQ4....@fx39.iad>, JF Mezei

<jfmezei...@vaxination.ca> wrote:

>
> > win nt has nothing to do with windows on arm today.
>
> Actually it does.

it does not

> I beleive that with Windows XP they used the Windows
> NT core and just added the retail client windows GUI to it.
>
> Windows NT was designed to be portable (since it originally booted off
> Aloha, x86 and pthers (you mentioned PowerPC)

windows nt is irrelevant to anything apple does.

> And Apple already has had Widnows on ARM.

no they don't.

this may come to you as a surprise, but apple does not have anything to
do with windows.

microsoft is responsible for windows and already has windows on arm.

> Still a lot of work to
> productize Windows on ARM machines and market it, provide solid 8086
> translator/emulator in it etc.

that already exists, but it doesn't work that well.

> >> EFI is already there , already written, no need to re-invent the wheel.
> >
> > efi is *not* already there for apple silicon macs.
>
> But EFI ios already there in OS-X.

efi has nothing to do with mac os.

> Ovbiously, this is a decision Apple has already made because OS-11 has
> support for whatever booting console the ARM based Macs will have.

which is not efi

> > that doesn't require efi.
>
> PowerPCs had Apple's own boot console. (forget the name).

nope.

powerpc macs used the industry standard open firmware.

68k macs did not use nor need anything.

> But modern
> OS-X supports EFI already. So it would make sense to just make the
> hardware that has EFI as boot console instead of writing both your own
> boot console fopr the CPU, AND updating OS-X to support that new boot
> console in the OS.

no it wouldn't.

[nospam]

In article <rd1a68$p39$1...@dont-email.me>, Paul <nos...@needed.invalid>
wrote:

> >> 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.

it was nowhere near that slow and has nothing to do with what apple is
doing for the apple silicon transition, running mac powerpc apps on
intel macs or running mac 68k apps on powerpc macs.

in fact, the first powerpc mac ran 68k apps faster than the fastest 68k
mac despite emulating 68k.

[Alan Browne]

On 2020-06-24 20:17, 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.

The best approach is to translate the machine code, efficiently, once,
as Rosetta does and save that translated code. Theoretically this could
result in many portions of code that run faster than the original if the
translation designers are very good at taking advantage of features of
the new processor absent in the prior. In a CISC-ish to RISC-ish
translation that's even bound to happen. (Granting that the CISC/RISC
gulf is quite narrow now).

[Alan Browne]

On 2020-06-25 01:47, Your Name wrote:

> Emaulting, say, Windows 95 on a Apple Silicon Mac should be fine, but
> emulating x86 Windows 10 on an Apple Silicon Mac is going to be slower
> than virtualising x86 Windows 10 on an Intel Mac, which in turn is
> slower than running x86 Windows 10 on an Intel Mac via Boot Camp.

The whole point of Rosetta is to avoid emulation and instead translate
the code to ARM code. If that can't be done for Windows, then
Parallels/Fusion would do well to come up with their own "Rosetta" that
can (as you said in your post, not quoted here).

The difference in speed running windows under Fusion and Bootcamp is
small enough that only 'gamers' should care to use Bootcamp. The
convenience that comes with having two (or more) OS' running at the same
time beats the miniscule drop in speed.

[Ant]

Huh? When I used VirtualPC's W2K VM in my PowerBook G4 1 Ghz back in its
days, it was SO slow! :(

--
Life is so crazy! ..!.. *isms, sins, hates, (d)evil, illnesses (e.g., COVID-19/2019-nCoV/SARS-CoV-2), deaths, heat waves, fires, out(r)ages, unlucky #4, 2020, etc.
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org /
/ /\ /\ \ http://antfarm.ma.cx. Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

[nospam]

In article <KNKdneJbl9lKBGnD...@earthlink.com>, Ant

<a...@zimage.comANT> wrote:

> > > >> 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.
>
> > it was nowhere near that slow and has nothing to do with what apple is
> > doing for the apple silicon transition, running mac powerpc apps on
> > intel macs or running mac 68k apps on powerpc macs.
>
> > in fact, the first powerpc mac ran 68k apps faster than the fastest 68k
> > mac despite emulating 68k.
>
> Huh? When I used VirtualPC's W2K VM in my PowerBook G4 1 Ghz back in its
> days, it was SO slow! :(

it was slow compared to an intel pc, but it was certainly usable.

as i said, that has nothing to do with running mac 68k apps on powerpc
macs or mac powerpc apps on intel macs, which in many cases, was
*faster*.

[JF Mezei]

On 2020-06-25 06:48, nospam wrote:

> windows nt is irrelevant to anything apple does.

This was in context of discussion of Windows going to ARM. Since
Windows's current core has its roots in Windows NT which was designed as
multi-platform, then moving the "industry standard" to ARM is something
that is doable.

Original Windows/DOS was highly tied to the 8086.

>
>> And Apple already has had Widnows on ARM.
>
> no they don't.

Meant to say Microsoft. my bad.

> that already exists, but it doesn't work that well.

Because there never was a concerted effort to make it work. If ARM gets
better performance and lower power, this equation can change quite fast.

> efi has nothing to do with mac os.

When OS-X on Intel boots, the OS-X code makes extensive use of EFI
service. Getting hardware config for instance, and the intial VGA
display on screen (such as when you boot verbose, those are all "printf"
calls to EFI which then displays on screen.

The Apple version of EFI also has the ability to select boot drives and
ability to lookup up the structure of the HFS or APFS to load the boot
block directly (as opposed to staring an EFI program in the EFI
partition, which program understands the disk dsurutire of the target OS
and can fimd where the boot block is located).

> powerpc macs used the industry standard open firmware.

OpenBoot. And I stand correct, it was done by Sun and used by Apple. It
has since been officially widthdrawn as an IEEE standard.

> 68k macs did not use nor need anything.

So pray tell, when tyou powered on, what created the chime? What caused
the CPU to issue the IO commands to fetch the boot block, and then
branch to it? What caused the CPU to show a sad face when it didn,T find
a bootage disk drive?

[nospam]

In article <ZT2JG.65177$PN2....@fx48.iad>, JF Mezei

<jfmezei...@vaxination.ca> wrote:

>
> > efi has nothing to do with mac os.
>
> When OS-X on Intel boots, the OS-X code makes extensive use of EFI
> service.

that's for intel macs.

it is *not* the case for powerpc macs or future apple silicon macs.

> > powerpc macs used the industry standard open firmware.
>
> OpenBoot. And I stand correct, it was done by Sun and used by Apple. It
> has since been officially widthdrawn as an IEEE standard.

openboot is what sun called it. outside sun, it was known as open
firmware.

<https://wiki.c2.com/?OpenFirmware>
Open Firmware is essentially a specification for a largely
machine-independent BIOS based on the AnsForth standard
that is capable of probing and initializing plug-in cards that
have on-board IEEE-1275 compliant Fcode in their ROMs. It
was invented by MitchBradley to aid in debugging recalcitrant
hardware at Sun. It is found in Sun, IBM, PowerMacintosh, and
OneLaptopPerChild systems.

it even has a song
<https://everything2.com/title/The+Open+Firmware+Song>

> > 68k macs did not use nor need anything.
>
> So pray tell, when tyou powered on, what created the chime? What caused
> the CPU to issue the IO commands to fetch the boot block, and then
> branch to it? What caused the CPU to show a sad face when it didn,T find
> a bootage disk drive?

the mac startup manager, which was in rom and contained a substantial
amount of mac os. there was no separate bios, nor did it need it.

[JF Mezei]

On 2020-06-25 08:19, Alan Browne wrote:

> as Rosetta does and save that translated code. Theoretically this could
> result in many portions of code that run faster than the original if the
> translation designers are very good at taking advantage of features of
> the new processor absent in the prior.

Very doubtful that the translator will try to optimize things. The ARM
processor will optmize the stream of instriuctions when it runs them.
Rememver that the compiler will have alteady optmized the source code in
generic fashion (LLVM then does the optimization for the target platform).

Where it gets interesting are hardware dependant instructions
(interrupts and other low level opcodes). Not so easy to translate.
Could be that the translator will only work on user mode code. ( I
recall hearing it won't work on kexts but there were other reasons since
they need to be signed/notarized/whatever).


The other area is if there is a complex function on Intel that isn't on
ARM. Say Intel has instruction to decompress a whole movie encoded in
H.999 but ARM doesn't. Does the translator embed assembly code to do
the job, or does it embed a call to a system service that performs the job?

On the flip side, the translator will not know that a series of opcodes
on Intel are used to perform a task that can be done by one operation on
ARM. (aka: it won't know that Intel code is trying to decode H.999 movie
stream which could be done by a single opcode on ARM).


But overall, I suspect that Rosetta-translated images will have very
good performance. And as they will be linked against native system
services, those will run at full speed.

[Frank Slootweg]

JF Mezei <jfmezei...@vaxination.ca> 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.

> 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?

[Alan Baker]

On 2020-06-25 11:21 a.m., Frank Slootweg wrote:
> JF Mezei <jfmezei...@vaxination.ca> 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/>

[Alan Baker]

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.

[Alan Baker]

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

[nospam]

In article <rd2qog$6q4$3...@dont-email.me>, Alan Baker

> 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.

[Alan Baker]

On 2020-06-25 11:37 a.m., nospam wrote:
> In article <rd2qog$6q4$3...@dont-email.me>, Alan Baker
> <notony...@no.no.no.no> 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.

[Frank Slootweg]

Alan Baker <notony...@no.no.no.no> wrote:
> On 2020-06-25 11:21 a.m., Frank Slootweg wrote:
> > JF Mezei <jfmezei...@vaxination.ca> 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.

[Alan Baker]

On 2020-06-25 12:14 p.m., Frank Slootweg wrote:
> Alan Baker <notony...@no.no.no.no> wrote:
>> On 2020-06-25 11:21 a.m., Frank Slootweg wrote:
>>> JF Mezei <jfmezei...@vaxination.ca> 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.

[Your Name]

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.

[Alan Baker]

Yup.

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

:-)

[Frank Slootweg]

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.

[Alan Browne]

On 2020-06-25 12:33, JF Mezei wrote:
> On 2020-06-25 08:19, Alan Browne wrote:
>
>> as Rosetta does and save that translated code. Theoretically this could
>> result in many portions of code that run faster than the original if the
>> translation designers are very good at taking advantage of features of
>> the new processor absent in the prior.
>
> Very doubtful that the translator will try to optimize things. The ARM

Absurd. The best time to optimize is during compilation or translation.
Then it is done once and for all. The translator designers (conjecture
follows) likely have a huge body of statistics on generated code from a
variety of most used languages. From this they can "Pareto" (and then
some) the things that need to be best optimized to achieve near optimal
code on the translated code.

> processor will optmize the stream of instriuctions when it runs them.
> Rememver that the compiler will have alteady optmized the source code in
> generic fashion (LLVM then does the optimization for the target platform).

If a compiler/linker optimizes for x86 then it is not optimized for
translation to a different target processor. The more "different" the
instruction set, the less an optimization for 1 processor will benefit
that code translated to the other. Could even make it far worse.

> Where it gets interesting are hardware dependant instructions
> (interrupts and other low level opcodes). Not so easy to translate.
> Could be that the translator will only work on user mode code. ( I
> recall hearing it won't work on kexts but there were other reasons since
> they need to be signed/notarized/whatever).

Apps typically use frameworks which handle interrupts and h/w and such.

>
> The other area is if there is a complex function on Intel that isn't on
> ARM. Say Intel has instruction to decompress a whole movie encoded in
> H.999 but ARM doesn't. Does the translator embed assembly code to do
> the job, or does it embed a call to a system service that performs the job?

As now with h.265 if the intel processor is older (like mine on this
machine) then programs like handbrake do a soft decode (or encode).

>
> On the flip side, the translator will not know that a series of opcodes
> on Intel are used to perform a task that can be done by one operation on
> ARM. (aka: it won't know that Intel code is trying to decode H.999 movie
> stream which could be done by a single opcode on ARM).

Translators knows the target instruction set. So it will generate soft
code if it's not in the set. Recall that Rosetta happens on the client
computer and it knows the instruction set available for that target.

[Alan Baker]

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.

[Lewis]

In message <jl4JG.38004$mK4....@fx03.iad> JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2020-06-25 08:19, Alan Browne wrote:

>> as Rosetta does and save that translated code. Theoretically this could
>> result in many portions of code that run faster than the original if the
>> translation designers are very good at taking advantage of features of
>> the new processor absent in the prior.

> Very doubtful that the translator will try to optimize things.

Once again, you cannot get past the first sentence without saying
something entirely absurd and entirely wrong.

> The ARM processor will optmize the stream of instriuctions when it
> runs them.

100% wrong.

Anyone can watch the relevant session from WWDC to see what an idiot you
are being.

--
There are many reasons for being friends with someone. The fact that he's pointing a deadly weapon at you is among the top four. --The Last Continent

[Arlen Holder]

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.

[Arlen Holder]

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.

[Alan Baker]

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?

[Alan Baker]

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.'

[sms]

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.

[Alan Baker]

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.

[nospam]

In article <rdocfg$bsp$1...@dont-email.me>, sms

<scharf...@geemail.com> 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.

[Your Name]

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.

[Your Name]

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.

[sms]

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.

[Alan Baker]

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.

[nospam]

In article <rdpc9h$nhe$1...@dont-email.me>, sms

<scharf...@geemail.com> 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 shit.

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

[JF Mezei]

On 2020-07-03 20:54, nospam 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.

Rosetta 2 is very unlikey to be able to read into a container file,
recognise an NTFS disk structure, recognize an Windows Intel binary
.exe convert it to ARM and somehow be able to relink all Windows systme
calls to a ARM based Windows library that then calls the Intel based
library that has been Rosettaed into ARM based library.

What is more likely to happen is the ability to load the ARM version of
Windows , run it in Parralells (Apple did mention hypervisor capability)
and use whatever 8086 to ARM translation that Microsoft provides with
Windows.

[nospam]

In article <yF5MG.58257$I15....@fx36.iad>, JF Mezei

<jfmezei...@vaxination.ca> 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.

[sms]

On 7/4/2020 1:30 PM, JF Mezei wrote:

<snip?

> What is more likely to happen is the ability to load the ARM version of
> Windows , run it in Parralells (Apple did mention hypervisor capability)
> and use whatever 8086 to ARM translation that Microsoft provides with
> Windows.

I wonder what percentage of Mac users run Windows applications either
via Boot Camp or via a VM?

Every Mac user that I know personally also runs Windows applications
(and some run Linux applications also). These are not low-resource
applications that would work well using virtualization and emulation,
they are commercial, creative, scientific, medical, and educational
applications that are not available under OS-X. But I'm in Silicon
Valley, surrounded by engineers and programmers. In other areas of the
world it could be that only a small percentage of Mac users have a need
to run Windows applications, or they have a separate computer for those
applications.

Every time a manufacturer omits capability from a product they know that
they'll lose some percentage of customer that depended on that omitted
capability, but the cost savings outweigh losing those customers. Often
there is a workaround that involves purchasing some extra device or
adapter. But moving from x86 to ARM is very different than having to buy
an external Ethernet adapter, Thunderbolt to HDMI adapter, USB external
optical drive, USB SD card reader, or Lightning to 3.5mm headphone adapter.

One of the big selling points of the Mac is that you can run OS-X only
applications like Final Cut and Garage Band, but you can also run
Windows applications, for which there is no OS-X equivalent, on the
Mac's higher-end hardware. This capability made it worth paying the
extra money for the Mac hardware. Hopefully there will still be at least
one x86 Macbook Pro, and one x86 Mac Pro, in the product lineup. They
can charge extra for it because the B.O.M. cost will be greater.

[Sn!pe]

sms <scharf...@geemail.com> wrote:

> On 7/4/2020 1:30 PM, JF Mezei wrote:
>
> <snip?
>
> > What is more likely to happen is the ability to load the ARM version of
> > Windows , run it in Parralells (Apple did mention hypervisor capability)
> > and use whatever 8086 to ARM translation that Microsoft provides with
> > Windows.
>
> I wonder what percentage of Mac users run Windows applications either
> via Boot Camp or via a VM?
>

I am one: I use SDR-Console in a Parallels Win10 VM on MacOS Catalina.
I would not want to lose that facility.

>
> Every Mac user that I know personally also runs Windows applications
> (and some run Linux applications also). These are not low-resource
> applications that would work well using virtualization and emulation,
> they are commercial, creative, scientific, medical, and educational
> applications that are not available under OS-X. But I'm in Silicon
> Valley, surrounded by engineers and programmers. In other areas of the
> world it could be that only a small percentage of Mac users have a need
> to run Windows applications, or they have a separate computer for those
> applications.
>
> Every time a manufacturer omits capability from a product they know that
> they'll lose some percentage of customer that depended on that omitted
> capability, but the cost savings outweigh losing those customers. Often
> there is a workaround that involves purchasing some extra device or
> adapter. But moving from x86 to ARM is very different than having to buy
> an external Ethernet adapter, Thunderbolt to HDMI adapter, USB external
> optical drive, USB SD card reader, or Lightning to 3.5mm headphone adapter.
>
> One of the big selling points of the Mac is that you can run OS-X only
> applications like Final Cut and Garage Band, but you can also run
> Windows applications, for which there is no OS-X equivalent, on the
> Mac's higher-end hardware. This capability made it worth paying the
> extra money for the Mac hardware. Hopefully there will still be at least
> one x86 Macbook Pro, and one x86 Mac Pro, in the product lineup. They
> can charge extra for it because the B.O.M. cost will be greater.

--
^Ï^ <https://youtu.be/_kqytf31a8E>

My pet rock Gordon just is.

[nospam]

In article <1ot31ax.1iassgv1y2o0loN%snip...@gmail.com>, Sn!pe

<snip...@gmail.com> wrote:

> > I wonder what percentage of Mac users run Windows applications either
> > via Boot Camp or via a VM?
> >
>
> I am one: I use SDR-Console in a Parallels Win10 VM on MacOS Catalina.
> I would not want to lose that facility.

sdr doesn't require windows.

there are mac & linux options available.

get a raspberry pi and build a standalone device.

[nospam]

In article <rdt079$9i9$1...@dont-email.me>, sms

<scharf...@geemail.com> wrote:

> I wonder what percentage of Mac users run Windows applications either
> via Boot Camp or via a VM?

very low.

> Every Mac user that I know personally also runs Windows applications
> (and some run Linux applications also). These are not low-resource
> applications that would work well using virtualization and emulation,
> they are commercial, creative, scientific, medical, and educational
> applications that are not available under OS-X. But I'm in Silicon
> Valley, surrounded by engineers and programmers. In other areas of the
> world it could be that only a small percentage of Mac users have a need
> to run Windows applications, or they have a separate computer for those
> applications.

you're lying or you don't know very many people. quite likely both.

you're also trolling, as usual.

> Every time a manufacturer omits capability from a product they know that
> they'll lose some percentage of customer that depended on that omitted
> capability, but the cost savings outweigh losing those customers. Often
> there is a workaround that involves purchasing some extra device or
> adapter. But moving from x86 to ARM is very different than having to buy
> an external Ethernet adapter, Thunderbolt to HDMI adapter, USB external
> optical drive, USB SD card reader, or Lightning to 3.5mm headphone adapter.

yep, you very definitely are trolling with your feature removal rubbish.

while it's true boot camp is gone (for now, it could return), very few
people care.

you are deliberately ignoring the *substantial* amount of new
capabilities that apple silicon will *add* which were previously not
possible with intel processors.

among them includes the ability to run iphone and ipad apps natively
(this is *huge*), mac apps running significantly faster, longer battery
life for laptops, easier app development which means better and more
capable apps for users, plus unannounced features that will be known
only when apple silicon macs are ready.

and with regard to windows, windows on arm exists, and it's up to
microsoft, not apple, to port it to apple hardware and license it for
use, at which point, boot camp could return, assuming there is
sufficient demand, which there really isn't.

> One of the big selling points of the Mac is that you can run OS-X only
> applications like Final Cut and Garage Band, but you can also run
> Windows applications, for which there is no OS-X equivalent, on the
> Mac's higher-end hardware.

no, that's not one of the big selling points.

there are very few use cases where there is no mac os equivalent,
namely specialized vertical market applications.

it also hasn't been called 'os-x' in a long time.

> This capability made it worth paying the
> extra money for the Mac hardware. Hopefully there will still be at least
> one x86 Macbook Pro, and one x86 Mac Pro, in the product lineup. They
> can charge extra for it because the B.O.M. cost will be greater.

nonsense.

intel macs are *going* *away*.

apple said 2 years, but history and common sense indicates it will be
much less than that since there is far less demand for an intel mac
now.

macs with apple processors will be faster and more capable, making it a
very tough sell to buy an older and outdated intel mac with more
limited functionality.

there is also no price premium. mac prices are comparable to windows
pcs for similar specs, and in many cases, macs are *less* expensive.

[Sn!pe]

nospam <nos...@nospam.invalid> wrote:

> In article <1ot31ax.1iassgv1y2o0loN%snip...@gmail.com>, Sn!pe
> <snip...@gmail.com> wrote:
>
> > > I wonder what percentage of Mac users run Windows applications either
> > > via Boot Camp or via a VM?
> > >
> >
> > I am one: I use SDR-Console in a Parallels Win10 VM on MacOS Catalina.
> > I would not want to lose that facility.
> >
>
> sdr doesn't require windows.
>
> there are mac & linux options available.
>

Yes there are a few, but I don't like them.

>
> get a raspberry pi and build a standalone device.
>

Why should I, when I have a Mac?

[nospam]

In article <1ot367x.1ymzm8e17x1hlgN%snip...@gmail.com>, Sn!pe

<snip...@gmail.com> wrote:

> > > I am one: I use SDR-Console in a Parallels Win10 VM on MacOS Catalina.
> > > I would not want to lose that facility.
> > >
> >
> > sdr doesn't require windows.
> >
> > there are mac & linux options available.
> >
>
> Yes there are a few, but I don't like them.

then you have a problem.

you're also assuming that windows apps will not work on an apple
silicon mac. that may be true on day one, but does not mean it will
always be that way.

if there's sufficient demand for running x86 windows apps, then someone
will provide a solution.

> > get a raspberry pi and build a standalone device.
> >
>
> Why should I, when I have a Mac?

because it's a dedicated device that uses very little power, without
the need to leave a mac on all the time.

[Sn!pe]

nospam <nos...@nospam.invalid> wrote:

> In article <1ot367x.1ymzm8e17x1hlgN%snip...@gmail.com>, Sn!pe
> <snip...@gmail.com> wrote:
>
> > > > I am one: I use SDR-Console in a Parallels Win10 VM on MacOS Catalina.
> > > > I would not want to lose that facility.
> > > >
> > >
> > > sdr doesn't require windows.
> > >
> > > there are mac & linux options available.
> > >
> >
> > Yes there are a few, but I don't like them.
> >
>
> then you have a problem.
>
> you're also assuming that windows apps will not work on an apple
> silicon mac. that may be true on day one, but does not mean it will
> always be that way.
>
> if there's sufficient demand for running x86 windows apps, then someone
> will provide a solution.
>

It isn't a problem, my choice of software works perfectly, thank you.
Also, I'm not making any assumptions. I was simply giving an answer
to sms's question (that you snipped). No big deal: this conversation
is just a data point, not a crusade.

It would be a pity If I was inhibited from buying a new ARM powered
Mac, but OTOH I already run a legacy Mac for 32 bit software. If
someone is far-sighted enough to provide a solution, then that will
be one less obstacle to me eventually replacing my existing Mac.

> > > get a raspberry pi and build a standalone device.
> > >
> >
> > Why should I, when I have a Mac?
>
> because it's a dedicated device that uses very little power,
> without the need to leave a mac on all the time.
>

That argument doesn't influence me.

[nospam]

In article <1ot37v1.1q4iztsfjvx9bN%snip...@gmail.com>, Sn!pe

<snip...@gmail.com> wrote:

> > > > > I am one: I use SDR-Console in a Parallels Win10 VM on MacOS
> > > > > Catalina. I would not want to lose that facility.
> > > > >
> > > >
> > > > sdr doesn't require windows.
> > > >
> > > > there are mac & linux options available.
> > > >
> > > Yes there are a few, but I don't like them.
> >
> > then you have a problem.
> >
> > you're also assuming that windows apps will not work on an apple
> > silicon mac. that may be true on day one, but does not mean it will
> > always be that way.
> >
> > if there's sufficient demand for running x86 windows apps, then someone
> > will provide a solution.
> >
>
> It isn't a problem, my choice of software works perfectly, thank you.

it might work perfectly now, but when it comes time to replace your
mac, you *will* have a problem.

> Also, I'm not making any assumptions.

you are making the assumption that your windows sdr app will not work

on an apple silicon mac.

as i said, that might be the case initially, but it's not necessarily
forever.

> I was simply giving an answer
> to sms's question (that you snipped). No big deal: this conversation
> is just a data point, not a crusade.

sms is trolling.