On Tuesday, August 17, 2021 at 9:23:00 AM UTC+12, Michael S wrote:
>
> According to my understanding, not many apps are readily available on WinArm in native form
> apart from Microsoft Office suite and Firefox.

On top of which, Microsoft’s x86 emulator only handles 32-bit code, not AMD64. The only thing that makes that palatable is the fact that much of Windows code never made the transition to 64-bit anyway.

> But in theory, most of in-house stuff nowadays is written in .Net ...

What, not Dotnet Core? What happened to Win64? Silverlight? WinRT? UWP? How many versions of “Project Reunion” have there been?

I don’t think Windows developers can say with any certainty right now which of Microsoft’s many platform APIs is the “core” one going forward...

On 8/18/2021 4:32 AM, Lawrence D’Oliveiro wrote:
> On Tuesday, August 17, 2021 at 9:23:00 AM UTC+12, Michael S wrote:
>> But in theory, most of in-house stuff nowadays is written in .Net ...
>
> What, not Dotnet Core? What happened to Win64? Silverlight? WinRT? UWP? How many versions of “Project Reunion” have there been?
>
> I don’t think Windows developers can say with any certainty right now which of Microsoft’s many platform APIs is the “core” one going forward...

The applications Michael is talking about are doing fine.

C# or VB.NET winform or WPF app acting as GUI for some business
application. "VB6 replacement"

Code should work unchanged from 1.0 (winform) / 3.0 (WPF) to 6.0.

So no problem for them.

The problems are in the more "exotic" sides of .NET.

..NET code running in the browser (SL) got canned. Just like
Java applets, Adobe Flash and other similar technologies. SL
never got much traction anyway.

The entire Metro/UWP and Xamarin/MAUI story is a big mess. But their
adoptation has so far been rather limited.

Arne

In article <184ecfb7-7efa-45e4-a8db-a1dcd565d91fn@googlegroups.com>,
lawrencedo99@gmail.com (Lawrence D_Oliveiro) wrote:

> On top of which, Microsoft's x86 emulator only handles 32-bit code,
> not AMD64. The only thing that makes that palatable is the fact
> that much of Windows code never made the transition to 64-bit
> anyway.

That is due to change, but it hasn't happened yet.

> I don_t think Windows developers can say with any certainty right
> now which of Microsoft's many platform APIs is the _core_ one going
> forward...

Indeed. I've never regretted sticking to portable C and C++. Fortunately,
my management are almost as suspicious of marketing-driven programming
innovations as I am.

John

In article <sfhs0n$4qq$1@dont-email.me>, morrisj@epsilon3.comcon (Jay E.
Morris) wrote:

> > A lot of Android tablets are sold, but they're mostly "family
> > devices" for use by kids, very cheap, and not very powerful.

> Don't tell the US Air Force that. Android tablets have been the
> standard for at least 10 years. The just selected the Samsung S2
> ruggedized tablet for flight line use and logistical operations.

I said "mostly". The USAF has only about 675,000 people, and Android
tablet sales are measured in tens of millions per quarter.

Got a link to the ruggedized tablet? The nearest I can find is a 2016
model that's been discontinued:
<https://www.gsmarena.com/samsung_galaxy_tab_s2_9_7-7438.php>

John

On 8/18/2021 11:27 AM, John Dallman wrote:
> In article <sfhs0n$4qq$1@dont-email.me>, morrisj@epsilon3.comcon (Jay E.
> Morris) wrote:
>
>>> A lot of Android tablets are sold, but they're mostly "family
>>> devices" for use by kids, very cheap, and not very powerful.
>
>> Don't tell the US Air Force that. Android tablets have been the
>> standard for at least 10 years. The just selected the Samsung S2
>> ruggedized tablet for flight line use and logistical operations.
>
> I said "mostly". The USAF has only about 675,000 people, and Android
> tablet sales are measured in tens of millions per quarter.
>
> Got a link to the ruggedized tablet? The nearest I can find is a 2016
> model that's been discontinued:
> <https://www.gsmarena.com/samsung_galaxy_tab_s2_9_7-7438.php>
>
> John
>

I shouldn't have said just as it was just before I retired three years
that they did that. Don't know how that fell out of my head. Couldn't
tell you what it's currently running on but could be part of the Air
Force Research Laboratory's Android Team Awareness Kit.

https://en.wikipedia.org/wiki/Android_Team_Awareness_Kit

On Wednesday, August 18, 2021 at 8:32:37 PM UTC+12, Lawrence D’Oliveiro wrote:
> On Tuesday, August 17, 2021 at 9:23:00 AM UTC+12, Michael S wrote:
> >
> > According to my understanding, not many apps are readily available on WinArm in native form
> > apart from Microsoft Office suite and Firefox.
> On top of which, Microsoft’s x86 emulator only handles 32-bit code, not AMD64. The only thing that makes that palatable is the fact that much of Windows code never made the transition to 64-bit anyway.

That's because for most applications unless you need to allocate more than 2GB of RAM there is little benefit in being 64bit - all it really does is increase memory consumption a bit and probably CPU cache misses as well.

> > But in theory, most of in-house stuff nowadays is written in .Net ...
>
> What, not Dotnet Core? What happened to Win64? Silverlight? WinRT? UWP? How many versions of “Project Reunion” have there been?
>
> I don’t think Windows developers can say with any certainty right now which of Microsoft’s many platform APIs is the “core” one going forward...

..net core is just a newer version of .net same as Java 7 is a newer version of Java. Microsoft has actually dropped the 'core' branding now - the most recent version is simply called .net 5. Win64 is still around and still enhanced - lots of stuff is built against the C API and it will never go away. Silverlight died for the same reason Flash did. WinRT is still around. As is UWP.

And, importantly, all of these things are still supported on current windows. Even the VB6 runtime is still supported on current windows. This is a substantially better situation than on Linux where you'd have a hard time building a Qt 3 application from source on a recent Ubuntu release and running an existing Qt 3 binary is impossible unless it happened to be statically linked (and even then there is a good chance it won't work properly)

It would sure be nice if Microsoft would just pick a UI toolkit and stick with it but Microsoft is by no means alone when it comes to this problem.

On 8/18/2021 8:45 PM, David Goodwin wrote:
> On Wednesday, August 18, 2021 at 8:32:37 PM UTC+12, Lawrence
> D’Oliveiro wrote:
>> On Tuesday, August 17, 2021 at 9:23:00 AM UTC+12, Michael S wrote:
>>>
>>> According to my understanding, not many apps are readily
>>> available on WinArm in native form apart from Microsoft Office
>>> suite and Firefox.
>> On top of which, Microsoft’s x86 emulator only handles 32-bit code,
>> not AMD64. The only thing that makes that palatable is the fact
>> that much of Windows code never made the transition to 64-bit
>> anyway.
>
> That's because for most applications unless you need to allocate more
> than 2GB of RAM there is little benefit in being 64bit - all it
> really does is increase memory consumption a bit and probably CPU
> cache misses as well.

Floating Point is also very different between 32 bit and 64 bit.

And virtual memory space does not only apply to RAM but can also
be mapped to a file.

But yes all 3 cases are probably exceptions.

>>> But in theory, most of in-house stuff nowadays is written in .Net
>>> ...
>>
>> What, not Dotnet Core? What happened to Win64? Silverlight? WinRT?
>> UWP? How many versions of “Project Reunion” have there been?
>>
>> I don’t think Windows developers can say with any certainty right
>> now which of Microsoft’s many platform APIs is the “core” one going
>> forward...
>
> .net core is just a newer version of .net same as Java 7 is a newer
> version of Java. Microsoft has actually dropped the 'core' branding
> now - the most recent version is simply called .net 5.

..NET Core and .NET FX were two different .NET flavors.

..NET FX got discontinued and .NET Core 3 evolved into .NET 5.

..NET Core 3 to .NET 5 is a normal version upgrade like Java 6 to 7.

But .NET FX 4 to .NET 5 is a somewhat bigger upgrade - some things
are different and some features were dropped.

So some .NET FX 4 users may need to stay or rewrite.

But not the typical .NET winform or WPF GUI.

> It would sure be nice if Microsoft would just pick a UI toolkit and
> stick with it but Microsoft is by no means alone when it comes to
> this problem.

Java went: AWT -> Swing -> JavaFX.

Arne

On Monday, August 16, 2021 at 4:53:08 PM UTC+12, dgso...@gmail.com wrote:
> Additionally, current Windows on ARM isn't their third or fourth attempt - its their first.
> They ported Windows NT to ARM once and have made it available in various editions
> ever since as they've tried to find a niche for it.

Fitting in with Einstein’s definition of insanity: trying the same thing over and over, hoping for a different outcome each time.

On Monday, September 20, 2021 at 10:41:54 AM UTC+12, Lawrence D’Oliveiro wrote:
> On Monday, August 16, 2021 at 4:53:08 PM UTC+12, dgso...@gmail.com wrote:
> > Additionally, current Windows on ARM isn't their third or fourth attempt - its their first.
> > They ported Windows NT to ARM once and have made it available in various editions
> > ever since as they've tried to find a niche for it.
> Fitting in with Einstein’s definition of insanity: trying the same thing over and over, hoping for a different outcome each time.

Good thing they've not been trying the same thing over and over then!

The initial ARM offering (Windows RT) was a variant of Windows 8 that could only run apps from the windows store. There was a version of Visual C++ that could target this variant of windows but I don't know if applications built with it could be distributed via the Windows Store or if Microsoft required "modern"-style apps written in .net. This product ultimately failed for reasons that should have been obvious to everyone within Microsoft before the first device running it was sold.

Later there was Windows 10 IoT Edition. This is just a rebrand of Windows Embedded which has been around in various forms since the 90s. The difference here is its now available on ARM in addition to whatever platforms it was previously available for. The IoT Core variant was made available for free on Raspberry Pis for hobbyist use. I've no idea if Windows IoT for ARM could be considered a failure as I doubt Microsoft publishes sales data for something like this. Given its been around since the 90s I assume if it wasn't making money they would have given up on it by now.

The most recent consumer-oriented effort is just Windows 10 (or 11) but on an ARM processor. Apparently it works fine. Its got some sort of binary translation/emulation thing (like Apples Rosetta 2 I guess) that lets it run unmodified x86 software. If an ARM Windows laptop appears to be just another laptop running Windows to end users then I'd say Microsoft has done all they can. Whether it would then be successful is down to the companies making the hardware it runs on. Seems unknown whether Qualcomm can be bothered trying to compete with Apple in making a high performance low power ARM CPU.

In article <6851ade5-b1ad-4062-b37e-1dd747ec5081n@googlegroups.com>,
dgsoftnz@gmail.com (David Goodwin) wrote:

> The most recent consumer-oriented effort is just Windows 10 (or 11)
> but on an ARM processor. Apparently it works fine.

It does, within the limits of its CPU power. The currently available
devices do not have leading-edge ARM processors.

> Its got some sort of binary translation/emulation thing (like
> Apples Rosetta 2 I guess) that lets it run unmodified x86 software.

That works too, although it's a bit slow. It is a binary translator, as
are all these things nowadays: instruction-by-instruction emulation is
Too Slow.

> If an ARM Windows laptop appears to be just another laptop running
> Windows to end users then I'd say Microsoft has done all they can.
> Whether it would then be successful is down to the companies making
> the hardware it runs on. Seems unknown whether Qualcomm can be bothered

> trying to compete with Apple in making a high performance low power
> ARM CPU.

Qualcomm's CEO has /claimed/ he'll deliver performance equivalent to
Apple's M1 next year. I have no idea if Qualcomm will manage this, but
there is no magic in the M1, and the same approach could be used by any
manufacturer prepared to go to the necessary effort.

John

On Wednesday, September 22, 2021 at 6:54:24 PM UTC+12, John Dallman wrote:
> In article <6851ade5-b1ad-4062...@googlegroups.com>,
> dgso...@gmail.com (David Goodwin) wrote:
>
>> The most recent consumer-oriented effort is just Windows 10 (or 11)
>> but on an ARM processor. Apparently it works fine.
>
> It does, within the limits of its CPU power. The currently available
> devices do not have leading-edge ARM processors.

It’s worth noting that these are not “ARM processors” in any general sense, but only a specific family of Qualcomm Snapdragon chips. Remember, the ARM ecosystem is huge, with a range of companies and volume of unit shipments that completely dwarf x86. For example, the Raspberry π runs a Broadcom processor. Samsung also make their own ARM chips.. And of course we know about Apple’s ones.

The problem is that ARM lacks a standardized BIOS layer like has been a traditional part of x86. Without such a system, Windows is lost. Linux has its “device tree” system for coping with that, which does mean compiling custom kernels for different families of SoCs. But that’s a lot easier than a Windows compile.

>> Its got some sort of binary translation/emulation thing (like
>> Apples Rosetta 2 I guess) that lets it run unmodified x86 software.

32-bit only, as I pointed out.

In article <cd94fd57-441f-4af0-8109-2b4b6d145306n@googlegroups.com>,
lawrencedo99@gmail.com (Lawrence D_Oliveiro) wrote:

> It_s worth noting that these are not _ARM processors_ in any
> general sense, but only a specific family of Qualcomm Snapdragon
> chips. Remember, the ARM ecosystem is huge, with a range of
> companies and volume of unit shipments that completely dwarf x86.
> For example, the Raspberry Pi runs a Broadcom processor. Samsung
> also make their own ARM chips. And of course we know about Apple's
> ones.

My view of ARM processors is concentrated on the fast 64-bit ones for
applications, mobile and otherwise, rather than embedded or other areas.
Within that:

Qualcomm's cores have their own branding, but are based on ARM Holding
core designs. Qualcomm make a fuss about their custom work but observing
the changes in performance over a few generations, it tracks closely with
ARM's Cortex-A7x series core designs. I've recently got to use Android
devices with ARM Cortex-X1 cores, in Snapdragon 888 SoCs, and they are
surprisingly close to Apple M1 performance.

Broadcom's chips use ARM Cortex-A cores, and they don't conceal that.

Samsung used to design their own cores, in the Exynos family, but they
used ARM Cortex-A cores for the American and South Korean markets, and
have recently given up on Exynos.

Apple's designs are entirely their own, of course. But lots of other SoC
manufacturers just use ARM Cortex-Ax cores.

> The problem is that ARM lacks a standardized BIOS layer like has
> been a traditional part of x86. Without such a system, Windows is
> lost.

That is, indeed, a big problem. Microsoft could produce a standard, but
are rather tentative about ARM in some ways.

John

On Wednesday, September 22, 2021 at 11:02:17 PM UTC+12, John Dallman wrote:
> In article <cd94fd57-441f-4af0...@googlegroups.com>,
> lawren...@gmail.com (Lawrence D_Oliveiro) wrote:
>
> > It_s worth noting that these are not _ARM processors_ in any
> > general sense, but only a specific family of Qualcomm Snapdragon
> > chips. Remember, the ARM ecosystem is huge, with a range of
> > companies and volume of unit shipments that completely dwarf x86.
> > For example, the Raspberry Pi runs a Broadcom processor. Samsung
> > also make their own ARM chips. And of course we know about Apple's
> > ones.
> My view of ARM processors is concentrated on the fast 64-bit ones for
> applications, mobile and otherwise, rather than embedded or other areas.
> Within that:
>
> Qualcomm's cores have their own branding, but are based on ARM Holding
> core designs. Qualcomm make a fuss about their custom work but observing
> the changes in performance over a few generations, it tracks closely with
> ARM's Cortex-A7x series core designs. I've recently got to use Android
> devices with ARM Cortex-X1 cores, in Snapdragon 888 SoCs, and they are
> surprisingly close to Apple M1 performance.
>
> Broadcom's chips use ARM Cortex-A cores, and they don't conceal that.
>
> Samsung used to design their own cores, in the Exynos family, but they
> used ARM Cortex-A cores for the American and South Korean markets, and
> have recently given up on Exynos.
>
> Apple's designs are entirely their own, of course. But lots of other SoC
> manufacturers just use ARM Cortex-Ax cores.
> > The problem is that ARM lacks a standardized BIOS layer like has
> > been a traditional part of x86. Without such a system, Windows is
> > lost.
> That is, indeed, a big problem. Microsoft could produce a standard, but
> are rather tentative about ARM in some ways.

I've never got my hands on any Windows-compatible ARM hardware but as
they're not giving out the source code I assume they're currently requiring a
standard pre-boot environment (UEFI?) similar to how they required ARC
firmware on MIPS, PowerPC and Alpha hardware capable of running
Windows NT 3.x and 4.0.

For other hardware differences Windows NT has a Hardware Abstraction
Layer which was used in the past for handling handling odd or not quite
standard hardware. I guess if an ARM board doesn't quite meet the specs
a custom HAL implementation may solve the problem.

I guess Microsoft has the power to dictate requirements here given Windows
on ARM isn't a retail product. The only way to get it is with hardware so
its on the manufacturer to design their widget to be compatible with Windows
in one way or another if they want to sell it with Windows on it.

On Wednesday, September 22, 2021 at 11:55:56 PM UTC+12, dgso...@gmail.com wrote:
> I guess Microsoft has the power to dictate requirements here ...

To whom? Nobody else seems to be bothering with Windows-on-ARM.

=?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> wrote:
>On Wednesday, September 22, 2021 at 11:55:56 PM UTC+12, dgso...@gmail.com wrote:
>> I guess Microsoft has the power to dictate requirements here ...
>
>To whom? Nobody else seems to be bothering with Windows-on-ARM.

Just like they didn't bother with Windows on Alpha.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 9/23/21 7:41 AM, Scott Dorsey wrote:
> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?= <lawrencedo99@gmail.com> wrote:
>> On Wednesday, September 22, 2021 at 11:55:56 PM UTC+12, dgso...@gmail.com wrote:
>>> I guess Microsoft has the power to dictate requirements here ...
>>
>> To whom? Nobody else seems to be bothering with Windows-on-ARM.
>
> Just like they didn't bother with Windows on Alpha.

When Windows on ARM comes in a turnkey, out-of-the-box package
with MS Office pre-loaded and costs less than x86/64 businesses
will take it up.

The majority of users don't care about processors. They only
care about getting the job done. Alpha Windows was released
before any applications were ready. Most people I knew who
actually bought one ended up dumping Windows and running Linux.
Why? Because Linux had applications.

I honestly believe VMS never had that problem because VMS users
run locally developed applications and not COTS.

bill

On 9/22/21 8:37 PM, Lawrence D’Oliveiro wrote:
> On Wednesday, September 22, 2021 at 11:55:56 PM UTC+12, dgso...@gmail.com wrote:
>> I guess Microsoft has the power to dictate requirements here ...
>
> To whom? Nobody else seems to be bothering with Windows-on-ARM.

Perhaps, but Microsoft makes their own hardware and is still releasing
new ARM-based devices:

<https://arstechnica.com/gadgets/2021/09/arm-based-surface-pro-x-gets-an-899-wi-fi-only-model-but-few-other-upgrades/>

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

I think someone mentioned up-thread that the x86 emulation is 32-bit
only, but that is changing and will be in Windows 11:

<https://blogs.windows.com/windows-insider/2020/12/10/introducing-x64-emulation-in-preview-for-windows-10-on-arm-pcs-to-the-windows-insider-program/>

Maybe this will all fizzle and end up like Windows on Alpha or Itanium.
But Microsoft is big enough that a small percentage of Windows devices
running on ARM is still a big market, so it's not at all obvious this
will follow the same pattern.

On 09/23/21 12:41, Scott Dorsey wrote:
> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?=<lawrencedo99@gmail.com> wrote:
>> On Wednesday, September 22, 2021 at 11:55:56 PM UTC+12, dgso...@gmail.com wrote:
>>> I guess Microsoft has the power to dictate requirements here ...
>>
>> To whom? Nobody else seems to be bothering with Windows-on-ARM.
>
> Just like they didn't bother with Windows on Alpha.
> --scott

Perhaps, but Arm has far more traction and installed base than Alpha
ever had. It does need Microsoft to get serious about Arm on the desktop
and in servers. The processors are already there, but mass adoption of
arm and windows would upset the probably very cosy relationship with Intel.

Can't see any reason for the delay otherwise. Arm is everywhere else...

Chris

On 9/23/2021 10:27 AM, chris wrote:
> On 09/23/21 12:41, Scott Dorsey wrote:
>> =?UTF-8?Q?Lawrence_D=E2=80=99Oliveiro?=<lawrencedo99@gmail.com> wrote:
>>> On Wednesday, September 22, 2021 at 11:55:56 PM UTC+12,
>>> dgso...@gmail.com wrote:
>>>> I guess Microsoft has the power to dictate requirements here ...
>>>
>>> To whom? Nobody else seems to be bothering with Windows-on-ARM.
>>
>> Just like they didn't bother with Windows on Alpha.
>> --scott
>
> Perhaps, but Arm has far more traction and installed base than Alpha
> ever had. It does need Microsoft to get serious about Arm on the desktop
> and in servers. The processors are already there, but mass adoption of
> arm and windows would upset the probably very cosy relationship with Intel.
>
> Can't see any reason for the delay otherwise. Arm is everywhere else...
>
> Chris
>

My question is, "why"?

x86 is cheap.
x86 is everywhere.

What reason would Microsoft have to look at anything else?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <ir39oeFmc42U1@mid.individual.net>, bill.gunshannon@gmail.com
(Bill Gunshannon) wrote:

> Alpha Windows was released before any applications were ready.
> Most people I knew who actually bought one ended up dumping
> Windows and running Linux. Why? Because Linux had applications.

It got used in some specialised fields, because it was faster than Intel
at the time. That advantage disappeared when Intel and AMD got into a
clockspeed battle in 1997, and when Compaq took over DEC, they weren't
interested in it. Microsoft continued to use Alpha-based machines to
develop 64-bit Windows until they had a reasonable number of Itanium
machines.

John

In article <sihsf2$2mo$1@dont-email.me>, craigberry@nospam.mac.com (Craig
A. Berry) wrote:

> On 9/22/21 8:37 PM, Lawrence D_Oliveiro wrote:
> > Nobody else seems to be bothering with Windows-on-ARM.
>
> Perhaps, but Microsoft makes their own hardware and is still
> releasing new ARM-based devices

They seem to have decided that Windows on ARM is /strictly/ for mobile
devices. It does help considerably with the battery life of small and
thin laptops.

John

On 2021-09-23, Dave Froble <davef@tsoft-inc.com> wrote:
> On 9/23/2021 10:27 AM, chris wrote:
>>
>> Perhaps, but Arm has far more traction and installed base than Alpha
>> ever had. It does need Microsoft to get serious about Arm on the desktop
>> and in servers. The processors are already there, but mass adoption of
>> arm and windows would upset the probably very cosy relationship with Intel.
>>

I wonder if the availability of RISC-V is likely to upset anything ? :-)

>> Can't see any reason for the delay otherwise. Arm is everywhere else...
>>
>
> My question is, "why"?
>
> x86 is cheap.
> x86 is everywhere.
>
> What reason would Microsoft have to look at anything else?
>

Why do phones use ARM processors instead of x86 processors ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-09-23 15:17:50 +0000, Dave Froble said:

> My question is, "why"?
>
> x86 is cheap.
> x86 is everywhere.
>
> What reason would Microsoft have to look at anything else?

Price and power efficiency, same as usual. Arm can be cheaper, more
power-efficient, and fast.

https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/9

Arm designs can also be juggernaut-scale, with 15 billion transistors
in one recent design; with fast big.LITTLE multiprocessor, a fast GPU,
statistics-math acceleration; that's a full-on SoC. And
power-efficient. For comparison, Itanium Poulson and Kittson are ~3
billion. And Alpha and Itanium processors and servers never really saw
appreciable work on power efficiency.

As for being "everywhere", the Arm installed base dwarfs those of Intel
and AMD and x86-64. And I'd suspect that Arm-related investments dwarf
Intel, too.

Intel has spectacular processor design and processor fabrication
abilities, but they're also necessarily working within a massive
software installed base, and with a complex and accreted architecture.
And their fabrication efforts have been falling short. TSMC and others
have massive investments in fabrication, as well. Intel has discussed
using TMSC to fab parts of some Intel-designed components.

https://www.reuters.com/business/intel-details-mixed-source-chip-strategy-tsmc-partnerships-2021-08-19/

Microsoft has been selling Arm clients for a while, and publicly
prototyping Arm servers for several years now, as have others. How far
Microsoft might get with Windows 11 for ARM64? There are a number of
folks working with the Windows ARM64 insiders' preview, including
having gotten that working on Apple M1.

https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/

How? If? When? Unknown. Architectural and product transitions tend to
be boring and slow and happening only around the periphery of other
markets, then the platforms and tools are ready, and then the changes
can then accelerate through the market.

--
Pure Personal Opinion | HoffmanLabs LLC

On 9/23/2021 3:20 PM, Stephen Hoffman wrote:
> On 2021-09-23 15:17:50 +0000, Dave Froble said:
>
>> My question is, "why"?
>>
>> x86 is cheap.
>> x86 is everywhere.
>>
>> What reason would Microsoft have to look at anything else?
>
> Price and power efficiency, same as usual. Arm can be cheaper, more
> power-efficient, and fast.
>
> https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/9
>
>
> Arm designs can also be juggernaut-scale, with 15 billion transistors in
> one recent design; with fast big.LITTLE multiprocessor, a fast GPU,
> statistics-math acceleration; that's a full-on SoC. And
> power-efficient. For comparison, Itanium Poulson and Kittson are ~3
> billion. And Alpha and Itanium processors and servers never really saw
> appreciable work on power efficiency.
>
> As for being "everywhere", the Arm installed base dwarfs those of Intel
> and AMD and x86-64. And I'd suspect that Arm-related investments dwarf
> Intel, too.
>
> Intel has spectacular processor design and processor fabrication
> abilities, but they're also necessarily working within a massive
> software installed base, and with a complex and accreted architecture.
> And their fabrication efforts have been falling short. TSMC and others
> have massive investments in fabrication, as well. Intel has discussed
> using TMSC to fab parts of some Intel-designed components.
>
> https://www.reuters.com/business/intel-details-mixed-source-chip-strategy-tsmc-partnerships-2021-08-19/
>
>
> Microsoft has been selling Arm clients for a while, and publicly
> prototyping Arm servers for several years now, as have others. How far
> Microsoft might get with Windows 11 for ARM64? There are a number of
> folks working with the Windows ARM64 insiders' preview, including having
> gotten that working on Apple M1.
>
> https://blogs.windows.com/windowsdeveloper/2021/06/28/announcing-arm64ec-building-native-and-interoperable-apps-for-windows-11-on-arm/
>
>
> How? If? When? Unknown. Architectural and product transitions tend to be
> boring and slow and happening only around the periphery of other
> markets, then the platforms and tools are ready, and then the changes
> can then accelerate through the market.
>
>
>
>

I'm aware of many of the things ARM is used for. Yes, they are quite
useful.

But, are they much better for desktop and notebook PCs? I really can't
see them being much better in that environment.

Now, talking Microsoft, how successful have they been outside the
desktop and notebook PCs? Not very. So, for them, x86 does the job.

I have no idea of cost to get a decent WEENDOZE on ARM. But whatever it
is, would doing so be of adequate benefit to Microsoft? Maybe sometime,
but right now I don't see it.

Then again, I don't get out much ....

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <siik2d$grk$1@dont-email.me>, seaohveh@hoffmanlabs.invalid
(Stephen Hoffman) wrote:

> There are a number of folks working with the Windows ARM64 insiders'
> preview, including having gotten that working on Apple M1.

Just in time for Microsoft to announce that running ARM Windows on M1 is
"not a supported scenario."

https://www.theregister.com/2021/09/10/windows_11_m1/

John