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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#132973

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.

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

#132974

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?

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

#132898

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.

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

#132909

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.

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

#132910

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.

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

#132912

In article <SeMIG.10594$Li1.6185@fx11.iad>, Alan Browne
<bitbucket@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.

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

#132920

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

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

#132921

In article <5oPIG.51075$AN2.43683@fx46.iad>, JF Mezei
<jfmezei.spamnot@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????

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

#132940

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

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

#132929

On 2020-06-24 14:02:42 +0000, Paul said:
> 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

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.

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

#132932

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.

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

#133186

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.

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

#133187

On 2020-07-03 3:46 p.m., sms wrote:
> On 6/23/2020 10:10 PM, Your Name wrote:
> 
> <snip>
> 
>> With an ARM Mac, it's going to have to be emulation rather than 
>> virtualisation. Code will have to be translated on the run, which 
>> means it will be slower. Whether that noticeable to the user will 
>> depend on what they're doing and how much more powerful the ARM Macs are.
> 
> Ah, shades of CMS (Code Morphing Software) to emulate an x86 on a low 
> powe RISC processor. Definitely a performance hit, but if you can throw 
> enough CPU power at it then the performance hit may be of no consequence 
> <https://courses.cs.washington.edu/courses/cse548/08wi/papers/transmeta.pdf>. 
> 
> 
> Besides performance, another issue is compatibility. I recall being at a 
> class where the development platform, Windows-only, was being run by 
> some Mac users using Bootcamp, and by some Mac users running Windows in 
> a virtual machine with Parallels. The latter had significant 
> compatibility issues in terms of the I/O ports (USB). The next time the 
> class was held they informed people in advance, "Windows 7 or 8 running 
> natively, not in a virtual machine."
> 
> The bottom line is that if you're running Windows on a Mac, using 
> Bootcamp is a much better solution that using a Virtual Machine. 
> Obviously that is going away on ARM-based Macs.

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

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

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

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

#133192

On 2020-07-03 22:53:28 +0000, Alan Baker said:
> On 2020-07-03 3:46 p.m., sms wrote:
>> On 6/23/2020 10:10 PM, Your Name wrote:
>> 
>> <snip>
>> 
>>> With an ARM Mac, it's going to have to be emulation rather than 
>>> virtualisation. Code will have to be translated on the run, which means 
>>> it will be slower. Whether that noticeable to the user will depend on 
>>> what they're doing and how much more powerful the ARM Macs are.
>> 
>> Ah, shades of CMS (Code Morphing Software) to emulate an x86 on a low 
>> powe RISC processor. Definitely a performance hit, but if you can throw 
>> enough CPU power at it then the performance hit may be of no 
>> consequence 
>> <https://courses.cs.washington.edu/courses/cse548/08wi/papers/transmeta.pdf>. 
>> 
>> 
>> Besides performance, another issue is compatibility. I recall being at 
>> a class where the development platform, Windows-only, was being run by 
>> some Mac users using Bootcamp, and by some Mac users running Windows in 
>> a virtual machine with Parallels. The latter had significant 
>> compatibility issues in terms of the I/O ports (USB). The next time the 
>> class was held they informed people in advance, "Windows 7 or 8 running 
>> natively, not in a virtual machine."
>> 
>> The bottom line is that if you're running Windows on a Mac, using 
>> Bootcamp is a much better solution that using a Virtual Machine. 
>> Obviously that is going away on ARM-based Macs.
> 
> That would very much hinge on the definition of "better" for a given purpose.
> 
> Is a Mac booted into Windows using Bootcamp going to be more perfectly 
> compatible with access to things such as USB ports? Of course.
> 
> But that leaves the question of whether that compatibility is important 
> for the purposes for which the user wants to run Windows in the first 
> place. For some users, the complete integration of a Windows 
> application into an otherwise all Mac OS environment will be much more 
> important.

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

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

#133200

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.

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

#133202

On 2020-07-04 12:49 a.m., sms wrote:
> On 7/3/2020 3:53 PM, Alan Baker wrote:
> 
> <snip>
> 
>> But that leaves the question of whether that compatibility is 
>> important for the purposes for which the user wants to run Windows in 
>> the first place. For some users, the complete integration of a Windows 
>> application into an otherwise all Mac OS environment will be much more 
>> important.
> 
> Perhaps. But the people I know running Windows applications on a Mac are 
> running apps that need a lot of compute power. Autocad for Windows 
> (better than the Mac version). AVID Media Composer for Windows (better 
> than the Mac version). Solidworks (no Mac version). Altium (no Mac 
> version). There's also the question of whether the VM is able to make 
> full use of high-end graphics chips. "graphics performance in a VM 
> suffers because Windows is unable to use the native drivers and instead 
> has to pass everything through virtualized graphics adapters."
> 
> The bottom line is that users that bought a Macbook Pro with the intent 
> of running high-resource Windows applications are probably not going to 
> buy an ARM Macbook. Back when that whole trend started there were slim 
> pickings for well-designed Windows laptops, now that's no longer the 
> case, so it's not a big deal for most of those users. The one exception 
> is those that do NLE and want to use Final Cut Pro under OS-X and AVID 
> Media Composer under Windows.

You tell yourself whatever you need to...

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

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

#133203

In article <rdpc9h$nhe$1@dont-email.me>, sms
<scharf.steven@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.

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

#133189

In article <rdocfg$bsp$1@dont-email.me>, sms
<scharf.steven@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.

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

#133233

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.

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

#133242

In article <yF5MG.58257$I15.21357@fx36.iad>, JF Mezei
<jfmezei.spamnot@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.

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

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

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

csiph-web