Live data from Hacker News

Welcome to the M1 Windows project

amarioguy.github.io

241–250 of 276 posts

Re: Welcome to the M1 Windows project

#241

hey, OP here, figured i'd clarify some things about this project: 1) yes, I realize this is going to be way harder than it seems, but I'm actually going to do my best to hopefully get a good user experience out of this and I'm easily preparing for this to be a multi-year effort, but I'm not going to give up right at the gate 2) Custom HALs were actually an option, up until very recently, since as of Windows 10, versi…

> 3) HAL Extensions (for those unaware they are tiny modules that allow you to extend the Windows HAL with functions for non standard hardware) are not tenable at the moment since they're limited in the APIs they use I haven't heard of those before, and I'm fascinated by them. I go looking for documentation – and I can't find any on Microsoft's website – some documentation which mentions their existence, [0] but no d…

> Is this something you have to sign an NDA with Microsoft to get access to the headers and docs for it? Or will I find the headers hidden away in the WDK somewhere?

Turns out the header file is included in the Windows 10 SDK, as km/nthalext.h

Not the very latest version, but someone posted it on GitHub here: https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16...

(You can download the multi-gigabyte Windows 10/11/2022 SDKs to get a more recent one, although not sure if anything has changed.)

Still doesn't seem to be any public documentation. The header includes very detailed comments, but (as you'd expect for header file comments) they concentrate on the nitty-gritty and omit the big picture.

Searching "nthalext.h" on GitHub finds source code for a handful of HAL extensions, so at least there is some sample code to look at. Microsoft has even open-sourced a few – see https://github.com/ms-iot/imx-iotcore/tree/public_preview/ha...

Microsoft used to include HAL extension samples in the Windows 10 driver samples – https://github.com/microsoft/Windows-driver-samples/tree/5b8... – but removed them as part of the Anniversary update – https://github.com/microsoft/Windows-driver-samples/tree/96e...

Re: Welcome to the M1 Windows project

#242

Earlier quoted context omitted.

This part is why I hope x86 has a long life ahead of it. Everybody and their dog have their own standard for things in ARM-land.

for what it's worth amd64 is not going anywhere outside of Macs for at least the next decade, possibly two. Despite the benefits ARM provides amd64 undeniably has advantages and non-trivial ones at that. personally, I'm of the opinion it'll come to a coexistence for a time rather than one dominating the other immediately.

Are you confusing "amd64" with "Aarch64"? "amd64" has nothing to do with Macs/Apple products.

Anyway, both amd64 and Aarch64 are already being used outside of Macs/Apple products.

Re: Welcome to the M1 Windows project

#243

Earlier quoted context omitted.

for what it's worth amd64 is not going anywhere outside of Macs for at least the next decade, possibly two. Despite the benefits ARM provides amd64 undeniably has advantages and non-trivial ones at that. personally, I'm of the opinion it'll come to a coexistence for a time rather than one dominating the other immediately.

Are you confusing "amd64" with "Aarch64"? "amd64" has nothing to do with Macs/Apple products. Anyway, both amd64 and Aarch64 are already being used outside of Macs/Apple products.

Apple still sells many computers that execute the amd64 insurrection set.

Re: Welcome to the M1 Windows project

#244

Earlier quoted context omitted.

That's only true up to a certain point. ARM is a very weird target, because a lot of standardized stuff we take for granted in x86/PC land aren't standardized on ARM. In particular, take the Interrupt Controller: x86 has a standard for it (well, technically has two, the PIC and APIC). The "standard" in ARM-land is the GICv3 or GICv4, but many different CPU vendors have their own. Apple has the "Apple Interrupt Contro…

This part is why I hope x86 has a long life ahead of it. Everybody and their dog have their own standard for things in ARM-land.

This is not true.

Most manufacturers take standardized IP and IP-providers provide an appropriate linux drivers. Few manufacturers are willing to develop and maintain their own GIC hardware and GIC driver, most of the time they just take the ARM standard GIC.

The fact that Apple does not provide drivers is a consequence of the Apple business model. And the fact that the ARM ISA does not stipulate a unique GIC is actually a strength. It makes the architecture more versatile and suitable for evolution (maybe Apple found out that the ARM standard GIC is not complete enough for them).

Re: Welcome to the M1 Windows project

#245
post #190

Earlier quoted context omitted.

>a while after the first M1 Mac came out one of Apple’s VPs had said something on the record about Apple having tried to get Microsoft to sell retail licenses of a Windows 10 for ARM build Not quite. The Craig Federighi quote is: >As for Windows running natively on the machine, “that’s really up to Microsoft,” he said. “We have the core technologies for them to do that, to run their ARM version of Windows, which in t…

Pretty surprising that MSFT would end up with a deal like that, I'd feel like they would be in a position of strength. Unless all the ARM vendors were pretty supicious of whether Microsoft would succeed/invest properly in the ecosystem?

Qualcomm has even ended up in a legal quarrel with Apple over a modem contract that in the end led to Qualcomm getting what they wanted.

They're a ferocious company when it comes to legal.

Re: Welcome to the M1 Windows project

#246
post #198

Earlier quoted context omitted.

You can't imagine why a Windows user would want to run it on better hardware? Or that there are Windows workflows that just don't work on OSX? Or want a fanless laptop with good performance?

TBH I have a hard time understanding why people choose to run windows at all, except for playing games. If you're stuck using windows because the corporate overlords insist, then yeah that sucks. Also you can always run windows in a VM. Even on an M1.

I’m with you. Many people constantly complain about windows but most of them still using it. They say it’s going to get better, but it won’t. You could spend five years trying to make windows run ob an M1 und MS would break it within an hour. I’m done with microsoft, they disappointed me to many times, never again. It’s necessary for some games but it’s getting better with linux (thanks to valve).

Re: Welcome to the M1 Windows project

#247
post #203

Earlier quoted context omitted.

>a while after the first M1 Mac came out one of Apple’s VPs had said something on the record about Apple having tried to get Microsoft to sell retail licenses of a Windows 10 for ARM build Not quite. The Craig Federighi quote is: >As for Windows running natively on the machine, “that’s really up to Microsoft,” he said. “We have the core technologies for them to do that, to run their ARM version of Windows, which in t…

My own pet theory, based on absolutely no inside knowledge, is that MS doesn’t want to have Windows on M1+ until other CPU makers have caught up to Apple. It would be a huge embarrassment to have Apple hardware running Windows that much better than all the native PCs. All the PC OEMs would slash Nadella’s tires.

> It would be a huge embarrassment to have Apple hardware running Windows that much better than all the native PCs.

That boat already sailed over a year ago.

>How did Microsoft screw this up? - Surface Pro X (SQ2) vs M1 Macbook Air

https://www.youtube.com/watch?v=OhESSZIXvCA

Re: Welcome to the M1 Windows project

#248

Earlier quoted context omitted.

This part is why I hope x86 has a long life ahead of it. Everybody and their dog have their own standard for things in ARM-land.

This is not true. Most manufacturers take standardized IP and IP-providers provide an appropriate linux drivers. Few manufacturers are willing to develop and maintain their own GIC hardware and GIC driver, most of the time they just take the ARM standard GIC. The fact that Apple does not provide drivers is a consequence of the Apple business model. And the fact that the ARM ISA does not stipulate a unique GIC is actu…

I think that's uncharitable even if I am using superlatives to describe the situation.

We have plenty of examples in the wild. Just look at the state of Pine64 and u-boot, for example. It's a mess of standards.

And what you see as a strength others don't.

Re: Welcome to the M1 Windows project

#249
post #140

Earlier quoted context omitted.

May I suggest you don't license the work in a way that allows it to be commercialized without your explicit permission and handsome compensation to you and any other contributors. You'll need this to be sustainable and it'll be incredibly frustrating if a company de-facto hijacks the development and takes it in a direction you don't expect or want.

Oh but then half of HN will complain about how that's not truly open according to a dictionary definition thus automatically becomes untrustworthy and they won't touch it with a ten foot pole. (/s) Jokes aside, technically I don't disagree on the "dictionary definition" thing there... but it's interesting how the current landscape has shifted and now more control for the developer starts to become a common interest b…

I don't generally like restrictive licenses but in this case we're taking about running closed, commercial software on closed, commercial hardware. It makes sense to use a GPL to prevent one of those companies from taking all of that hard work and incorporating it back into their platforms for free.

Re: Welcome to the M1 Windows project

#250

Earlier quoted context omitted.

This is not true. Most manufacturers take standardized IP and IP-providers provide an appropriate linux drivers. Few manufacturers are willing to develop and maintain their own GIC hardware and GIC driver, most of the time they just take the ARM standard GIC. The fact that Apple does not provide drivers is a consequence of the Apple business model. And the fact that the ARM ISA does not stipulate a unique GIC is actu…

I think that's uncharitable even if I am using superlatives to describe the situation. We have plenty of examples in the wild. Just look at the state of Pine64 and u-boot, for example. It's a mess of standards. And what you see as a strength others don't.

Pine64 is based on an Allwinner A64 which has a ARM GIC-400. ARM GIC-400 is a standard GIC IP from ARM and compliant with ARM GICv2 specification.

It seems pretty standard to me, not a custom GIC as Apple.

And yes, in u-boot there are plenty of device-trees for each target. What's wrong with that?

The device tree is usually provided by the manufacturer, the compiled device tree is usually very small and allows genericity.

Post reply on HN