NTFS + UEFI boot with Win8.1PE

Hi, I understand that NTFS + UEFI boot is possible but I did not manage to get it with Win8.1PE and Rufus 2.1.649 If I choose "MBR partition scheme for BIOS or UEFI computers", FAT or FAT32 are not available after selecting Win8.1SE_x64.iso (message: can not be used with this type of ISO) And if I choose NTFS File system, I do not seem to have the very small FAT partition with the NTFS EFI driver... Here is rufus.log:

Rufus version: 2.1.649
Windows version: Windows 7 SP1 64-bit
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.02~beta2
Locale ID: 0x040C
Found USB device 'Generic- Compact Flash USB Device' (????:????)
Device eliminated because it appears to contain no media
Found USB device 'Generic- MS/MS-Pro USB Device' (????:????)
Device eliminated because it appears to contain no media
Found USB 2.0 device 'Generic- SD/MMC USB Device' (058F:6362)
Device eliminated because it appears to contain no media
SetupDiGetDeviceRegistryProperty (Friendly Name) failed: [0x0000000D] Données non valides.
Found USB device 'USB Storage Device (Generic)' (????:????)
Device eliminated because it appears to contain no media
Found USB 2.0 device 'PNY USB 2.0 FD USB Device' (154B:0005)
Using autorun.inf label for drive L: 'WinPESE'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 250, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x000031DB
Drive has a Windows 7 Master Boot Record
Partition 1:
  Type: FAT32 (0x0b)
  Size: 1.9 GB (2062548480 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes
Scanning image...
Disc image is an UDF image
ISO label: Win8.1SE
  Size: 608919552 bytes
  Has a >64 chars filename: No
  Has Symlinks: No
  Has a >4GB file: No
  Uses Bootmgr: Yes
  Uses EFI: Yes
  Uses Grub 2: No
  Uses Grub4DOS: No
  Uses isolinux: No
  Uses KolibriOS: No
  Uses ReactOS: No
  Uses WinPE: No
Using image: Win8.1SE_x64.ISO

Format operation started
Requesting disk access...
Opened drive \\.\PHYSICALDRIVE5 for write access
Will use 'L:' as volume mountpoint
I/O boundary checks disabled
Analyzing existing boot records...
Drive has a Windows 7 Master Boot Record
Volume has an unknown FAT16 or FAT32 Partition Boot Record
Deleting partitions...
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Partitioning (MBR)...
Closing existing volume...
Waiting for logical drive to reappear...
Formatting (NTFS)...
Using cluster size: 4096 bytes
Quick format was selected
Creating file system...
Format completed.
Writing master boot record...
Drive has a Zeroed Master Boot Record
Set bootable USB partition as 0x80
Using Rufus MBR
Found volume GUID \\?\Volume{400e88c7-fb16-11de-93be-002511a6d1b1}\
Opened drive \\?\Volume{400e88c7-fb16-11de-93be-002511a6d1b1} for write access
Writing partition boot record...
Using Standard NTFS partition boot record
Confirmed new volume has an NTFS boot sector
Successfully remounted Volume{400e88c7-fb16-11de-93be-002511a6d1b1}\ on L:\
Copying ISO files...
Extracting files...
Disc image is an UDF image
Extracting: L:\BOOTMGR (394.8 KB)
Extracting: L:\Boot\GFXBoot.gfx (345.5 KB)
Extracting: L:\Boot\IMG\MEMTEST.BIN (160.6 KB)
Extracting: L:\Boot\IMG\PLPBT.BIN (42.5 KB)
Extracting: L:\Boot\bcd (256 KB)
Extracting: L:\Boot\bcd{7ceb527b-f869-11e4-9125-005056c00008}.TM.blf (64 KB)
Extracting: L:\Boot\bcd{7ceb527b-f869-11e4-9125-005056c00008}.TMContainer00000000000000000001.regtrans-ms (512 KB)
Extracting: L:\Boot\bcd{7ceb527b-f869-11e4-9125-005056c00008}.TMContainer00000000000000000002.regtrans-ms (512 KB)
Extracting: L:\Boot\boot.sdi (3 MB)
Extracting: L:\Boot\bootfix.bin (1 KB)
Extracting: L:\Boot\bootsect.exe (106.8 KB)
Extracting: L:\Boot\etfsboot.com (4 KB)
Extracting: L:\Boot\fonts\chs_boot.ttf (3.5 MB)
Extracting: L:\Boot\fonts\cht_boot.ttf (3.7 MB)
Extracting: L:\Boot\fonts\jpn_boot.ttf (1.9 MB)
Extracting: L:\Boot\fonts\kor_boot.ttf (2.3 MB)
Extracting: L:\Boot\fonts\malgun_boot.ttf (164.3 KB)
Extracting: L:\Boot\fonts\malgunn_boot.ttf (161.9 KB)
Extracting: L:\Boot\fonts\meiryo_boot.ttf (131.4 KB)
Extracting: L:\Boot\fonts\meiryon_boot.ttf (129.8 KB)
Extracting: L:\Boot\fonts\msjh_boot.ttf (151.3 KB)
Extracting: L:\Boot\fonts\msjhn_boot.ttf (149.3 KB)
Extracting: L:\Boot\fonts\msyh_boot.ttf (142.8 KB)
Extracting: L:\Boot\fonts\msyhn_boot.ttf (138.8 KB)
Extracting: L:\Boot\fonts\segmono_boot.ttf (35.2 KB)
Extracting: L:\Boot\fonts\segoe_slboot.ttf (75.6 KB)
Extracting: L:\Boot\fonts\segoen_slboot.ttf (75.3 KB)
Extracting: L:\Boot\fonts\wgl4_boot.ttf (46.3 KB)
Extracting: L:\Boot\fr-FR\bootmgr.exe.mui (76.8 KB)
Extracting: L:\Boot\fr-FR\bootsect.exe.mui (15.5 KB)
Extracting: L:\Boot\grldr (277.1 KB)
Extracting: L:\Boot\memdisk (25.5 KB)
Extracting: L:\Boot\memtest.exe (1.1 MB)
Extracting: L:\Boot\resources\bootres.dll (17.8 KB)
Extracting: L:\CdUsb.Y (0 bytes)
Extracting: L:\PecmdExt.ini (1.1 KB)
Extracting: L:\Programs\7-Zip_x64\7-zip.dll (78.5 KB)
Extracting: L:\Programs\7-Zip_x64\7-zip32.dll (49 KB)
Extracting: L:\Programs\7-Zip_x64\7z.dll (1.4 MB)
Extracting: L:\Programs\7-Zip_x64\7z.exe (413.5 KB)
Extracting: L:\Programs\7-Zip_x64\7z.sfx (177.5 KB)
Extracting: L:\Programs\7-Zip_x64\7zCon.sfx (162.5 KB)
Extracting: L:\Programs\7-Zip_x64\7zFM.exe (783.5 KB)
Extracting: L:\Programs\7-Zip_x64\7zG.exe (533 KB)
Extracting: L:\Programs\7-Zip_x64\Lang\en.ttt (7.2 KB)
Extracting: L:\Programs\AttributeChanger_x64\ac.pdf (144 KB)
Extracting: L:\Programs\AttributeChanger_x64\acmain.exe (1.7 MB)
Extracting: L:\Programs\AttributeChanger_x64\acshell.dll (129.5 KB)
Extracting: L:\Programs\AttributeChanger_x64\acshell32.dll (111.5 KB)
Extracting: L:\Programs\AttributeChanger_x64\template.ini (28.2 KB)
Extracting: L:\Programs\BootIce_Pauly\BOOTICEx64.exe (450 KB)
Extracting: L:\Programs\Explorer++\Explorer++.exe (1.5 MB)
Extracting: L:\Programs\Explorer++\History.txt (45.6 KB)
Extracting: L:\Programs\Explorer++\License.txt (32.3 KB)
Extracting: L:\Programs\Explorer++\Readme.txt (722 bytes)
Extracting: L:\Programs\Explorer++\config.xml (8.5 KB)
Extracting: L:\Programs\MultiRes\MultiRes.exe (53.5 KB)
Extracting: L:\Programs\MultiRes\MultiRes.exe.manifest (661 bytes)
Extracting: L:\Programs\MultiRes\MultiRes.htm (38.7 KB)
Extracting: L:\Programs\MultiRes\MultiRes.ini (53 bytes)
Extracting: L:\Programs\MultiRes\usp10.dll\usp10.dll (75.5 KB)
Extracting: L:\Programs\MultiRes\winsta.dll\winsta.dll (270.3 KB)
Extracting: L:\Programs\NirSoft_ServiWin\readme.txt (13.5 KB)
Extracting: L:\Programs\NirSoft_ServiWin\serviwin.chm (16.1 KB)
Extracting: L:\Programs\NirSoft_ServiWin\serviwin.exe (42.6 KB)
Extracting: L:\Programs\Opera12\D3DCompiler_43.dll (2 MB)
Extracting: L:\Programs\Opera12\defaults\dictionaries.xml (4.1 KB)
Extracting: L:\Programs\Opera12\defaults\feedreaders.ini (718 bytes)
Extracting: L:\Programs\Opera12\defaults\handlers-ignore.ini (636 bytes)
Extracting: L:\Programs\Opera12\defaults\license.txt (15.7 KB)
Extracting: L:\Programs\Opera12\defaults\mailproviders.xml (39.4 KB)
Extracting: L:\Programs\Opera12\defaults\plugin-ignore.ini (1 KB)
Extracting: L:\Programs\Opera12\defaults\public_domains.dat (98.1 KB)
Extracting: L:\Programs\Opera12\defaults\search.ini (8.3 KB)
Extracting: L:\Programs\Opera12\defaults\standard_trusted_repositories.ini (262 bytes)
Extracting: L:\Programs\Opera12\defaults\tips_metadata.ini (1.4 KB)
Extracting: L:\Programs\Opera12\defaults\webmailproviders.ini (591 bytes)
Extracting: L:\Programs\Opera12\defaults\xmlentities.ini (2.8 KB)
Extracting: L:\Programs\Opera12\encoding.bin (513.9 KB)
Extracting: L:\Programs\Opera12\extra\missingplugin.svg (753 bytes)
Extracting: L:\Programs\Opera12\extra\missingpluginhover.svg (671 bytes)
Extracting: L:\Programs\Opera12\extra\windows-direct3d-10.blocklist.json (1.6 KB)
Extracting: L:\Programs\Opera12\extra\windows-opengl.blocklist.json (6 KB)
Extracting: L:\Programs\Opera12\files.sig (18.3 KB)
Extracting: L:\Programs\Opera12\files_list (8.1 KB)
Extracting: L:\Programs\Opera12\files_old.sig (23.8 KB)
Extracting: L:\Programs\Opera12\gstreamer\LGPL.txt (25.2 KB)
Extracting: L:\Programs\Opera12\gstreamer\README.txt (401 bytes)
Extracting: L:\Programs\Opera12\gstreamer\gstreamer.dll (816 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstaudioconvert.dll (91.5 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstaudioresample.dll (92 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstautodetect.dll (56 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstcoreplugins.dll (94 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstdecodebin2.dll (61.5 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstdirectsound.dll (65.5 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstffmpegcolorspace.dll (154.5 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstoggdec.dll (305.5 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstwaveform.dll (38 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstwavparse.dll (72 KB)
Extracting: L:\Programs\Opera12\gstreamer\plugins\gstwebmdec.dll (99.5 KB)
Extracting: L:\Programs\Opera12\html40_entities.dtd (7.7 KB)
Extracting: L:\Programs\Opera12\html5_entity_init.dat (35.4 KB)
Extracting: L:\Programs\Opera12\lngcode.txt (3.8 KB)
Extracting: L:\Programs\Opera12\locale\en\en.lng (191.5 KB)
Extracting: L:\Programs\Opera12\locale\en\en.zip (235.4 KB)
Extracting: L:\Programs\Opera12\locale\en\license.txt (15.7 KB)
Extracting: L:\Programs\Opera12\mapi\OperaMAPI.dll (197 KB)
Extracting: L:\Programs\Opera12\mathml.dtd (57.6 KB)
Extracting: L:\Programs\Opera12\opera.dll (15.5 MB)
Extracting: L:\Programs\Opera12\opera.exe (858.8 KB)
Extracting: L:\Programs\Opera12\operaprefs_default.ini (671 bytes)
Extracting: L:\Programs\Opera12\program\plugins\readme.txt (76 bytes)
Extracting: L:\Programs\Opera12\pubsuffix.xml (145.5 KB)
Extracting: L:\Programs\Opera12\region\ar\bookmarks.adr (6.4 KB)
Extracting: L:\Programs\Opera12\region\ar\search.ini (7.7 KB)
Extracting: L:\Programs\Opera12\region\ar\standard_speeddial.ini (1.3 KB)
Extracting: L:\Programs\Opera12\region\au\bookmarks.adr (7.7 KB)
Extracting: L:\Programs\Opera12\region\au\standard_speeddial.ini (1.1 KB)
Extracting: L:\Programs\Opera12\region\cis\en\bookmarks.adr (4.9 KB)
Extracting: L:\Programs\Opera12\region\cis\en\search.ini (8.8 KB)
Extracting: L:\Programs\Opera12\region\cis\en\standard_speeddial.ini (1.2 KB)
Extracting: L:\Programs\Opera12\region\cis\ru\bookmarks.adr (7.2 KB)
Extracting: L:\Programs\Opera12\region\cis\ru\search.ini (8.6 KB)
Extracting: L:\Programs\Opera12\region\cis\ru\standard_speeddial.ini (1.2 KB)
Extracting: L:\Programs\Opera12\region\cn\browser.js (115.9 KB)
Extracting: L:\Programs\Opera12\region\cn\en\bookmarks.adr (2.8 KB)
Extracting: L:\Programs\Opera12\region\cn\en\search.ini (8.5 KB)
Extracting: L:\Programs\Opera12\region\cn\en\standard_speeddial.ini (1.2 KB)
Extracting: L:\Programs\Opera12\region\cn\turbosettings.xml (130 bytes)
Extracting: L:\Programs\Opera12\region\eg\bookmarks.adr (4.0 KB)
Extracting: L:\Programs\Opera12\region\eg\search.ini (7 KB)
Extracting: L:\Programs\Opera12\region\eg\standard_speeddial.ini (1.4 KB)
Extracting: L:\Programs\Opera12\region\gb\bookmarks.adr (8.5 KB)
Extracting: L:\Programs\Opera12\region\gb\search.ini (8.6 KB)
Extracting: L:\Programs\Opera12\region\gb\standard_speeddial.ini (1.2 KB)
Extracting: L:\Programs\Opera12\region\hk\browser.js (115.9 KB)
Extracting: L:\Programs\Opera12\region\hk\turbosettings.xml (551 bytes)
Extracting: L:\Programs\Opera12\region\id\bookmarks.adr (5.9 KB)
Extracting: L:\Programs\Opera12\region\id\search.ini (8.0 KB)
Extracting: L:\Programs\Opera12\region\id\standard_speeddial.ini (1.3 KB)
Extracting: L:\Programs\Opera12\region\in\bookmarks.adr (10.1 KB)
Extracting: L:\Programs\Opera12\region\in\search.ini (7.7 KB)
Extracting: L:\Programs\Opera12\region\in\standard_speeddial.ini (1.3 KB)
Extracting: L:\Programs\Opera12\region\ke\bookmarks.adr (7.2 KB)
Extracting: L:\Programs\Opera12\region\ke\standard_speeddial.ini (1.1 KB)
Extracting: L:\Programs\Opera12\region\kz\bookmarks.adr (6.3 KB)
Extracting: L:\Programs\Opera12\region\kz\search.ini (8.6 KB)
Extracting: L:\Programs\Opera12\region\kz\standard_speeddial.ini (1.4 KB)
Extracting: L:\Programs\Opera12\region\latin_america\bookmarks.adr (6.9 KB)
Extracting: L:\Programs\Opera12\region\latin_america\search.ini (7.7 KB)
Extracting: L:\Programs\Opera12\region\latin_america\standard_speeddial.ini (1.4 KB)
Extracting: L:\Programs\Opera12\region\middle_east\bookmarks.adr (3.7 KB)
Extracting: L:\Programs\Opera12\region\middle_east\search.ini (7 KB)
Extracting: L:\Programs\Opera12\region\middle_east\standard_speeddial.ini (1.4 KB)
Extracting: L:\Programs\Opera12\region\mx\bookmarks.adr (7.2 KB)
Extracting: L:\Programs\Opera12\region\mx\search.ini (7.7 KB)
Extracting: L:\Programs\Opera12\region\mx\standard_speeddial.ini (1.4 KB)
Extracting: L:\Programs\Opera12\region\my\bookmarks.adr (7.4 KB)
Extracting: L:\Programs\Opera12\region\my\standard_speeddial.ini (1.1 KB)
Extracting: L:\Programs\Opera12\region\ng\bookmarks.adr (6.4 KB)
Extracting: L:\Programs\Opera12\region\ng\standard_speeddial.ini (1.4 KB)
Extracting: L:\Programs\Opera12\region\ph\bookmarks.adr (5.6 KB)
Extracting: L:\Programs\Opera12\region\ph\standard_speeddial.ini (1.3 KB)
Extracting: L:\Programs\Opera12\region\pk\bookmarks.adr (5.0 KB)
Extracting: L:\Programs\Opera12\region\pk\standard_speeddial.ini (1.3 KB)
Extracting: L:\Programs\Opera12\region\region.ini (1.6 KB)
Extracting: L:\Programs\Opera12\region\ru\bookmarks.adr (9.5 KB)
Extracting: L:\Programs\Opera12\region\ru\search.ini (9.2 KB)
Extracting: L:\Programs\Opera12\region\ru\standard_speeddial.ini (1.3 KB)
Extracting: L:\Programs\Opera12\region\se\bookmarks.adr (7.3 KB)
Extracting: L:\Programs\Opera12\region\se\standard_speeddial.ini (1.3 KB)
Extracting: L:\Programs\Opera12\region\tw\browser.js (115.9 KB)
Extracting: L:\Programs\Opera12\region\tw\turbosettings.xml (551 bytes)
Extracting: L:\Programs\Opera12\region\ua\ru\bookmarks.adr (6.9 KB)
Extracting: L:\Programs\Opera12\region\ua\ru\search.ini (8.8 KB)
Extracting: L:\Programs\Opera12\region\ua\ru\standard_speeddial.ini (1.3 KB)
Extracting: L:\Programs\Opera12\region\us\bookmarks.adr (7.1 KB)
Extracting: L:\Programs\Opera12\region\us\search.ini (8.6 KB)
Extracting: L:\Programs\Opera12\region\us\standard_speeddial.ini (1.2 KB)
Extracting: L:\Programs\Opera12\region\vn\bookmarks.adr (5.9 KB)
Extracting: L:\Programs\Opera12\region\vn\standard_speeddial.ini (1.2 KB)
Extracting: L:\Programs\Opera12\region\za\bookmarks.adr (7.4 KB)
Extracting: L:\Programs\Opera12\region\za\standard_speeddial.ini (1.2 KB)
Extracting: L:\Programs\Opera12\skin\standard_skin.zip (1.4 MB)
Extracting: L:\Programs\Opera12\styles\about.css (27 bytes)
Extracting: L:\Programs\Opera12\styles\cache.css (23 bytes)
Extracting: L:\Programs\Opera12\styles\certinfo.css (3.7 KB)
Extracting: L:\Programs\Opera12\styles\config.css (7.4 KB)
Extracting: L:\Programs\Opera12\styles\contentblock.css (331 bytes)
Extracting: L:\Programs\Opera12\styles\cpu.css (662 bytes)
Extracting: L:\Programs\Opera12\styles\debug.css (3.2 KB)
Extracting: L:\Programs\Opera12\styles\dir.css (25 bytes)
Extracting: L:\Programs\Opera12\styles\drives.css (658 bytes)
Extracting: L:\Programs\Opera12\styles\error.css (1.9 KB)
Extracting: L:\Programs\Opera12\styles\feed.css (1.8 KB)
Extracting: L:\Programs\Opera12\styles\gpu.css (62 bytes)
Extracting: L:\Programs\Opera12\styles\history.css (420 bytes)
Extracting: L:\Programs\Opera12\styles\im.css (2.4 KB)
Extracting: L:\Programs\Opera12\styles\image.css (516 bytes)
Extracting: L:\Programs\Opera12\styles\images\Opera_256x256.png (18.6 KB)
Extracting: L:\Programs\Opera12\styles\images\arrow.png (106 bytes)
Extracting: L:\Programs\Opera12\styles\images\bar.png (192 bytes)
Extracting: L:\Programs\Opera12\styles\images\bkgd-rev.png (1.6 KB)
Extracting: L:\Programs\Opera12\styles\images\bkgd.png (860 bytes)
Extracting: L:\Programs\Opera12\styles\images\bullet.png (349 bytes)
Extracting: L:\Programs\Opera12\styles\images\center.png (173 bytes)
Extracting: L:\Programs\Opera12\styles\images\container.png (11.8 KB)
Extracting: L:\Programs\Opera12\styles\images\customize.gif (243 bytes)
Extracting: L:\Programs\Opera12\styles\images\darkBox.png (142 bytes)
Extracting: L:\Programs\Opera12\styles\images\defaultFavicon.png (763 bytes)
Extracting: L:\Programs\Opera12\styles\images\error.png (2.7 KB)
Extracting: L:\Programs\Opera12\styles\images\file.png (534 bytes)
Extracting: L:\Programs\Opera12\styles\images\flag.png (258 bytes)
Extracting: L:\Programs\Opera12\styles\images\folder.png (792 bytes)
Extracting: L:\Programs\Opera12\styles\images\hanger.png (15.8 KB)
Extracting: L:\Programs\Opera12\styles\images\opera-icon-red.png (24.2 KB)
Extracting: L:\Programs\Opera12\styles\images\opera.png (5.3 KB)
Extracting: L:\Programs\Opera12\styles\images\page-bot.png (1.8 KB)
Extracting: L:\Programs\Opera12\styles\images\red_center.png (190 bytes)
Extracting: L:\Programs\Opera12\styles\images\red_left.png (327 bytes)
Extracting: L:\Programs\Opera12\styles\images\red_right.png (343 bytes)
Extracting: L:\Programs\Opera12\styles\images\root.png (123 bytes)
Extracting: L:\Programs\Opera12\styles\images\search.png (453 bytes)
Extracting: L:\Programs\Opera12\styles\images\section.png (204 bytes)
Extracting: L:\Programs\Opera12\styles\images\smartGroup.png (1010 bytes)
Extracting: L:\Programs\Opera12\styles\images\tooltiptail.png (414 bytes)
Extracting: L:\Programs\Opera12\styles\images\top.png (360 bytes)
Extracting: L:\Programs\Opera12\styles\images\warning.png (2.4 KB)
Extracting: L:\Programs\Opera12\styles\info.css (779 bytes)
Extracting: L:\Programs\Opera12\styles\m2_upgrade_1160.mbs (261.7 KB)
Extracting: L:\Programs\Opera12\styles\m2_welcome_message.mbs (154.6 KB)
Extracting: L:\Programs\Opera12\styles\mail.css (1.9 KB)
Extracting: L:\Programs\Opera12\styles\mathml.css (14.4 KB)
Extracting: L:\Programs\Opera12\styles\media.css (731 bytes)
Extracting: L:\Programs\Opera12\styles\message.css (54 bytes)
Extracting: L:\Programs\Opera12\styles\mime.css (8.9 KB)
Extracting: L:\Programs\Opera12\styles\opera.css (2.9 KB)
Extracting: L:\Programs\Opera12\styles\plugins.css (2.2 KB)
Extracting: L:\Programs\Opera12\styles\private.css (798 bytes)
Extracting: L:\Programs\Opera12\styles\search.css (558 bytes)
Extracting: L:\Programs\Opera12\styles\unstyledxml.css (2.2 KB)
Extracting: L:\Programs\Opera12\styles\user\accessibility.css (2.7 KB)
Extracting: L:\Programs\Opera12\styles\user\altdebugger.css (1.3 KB)
Extracting: L:\Programs\Opera12\styles\user\classid.css (1.2 KB)
Extracting: L:\Programs\Opera12\styles\user\contrastbw.css (673 bytes)
Extracting: L:\Programs\Opera12\styles\user\contrastwb.css (705 bytes)
Extracting: L:\Programs\Opera12\styles\user\disablebreaks.css (213 bytes)
Extracting: L:\Programs\Opera12\styles\user\disablefloats.css (229 bytes)
Extracting: L:\Programs\Opera12\styles\user\disableforms.css (269 bytes)
Extracting: L:\Programs\Opera12\styles\user\disablepositioning.css (243 bytes)
Extracting: L:\Programs\Opera12\styles\user\disabletables.css (410 bytes)
Extracting: L:\Programs\Opera12\styles\user\outline.css (735 bytes)
Extracting: L:\Programs\Opera12\styles\user\structureblock.css (4.5 KB)
Extracting: L:\Programs\Opera12\styles\user\structureinline.css (2.1 KB)
Extracting: L:\Programs\Opera12\styles\user\structuretables.css (2.7 KB)
Extracting: L:\Programs\Opera12\styles\user\tablelayout.css (258 bytes)
Extracting: L:\Programs\Opera12\styles\user\toc.css (4.7 KB)
Extracting: L:\Programs\Opera12\styles\warning.css (1.1 KB)
Extracting: L:\Programs\Opera12\styles\webfeeds.html (12.4 KB)
Extracting: L:\Programs\Opera12\styles\webstorage.css (422 bytes)
Extracting: L:\Programs\Opera12\styles\wml.css (1.8 KB)
Extracting: L:\Programs\Opera12\ui\dialog.ini (167.4 KB)
Extracting: L:\Programs\Opera12\ui\dialogs.yml (82.8 KB)
Extracting: L:\Programs\Opera12\ui\embedded_keyboard.ini (8.7 KB)
Extracting: L:\Programs\Opera12\ui\embedded_menu.ini (12.7 KB)
Extracting: L:\Programs\Opera12\ui\embedded_mouse.ini (583 bytes)
Extracting: L:\Programs\Opera12\ui\fastforward.ini (2.6 KB)
Extracting: L:\Programs\Opera12\ui\standard_keyboard.ini (28.7 KB)
Extracting: L:\Programs\Opera12\ui\standard_keyboard_compat.ini (25.6 KB)
Extracting: L:\Programs\Opera12\ui\standard_menu.ini (98.9 KB)
Extracting: L:\Programs\Opera12\ui\standard_mouse.ini (1.6 KB)
Extracting: L:\Programs\Opera12\ui\standard_toolbar.ini (53.4 KB)
Extracting: L:\Programs\Opera12\ui\widgets.yml (26.3 KB)
Extracting: L:\Programs\Opera12\updatechecker\LICENSES (7.6 KB)
Extracting: L:\Programs\Opera12\updatechecker\opera_autoupdate.exe (1.1 MB)
Extracting: L:\Programs\PStart.exe (760.5 KB)
Extracting: L:\Programs\PStart.xml (3.5 KB)
Extracting: L:\Programs\Q-Dir_x64\Q-Dir.exe (1.5 MB)
Extracting: L:\Programs\Q-Dir_x64\Q-Dir.ini (10.2 KB)
Extracting: L:\Programs\Q-Dir_x64\start.qdr (710 bytes)
Extracting: L:\Programs\Runscanner\RunScanner.exe (79.5 KB)
Extracting: L:\Programs\Runscanner\RunScannerDLL.dll (64 KB)
Extracting: L:\Programs\SuperFinder\Config\Options.ini (539 bytes)
Extracting: L:\Programs\SuperFinder\Config\readme.txt (60 bytes)
Extracting: L:\Programs\SuperFinder\FSL.dat (9 KB)
Extracting: L:\Programs\SuperFinder\Help\English\SuperFinder.chm (502.6 KB)
Extracting: L:\Programs\SuperFinder\Help\Franτais\SuperFinder.chm (896.8 KB)
Extracting: L:\Programs\SuperFinder\Languages\ENGLISH.BMP (214 bytes)
Extracting: L:\Programs\SuperFinder\Languages\ENGLISH.LNG (26.8 KB)
Extracting: L:\Programs\SuperFinder\License.txt (794 bytes)
Extracting: L:\Programs\SuperFinder\News.wri (1.2 KB)
Extracting: L:\Programs\SuperFinder\Plugins\readme.txt (48 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Arabic\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Deutsch\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\New Search.rules (647 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\English\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\B�squeda de archivos de audio.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\B�squeda de archivos de video.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\B�squeda de documentos.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\B�squeda de im�genes de disco (ISO_ NRG_ IMG_ etc..) de todos los tama�os.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\B�squeda de im�genes de disco (ISO_ NRG_ IMG_ etc..) por encima de 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\B�squeda de im�genes.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\B·squeda por contenido (s≤lo archivos de texto).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\B�squeda por contenido (todos los archivos).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Limpieza de disco (archivos sin tama�o).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Limpieza de disco (archivos temporales).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Nueva b�squeda.rules (647 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Espa�ol\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Chercher des documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Chercher des fichiers image (ISO_ NRG_ IMG_ etc.) toutes tailles.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Chercher des fichiers image (ISO_ NRG_ IMG_ etc..) au-dessus de  250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Chercher des fichiers video.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Chercher des photos.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Chercher les fichiers audio.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Chercher par contenu (fichiers textes seuls).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Chercher par contenu (tous fichiers).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Nettoyeur (fichiers longueur nulle).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Franτais\Nettoyeur (fichiers temporaires).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Galego\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Hrvatski\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Cerca contenuto (solo files di testo).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Cerca contenuto (tutti i files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Cerca documenti.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Cerca files Immagine  (ISO_ NRG_ IMG_ ecc..) pi∙ di 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Cerca files Immagine (ISO_ NRG_ IMG_ ecc..) qualunque dimensione.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Cerca files audio.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Cerca immagini.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Cerca video.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Pulizia disco (files di zero bytes).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Italiano\Pulizia disco (files temporanei).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Japanese\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Audio fajlok keresese.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Dokumentumok keresΘse.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Kepek keresese.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Kereses tartalomra(osszes file).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\KeresΘs tartalomra(csak szoveges(.txt) fajlok).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Lemez takaritas(ideiglenes fajlok).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Lemezkep fajlok keresese (ISO_ NRG_ IMG_ etc..).rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Lemezkep fajlok keresese(ISO_ NRG_ IMG_ etc..) csak 250 MB felett.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Lemeztakaritas(ures fajlok).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Uj kereses.rules (647 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Magyar\Video fajlok keresese.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Nederlands\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Polski\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Portuguese (Brazil)\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Romanian\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Russian\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Serbian\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Simplified Chinese\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Slovak\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Svenska\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Traditional Chinese\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Translation\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Ukrainian\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Valenciα\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Clean disk (temporary files).rules (783 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Clean disk (zero length files).rules (657 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Search for audio files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Search for contents (all files).rules (655 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Search for contents (text files only).rules (659 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Search for documents.rules (677 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Search for image files (ISO_ NRG_ IMG_ etc..) all sizes.rules (678 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Search for image files (ISO_ NRG_ IMG_ etc..) over 250 MB.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Search for pictures.rules (701 bytes)
Extracting: L:\Programs\SuperFinder\Rules\Vietnamese\Search for video files.rules (684 bytes)
Extracting: L:\Programs\SuperFinder\SuperFinder.exe (2.3 MB)
Extracting: L:\Programs\SuperFinder\gdiplus.dll (1.6 MB)
Extracting: L:\Programs\xCHM\xchm-1.23win32.exe (1.5 MB)
Extracting: L:\Win8.1.cd (0 bytes)
Extracting: L:\autorun.inf (182 bytes)
Extracting: L:\bootmgr.efi (1.5 MB)
Extracting: L:\bootmgr.exe (635.8 KB)
Extracting: L:\efi\boot\bootx64.efi (1.5 MB)
Extracting: L:\efi\microsoft\boot\bcd (256 KB)
Extracting: L:\efi\microsoft\boot\bcd.LOG1 (17 KB)
Extracting: L:\efi\microsoft\boot\bcd.LOG2 (0 bytes)
Extracting: L:\efi\microsoft\boot\bcd{7ceb52a0-f869-11e4-9125-005056c00008}.TM.blf (64 KB)
Extracting: L:\efi\microsoft\boot\bcd{7ceb52a0-f869-11e4-9125-005056c00008}.TMContainer00000000000000000001.regtrans-ms (512 KB)
Extracting: L:\efi\microsoft\boot\bcd{7ceb52a0-f869-11e4-9125-005056c00008}.TMContainer00000000000000000002.regtrans-ms (512 KB)
Extracting: L:\efi\microsoft\boot\cdboot.efi (1.3 MB)
Extracting: L:\efi\microsoft\boot\efisys.bin (1.4 MB)
Extracting: L:\efi\microsoft\boot\fonts\chs_boot.ttf (3.5 MB)
Extracting: L:\efi\microsoft\boot\fonts\cht_boot.ttf (3.7 MB)
Extracting: L:\efi\microsoft\boot\fonts\jpn_boot.ttf (1.9 MB)
Extracting: L:\efi\microsoft\boot\fonts\kor_boot.ttf (2.3 MB)
Extracting: L:\efi\microsoft\boot\fonts\malgun_boot.ttf (164.3 KB)
Extracting: L:\efi\microsoft\boot\fonts\malgunn_boot.ttf (161.9 KB)
Extracting: L:\efi\microsoft\boot\fonts\meiryo_boot.ttf (131.4 KB)
Extracting: L:\efi\microsoft\boot\fonts\meiryon_boot.ttf (129.8 KB)
Extracting: L:\efi\microsoft\boot\fonts\msjh_boot.ttf (151.3 KB)
Extracting: L:\efi\microsoft\boot\fonts\msjhn_boot.ttf (149.3 KB)
Extracting: L:\efi\microsoft\boot\fonts\msyh_boot.ttf (142.8 KB)
Extracting: L:\efi\microsoft\boot\fonts\msyhn_boot.ttf (138.8 KB)
Extracting: L:\efi\microsoft\boot\fonts\segmono_boot.ttf (35.2 KB)
Extracting: L:\efi\microsoft\boot\fonts\segoe_slboot.ttf (75.6 KB)
Extracting: L:\efi\microsoft\boot\fonts\segoen_slboot.ttf (75.3 KB)
Extracting: L:\efi\microsoft\boot\fonts\wgl4_boot.ttf (46.3 KB)
Extracting: L:\efi\microsoft\boot\memtest.efi (1.4 MB)
Extracting: L:\efi\microsoft\boot\resources\bootres.dll (17.8 KB)
Extracting: L:\menu.lst (2.5 KB)
Extracting: L:\sources\boot.wim (495.9 MB)
Finalizing, please wait...
L:autorun.inf already exists - keeping it
NTFS Fixup (Checkdisk)...
Le nom de volume est Win8_1SE.

CHKDSK est en train de vérifier les fichiers (étape 1 sur 3)...
  768 enregistrements de fichier traités.
La vérification des fichiers est terminée.
  0 enregistrements de grand fichier traités.
  0 enregistrements de fichier incorrect traités.
  0 enregistrements EA traités.
  0 enregistrements d'analyse traités.
CHKDSK est en train de vérifier les index (étape 2 sur 3)...
  1006 entrées d'index traitées.
La vérification des index est terminée.
CHKDSK est en train de vérifier les descripteurs de sécurité (étape 3 sur 3)
  768 SD/SID de fichiers traités.
La vérification des descripteurs de sécurité est terminée.
  119 fichiers de données traités.
Windows a vérifié le système de fichiers sans trouver de problème.

   2014207 Ko d'espace disque au total.
    617980 Ko dans 586 fichiers.
       208 Ko dans 121 index.
     13375 Ko utilisés par le système.
     12128 Ko occupés par le fichier journal.
   1382644 Ko disponibles sur le disque.
      4096 octets dans chaque unité d'allocation.
    503551 unités d'allocation au total sur le disque.
    345661 unités d'allocation disponibles sur le disque.
NTFS Fixup completed.

Found USB device 'Generic- Compact Flash USB Device' (????:????)
Device eliminated because it appears to contain no media
Found USB device 'Generic- MS/MS-Pro USB Device' (????:????)
Device eliminated because it appears to contain no media
Found USB 2.0 device 'Generic- SD/MMC USB Device' (058F:6362)
Device eliminated because it appears to contain no media
SetupDiGetDeviceRegistryProperty (Friendly Name) failed: [0x0000000D] Données non valides.
Found USB device 'USB Storage Device (Generic)' (????:????)
Device eliminated because it appears to contain no media
Found USB 2.0 device 'PNY USB 2.0 FD USB Device' (154B:0005)
Using autorun.inf label for drive L: 'WinPESE'
1 device found
Disk type: Removable, Sector Size: 512 bytes
Cylinders: 250, TracksPerCylinder: 255, SectorsPerTrack: 63
Partition type: MBR, NB Partitions: 1
Disk ID: 0x02D69C8B
Drive has a Rufus Master Boot Record
Partition 1:
  Type: NTFS (0x07)
  Size: 1.9 GB (2062548992 bytes)
  Start Sector: 2048, Boot: Yes, Recognized: Yes

In the log, I have Uses WinPE: No, how do you detect WinPE ?

Here's how I am currently doing with BootIce for the dual boot

BootIcex64.exe /device=L: /partitions /repartition /activate /usb-hdd /fstype=FAT32 /vollabel=WinPESE 
BootIcex64.exe /device=L: /mbr /install /type=nt60 /quiet
// in bootice, I have 1 active FAT32 partition, ID=OB 
// MBR=Windows NT 6.x MBR - PBR=BOOTMGR Boot record

After copying the contents of Win8.1PE.iso, the startup works in BIOS and UEFI.

how do you detect WinPE ?

Only Windows XP uses WinPE. Windows Vista an later use bootmgr (which is properly detected according to your log) → nothing abnormal here.

If I choose "MBR partition scheme for BIOS or UEFI computers" (...)

If you select this, your USB will only be bootable in BIOS mode (i.e. using the CSM module on UEFI computers). This means that you will not be able to boot in UEFI:NTFS mode since you're not booting in pure UEFI mode in the first place, and thus the extra UEFI:NTFS partition is not created.

Do you have any need to boot that USB in BIOS mode?

If not, then you should really select one of the other options, preferably "GPT partition scheme for UEFI computer".
If you do, i.e. if you plan to use the same USB to install Windows on a BIOS computer AND on an UEFI computer, then see here. You will need to use the Alt-E cheat mode if you really want both.

Thanks Pete, I should have read more the FAQ, I want to preserve the dual EFI+BIOS boot, like Win ToGo I will try the Alt-E cheat mode tomorrow, that appears to fit my need. Which partition scheme and target system type, I need to choose in addition to the "Dual UEFI/BIOS mode enabled" Cheat modes ?

The cheat mode only applies for the first option. If you use any of the other pure UEFI options, you'll never be able to boot in BIOS mode, so of course, Alt-E has no effect there.

Please let me know the outcome of your test, so that I can deal with this issue accordingly.

OK, I started now with the "Dual UEFI/BIOS mode enabled" Cheat modes. I have now the small (256 Kb) UEFI_NTFS FAT12 partition.

Without surprise, everything works fine on my BIOS laptop.

On UEFI firmware and the default "Bios" setting with secure boot enabled, I get the message: "EFI USB device (xxxx USB 2.0) has been blocked by the current security Policy". Once secure boot disabled, It starts flawlessly with your UEFI_NTFS driver. Great

Is there any solution to get a free code signing certificate for OpenSource with something like https://www.certum.eu/certum/cert,offer_en_open_source_cs.xml, it would be great. Otherwise, have the opportunity to choose between your nice UEFI_NTFS solution or the FAT32 formatting to be able to use the original Ms bootx64.efi and to keep the secure boot On.

Yes, I should have mentioned that UEFI:NTFS will only work if Secure Boot is disabled, as the UEFI:NTFS loader is not signed.

Is there any solution to get a free code signing certificate

I wish it was a simple as that!

Microsoft is in control of what can get signed, and explicitly forbids GPLv3 executables. As per Microsoft's UEFI signing policy: "Code submitted for UEFI signing must not be subject to GPLv3". Both the UEFI:NTFS loader and the EFI NTFS driver are GPLv3.

Also, there's no such thing as a free UEFI signing certificate (which needs to be renewed if you plan to update your binary). If you have a look at the links from Microsoft's page, you'll find that this costs at least $200. That's quite expensive.

I would believe however that you can install Windows using UEFI:NTFS with Secure Boot disabled, and then re-enable it afterwards (since Microsoft's UEFI binaries are signed). Does that not work? Also, since the Rufus application itself is signed, you should be able to trust that the UEFI:NTFS modules installed by Rufus on the USB haven't been tampered with, so your installation should be trustworthy, even with Secure Boot disabled.

What a shame that signature, your NTFS_UEFI solution would really deserves. Maybe you can go a step back on your nice and fair principle on donations and suggest a donation for the sole purpose of signing, who knows, some generous soul for this really great solution. I have no problem to disabled the secure boot and then activate, here, but it may be a concern for others.

Otherwise I do not understand why FAT32 file sytem is not allowed for the "MBR partition scheme for BIOS or UEFI computers" in Rufus ? Win2Go, WinPE,.. with the standard files (Boot en efi folders) should be able to start in BIOS and secure boot UEFI with the FAT32 File system with the limit of 32Gb and 4Gb file size. I do like that, by using BootIce (first post) and the dual boot works well.

Well, if needed, I could cover the certificate with the ad I have on the Rufus website, so the price is not really the issue.

The real problem is that there's no way in hell I'm gonna switch license, in order to comply with a unilateral & tyrannical decree from Microsoft about the licenses they deem acceptable the ones they don't.

Furthermore, as far as I'm concerned, a world where it would be impossible for Secure Boot to be disabled by users (which Microsoft tried to push on ARM system) is unacceptable, as it will restrict user freedom. The person in ultimate control of choosing what can and cannot be booted on a computer should always be the user, not the system manufacturer or Microsoft.

Thus, if the ability to use UEFI:NTFS can influence people to prefer systems where Secure Boot can be disabled, or forcefully complain, to system manufacturers or Microsoft, that the Secure Boot restrictions are preventing them from achieving what they want, then, by all means, this is how it should be. I don't care if someone's an average Joe that has no idea what Secure Boot is, how it can be disabled, and would just like their system to work - this is just too important a matter, in the battle to ensure continued freedom to run the software that one wants on the machine that one owns, to be glossed over on the account of "convenience"... Or to put in in an easy to remember quote: "People willing to trade their freedom for convenience deserve neither and will lose both."

I do not understand why FAT32 file sytem is not allowed for the "MBR partition scheme"

This is only for Windows (Rufus will use FAT32 for Linux ISOs for instance). The main reasons are as follows:

4 GB file support. There are a few Windows installation ISOs out there, including official ones from Microsoft, with a >4GB install.wim. Not having to educate users and pop up messages about the restrictions of FAT32 when it comes to file size is a BIG PLUS. This is also important if the user has a large USB drive and plans to use it for more than the Windows install. For instance, if you have a 32GB drive, and your install files occupy only 5-6GB, you may want to use the remaining capacity to move stuff around. But if you use FAT32, you can say goodbye to using that drive for transferring large backups, movies or whatever file you have that's larger than 4GB.
The use of NTFS effectively allows me to enforce the use of BIOS / UEFI/CSM mode for the install, so that there is not question about which mode Windows will be installed in. If I were to allow FAT32, I'd have to remove files to prevent UEFI boot. Rufus always attempts to leave the ISO content as untouched as it can.
I don't see much point of allowing choice when I am not aware of any issue with using NTFS rather than FAT32. Most Linux systems have mature NTFS support, so it's hard for me to see much of any advantage in allowing FAT32, besides the user being able to say "yeah, I am able to choose between FAT32 and NTFS".
Every thing I have seen about dual/multi boot tells me it's an utter waste of time, and that you will always be much better off without it (which is why I'm not planning to support it in Rufus, ever - if you want anything multiboot, you're on your own). With a decent USB, it only takes a couple minutes to recreate a drive in Rufus, and you don't have to be actively involved in the process at all - you can do something else. Even if you have to recreate your drive 10 or 20 times, I'm hard pressed to see how using Rufus will ever cost you more time than trying to maintain a multiboot drive... But sadly a lot of people seem to have difficulty grasping the concept of trying to save them time by inviting them not waste it in something as fruitless as multiboot...

I fully agree on the unacceptable & unilateral & tyrannical position from Microsoft. but I'm unable to write it with my poor English

I respect your choice for MultiBoot or for UEFI_CSM_NTFS (it will be unfortunately a bit hard for Joe), but I do not really share your point on FAT32. Most install.wim are below 4Gb. Those who want to use for Backup, movies will use your great UEFI_NTFS with CSM or Secure Off. For ToGo, PE, it is not really a multiboot matter but be able to start the same USB stick whatever the firmware and without going through the Bios setting. Just my point of view, as said above, I really respect your work and your choice done on Rufus.

Rufus does enable dual BIOS+UEFI boot for To Go (because you may use that same drive in either a BIOS or UEFI computer). But then you should be prepared to disable Secure Boot since Microsoft ensured that it would be incompatible with free software...

Yep, another unacceptable M$ level, for the bait of gain. They will perhaps bite their fingers one day.

A new cheap mode for the dual Boot UEFI/BIOS in a single FAT32 partition would have been good for me, but you are not me and I let you do the way that you think is best of course.

Thanks for all these answers and for the great Rufus, UEFI_NTFS,.... :)

Well, it's always difficult to try to satisfy everyone, and, again, I'd rather people educate themselves about Secure Boot, and how part of it was clearly designed to take control away from the user, than hide the issue and open the door for an even more restrictive boot process in the long run...

I'm going to close this issue now.

Hi Pete, Some of us are in a situation where we are required (for work purposes) to keep secure boot on, but we would still like to use Windows To Go on a USB stick. DIsabling secure boot does not work in this scenario, since Rufus-created Windows To Go sticks won't boot with secure boot on.

One option that DOES work is to generate our own secure boot keys and install our own keys into the secure boot database for our machines, and then sign the Rufus binaries (bootx64.efi, ntfs.efi etc.) with our own keys. However, by default, Rufus creates EFI (fat32) system partitions with less than 1 kilobyte of free space -- not enough free space to append even a single signature.

For now one workaround is to delete unneeded files from the EFI system image (e.g. bootarm.efi), but this is kind of annoying (which is why Rufus includes all three supported architectures in one image to begin with!). Would it be possible to have Rufus include a bit more free space in the EFI partition, on the order of 10 kilobytes or so, at the time that it creates the system image?

This is too custom a requirement, and I'm afraid I don't do custom stuff if it'll just help solve one person's specific problem (or even a handful — far too few people would use this). Plus, I kind of am opposed to the use of Secure Boot altogether, first, because Microsoft is clearly using it as a way to shut down GPLv3 software and restrict what people should have the freedom to do, and second, because the whole Secure Boot feature has recently become kind of pointless, since it's been demonstrated that anybody can break it through the use of old Microsoft Windows EFI bootloaders.

If you need a custom solution with your keys, I would encourage you to first recreate your own UEFI:NTFS partition as documented here, with your own signed files, and then recompile your own Rufus with this new new uefi-ntfs.img. You can very easily recompile Rufus by installing Visual Studio 2015 Community Edition as it is freely available from Microsoft and you are licensed to use it, even in a corporate environment, if the project you compile is Open Source software (which Rufus is).

Thanks, that's fair, and yes it's easy enough to recompile. But I might try one last time to convince you that Secure Boot is not intrinsically evil. Like all tools, it can be used for evil, and Microsoft is using it that way, but the tool itself is not inherently bad. Of course if you and others in the community don't support custom keys, then too few people will use that capability, making your prophecy self-fulfilling. I think it's better to democratize Secure Boot rather than leaving all the keys in the hands of Microsoft.

Take a look at the "evil maid" attack (https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html or https://twopointfouristan.wordpress.com/2011/04/17/pwning-past-whole-disk-encryption/). This is the kind of thing that Secure Boot can (help to) protect against.

Ironically, one can protect Secure Boot against old Microsoft bootloaders by deleting the Microsoft Windows Production PCA 2011 key from your computer's secure boot database. Of course this renders your machine entirely unable to boot Windows, which might be a feature.

But I might try one last time to convince you that Secure Boot is not intrinsically evil

It is when the entity that controls the master key arbitrarily (and with a deliberate misinterpretation of the license terms, to pretend they would force private keys to be published, which is blatantly wrong) decides which license a code should use to be eligible to be signed by the master key. See Microsoft's UEFI signing policy: "Code submitted for UEFI signing must not be subject to GPLv3". It doesn't matter if one can (through a process that could EASILY have been made a lot simpler) sometimes install additional certificates to validate their own code (how about those Windows certified ARM tablets that MUST have Secure Boot enforced, without the possibility of installing custom keys? Or how about the devious Windows 10 hardware requirement that are also taking one step towards preventing users to have any control over their Secure Boot settings?).

If the default signing process wasn't controlled by Microsoft alone, I would agree with you that Secure Boot isn't inherently bad. But whatever committee designed Secure Boot blew their chance of trying to convince the world it had the end user's interest in mind, when they relinquished exclusive control of the signing process to Microsoft.

And no, by being able, for a while (that is, until Microsoft pushes more hardware manufacturers to do otherwise), to install your own private keys, because you are being allowed to do so, isn't helping towards not "leaving all the keys in the hands of Microsoft". When Microsoft have already and unilaterally leveraged Secure Boot to oust the GPLv3, do you really want to take a chance that they'll graciously leave you install your own keys on upcoming commodity hardware?

Also, IMO, "Secure" Boot is a poor excuse for security... Physical Hardware switches to control any kind of firmware rewrite (be it for mobo or HDD firmware - what else is the point of having a write enable pin on all these flash chips), and authentication with a hardware token (such as U2F), uniquely associated with the mobo, to painlessly grant boot authorisation to an executable of the user's choosing, without having to rely on a third party, is what the UEFI committee should have gone for if they really had user interests in mind. But instead they chose to ignore basic security advice, and told Microsoft "Here, please be in charge of this lock, that also happens to control just how much access users can have to your competitors' products"...

As long as the problems of Microsoft being the sole party with control of the signing process, and being able to strongarm hardware manufacturers into disabling the installation of private keys, is not being addressed, I just can't see myself supporting Secure Boot.

But whatever committee designed Secure Boot blew their chance of trying to convince the world it had the end user's interest in mind, when they relinquished exclusive control of the signing process to Microsoft.

Hi, I'm not an expert on these matters so excuse me if I'm completely off base here, but isn't this quote really misrepresenting facts? I'm no blind MS fan and clearly they use their influence on OEMs to ensure that all Windows-certified systems have to include their Key Exchange Key (KEK) in addition to the OEM's own Platform Key (PK), but as Matthew Garrett has clearly mentioned "The UEFI spec doesn't describe or mandate a central certifying authority." As I understand it nothing actually prevents all the Linux distros from getting together under the banner of say the Linux Foundation (LF) and creating their own KEK (there are enough companies and users who can contribute the $ required). Only issue is that they don't have the influence over OEMs that MS does, so systems made by OEMs that don't agree to include the LF KEK (or OEMs the LF hasn't made a deal with) won't run Linux unless Secure Boot (SB) is either disabled or the user adds his own key in custom mode. Clearly Linux distros came to the conclusion that the easiest solution was to use the MS KEK that's anyway going to be present almost always, and so they use the MS-signed shim now. Thus while the end result is that they're in a way beholden to MS, the way I see it it's more due to their caving in and taking the path of least resistance (one that's probably cheaper too). What if they'd all banded together to create their own KEK and even filed suit (I'm sure the FSF etc. would have loved to contribute) against any OEMs dumb enough to refuse to include the same? Wouldn't that have resulted in a real meaningful win for Linux as a whole instead of now crying over MS wielding so-called "exclusive control of the signing process"? Expecting a well-known aggressively for-profit entity like MS to ever act benevolently towards a competing OS is ridiculous, and I found it a real shame (and continue to do so) that the people in charge of Linux and the various distros as a whole didn't decide to take the far tougher but also infinitely more rewarding path.

Regarding OEMs that don't allow SB to be disabled by users, I don't see why a class-action suit can't be filed against them. However, is there any such OEM actually dumb enough to be known as the company that deliberately blocks Linux on their hardware? Seems to be an overblown concern because I can't imagine any OEM willing to shoot itself in the foot like that and ensure it turns away paying customers who simply don't like Windows. MS can say anything it wants about OEMs not being required to allow users to disable SB, but it's just another nonsensical suggestion that cannot be legally enforced. I would quite honestly be amazed if any OEM actually went and did this and deliberately reduced its user base only to users of a single OS. If you know of any please let me know so I can spread the word and avoid them like the plague.

OK, you're right, and it is a poor choice of word of my part to imply that the UEFI committee officially mandated Microsoft as the sole controller of the Secure Boot signing. However, I'm still of the opinion that, by deciding that they would effectively relinquish control of the signing process to whoever has the most influence onto OEMs to have them embed their root certificate, they implicitly gave Microsoft the keys of the realm, knowing full well that Microsoft wouldn't play nice at all ("No GPLv3 for you!", which I'll come to in a moment), as they had already been known to strongarm OEMs into making it much harder than it should to provide computers that come with Linux by default (e.g. Dell) and as much as very recently, still seem to be pulling strings behind everyone's back to encourage OEMs not make Linux installation harder (see Lenovo and AHCI... coz why else would an OEM chose to reduce their potential sales targets, by preventing installation of a non Windows OS). I assume that you're familiar with these cases, that, when looked at in a logical fashion, seem very much at odds with both the OEM and the consumers' interests...

So, we do have strong circumstantial evidence that, up to as much as very recently, Microsoft will do anything but play nice when it comes to the installation of non Microsoft OSes. I know that, for the time being this counter argument doesn't seem related to the point you were making, but I'm coming to that. What I am trying to establish here is that, at the time they decided the Secure Boot process, the UEFI committee should have been well aware that, when they said that "We'll keep our hands off the Secure Boot signing process and instead hand it over to whoever can convince OEMs to include their master public key", Microsoft would jump at the occasion to do what they've always done, and prevent the competition from taking hold.

And now, I can hear you go back to your original point that, regardless, the Linux people are still officially able to ask OEMs to add their own master public key, so let's look at this, because there again, there exists strong circumstantial evidence that something odd has been happening.

You see, Microsoft made it exceedingly explicit (paragraph 4 here) that they would never sign anything GPLv3 (which they feebly tried to "justify" by pretending that it would force them to produce their private signing key, which is preposterous... but hey, they needed a semi plausible excuse not to look as abusive as their conditions clearly indicated they were). And GRUB, which is the bootloader of choice for most Linux systems, is GPLv3. So where you simply say "non benevolent", when qualifying Microsoft's behaviour, I have to go a bit further and say "downright authoritarian"...

Now, be mindful that I'm only focusing on the GPLv3 part here, and not the fact that the default GRUB is generic bootloader, which, of course, you don't want to sign as a a Secure Boot executable, as, if using the unmodified source, you'd then be able to boot anything... and defeat the while point of SB. Obviously, if you wanted to use GRUB, then you'd have to add trust chain mechanism into it, that'll reject anything that you didn't vouch for, before you get it signed for Secure Boot, but then again, modifying the existing codebase of the project you already use, to add the new feature you need is exactly what you do in the Open Source world. Yet, this is not what happened. And even worse, instead of doing the right thing, which would have been to flat out reject working with Microsoft as long as they arbitrarily get to prohibit licensing models they don't like, and instead establish their own signing entity (as you correctly point out they should have been able to), they went with fragmented routes and solutions, every one of which still leaving Microsoft in sole control of the signing process.

Maybe this doesn't ring an alarm bell for you, but as far as I'm concerned, there's something rotten in the realm of Secure Boot signing if Microsoft was able to get away with being the sole entity in control of the signing process, despite their enforcing of terms of conditions that are very much discriminatory and biased against the Open Source community, and despite the fact that the UEFI committee declared that anyone should be able to become a Secure Boot signing authority. In other words, I have to go further than your "It's a shame that the Linux people didn't do something about creating their own entity", by saying that something smells fishy, and knowing Microsoft's established fondness for abusing their control over OEMs, I find it hard to believe that it's just down to luck, or, that the UEFI committee, of which I believe Microsoft was an active participant, didn't know that, by declaring that the signing would be "open to whoever can work with OEMs", they would essentially ensure that only Microsoft would have control of it.

However, is there any such OEM actually dumb enough to be known as the company that deliberately blocks Linux on their hardware?

I would have been with you on this about a month ago. However, I have it from good source that, with the introduction of intel's Apollo Lake some OEMs have started producing UEFI firmwares that no longer come with a CSM module, and I guess that, even if they aren't related, once legacy is out, the next logical step, if your goal is OS lockdown (which I should point out, Microsoft already managed to get OEMs to accomplish on ARM), is to remove the ability to disable Secure Boot...

As I pointed above, it looks to me like Microsoft has successfully been able to strongarm Dell, Lenovo and other OEMs behind the scenes into a semi Windows exclusivity on their platform. So that's why, even as I wholeheartedly agree that your point is 100% valid, I can't help being very pessimistic about Secure Boot, from its inception to what we are continuing to see now, with still a single authoritative player controlling all the strings...

Your points about MS' deliberate rejection of the GPLv3 for signing purposes are perfectly valid, but I hope you understand that MS refusing to sign GRUB due to GPLv3 would be completely irrelevant if the LF had its own KEK. Ideally, we'd then have OEM systems with the OEM's PK and both MS and LF's KEKs. MS does whatever the heck it wants, LF does their own thing and never the twain need meet. For the end user it would be all about having the freedom to install Linux or Windows or both, with no need to turn off SB.

One thing I hope you can explain though - why the outrage over MS not signing GRUB? Don't they currently sign the shim bootloader that most (if not all) major Linux distros use now to deal with SB? What would be the big advantage of having an MS signed GRUB over the MS signed shim?

And even worse, instead of doing the right thing, which would have been to flat out reject working with Microsoft as long as they arbitrarily get to prohibit licensing models they don't like, and instead establish their own signing entity (as you correctly point out they should have been able to), they went with fragmented routes and solutions, every one of which still leaving Microsoft in sole control of the signing process.

Again, if they had done their own (right) thing then it wouldn't have mattered how MS treats the GPLv3. It's only because they themselves bought into MS' way of doing things that they then naturally found themselves at the mercy of the latter. Now who really found that surprising and didn't see it coming? If some Linux folk didn't then I don't know which planet they were living on.

I would have been with you on this about a month ago. However, I have it from good source that, with the introduction of intel's Apollo Lake some OEMs have started producing UEFI firmwares that no longer come with a CSM module, and I guess that, even if they aren't related, once legacy is out, the next logical step, if your goal is OS lockdown (which I should point out, Microsoft already managed to get OEMs to accomplish on ARM), is to remove the ability to disable Secure Boot...

The best response as a consumer is to vote with your wallet, and guess what the consumer did when it came to Windows on ARM (WoA) i.e. Windows RT? Also, how many OEMs were there anyway? The majority of WinRT devices were from MS itself, i.e. the Surface RT and Surface 2, and the massive write-down for them is well-known. Still, since these were their own devices MS could do whatever the heck it wanted including preventing disabling of SB. Next in popularity probably was the 2520 from Nokia (which was practically dancing to MS' tune), and finally there was a device each from Asus, Dell, Lenovo and Samsung. All dead sooner rather than later, and even if all were forced by MS to prevent users from disabling SB, frankly I don't know anyone who cared. Not to mention nothing stops any OEM from releasing ARM tablets with Linux on them. (Also curious, why isn't there a similar amount of outrage when it comes to ARM phones being all locked down?)

When it comes to x86 of course we're eventually going to have class 3 UEFI devices that no longer include either a CSM or BIOS and will be purely UEFI only. I don't care to deal in idle speculation about possible lockdowns, but when some OEM actually prevents SB disabling you can be sure there will be some people raising a huge hue and cry over it. However, now that I think about it some more, who will these people be? I mean, the majority of Linux users won't care since most Linux distros decided to depend on an MS signed shim and that means having SB enabled won't affect them at all. The only ones affected will be those who don't use the MS signed shim for some reason, and are there really enough of them to make a difference? Again, this is a direct consequence of depending on MS' KEK, and whose fault is that?

tl;dr (even though the allegory might sound harsh) - The sheep believed the wolf and went to play with it, then cried in disbelief when it ate them one by one.

(Again, if I'm factually wrong about any point I'd love to be educated about it since I never claimed to be an expert on the topic, but the above reflects my current understanding of the subject and why I believe blaming MS now is like crying over spilt milk.)

MS refusing to sign GRUB due to GPLv3 would be completely irrelevant if the LF had its own KEK

and

why the outrage over MS not signing GRUB?

Again, my outrage is over MS not signing GPLv3 code, be it GRUB or any other software. And I believe it is very much relevant when nobody seems to:

Bother to create their own signing entity OR
"Raise a huge hue and cry over it" (to take your words).

One of these two things should be happening, because nobody in the Open Source world should let a single signing entity tell what license they can and cannot use. Yet, it's been years and everybody seems to accept the situation. Especially, nobody in the Open Source community seems to take outrage to working with a company that has right of say about which license they can use.

And this complacency with the status quo is precisely why I am predicting that we are going to let Microsoft get away with more. As such, I think you are deluding yourself if you think that:

People rejected the locked down ARM tablet because they were locked down. They were rejected because there were Android tablets that were usually cheaper and with a larger number of apps. People buy tablets for apps. If the apps aren't there, of course the thing isn't going to sell. Especially, I don't remember that much of an outrage about the platforms being locked down (which is why I'm worried that, seeing this, Microsoft will think it is fair game to just go for it on x86... which they're already doing).
Microsoft is going to be cautious about trying to get away with locked down systems. They've been testing the waters left and right for that, and the level of protest they've seen has been dismal, if there have been any protests at all. On the contrary, they are probably contemplating the long list of what they've been able to get away with so far (including FUD about the GPLv3), and are bound to consider that x86 lockdown is no big deal.

Oh, and guess what, Microsoft has already taken measures with manufacturers to prevent people from disabling Secure Boot on Windows 10 mobile. You do realize that this is no longer RT, and that this no longer applies to ARM. With intel being eager to grab a chunk of the mobile pie from ARM, we're already getting into Secure Boot and x86 lockdown, and so far I'm not seeing "people raising a huge hue and cry over it". But hey, it's just x86 mobile... Just as it was ARM mobile previously.

Or, in case you wonder if Microsoft kept up with their pre Windows 10 release plans, from their up to date own words:

All Windows 10 Mobile devices always have Secure Boot enabled.

Which is another way of saying that no Windows 10 Mobile device can disable Secure Boot. And yes, that includes a bunch of x86 based ones, that weren't manufactured by Microsoft (we have some HP and Sony ones if I'm not mistaken). A finger here, a toe there... Hmmm, I wonder where this is going?

With regards to your "blaming MS now is like crying over spilt milk", please understand that I am not solely blaming MS for their past action, but for their continuing series of actions for which there can logically only be a single endgame, if all they are being faced with is the kind of complacency both yourself and the Linux people continue to have vis a vis this matter.

Also curious, why isn't there a similar amount of outrage when it comes to ARM phones being all locked down?

If that's the argument you are trying to make, I hope you realize that having people not complaining about dictator X does not mean squat with regards to whether people should complaining about dictator Y. Oh, and I wouldn't be so sure about the level of outrage about ARM lockdown being less than RT lockdown. At least, I, along with the people of the FSF, treat these matters with equal importance. However, you do realize that, because Rufus is not dealing with ARM phone installation, but with UEFI systems, you're a lot more likely to hear me reminding people how the current Secure Boot process is bound to try to lock users down here, due to Microsoft's uncheked influence on the matter, and why it is crucial that people don't just dismiss that issue as something that's is unlikely to happen, rather than how ARM manufacturers or Apple are also locking down their devices. I'm obviously going to try to engage people on matters that I know is of direct interest to them, when I can vouch that they own hardware it applies to, rather than speculate on what other equipment they may or may not have.

Now, I wasn't going to revive this thread, but now that it's alive again, I'll put in my two cents.

One of these two things should be happening

In fact, most Linux companies, including Canonical, SuSE, and RedHat, do have their own signing keys, and do sign their own kernels with their signing keys. It's just that they haven't had much success convincing OEMs to ship their keys in OEM firmware. Wonder why ...

As for the FSF, they are definitely not adamantly opposed to Secure Boot in and of itself, only to the current implementation of it. FSF recommendations state:

Secure Boot, done right, embodies the free software view of security, because it puts users -- whether individuals, government agencies, or organizations -- in control of their machines. Our thought experiment to demonstrate this is simple: Microsoft may be worried about malware written to take over Windows machines, but we view Windows itself as malware and want to keep it away from our machines. Does Secure Boot enable us to keep Windows from booting on a machine? It does: We can remove Microsoft's key from the boot firmware, and add our own key or other keys belonging to free software developers whose software we wish to trust.

and also:

The threat is not the UEFI specification itself, but in how computer manufacturers choose to implement the boot restrictions. Depending on a manufacturer's implementation, they could lock users out of their own computers, preventing them from ever booting into or installing a free software operating system. It is essential that manufacturers get their implementation of UEFI right. To respect user freedom and truly protect user security, they must either provide users a way of disabling the boot restrictions, or provide a sure-fire way that allows the computer user to install a free software operating system of her choice.

Now let's consider my laptop and its current implementation of Secure Boot. I can, and have, removed Microsoft's signing key from the boot firmware. I can, and have, added my own signing key and Ubuntu's signing key to my boot firmware. I have, essentially, a Linux-compatible and Linux-friendly instantiation of Secure Boot. I have the private key for my own signing key and I can control what I sign. This setup satisfies everything in the FSF's list of recommendations. I see no reason, in principle, to avoid using Secure Boot under these circumstances, and neither does the FSF.

I actually agree with you, Pete, that Secure Boot is headed in the wrong direction, and that for most people it does more harm than good. I respect your choice not to support it. But I am going to keep using it for myself because it works for me. If that changes, then I'll change.

One of these two things should be happening, because nobody in the Open Source world should let a single signing entity tell what license they can and cannot use. Yet, it's been years and everybody seems to accept the situation. Especially, nobody in the Open Source community seems to take outrage to working with a company that has right of say about which license they can use.

No argument there.

As such, I think you are deluding yourself if you think that:

People rejected the locked down ARM tablet because they were locked down. They were rejected because there were Android tablets that were usually cheaper and with a larger number of apps.

Ok, so basically WoA tablets didn't sell well because Android on ARM ones were cheaper and had more apps. Besides the fact that IMO Android winning is akin to Linux winning, what stops OEMs from making cheap unlocked Linux on ARM (or x86) tablets? Do you think (serious question) that there's enough demand for something like that?

On the contrary, they are probably contemplating the long list of what they've been able to get away with so far (including FUD about the GPLv3), and are bound to consider that x86 lockdown is no big deal.

Unfortunately, wouldn't they be right ironically because of what the distros did? As I noted above, using the MS signed shim means the majority of Linux users will simply not be affected by not being able to disable SB. For them the Linux experience will remain the same. Seems we're going round in circles, because it always comes round to the Linux folks' decision, with MS pretty much doing what it always does.

Anyway, given their previous experience I feel MS and OEMs will be slightly more circumspect in the EU at least when it comes to lockdowns and restricting user choice (even if relatively few users have cause to complain). The US market though is an entirely different matter.

Oh, and guess what, Microsoft has already taken measures with manufacturers to prevent people from disabling Secure Boot on Windows 10 mobile.

Just to be clear, when I was talking about outrage against locked down mobiles I was referring to all the major ones (although right now only 2 major mobile OSes remain and WP is almost dead). Do iPhones allow Android to be installed, or vice versa? Heck, can you even get rid of OEM bloatware without rooting? We all know the answers to these questions. I guess mobile is an entirely different sort of beast where the notion of an open hardware environment is almost unknown.

Which is another way of saying that no Windows 10 Mobile device can disable Secure Boot. And yes, that includes a bunch of x86 based ones, that weren't manufactured by Microsoft (we have some HP and Sony ones if I'm not mistaken).

Not sure if Sony's still selling any WPs. HP released the Elite x3 but I don't think anyone expects it to make waves in terms of sales. So because of how monopoly-related laws seem to work MS can probably get away with stuff they otherwise couldn't if they were the market leader in mobiles as well instead of being on the verge of death. Plus, that whole point I made above about everyone doing pretty much the same thing on mobiles when it comes to locking them down.

With regards to your "blaming MS now is like crying over spilt milk", please understand that I am not solely blaming MS for their past action, but for their continuing series of actions

No-one's excusing their actions (and when possible they should be reigned in legally), but as I've been repeating they are quite predictable. Despite that if competing entities have played into their hands then whose fault is it? (Rhetorical question at this point :)

If that's the argument you are trying to make, I hope you realize that having people not complaining about dictator X does not mean squat with regards to whether people should complaining about dictator Y.

There was never any suggestion on my part that lack of outrage about locked down phones should imply lack of outrage about locked down PCs. The phone-related bit was just an aside and a mere observation. But speaking of locked down PCs, I'm curious to know your reaction to my observations about the lockdown not affecting too many Linux users precisely because of what the distros did (i.e. rely on MS).

However, you do realize that, because Rufus is not dealing with ARM phone installation, but with UEFI systems, you're a lot more likely to hear me reminding people how the current Secure Boot process is bound to try to lock users down here

Again just to be clear, when I talked about why there doesn't seem to be a similar amount of outrage when it comes to ARM phones I didn't mean specifically from you but in general. As I said above I think on mobiles people have been conditioned from the beginning of the smartphone era to accept locked down systems. (Of course there's also the fact that very few people might even want to tinker with different OSes on their phones...)

In fact, most Linux companies, including Canonical, SuSE, and RedHat, do have their own signing keys, and do sign their own kernels with their signing keys. It's just that they haven't had much success convincing OEMs to ship their keys in OEM firmware. Wonder why ...

Given they're up against MS, a piecemeal/divided approach where every distro with its own KEK tried to deal with OEMs individually was bound not to result in any great amount of success. Hardly surprising.

As for the FSF, they are definitely not adamantly opposed to Secure Boot in and of itself, only to the current implementation of it.

Their recommendations (at least the parts you quoted about no lockdowns) sound quite reasonable. Are the FSF or at least the major Linux companies part of the UEFI Forum in charge of UEFI and SB? If not then why not? Didn't they think they needed to be involved in this important decision-making process just as much as MS?

I think we're more or less on the same page here. Especially, just like the FSF, I'm not against a vetting process for running applications, as long as it is designed to guarantee that the user that own the hardware remains in full control of that process. To that extent, I see a lot of things that Secure Boot could have done better, and you seem to agree on that as well. My only problem is that, as long as there doesn't exist an entity capable of vetting and signing GPLv3 code, and that can ensure that said signed code will always run on whatever Secure Boot enforcing machine I may choose to purchase, even if manufacturers start to enforce lock down, I just can't see myself recommending anyone to use Secure Boot. Even if, for the most part, workarounds have been devised to satisfy the Linux crowd who is just happy to use a stock kernel from one of the major distros, that will work with the default keys, and, for the time being, it should be possible (at least in the PC world) for someone who wants to run their own kernel or bootloader to install their own key, I think there's just too much of a risk that SB will evolve in the wrong direction.

So let me just try to answer your questions:

What stops OEMs from making cheap unlocked Linux on ARM (or x86) tablets? Do you think (serious question) that there's enough demand for something like that?

Well, besides the official "we don't want to have to support it, so we can make more profit from having less support staff" (which is what Lenovo is trying to use in their recent AHCI/Windows-lockdown fiasco), and considering that we've seen many hints for that in the past, I would say that part of what stops OEM from making cheap unlocked Linux tablets has to be to try to avoid angering Microsoft (who have made their feelings with regards to OEMs who make Linux access a bit too mainstream, abundantly clear), and in the process lose a much needed deal on cheap Windows licenses.

The problem is that, if they are designing open hardware that can run Linux, an OEM who wants to be profitable will be bound to also provide a Windows offering for the same hardware (or at least, any of their salespeople will tell the company it would be stupid not to do so). And, since we are living in a world where Windows is the dominant OS, the Windows version is bound to be the one that sells the most units. Ergo, you wouldn't want to do anything that may jeopardize these sales, such as having Microsoft tell you something along the lines of "It's a shame that you are also providing a Linux version of this hardware, otherwise I'm sure we would be able to come to a much better deal with regards to how much we want to charge you for Windows licenses.". So it boils down to how much more profit an OEM thinks they may get by providing both Linux and Windows, with a higher Windows license cost, vs the one they can make with a Windows only offering and lower Windows license cost.

As long as Linux demand remains low enough, and an OEM requires extra support staff to satisfy 2 separate OS bases, then yeah, I don't think there's just enough Linux demand to make OEMs go in a direction where they just won't see much of a profit incentive.

Are the FSF or at least the major Linux companies part of the UEFI Forum in charge of UEFI and SB?

I don't think the FSF was ever invited to provide any insight at any of the UEFI committee decisions or meetings. And judging by how Red Hat and other companies had to scramble for a workaround after the UEFI committee introduced Secure Boot to the world, even as I am not privy with who was actually there at the time, I think the questions of whether major Linux companies have much of a say in major UEFI technical decisions pretty much answers itself...

To carry on with my pessimistic view of things, I think you may be giving a bit too much credit to how much a select group of major for profit large multinationals, are actually willing to play fair...

As long as Linux demand remains low enough, and an OEM requires extra support staff to satisfy 2 separate OS bases, then yeah, I don't think there's just enough Linux demand to make OEMs go in a direction where they just won't see much of a profit incentive.

Unfortunately this is the crux of the matter, isn't it? As long as Linux is always seen as an alternative OS that some people choose to install instead of the default Windows, it's obvious who's going to be calling the shots. Other than a few 'Developer Edition' type models being sold specifically with Linux, the rest always boil down to "Will this Windows system also be able to run Linux?"

I think there's just too much of a risk that SB will evolve in the wrong direction. To carry on with my pessimistic view of things, I think you may be giving a bit too much credit to how much a select group of major for profit large multinationals, are actually willing to play fair...

Not at all; I know how cut-throat businesses can be, especially when they're fighting to protect their turf. However sitting it out just because one thinks one cannot win is hardly useful, is it? It's not a question of waiting for an invitation to be part of the Forum, which just sounds silly. Back when the Forum was formed, if not the FSF then at least the major Linux companies (collectively, not individually) should have pushed to be involved from the get-go. They ought to have been founder members who dedicated resources and got themselves in a position where their voices could be heard and at least ensured their concerns simply couldn't be brushed aside. So, did they? I don't know. But if they really didn't even try to be a part of the process because they either didn't anticipate the potential impact or didn't want to divert resources or whatever, then it's hardly a surprise if SB evolves in a way that furthers only the agenda of certain competing entities that are in charge of it.

Edit 1: Here's a post from July 2015 stating that Canonical, Red Hat and SuSe were the only major distros who had joined the UEFI Forum (doesn't say whether they were part of it from the beginning or not, but still they were there at least), and exhorting others to join too: https://firmwaresecurity.com/2015/07/18/linux-distros-and-freebsd-join-the-uefi-forum/

Let me quote some interesting bits:

If you don’t join, you’ll be constantly reacting to UEFI Forum releases, have less resources than UEFI Member distros have, and if there’s a problem all you can do is whine and blame Intel and/or Microsoft, when you should look into the mirror instead.

The Linux Foundation should help enable community distros, which don’t have large corporations to back their membership, to get involved as well. The Free Software Foundation should join and participate, instead of keeping their heads in the sand and wish everyone would stop using UEFI. Embrace and Extend.

This tells me my reading of the situation was mostly (and depressingly) correct.

Edit 2: From https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ I quote:

Now, for ARM machines, the requirements are significantly more evil: they state exactly the opposite, that it must not be possible to disable Secure Boot and it must not be possible for the system owner to change the trusted keys. This is bad and wrong. It makes Microsoft-certified ARM systems into a closed shop. But it’s worth noting it’s no more bad or wrong than most other major ARM platforms. Apple locks down the bootloader on all iDevices, and most Android devices also ship with locked bootloaders.

If you’re planning to buy a Microsoft-certified ARM device, be aware of this, and be aware that you will not be in control of what you can boot on it. If you don’t like this, don’t buy one. But also don’t buy an iDevice, or an Android device with a locked bootloader (you can buy Android devices with unlocked or unlockable bootloaders, still, but you have to do your research).

Again, echoes what I stated above about the far worse state of affairs in the mobile world, which isn't restricted to only WPs either.

Anyway, back to the PC and the first link above only reinforces my view that the FSF and all the Linux distros should have done a lot more and presented a far more united front. They still can actually, to at least ensure that OEM implementations of SB don't evolve into complete locked down versions that deny the end user any choice whatsoever. Will they, however? Guess only time will tell.

Edit 3: Just came across this article by Matthew Garrett: Microsoft aren't forcing Lenovo to block free operating systems regarding the whole Lenovo AHCI issue you mentioned. mjg59 is not an MS fan BTW, in case you didn't know, and yet he doesn't seem to think they're involved in some nefarious conspiracy, at least in this particular case.

You're mistaking "choice" and $$$. Also, you're under the impression that the FSF has a much higher level of resources and power than it actually has.

Getting into these committees is taxing, both in term of manpower and money. With a few dozen employees, and a budget that needs to be stretched in many directions, do you really think that the FSF has the luxury to send people to the large number of technical entities, in charge of deciding the future of software and hardware users, especially if they are emerging ones, and not at all guaranteed to turn up anything impactful? I think that trying to blame the FSF, as you are doing, for the direction in which SB is evolving is like trying to blame the road safety authority for not sending one of their guys, to detect the possible future formation of potholes, every time and every place a road is being resurfaced.

You might as well blame RedHat, or Debian or Suse. After all, if Microsoft was there, and they operate in the same circles of OS development, why weren't they there to make their voice heard?

Also, as an individual who once tried to make his voice heard to the HDMI committee (I had an interest in HDMI-CEC then), and was almost laughed at for not being a contributing member, I can tell you that these entities are designed around "sufficient" upfront fees, to keep the discussion about the direction the project should take among people who are likely to share the same view... regardless of how negatively it may impact end users.

Please, as an independent person that wants to represent the user community, try to get into one of these boards that (may) decide the future of computer hardware and software, and let me know how fast you are being turned down.

Yes, that's correct. Most standards committees (with the IETF being a major exception) allocate voting power according to annual revenues. Your voting power is proportional to your annual dues, which are proportional to your annual revenues. There's basically no way the pure-play Linux companies could have influenced the standard in any meaningful way. Oracle or Google could have, maybe, but they're not pure-play Linux companies.

The correct place to act was after the standard was published. The original Secure Boot specification, as I've pointed out already, is quite favorable to Linux. It lets end users disable Secure Boot or install their own signing keys. We should have been taking advantage of this favorable sitaution to deploy critical Linux applications (e.g. servers) that depend on the existing functionality, in order to make sure that the market would demand a continuation of the status quo. Instead, by boycotting Secure Boot, we've abdicated future control of the standard to Microsoft, who is now the only company using it.

I agree.

However, I don't believe it's to the FSF to step in, as they have neither the budget, nor the relations (or the goodwill, as they and the EFF are mostly seen as an annoyance by the parties that would need convincing) to convince OEM to add a new Secure Boot certificate for which they control the signing. Also, if you establish your code signing entity, then you need to properly review code, which, again, is taxing in terms of resources. Heck, part of the reason MS went for EV (Extended Validation - typical price here) code signing certs is that, once again, it's a good way to ensure that only developers who are relatively well off can afford to get their UEFI code signed for Secure Boot.

If, on the other hand, a more Open Source friendly entity was established, it could hardly justify making the barrier of entry to Secure Boot that expensive, and therefore would likely have to review a lot more code than Microsoft currently does... IMO, Red Hat are probably the only ones who could manage the resources required for that.

I also don't see how by boycotting Secure Boot, we're playing into Microsoft's hands. The whole point is to avoid legitimizing a process that, either by design or by lucky coincidence, has become the sole control of an organization that doesn't have user's freedoms at heart.

I think that trying to blame the FSF, as you are doing, for the direction in which SB is evolving is like trying to blame the road safety authority for not sending one of their guys, to detect the possible future formation of potholes, every time and every place a road is being resurfaced.

You might as well blame RedHat, or Debian or Suse. After all, if Microsoft was there, and they operate in the same circles of OS development, why weren't they there to make their voice heard?

I do blame the distros and certainly am not placing the entire burden of blame on the FSF. As I've said above more than once, going up against MS meant the FSF and all the distros should have been presenting a united front from the very beginning. Yes, it's all easier said than done and it requires resources that any one distro or the FSF alone might not be able to come up with, which is why I've been harping on that whole "united front" thing again and again (along with end user donations which I mentioned too above). Heck, even when it comes to the MS signed shims we seem to have a fractured scenario in place, with distros each getting their different versions signed, in addition to the LF's own PreLoader that only a few distros use. If they expend energy only in internecine quarrels, how can they ever get together and fight for what's right (and which will benefit them all)?

I think that trying to blame the FSF, as you are doing, for the direction in which SB is evolving is like trying to blame the road safety authority for not sending one of their guys, to detect the possible future formation of potholes, every time and every place a road is being resurfaced.

That's just a very bad example IMO. If you're actually suggesting that the FSF had no clue at all about the implications of (locking down) SB, even as late as July 2015 (see first quote above), that just paints it in an extremely unflattering light. It's as if the road safety authority failed to send their guys even when the potholes had formed and grown into craters big enough to swallow large vehicles.

I agree with David's observation that boycotting SB is akin to behaving like an ostrich (but not at all with "The correct place to act was after the standard was published"). Let me repeat a quote from above:

The Linux Foundation should help enable community distros, which don’t have large corporations to back their membership, to get involved as well. The Free Software Foundation should join and participate, instead of keeping their heads in the sand and wish everyone would stop using UEFI. Embrace and Extend.

For something that has the potential to affect the entire community (depending on how it evolves), the FSF, LF and every single entity involved with Linux should have gotten involved ideally from the very beginning or at least as soon as was possible. Ignoring the problem and wishing it would simply go away doesn't work. Boycotting SB does not avoid legitimizing it, especially when the Linux community as a whole isn't even interested in boycotting it in the first place. (As many in the community have pointed out, SB's not inherently evil but only locking it down completely would be.)

Yes, I know that MS can out-muscle others in the Forum, but if we're being 100% honest it cannot get away with any sort of nonsense it feels like if there's a united front presented against it. Remember how the MS Certification Requirements for x86 Win8 systems explicitly stated that there should be an option allowing users to disable SB? Also as David said, "The original Secure Boot specification, as I've pointed out already, is quite favorable to Linux." It was, but guess what, that wasn't due to some sort of unexplained benevolence on MS' part. Let me quote from the second link I provided above:

These requirements aren’t present entirely out of the goodness of Microsoft’s heart, or anything – they’re present in large part because other people explained to Microsoft that if they weren’t present, it’d have a hell of a lawsuit on its hands – but they are present. Anyone who actually understands UEFI and Secure Boot cannot possibly read the requirements any other way, they are extremely clear and unambiguous. They both clearly intend to and succeed in ensuring the owner of a certified system has complete control over Secure Boot.

As you can see, this isn't the '90s any more and MS can no longer get its way 100% of the time without attracting censure from peers and almost certainly inviting legal action. IMO even while having a clear-eyed view of how committees work, simply saying that it's no use being in the Forum because MS will do what it wants anyway is just being unduly pessimistic and that sort of defeatist attitude is useless and accomplishes nothing at all. Worse, it's completely detrimental to the cause if you simply sit it out in a huff and think that is in any form or way better than at least participating and trying to make your voice heard. And let me tell you this, I am speaking from personal experience having been part of the minority view (or even the lone voice) in certain committees and struggling against almost everyone else involved, simply because I strongly believed in something I felt was right. Without significant support and backing it's of course nearly impossible to ever win, but one can, if one tries hard enough and employs the right diplomatic tactics, at least have the final decision incorporate some of one's viewpoints and suggestions. Even if that's the best one can hope for, it's still IMO a helluva lot better than not getting involved at all and thus being completely ignored.

Sorry, but I don't think the approach of "let others unite and fix this for us" will ever work. That's just hopeful thinking. You're advocating for a lot of "should" and "let's". Also, and this has been going for a while now, you are misrepresenting my position as calling for a boycott of SB, which is a straw man. Maybe I didn't express myself properly, but I can't help but wonder where you got that from when all I said was "I just can't see myself supporting Secure Boot" or "I kind of am opposed to the use of Secure Boot altogether", and advised people to disable it to boot UEFI:NTFS.

If I was calling for a boycott of SB, I'd certainly not be telling Rufus users that they can re-enable it after their done with UEFI:NTFS and other stuff. So thanks for trying to bring me down... on a position that I have never taken. In case this hasn't gotten through, my position is a lot closer to the official one of the FSF, though experience tells me that, unless there is decisive action from users (rather than others that should "just" do something together about it), Microsoft will continue to get its way, and some more.

If you're actually suggesting that the FSF had no clue at all about the implications of (locking down) SB, even as late as July 2015

I'm not. That's another complete straw man.

Again, to try to cut this short, my beef (along with a sprinkle of "this could have been implemented A LOT better") is almost entirely with Microsoft having managed to get away with preventing GPLv3 code from booting SB enabled computers, which is 100% UNACCEPTABLE. This is the part where, if I were to join your position, I would say everybody should unite and bring some pitchforks to Microsoft's headquarters.

Yet, every time I bring it up, people seem to skirt around that authoritarian rule, like it's no big deal, and try to bring the debate into a completely different direction.

Sorry but what Microsoft did in that instance is unacceptable, and, as long as people don't seem to recognise this as the most worrying fact of this whole SB discussion, it simply serves to corroborate my conclusion that, if it wanted to, Microsoft could probably get away with restricting users freedom as much as it wants. I'm still waiting for the "censure" or "legal action" on that no GPLv3 rule... and have been waiting for YEARS now.

Sorry, but I don't think the approach of "let others unite and fix this for us" will ever work.

I don't understand what you mean. Who are these "others" you're talking of? I specifically said that the effort should involve the Linux community as a whole, and even mentioned soliciting contributions from end users if required.

Matter of fact, the Linux folk depending on others (= MS) is exactly what has caused this issue in the first place.

I kind of am opposed to the use of Secure Boot altogether, first, because Microsoft is clearly using it as a way to shut down GPLv3 software and restrict what people should have the freedom to do, and second, because the whole Secure Boot feature has recently become kind of pointless, since it's been demonstrated that anybody can break it through the use of old Microsoft Windows EFI bootloaders.

By stating you consider SB pointless and are opposed to it I thought you wanted to boycott it altogether. If that wasn't your position and you're fine with having SB present on all new systems as long as users can just disable it, then I apologize for getting things mixed up. Still doesn't change my stance though that the Linux community, FSF etc. should be much more (forcefully) involved in the process when it comes to defining SB's future.

Again, to try to cut this short, my beef (along with a sprinkle of "this could have been implemented A LOT better") is almost entirely with Microsoft having managed to get away with preventing GPLv3 code from booting SB enabled computers, which is 100% UNACCEPTABLE. This is the part where, if I were to join your position, I would say everybody should unite and bring some pitchforks to Microsoft's headquarters.

My position on this is actually that while MS' actions regarding GPLv3 are indeed 100% unacceptable (but not illegal), giving them that power to decide is even more unacceptable and should obviously never have been done in the first place. Saying "Oh there was nothing else the Linux folk could have done and the only solution was to depend on MS" is not acceptable.

This doesn't mean I'm skirting the unacceptability issue or the obvious authoritarian aspect, but I again circle back to my allegory about the sheep delivering themselves to the wolf and then crying about it. MS being MS and doing nothing that's new or surprising, why the heck was it allowed to get into such a position of power in the first place by the Linux community? That is the core issue that needs to be addressed, and complaining that the wolf is exhibiting its well-known nature is indeed useless and only serves to conveniently skirt around the culpability of the sheep for placing themselves in such an obviously vulnerable position.

P.S. I agree with you - I think we should indeed cut this ~~short~~ off here.

Fine with me. I think we probably said all we wanted to say, and anything else would be more or the same.

pbatard / rufus

NTFS + UEFI boot with Win8.1PE #507