Ability to create Windows USB installers

[depau]

Relevant information:

• https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/install-windows-from-a-usb-flash-drive
• https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/split-a-windows-image--wim--file-to-span-across-multiple-dvds#usb-deployment
• https://rys.pw/operating_systems#windows_images

Requirements

• TODO: Investigate whether shoving the raw UDF filesystem into a partition in a new MBR does the trick without any filesystem parsing
  • Investigate how many UEFI firmwares will start crying after seeing it
  • Still need to find a MBR boot sector that can parse enough of it and jump into Crapdows
  • Investigate how many legacy BIOS firmwares will try to parse it even if they're not supposed to and die
• DVD image
  • Mount Windows ISOs (UDF) (possibly without root, maybe without actually mounting them but reading the image directly with some library)
    • Wrapper for GRUB's read-only filesystem driver: https://github.com/coreos/grub/blob/2.02-coreos/grub-core/fs/udf.c
• MBR
  • Be able to create a MBR partition table with one partition
    • Embed fdisk from Termux, or implement it in Kotlin, either way it should be fairly easy
  • Find a suitable MBR boot sector - syslinux should have a few Windows boot sectors, investigate whether they're okay for Windows installer disks
• FAT32
  • Create FAT32 filesystems (shouldn't be too hard - mkdosfs from Termux)
  • Read/write FAT32 filesystems (libaums can do that)
• UEFI
  • Nothing to be done, just ensure the filesystem of choice is supported by 100% firmwares or add a FAT32 ESP
• Too large install.wim
  • wimlib (a Java wrapper needs to be written)

Once the requirements are met, the app will have to:

• Create a MBR partition table on the USB drive
• Add one big FAT32 partition (we might be able to use Android's USB format feature)
• Copy the image content (not the image itself) to the partition
• If install.wim is too big, split it.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Gen0]

Very confused as this seems mucho complicated. Understanding the source and destination partitions should only be relevant when writing to pre-partitioned drives AFAIK. Block for Block Iso9660 is far more reliable and the format is extensible to ISO 13490 for read write access. With caveats (esp in creating partitions additionally) it works fine as a format for a USB boot. Even Windows itself will not format the drive as FAT32, but may choose to retain a FAT32 partition in the first 250MB for EFI System Reserved partition. As far as I can tell you have the capability already to copy the contents of the ISOs EFI folder to it's own partition with boot files already, but you would probably have to modify them to point to the new partition, which is why this just seems incredibly complicated.

Due to the likelihood of a BIOS not natively supporting either ISO13490 or NTFS, I feel ISO9660 is the best choose for a one click no fuss app like you have. Most end users just want a working flash.

[depau]

I'm not sure what you're referring to.

Whatever filesystem can be used, as long as it's supported by the Windows installer on USB drives (for MBR) and by most firmwares + Windows (UEFI).

Windows does support FAT32, NTFS, but also ISO9660 and UDF since it's also able to boot the installer from CDs and DVDs. However:

• Dumping the ISO to a USB drive doesn't work, but I'm not surprised
• Maybe creating a GPT/MBR partition table on the drive and then copying bit-by-bit the UDF filesystem inside a partition will work? I've never tested or investigated this, I'm thinking of it only now.

Fat32 is probably the easiest choice since 1) it's already implemented in libaums, 2) tackling the 4GB issue isn't too hard with wimlib and 3) it's supported by all UEFI firmwares (including Apple devices).

Going with ISO9660 would add it up to the filesystems that need to be added to libaums (on top of UDF).

If you're referring to the fact that I wrote ISO9660 in the tasklist in the first post, that's an error, Windows ISOs use UDF if I remember correctly. I'll correct it.

Either way I'm quite busy right now and EtchDroid needs some major clean up before this is implemented. I'm not happy at all with the way it's currently implemented and I'd like to make it more "pluggable", since I'm planning to distribute the Windows ISO functionality as a separate paid app plugin on the Play Store (still free on F-Droid and open-source GPLv3-licensed on GitHub for whoever wants to build it themselves — Termux plugins-style).