maharmstone / quibble

Quibble - the custom Windows bootloader
GNU Lesser General Public License v3.0
2.12k stars 81 forks source link

Add Windows 11 support #105

Open thewanderingtraderm opened 9 months ago

SzczurekYT commented 9 months ago

I'm not the author, but to my knowledge this will probably going to be added, but currently Quibble can't even support latest windows 10 due to a some change in it, breaking Quibble with no known solution yet.

joeyoropesa-dev commented 7 months ago

Yes - this is also wanted but not only this

We also need an Quiling/Unicorn Framework implemented into this bootloader that will at boot emulate CPU architecture for example to support and execute Windows On ARM versions on Intel/AMD-based PCs with Intel/AMD CPUs

maharmstone commented 7 months ago

I think reimplementing Qemu might be a little out of the scope of the project...

joeyoropesa-dev commented 7 months ago

I think reimplementing Qemu might be a little out of the scope of the project...

Well who will do it if no one who are skilled enough doesn't want to spend time on coding and do this thing... There is literally no such a thing created that will be able to do this - there is no even an method of running another architecture executables dynamically on Windows without VM just like Qemu provided for linux systems...

binarymaster commented 7 months ago

There is literally no such a thing created that will be able to do this - there is no even an method of running another architecture executables dynamically on Windows without VM

Wrong: https://virtuallyfun.com/2024/02/17/announcing-emuwow-beta-1-axp-preview1/

joeyoropesa-dev commented 7 months ago

There is literally no such a thing created that will be able to do this - there is no even an method of running another architecture executables dynamically on Windows without VM

Wrong: https://virtuallyfun.com/2024/02/17/announcing-emuwow-beta-1-axp-preview1/

For a very long time I've searched for something like this and I never found it until now - thanks for sharing the link to that project - I hope that the dev will see there too an suggestion in the already created issue by someone suggesting ARM emulation so maybe we can see some wonders like this in the future : ) - I love this new year 2024 : )

maharmstone commented 7 months ago

@binarymaster - thanks, that was an interesting read

@admin-elvistrujanovic - I think the way to approach this would be to add ARM support to Quibble, which I plan to do eventually, and have a separate EFI application acting as a generic emulator. Like I said though, this latter bit would be a pretty gigantic project largely unrelated to everything else (as cool as it would be).

BHTY commented 6 months ago

Hi, this is coming a little late but I'm the developer of EmuWoW and I heard through the grapevine that my project had come up here. First of all, I took a brief look at Quibble and it's interesting work, but I have to agree with mahramstone that at least from where I'm sitting, implementing QEMU on bare metal is a little out of the scope of this project, since that's essentially what would be required to boot ARM64 Windows on x64 machines (though obviously support for running Quibble on ARM machines to use it as a bootloader there would be neat). Also, EmuWoW isn't really what you're looking for if that was the goal you were looking to accomplish, for the following reasons

mateli commented 4 hours ago

@joeyoropesa-dev

Yes - this is also wanted but not only this

We also need an Quiling/Unicorn Framework implemented into this bootloader that will at boot emulate CPU architecture for example to support and execute Windows On ARM versions on Intel/AMD-based PCs with Intel/AMD CPUs

Running Windows inside binary translation or an emulator is extremely slow. Running Windows applications inside a binary translator or or on the other hand can be done either by running wine inside qemu or by retrowin32. Neither of those solutions work well quite yet but they are considerably easier starting points than running a full Windows inside qemu.

Running a full operating systems inside an emulator means that you will spend a large amount of CPU time running basic OS stuff like scheduling tasks and drawing the desktop (which is most likely going to be software rendered.

So if you have a list if you want to develop something that run foreign windows applications I would suggest that you for starters do this on a native operating system which could be Windows, Linux, FreeBSD or whatever gives you best access to the hardware you are running on.

Wine is the most mature way to run Windows applications on Linux and FreeBSD but if you want a binary translation layer then this is tricky. The solution here is to run wine inside qemu with the main problem being that this is not at all supported by wine. Usually it is possible and you can get most applications supported by wine working but do not expect this to be a pleasant experience. Wine is not designed for this and to make it work well you will have to make major improvements to how wine work. Also note that currently you will have to run the entirety of wine inside QEMU which is slow. Not as slow as running the entirety of Windows inside an emulator but still very slow.

Retrowin32 on the other hand is a rather fresh project that can run 32 bit x86 applications. Unlike Wine it is an emulator and it is designed to run on windows applications on different hardware. What you would have to do first is to add emulation for the CPU architectures that you need as your applications will obviously not work without this. Then you will have to extend the set of Windows API:s supported by retrowin32 until it runs your applications. Now a major advantage here is that everything that is done inside a Windows API here runs as platform native code and is therefore much faster than running wine inside QEMU.

How difficult this is depends entirely on how difficult your applications are to run within the emulation layer. It is possible that the easiest option are to re-implement the application using a portable framework that can run natively on whatever operating system and hardware you are using.

@BHTY I noticed that EmuWoW is rather similar to what retrowin32 support. As such I would find it more interesting if you used retrowin32's implementation of the Windows API so that running the MIPS/Alpha binaries are not dependent on Windows.

As for the "rewrite" option minesweeper has a rewrite in winemine (part of wine), gnome mines, kmines and a significant list of other implementations. FreeCell also have numerous alternatives such as AisleRiot.

Obviously with application level emulation you do not need a bootloader to run your windows applications on BTRFS, you just install Linux on BTRFS and run them using the emulator of your choice.

Finally running an application using any of the suggested paths is a significant undertaking. However compared to the initial suggestion of running the entirety of Windows inside a binary translator would require a lot more work and run a lot slower.

Also running qemu bare metal do not provide a significant advantage over installing Linux and running qemu even if you would be able to pull it of. Would you run Windows BTRFS drivers inside the emulator? Well then your computer will probably spend most of it's time within BTRFS code.