[Info-vax] VSI licensing policy (again), was: Re: VSI has a new CEO

[David Goodwin]

On Wednesday, September 22, 2021 at 11:02:17 PM UTC+12, John Dallman wrote:
> In article <cd94fd57-441f-4af0... at googlegroups.com>, 
> lawren... at 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.