Live data from Hacker News

Welcome to the M1 Windows project

amarioguy.github.io

81–90 of 276 posts

Re: Welcome to the M1 Windows project

#81

Earlier quoted context omitted.

My understanding is that drivers aren't part of the kernel in Windows like they are in Linux. And I believe an ARM build of some kind or another already exists out there for Windows

It does. Officially there is an ARM build of Windows that Microsoft licenses to OEMs, and there is (or maybe was?) Windows IoT Core which has a build for ARM. If I recall (grain of salt then) 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, because they didn’t want to deprecate B…

It seem a bit disingenuous for Apple to shift blames to Microsoft.

Microsoft does not sell retail licenses of Windows for ARM devices and what Apple proposed isn't the way Microsoft currently does business for ARM hardware.

Yes, Microsoft could change how they do business to accommodate, but so too could Apple.

If Microsoft turn around and ask Apple to license Windows and provide the OS as an option to buyers, or ask Apple to supply Macbook hardware so Microsoft could sell Macbooks with Windows on it, Apple likely would have said no too.

Re: Welcome to the M1 Windows project

#82
post #79
post #75

Earlier quoted context omitted.

I feel like there should be a common etiquette rule on HN where if you don't care about a particular project / technology / initiative that you skip commenting and move on. For example, your comment says that this initiative will not work out. Should there be a debate whether or not it's theoretically possibly for this to work out logistically? What is the value in that? Even if there is a convincing argument that th…

They didn't say they aren't interested in the idea, they just expressed skepticism. > Should there be a debate whether or not it's theoretically possibly for this to work out logistically? What is the value in that? Certainly if you're going to work on this you'd like to know if it's just a dead end.

This is an incredibly challenging problem so I imagine if you have any chance of coding it you probably know what you’re getting yourself into.

Re: Welcome to the M1 Windows project

#83
post #79
post #75

Earlier quoted context omitted.

I feel like there should be a common etiquette rule on HN where if you don't care about a particular project / technology / initiative that you skip commenting and move on. For example, your comment says that this initiative will not work out. Should there be a debate whether or not it's theoretically possibly for this to work out logistically? What is the value in that? Even if there is a convincing argument that th…

They didn't say they aren't interested in the idea, they just expressed skepticism. > Should there be a debate whether or not it's theoretically possibly for this to work out logistically? What is the value in that? Certainly if you're going to work on this you'd like to know if it's just a dead end.

I would be with you except for the "Disclaimer: Not really a kernel dev of any sort." bit at the end. Skepticism from people not in the field is far less meaningful (as is booster-ism, for that matter).

Re: Welcome to the M1 Windows project

#84

Earlier quoted context omitted.

Windows (really: NT) has always been hardware independent. So it's a matter of a) having binaries and a HAL (Hardware Abstraction Layer) for aarm64 (this exists -- Microsoft already sells arm-based devices such as the Surface Pro X), and b) having the necessary set of device drivers. These may exit already from MS, or may need to be compiled from source already used for x86, or may need to be written from scratch if…

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.

Re: Welcome to the M1 Windows project

#85

I’d frankly be surprised if you were able to muster the talent/willpower for something like this. 1. Most of the people able to do this sort of thing probably work in Linux/FreeBSD/etc land. 2. You’re really working doubly against the tide here. You have proprietary stuff on the Mac and on the Windows side. 3. (Personal opinion) Dear God that sounds like a lot of work for something that is a fairly unfriendly experie…

Why be so negative? The world is better for ambitious people like this

Sorry, I’m not specifically trying to be negative, these were just my honest first reactions. If they can do it, more power to ‘em.

Re: Welcome to the M1 Windows project

#87
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, version 2004, the HAL is now statically linked into the kernel, meaning that if I wanted to use the AIC natively I'd need to write a patch finder that runs before the Windows kernel loads (This is what EfiGuard does for example to disable PatchGuard)

(Yes this is actually more tenable than it may seem, due to some undocumented policy files Windows is able to use, but I have already decided to hold off on this until after I get Windows working under the thin hypervisor)

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

4) I am well aware that Windows is going to need a lot more help than just purely the interrupt controller, I'm currently trying to bring up the vGIC first since the distributor and redistributors need to be emulated and I need to bring up Project Mu first

5) as for the GPU, I'm way too far away from that being a concern to figure out the approach lol

if you have any feedback btw, please do feel free to comment it i'll try to address it as best as I can

yes I'll update the website theme soon enough, thanks to the commenter who remarked about readability.

Re: Welcome to the M1 Windows project

#88
post #38
post #10

Can't microsoft work on this instead? I don't get it.

I don't think Microsoft sees a future in Windows. Their current strategy seems to be one of extracting as much value from it as possible until it dies.

Really? I think Windows is in the best state it's ever been... WSL is incredibly nice to use as a development platform, and many well-designed apps have a Windows version ever since Electron started becoming the de facto standard.

Re: Welcome to the M1 Windows project

#90

Earlier quoted context omitted.

I don't have the impression that they're doing anything specifically to make it hard. But right now users would have to pirate Windows in order to run it on Apple Silicon hardware, so it's hard to argue for an official solution. And they're not currently publishing specs in the open that would really speed it along. But the Asahi Linux developers say Apple is helping in some measure[1], so it doesn't seem likely that…

You don't have to pirate windows, you have to buy Parallels, which then downloads and installs Arm windows onto your M1 - and Arm Windows will run x86 binaries. I used this to run FPGA bitstream-creation software on my Mac Studio. Worked like a dream. I'm generally fine with running on the PC on the bookshelf and serving s/w via MS Remote Desktop, but having it on the machine itself is a bit more useful in terms of s…

Parallels uses Insider builds of Windows ARM, which aren't useful if you want a stable system. Additionally, Microsoft only offers those builds for people who have Windows ARM licenses, so you can't use this in a professional setting since you're violating the EULA.
Post reply on HN