No replies to this topic

[Brito]

There exists a recent boot loader that permits to boot recent Windows editions from other file systems outside NTFS.

Quibble is the custom Windows bootloader - an open-source reimplementation of the files bootmgfw.efi and winload.efi, able to boot versions of Windows from XP to Windows 10 22H2. Unlike the official bootloader, it is extensible, allowing you to boot from other filesystems than just NTFS.
This is only a proof of concept at this stage - don't use this for anything serious.

The download and install page: https://github.com/maharmstone/quibble

 

 

A larger explanation of what to expect: https://www.lilysthi...ndows-on-btrfs/

 

Have fun!

[antonino61]

I would like to know if I could use it on legacy systems instead of g4d to load just windows, and if I can, I would like to know if it loads any faster than ordinary bootmgr or svbus and if it can load vhd's into ram in its own right. 

[Wonko the Sane]

WIth all due respect, I am not too convinced.

 

Possibly it will become the fourth best thing in the world, after bread, ice cream and grub4dos, but right now there are too many unclear, confusing or downright wrong claims.

 

Hopefully it will evolve/mature.

 

It is not clear at all what the thingly does (or should do) it seems like it is a replacement for the bootmgr.efi, but the SeaBIOS is involved, so maybe it is a sort of software CSM (that would be a great thing) if not then it is not clear the mechanism about  using (or replacing)  winload.efi (on EFI systems) or winload.exe (on BIOS ones) nor how (the heck) it would load XP that use neither, there is a reference to freeldr.ini so maybe some files form ReactOS are used for this.

 

Facts (only for the record):

Windows XP is fine on FAT32

Windows Vista on FAT32 can be done with a couple tricks

Windows 7 on FAT32 can be done with a couple tricks AND greatrly reducing the WinSXS directory contents (reduction that may leave the 7 only partiallly functional) <- this is a FAT32 filesystem limit that does not allow too may files in a directory

8 onwards is likely not possible at all because of the above FAT32 filesystem limit

 

Interesting an IMHO we should keep an eye on this, but at the moment possibly only useful if you want to boot a Windows 10 on BTRFS (a rather niche activity, I would say).

 

Wonko

[antonino61]

well, still if I may, yesterday I watched a videoclip on this bootloader on bootup and..., well..., from a layman's point of view, it shows what files are involved in the bootup process (as we see them scrolling, I mean, and not beyond), and then it apparently dashes through and then it gives a couple of jerks and jolts, then it stops, then it resumes dashing through (as we say in Italian, da una gamba è zoppo e con l'altra tira calci), and until now, as wonko would put it, neither action seems to have prevailed. If it replaces winload.exe (as far as legacy-booting-lovers are concerned), it would be interesting to time one against the other and see if we can get better booting times - of course we should be taking a forward dimension (I do not think any improvement is going to crop up any time soon). In the meantime, though, it is worth our while playing a bit with it. With g4d we have a menu.lst, how would we boot vhds with quibble? If anybody told me I would give it a try and tell u how it feels. I do not mind experimenting.

Another question would be -should we opt for this new scenario, how would svbus and rambooting fit into it?

 

BTW, most important thing - is anyone here so familiar with the developer in question as to talk him into adjusting quibble to the requirements of the wimboot, ramboot, alacranboot and jfxboot era(s)? if one is, pls do so.

[alacran]

There exists a recent boot loader that permits to boot recent Windows editions from other file systems outside NTFS.

Quibble is the custom Windows bootloader - an open-source reimplementation of the files bootmgfw.efi and winload.efi, able to boot versions of Windows from XP to Windows 10 22H2. Unlike the official bootloader, it is extensible, allowing you to boot from other filesystems than just NTFS.
This is only a proof of concept at this stage - don't use this for anything serious.

The download and install page: https://github.com/maharmstone/quibble

 

 

A larger explanation of what to expect: https://www.lilysthi...ndows-on-btrfs/

 

Have fun!

 

Thanks for the info about this interesting project, but for now it doesn't seem (to me) very useful yet unless the user wants to boot from BTRFS as Wonko said.

 

@ antonino61

 

JFYI

 

This loader is only for FILEDISK booting, it doesn't have any use in RAMBOOT scenarios.

 

alacran

[antonino61]

Thank u ever so much, alacran. Now, within the fileboot milieu, is it any faster than bootmgr and/or svbus booting?

[alacran]

Thank u ever so much, alacran. Now, within the fileboot milieu, is it any faster than bootmgr and/or svbus booting?

 

 

Once again, you are trying to compare apples and oranges:

 

1 - Quibble (a boot loader) is only for FILEDISK booting. It is an optional replacement for MS boot loader.

 

2 - SVBus is not a boot loader, it is a driver, used only for RAMBOOT, after loading the OS to RAM by means of grub4dos.

 

 

FILEDISK booting versus RAMBOOTING:

 

Anyway, it is obvious FILEDISK booting will be always faster than RAMBOOTING as you just start booting since the begining, and don't spend any time in loading the OS to RAM.

 

 

Quibble boot loader versus MS boot loader:

 

As Quibble is only for FILEDISK booting. and It is an optional replacement for MS boot loader (also used for FILEDISK booting), it sounds more logical to compare them.

 

I don't have tested this, but it sounds very logical the MS boot loader (propietary software) has to be faster, and Quibble is made by reverse engineering from unknown information and also requires loading additional third party drivers for each filesystem where you want to use it.

 

alacran