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

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

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

apple didn't orphan anything.

Hi nospam,

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

But if it runs just as well...

...why would you care?

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

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

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

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

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

apple didn't orphan anything.
Hi nospam,

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

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

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

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

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

Paul

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.

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 bull**** from trolls like Char Jackson is.

Trolls dispute facts that they themselves don't bother to back up with any
facts themselves... they just bull**** 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.

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

apple didn't orphan anything.
Hi nospam,

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

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

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

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

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

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.

Arlen Holder wrote:
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 bull**** from trolls like Char Jackson is.

Trolls dispute facts that they themselves don't bother to back up with any
facts themselves... they just bull**** 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 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

In article , JF Mezei
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.

In article , Paul
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.

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

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.

In alt.comp.os.windows-10 nospam wrote:
In article , Paul
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!

--
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| |
\ _ /
( )

In article , Ant
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*.

In article , JF Mezei
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 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?

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

windows on arm already exists, although x86 emulation sucks.

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

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

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

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

There already is a version of Windows for ARM:

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


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?