Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #132884 > unrolled thread

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

Back to article view | Back to comp.sys.mac.system

Contents

  Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-24 04:38 +0000
    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-23 21:45 -0700
      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Your Name <YourName@YourISP.com> - 2020-06-24 17:10 +1200
        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Paul <nospam@needed.invalid> - 2020-06-24 02:05 -0400
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-24 01:47 -0700
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-24 13:29 +0000
        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Browne <bitbucket@blackhole.com> - 2020-06-24 09:42 -0400
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-24 09:45 -0400
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Browne <bitbucket@blackhole.com> - 2020-06-24 13:10 -0400
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-24 14:42 -0400
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Paul <nospam@needed.invalid> - 2020-06-24 10:02 -0400
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-24 10:24 -0400
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-24 14:38 +0000
                Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-24 14:40 +0000
                  Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-24 16:48 -0700
                  Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-25 01:53 +0000
                    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-25 11:34 -0700
                Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-24 16:47 -0700
                  Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Paul <nospam@needed.invalid> - 2020-06-24 20:17 -0400
                    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-25 02:03 +0000
                    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Char Jackson <none@none.invalid> - 2020-06-24 23:34 -0500
                      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Paul <nospam@needed.invalid> - 2020-06-25 00:46 -0400
                        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-25 05:18 +0000
                          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Paul <nospam@needed.invalid> - 2020-06-25 01:49 -0400
                        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Your Name <YourName@YourISP.com> - 2020-06-25 17:47 +1200
                          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-25 02:50 -0400
                          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Browne <bitbucket@blackhole.com> - 2020-06-25 08:24 -0400
                        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-25 06:48 -0400
                          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs ant@zimage.comANT (Ant) - 2020-06-25 07:34 -0500
                            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-25 08:39 -0400
                        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-25 11:34 -0700
                          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-25 14:37 -0400
                            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-25 11:43 -0700
                          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Your Name <YourName@YourISP.com> - 2020-06-26 08:40 +1200
                            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-25 13:42 -0700
                      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-25 04:46 +0000
                    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Browne <bitbucket@blackhole.com> - 2020-06-25 08:19 -0400
                      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-25 12:33 -0400
                        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Browne <bitbucket@blackhole.com> - 2020-06-26 10:53 -0400
                        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Lewis <g.kreme@gmail.com.dontsendmecopies> - 2020-06-26 23:39 +0000
                      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-27 00:39 +0000
                        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-26 18:01 -0700
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-24 14:29 +0000
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Browne <bitbucket@blackhole.com> - 2020-06-24 13:41 -0400
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Browne <bitbucket@blackhole.com> - 2020-06-24 13:55 -0400
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-24 14:42 -0400
                Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-24 17:15 -0400
                  Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-24 17:56 -0400
                    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-25 02:31 -0400
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Your Name <YourName@YourISP.com> - 2020-06-25 13:06 +1200
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-25 02:24 +0000
        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs sms <scharf.steven@geemail.com> - 2020-07-03 15:46 -0700
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-07-03 15:53 -0700
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Your Name <YourName@YourISP.com> - 2020-07-04 15:14 +1200
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs sms <scharf.steven@geemail.com> - 2020-07-04 00:49 -0700
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-07-04 01:15 -0700
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-07-04 08:09 -0400
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-07-03 20:54 -0400
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-07-04 16:30 -0400
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-07-04 17:12 -0400
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs sms <scharf.steven@geemail.com> - 2020-07-05 09:47 -0700
                Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs snipeco.2@gmail.com (Sn!pe) - 2020-07-05 19:23 +0100
                  Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-07-05 15:50 -0400
                    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs snipeco.2@gmail.com (Sn!pe) - 2020-07-05 21:00 +0100
                      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-07-05 16:11 -0400
                        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs snipeco.2@gmail.com (Sn!pe) - 2020-07-05 21:51 +0100
                          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-07-05 16:57 -0400
                Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-07-05 15:50 -0400
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Your Name <YourName@YourISP.com> - 2020-07-04 15:11 +1200
      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-24 15:55 -0400
        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-24 16:04 -0400
        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-24 16:51 -0700
    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-24 15:04 -0400
      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-24 15:12 -0400
        Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-24 18:07 -0400
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-24 18:27 -0400
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-25 02:41 -0400
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-25 06:48 -0400
                Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs JF Mezei <jfmezei.spamnot@vaxination.ca> - 2020-06-25 10:53 -0400
                  Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs nospam <nospam@nospam.invalid> - 2020-06-25 11:11 -0400
          Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Frank Slootweg <this@ddress.is.invalid> - 2020-06-25 18:21 +0000
            Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-25 11:32 -0700
              Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Frank Slootweg <this@ddress.is.invalid> - 2020-06-25 19:14 +0000
                Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-25 12:56 -0700
                  Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Frank Slootweg <this@ddress.is.invalid> - 2020-06-26 12:22 +0000
                    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-26 12:21 -0700
    Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Arlen Holder <arlenholder@newmachine.com> - 2020-06-27 00:33 +0000
      Re: Boot Camp freeware to dual boot Windows & MacOS is dead on all new ARM-core Macs Alan Baker <notonyourlife@no.no.no.no> - 2020-06-26 18:02 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#132934

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

[toc] | [prev] | [next] | [standalone]

#132935

Char Jackson wrote:
> On Wed, 24 Jun 2020 20:17:57 -0400, Paul <nospam@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.

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

    Paul

[toc] | [prev] | [next] | [standalone]

#132937

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.

[toc] | [prev] | [next] | [standalone]

#132939

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

[toc] | [prev] | [next] | [standalone]

#132938

On 2020-06-25 04:46:05 +0000, Paul said:
> Char Jackson wrote:
>> On Wed, 24 Jun 2020 20:17:57 -0400, Paul <nospam@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.
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#132942

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.

[toc] | [prev] | [next] | [standalone]

#132946

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.

[toc] | [prev] | [next] | [standalone]

#132944

In article <rd1a68$p39$1@dont-email.me>, Paul <nospam@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.

[toc] | [prev] | [next] | [standalone]

#132947

In alt.comp.os.windows-10 nospam <nospam@nospam.invalid> wrote:
> In article <rd1a68$p39$1@dont-email.me>, Paul <nospam@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.

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

[toc] | [prev] | [next] | [standalone]

#132948

In article <KNKdneJbl9lKBGnDnZ2dnUU7-YudnZ2d@earthlink.com>, Ant
<ant@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*.

[toc] | [prev] | [next] | [standalone]

#132957

On 2020-06-24 9:46 p.m., Paul wrote:
> Char Jackson wrote:
>> On Wed, 24 Jun 2020 20:17:57 -0400, Paul <nospam@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.
> 
> This would be running an x86 Windows OS on a PowerPC platform.
> Yes, it's slow.
> 
>     Paul
> 

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

[toc] | [prev] | [next] | [standalone]

#132958

In article <rd2qog$6q4$3@dont-email.me>, Alan Baker
<notonyourlife@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.

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

[toc] | [prev] | [next] | [standalone]

#132959

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

[toc] | [prev] | [next] | [standalone]

#132962

On 2020-06-25 18:34:55 +0000, Alan Baker said:
> On 2020-06-24 9:46 p.m., Paul wrote:
>> Char Jackson wrote:
>>> On Wed, 24 Jun 2020 20:17:57 -0400, Paul <nospam@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.
>> 
>> This would be running an x86 Windows OS on a PowerPC platform.
>> Yes, it's slow.
>> 
>>    Paul
> 
> That was done with a product called "VirtualPC" was it not?

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

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

[toc] | [prev] | [next] | [standalone]

#132963

On 2020-06-25 1:40 p.m., Your Name wrote:
> On 2020-06-25 18:34:55 +0000, Alan Baker said:
>> On 2020-06-24 9:46 p.m., Paul wrote:
>>> Char Jackson wrote:
>>>> On Wed, 24 Jun 2020 20:17:57 -0400, Paul <nospam@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.
>>>
>>> This would be running an x86 Windows OS on a PowerPC platform.
>>> Yes, it's slow.
>>>
>>>    Paul
>>
>> That was done with a product called "VirtualPC" was it not?
> 
> Even back in the 68K Mac era there was SoftPC (later renamed RealPC), 
> but VirtualPC was the best known product for Windows emulation.
> 
> There also used to be add-on cards to give Windows capability (Apple 
> even sold a Mac with one built-in) - basically a whole PC on a card.
> 
> 

Yup.

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

:-)

[toc] | [prev] | [next] | [standalone]

#132936

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.

[toc] | [prev] | [next] | [standalone]

#132945

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

[toc] | [prev] | [next] | [standalone]

#132951

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.

[toc] | [prev] | [next] | [standalone]

#132967

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.

[toc] | [prev] | [next] | [standalone]

#132970

In message <jl4JG.38004$mK4.12163@fx03.iad> JF Mezei <jfmezei.spamnot@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

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.sys.mac.system

csiph-web