Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Welcome to the M1 Windows project

amarioguy.github.io

Post reply on HN
Print view View original

211–220 of 276 posts

Re: Welcome to the M1 Windows project

#211

Post by mappu »

amarioguy wrote: post #104
fold3 wrote: post #14

Do you think it would eventually be possible to run amd64 programs on it (like rosetta2 but for Microsoft Windows?) The main feature of Windows is legacy compatibility and that is perhaps why arm Windows doesn't seems to gain much traction. Eventually I wonder if this project could be helpful to run wine on asahi linux, which would be awesome.

Project developer here, Windows actually has a x64 compatibility layer now for ARM64 systems in general, so any ARM64 Windows device should be able to run x64 apps (granted the performance penalty is worse than Rosetta since Rosetta relies on Apple SoCs actually implementing small slices of x86 (memory ordering model for instance) which isn't true for any Qualcomm SoC at the moment.) The problem with x64 on arm64 is…

It turns out Rosetta2 does not rely on special M1 hardware memory ordering at all:

https://twitter.com/never_released/status/153412764108259328...

https://twitter.com/marcan42/status/1534032369166225409

The baseline for translation is qemu-user, but other pure-software emulators like FEX-emu and Box86/Box64 can perform this translation significantly faster. So I think there's just ordinary performance engineering to close the gap.

Re: Welcome to the M1 Windows project

#212

Post by [deleted] »

mr_toad wrote: post #195
ntoskrnl wrote: post #21

Earlier quoted context omitted.

Windows on ARM supports that already[1]. The low traction is probably because of the (sorry) bad hardware. Windows branded ARM as the budget option so nobody wanted it. Then Apple came along and flipped the script. [1]: https://blogs.windows.com/windows-insider/2020/12/10/introdu...

It’s not just that the hardware was lacking, there was no good solution for running x86 binaries. ARM windows has no Rosetta.

[deleted]

Re: Welcome to the M1 Windows project

#213

Post by JoshTko »

buffington wrote: post #150
JoshTko wrote: post #141

Why?

The OP expresses exactly why on their site. Let's assume you didn't read their site though. Why not?

All the reasons are technical but nothing about an actual user need. Especially given the cost and complexity and most likely sub native window user experience this project seems to serve no actual utility.

Re: Welcome to the M1 Windows project

#214

Post by Thorrez »

colordrops wrote: post #182
j1elo wrote: post #146

Earlier quoted context omitted.

It doesn't look like we can say " licenses like AGPL ". It's more that AGPL is basically the only one in that vein. Remove the A, if you please, but that's pretty much it in terms of variety. On the other hand, reading HN over time I also got the idea that *GPL has been tried with the intention of avoiding abuse, and it failed several of those intentions. I now regret not having taken note each time I saw comments in…

The problem is not with the GPL. The GPL is just as enforceable as any other proprietary license. The difference is that these amateur projects often don't have the resources to fight infringement.

If the problem is that there are no resources to fight infringement, then how would changing the license help at all?

Re: Welcome to the M1 Windows project

#215

Post by 58028641 »

f311a wrote: post #99
58028641 wrote: post #51

Earlier quoted context omitted.

Hector Martin and others have had decent success with reverse engineering so far.

Only the CPU part, GPU is much harder.

Alyssa Rosenzweig is working on the Mesa driver. Hector Martin is working on the kernel driver.

Re: Welcome to the M1 Windows project

#216

Post by yuhong »

zinekeller wrote: post #169
xattt wrote: post #158

Earlier quoted context omitted.

> x86 Windows even supports non-PC servers from Compaq Were there x86 but non-IBM compatible models or did you mean the alternate instruction sets (Alpha, PPC, RISC)?

Not GP. I'm not sure if there's a special Compaq version but there's a version (until Windows 2000, https://winworldpc.com/download/5204c39d-c3a9-5a68-11c3-a7c2... ) for NEC PC-98 architecture which is x86-based but IBM PC-incompatible, so it's likely that a Compaq version exists.

The Compaq is IBM PC compatible but uses a different HAL for SMP support. You can see all of them by looking at what NT4 shipped with for example.

Re: Welcome to the M1 Windows project

#217

Post by alwaysanon »

alwaysanon wrote: post #201

I am struggling to see here how this shouldn't be something that Microsoft does itself. And, if Microsoft is doing it, they can just call Apple and get what they need re: documentation or specs or questions answered. They might just need appropriate NDAs between the two companies (which I'd have to imagine they already have?)? With Linux they have to reverse-engineer it. Microsoft shouldn't need to...

Actually - come to think of it there is one reason. If this person wants a job with Microsoft or Apple getting something like this working without the support of MS or Apple is a hell of an exceptional application...

Re: Welcome to the M1 Windows project

#218

Post by skissane »

amarioguy wrote: post #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, 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 details on the API or how to write them.

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?

Is there any good public source of info on them? The best I've found is [1] – which includes some important details but isn't comprehensive (not that anyone would expect a slide deck to be).

[0] e.g. https://docs.microsoft.com/en-us/windows-hardware/test/hlk/t...

[1] https://infocon.org/cons/SyScan/SyScan%202012%20Singapore/Sy...

Re: Welcome to the M1 Windows project

#219

Post by 1123581321 »

qzw wrote: post #203
GeekyBear wrote: post #144

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.

I like the theory, but I’ll counter with my own theory that MacBook Pros were the best Windows laptop for many years, and they ended up pushing PC quality to catch up which was good for the Windows install base and Office. :)

Re: Welcome to the M1 Windows project

#220

Post by DeathArrow »

AshamedCaptain wrote: post #54
roblabla wrote: post #39

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…

Actually you might be surprised. Windows NT is _older_ than many of the "standards we take for granted in x86/PC land", and for example it does support multiple types of pre-ACPI ways of bringing up multiprocessor systems and specifically multiple types of interrupt controllers. Heck, x86 Windows even supports non-PC servers from Compaq and others; ever tried to press F5 during (old) Windows NT setup ? As the OP said…

>Outside of simple binary patches, I don't think anyone has come close to writing a new one.

What about ReactOS, do they use a HAL implementation or not?

Post reply on HN