384 replies to this topic

[misty]

@Wonko
mkisofs version is from schily-cdrtools-3.02a07.7z (download link is in cdob's post #288).

mkisofs.exe executable information as reported by 7-zip

---------------------------
Checksum information
---------------------------
Name: mkisofs.exe
Size: 386560 bytes (0 MB)

SHA1: 1FB596291496BA1014933C11961C274F2794527C

Using cdob's command syntax from post #288 but ommiting the -hide "*" switch to create an .iso capable of booting on UEFI and BIOS firmware appears to work

The same .iso booted fine in VMWare Workstation 12 on both UEFI and BIOS firmware types.

Regards

Misty

P.s. the following command was used -

mkisofs.exe -iso-level 3 -D -udf -hide-udf boot.catalog -no-emul-boot -b boot/etfsboot.com -eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys.bin -no-emul-boot -o "%ISODir%\WinPE.iso" "%OutputDir%"

[Wonko the Sane]

Hmmm.

 

Strange.

 

cdob is usually exceptionally accurate when providing command examples, and it doesn't look like a typo.

 

Maybe some differences between the 64 bit version and the 32 bit one? Of either the mkisofs or of the running OS...

 

Wonko 

[misty]

...Maybe some differences between the 64 bit version and the 32 bit one? Of either the mkisofs or of the running OS...

Running OS is 64-bit Windows 8.1 (Update)

mkisofs version from schily-cdrtools-3.02a07.7z is a 32-bit only release.

Misty

[Wonko the Sane]

Running OS is 64-bit Windows 8.1 (Update)

mkisofs version from schily-cdrtools-3.02a07.7z is a 32-bit only release.

Misty

Well, no, there is a schily-cdrtools-3.02a07.7z\win64 (testing)\ version, that's why I asked, possibly the "testing" has still some issues to be ironed out. :dubbio.

 

Wonko

[Blackcrack]

Well, in this case should you contact Joerg in his private@mail
maybe would it well, if Joerg give this tools under gpl2 and on Github
to have the possible for other to help and resolve issues (maybe read this Joerg)
also is this really well if this under gpl2 to be compatible with Ros
so, this is his Personally HP cdrtools.sourceforge.net/private on http

best regards
Blacky

[cdob]

Both attempts completed when the -hide "*" switch was removed. Any thoughts or suggestions?

Sorry, it's getting confusing

It's about diffferent file systems: ISO9660, Joliet, Rock Rigde and UDF
There are several requirements at a multiboot DVD.
We don't create a multiboot DVD currently.

The OS manufacturer uses UDF at a Vista DVD and up.
In addition there is a second ISO-9660 file system with one single file: readme.txt
Example: there is a file UDF \boot\bcd, but no ISO-9660 \boot\bcd
We may use this approach too or ignore it.

-hide is about ISO-9660 file system, the UDF names exists still.
'-hide "*"' works at XP 32 bit. And fails at Win 8.1 64 bit mingw.
Works at Win 8.1 64 bit cygwin. I've no explanation.

Work arround, use a hide file list

echo *>hide_list.txt
mkisofs -iso-level 3 -D -udf -hide-list hide_list.txt

But this addional file may cause trouble, e.g. is not found.

I suggest: if ISO9660 names are added, then respect NT4.
Thereafter Vista etfsboot.com and bootmgr and up should work too.
The Vista etfsboot.com reads UDF file system, if there is one.
Nice NT4 ISO9660 names are not required, but are nice to have as a reference.

-udf -iso-level 3 -N -D -d -relaxed-filenames

-iso-level 3 adds large file support too. Just in case, if someone adds a image file.

https://en.wikipedia.org/wiki/Inode
Technically: there are no inode suppport at the mingw version.
It's about reading files from the hard disk.
The cygwin version support hard link and inodes, hard linked files are added once to the ISO image.
As for a PE, most likely there are no hard links used.
Ignore the inode warning.

[Wonko the Sane]

Still, WHY there is any *need* to "hide" anything?

 

As said just an exercise in futility to have the same appearance of the OSCDIMG created one?

 

THen we will also need to add the README.TXT.

 

The "original" documented OSCDIMG command:

https://support.micr...ndows-pe-cd-rom

 

seems to be creating "only" a UDF filesystem.

 

And *somehow*  they add the readme.txt:

 

 

This disc contains a "UDF" file system and requires an operating system
that supports the ISO-13346 "UDF" filesystem specification.

to the ISO9660 fiesystem (which is the reason why on older OS's you can only see the readme.txt), most probably it is some form of "default" behaviour dating back to times when the UDF was not understood by systems, that probably made a lot of sense in Vista times, but nowadays is most probably unneeded.

 

The above test (and the README.TXT filename) is "embedded" in the OSCDIMG.EXE, followed by what probably is an "alternate" README.TXT:

 

 

This disc contains Unicode file names and requires an operating system
that supports the ISO-9660 "Joliet" CD-ROM file system specification
such as Microsoft Windows 95 or Microsoft Windows NT 4.0.

 

I don't really see a reason why this approach needs to be perpetuated, maybe the resulting .iso will be a few Kb smaller , but I fail to see the point.

 

As I see it (but I may well be wrong), if no file is hidden BUT the stupid .iso created boots, both BIOS and UEFI, what is the problem?

 

Even the command used by erwan.l (with the unnecessary "wider" iso-level 4 and the gratuitious Rockridge filesystem) works fine, reportedly.

 

This said, to recap:

1) the 32 bit works at XP 32 bit.

2) And fails at Win 8.1 64 bit mingw.

Maybe the issue lies with the Win 8.1 WOW64?

Or the (testing) 64 bit version behaves the same?

 

The report from Misty says that using the "hide "*" the iso file is not created, so it seemingly creates an error, not a warning (that could be ignored).

 

Wonko

[misty]

@cdob
I'm still digesting the information - thank you for the detailed explanation and education
 

...The OS manufacturer uses UDF at a Vista DVD and up.
In addition there is a second ISO-9660 file system with one single file: readme.txt
Example: there is a file UDF \boot\bcd, but no ISO-9660 \boot\bcd
We may use this approach too or ignore it....

I'm in favour of ignoring this approach due to the reported issues with mkisofs.exe functioning differently dependent upon the OS environment it's running on. Trying to replicate oscdimg.exe behaviour using mkisofs would make coding MistyPE unnecessarily difficult. As omiting the -hide "*" switch does not appear to cause any complications this would appear to be the best approach.

@Wonko

Still, WHY there is any *need* to "hide" anything? ....

....I don't really see a reason why this approach needs to be perpetuated, maybe the resulting .iso will be a few Kb smaller , but I fail to see the point.

As I see it (but I may well be wrong), if no file is hidden BUT the stupid .iso created boots, both BIOS and UEFI, what is the problem? ....

No need to hide anything. To be fair to cdob, he appears to be responding my question in post #293 and suggesting what needs to be done to fully replicate oscdimg behaviour -

....Anyone able to help with the mkisofs equivalent of the following oscdimg.exe command (to create a UEFI bootable .iso)

oscdimg.exe -l"WinPE" -pEF -u2 -udfver102 -b"D:\efisys.bin" "%OutputDir%" "%ISODir%\WinPE.iso"

...

I'm therefore to blame for such a badly worded question. I should have perhaps more specifically asked how to use mkisofs to create a UEFI bootable disc image.
 

The report from Misty says that using the "hide "*" the iso file is not created, so it seemingly creates an error, not a warning (that could be ignored).

Correct - no .iso created on host OS Windows 8.1 Update (64-bit).

Misty

[Wonko the Sane]

Correct - no .iso created on host OS Windows 8.1 Update (64-bit).

 

Yep, I had to check of course, and on XP (32-bit) the "hide "*"" provokes a Warning but the .iso is created just fine (and the file(s) are actually hidden in the ISO directory of the image).

 

Anyway, the "right" way is to create a single image that can both BIOS and UEFI boot, comparable to the one created with the reference OSCDIMG command:

https://support.micr...ndows-pe-cd-rom

 

The mkisofs command line erwan.l suggested/used is for some parts either "unneeded" or "irrelevant".

The -R is adding a RockRidge directory structure that won't be used/accessed by *anything* unless - it has to be checked - by grub4dos, earlier version at least needed it, and - still to be fair - it should be -r (as though the mkisofs -help talks of "rational RockRidge", actually that means on Linux/Unix system having "sane" permissions on the file):

 

 

-R
Generate SUSP and RR records using the Rock Ridge protocol to further describe the files on the iso9660 filesystem.
-r
This is like the -R option, but file ownership and modes are set to more useful values. The uid and gid are set to zero, because they are usually only useful on the author's system, and not useful to the client. All the file read bits are set true, so that files and directories are globally readable on the client. If any execute bit is set for a file, set all of the execute bits, so that executables are globally executable on the client. If any search bit is set for a directory, set all of the search bits, so that directories are globally searchable on the client. All write bits are cleared, because the CD-Rom will be mounted read-only in any case. If any of the special mode bits are set, clear them, because file locks are not useful on a read-only file system, and set-id bits are not desirable for uid 0 or gid 0. When used on Win32, the execute bit is set on all files. This is a result of the lack of file permissions on Win32 and the Cygwin POSIX emulation layer. See also -uid -gid, -dir-mode, -file-mode and -new-dir-mode.

 

The -iso-level is (highly) debatable, I concur with cdob that -iso-level 3 is (more than) enough for the way the WinPE's are now built (with a .wim) unless stupidly long filenames and multi-nested  paths are used:

 

 

-iso-level level
Set the iso9660 conformance level. Valid numbers are 1..3 and 4.

With level 1, files may only consist of one section and filenames are restricted to 8.3 characters.

With level 2, files may only consist of one section.

With level 3, no restrictions (other than ISO-9660:1988) do apply.

With all iso9660 levels from 1..3, all filenames are restricted to upper case letters, numbers and the underscore (_). The maximum filename length is restricted to 31 characters, the directory nesting level is restricted to 8 and the maximum path length is limited to 255 characters.

Level 4 officially does not exists but mkisofs maps it to ISO-9660:1999 which is ISO-9660 version 2.

With level 4, an enhanced volume descriptor with version number and file structure version number set to 2 is emitted. There may be more than 8 levels of directory nesting, there is no need for a file to contain a dot and the dot has no more special meaning, file names do not have version numbers, the maximum length for files and directory is raised to 207. If Rock Ridge is used, the maximum ISO-9660 name length is reduced to 197.

When creating Version 2 images, mkisofs emits an enhanced volume descriptor which looks similar to a primary volume descriptor but is slightly different. Be careful not to use broken software to make ISO-9660 images bootable by assuming a second PVD copy and patching this putative PVD copy into an El Torito VD.

 

For the same reasons, the -d and -D should NOT be *needed* for a WinPE:

 

 

-d
Omit trailing period from files that do not have a period.
This violates the ISO9660 standard, but it happens to work on many systems. Use with caution.
-D
Do not use deep directory relocation, and instead just pack them in the way we see them.
If ISO9660:1999 has not been selected, this violates the ISO9660 standard, but it happens to work on many systems. Use with caution.

and the end of the day they are just "cosmetics".

 

I.e., this:

 

mkisofs.exe -iso-level 3  -udf -hide-udf boot.catalog -no-emul-boot -b boot/etfsboot.com -eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys.bin -no-emul-boot -o "%ISODir%\WinPE.iso" "%OutputDir%"

should work just fine.

 

Adding a -volid "WINPE" or -volid "MistyPE" would be equivalent to add to the OSCDIMG a -lWINPE or -lMistyPE, a possibly useful "enhancement".

 

Now a good  question, for  - given the scarcity of those systems - academic purposes only (another exercise in futility):

We (but seemingly MS also) are assuming that a BIOS system can be either 32 bit or 64 bit, while the UEFI is 64 bit only.

This is not entirely accurate as there are (very few I believe) 32 bit UEFI systems (inside the efisys.bin of x86 install discs there is BOOTIA32.EFI).

So, it seems like not possible to have a UEFI bootable DVD that can boot both x86 and 64 bit OS's?

 

Wonko

[misty]

@Wonko
Most education and helpful - as ever.
 

...Anyway, the "right" way is to create a single image that can both BIOS and UEFI boot, comparable to the one created with the reference OSCDIMG command:
https://support.micr...ndows-pe-cd-rom...

I agree. And thanks to the advice from you, erwan.l and cdob, this will be the default setting in the next release of MistyPE.

 

...The -iso-level is (highly) debatable, I concur with cdob that -iso-level 3 is (more than) enough for the way the WinPE's are now built (with a .wim) unless stupidly long filenames and multi-nested paths are used...

Or unless a Flat Boot WinPE is required. A supported feature in MistyPE if Windows 7 (and Vista, and probably Windows 2008) source files are used. Flat boot from a CD/DVD does not appear to be supported in Windows 8 and newer based WinPE.
 

...This is not entirely accurate as there are (very few I believe) 32 bit UEFI systems....

The Lenovo 100s is such a system. And my daughter has one (see my mini-review here). I'm not offering to experiment with it as she would be most upset if anything happened to it. Actually she'd be upset by me going anywhere near it!!!!

Misty

[misty]

The following post is not that relevant, it's just an observation.

Just created an .iso file using mkisofs.exe. This is a Flat Boot WinPE bootable on BIOS and UEFI systems. The command used the following syntax -

mkisofs.exe -iso-level 4 -D -udf -hide-udf boot.catalog -no-emul-boot -volid "WINPE" -b boot/etfsboot.com -eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys_noprompt.bin -no-emul-boot -o "PATH\WinPE.iso" "PATH"

Created a similar image using oscdimg.exe with command with following syntax -

oscdimg.exe -l"WinPE" -m -o -u2 -udfver102 -bootdata:2#p0,e,b"PATH\etfsboot.com"#pEF,e,b"PATH\efi\microsoft\boot\efisys_noprompt.bin" "PATH" "PATH\WinPE.iso"

Both .iso are booting fine in VMWare Workstation 12 - on both UEFI and BIOS VMs.

oscdimg.exe created .iso is 505MB
mkisofs.exe created .iso is 1.08GB

Note the significant size difference.

Interestingly when using oscdimg.exe to create BIOS only and UEFI only .iso files (using the MS reference commands), the file size is over 1GB and is similar to the mkisofs.exe created file.

Misty

P.s. I hope I remembered to convert the code from winbuilder code correctly!

[cdob]

Back to basics, I made some booting tests, Vista, Windows 7, Windows 10:

http://mistyprojects...iles/issues.htm
The oldest sources are listed: WinPE 2.0 - 6.0.6000 sources (Vista)

The previous beta Longhorn uses bootmgr and boot.ini, there are UDF and uppercase ISO 9660 names.
This is a special case, luckily this version is not supported and to be ignored here.

Vista beta2 5384 and later: etfsboot.com and bootmgr prefers UDF, ISO 9660 are ignored
We are free to include ISO 9660 file names or not. With current mingw mkisofs it's simpler to include the ISO 9660 file names.
No average end user will detect a ISO 9660 file name, a OS matching MistyPE (Vista and up) shows the UDF name.

The OS manufacturer uses short names at DVD.
However MistyPE adds programs too. The programs may use long names, now or in future.
BartPE and MistyPE used -iso-level 4 in the past. This worked.
The question is now: try a new aproach or keep the settings?
 

mkisofs.exe -iso-level 4 -udf -duplicates-once  -hide boot.catalog -hide-udf boot.catalog -no-emul-boot -b boot/etfsboot.com -eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys.bin -no-emul-boot -o "%ISODir%\WinPE.iso" "%OutputDir%"

.
https://support.micr...ndows-pe-cd-rom

o Optimizes storage by encoding duplicate files only one time.
Use -duplicates-once instead. There are some duplicate fonts files at RAM load too.

pEF,e,bc:\winpe_x64\efisys.bin
e Specifies the floppy disk emulation in the El Torito catalog.

Does this asks for floppy disk emulation at EFI?
UEFI Specification, 13.3.2.1 ISO-9660 and El Torito, requests no emulation.
http://www.uefi.org/specifications

To boot from a CD-ROM or DVD-ROM in the boot services
environment, an EFI System partition is stored in a “no emulation” mode as defined by
the “El Torito” specification. A Platform ID of 0xEF indicates an EFI System Partition.

So, it seems like not possible to have a UEFI bootable DVD that can boot both x86 and 64 bit OS's?

Put both x86 and amd64 efi files inside the floppy image.
http://reboot.pro/to...em/#entry192606

Or get creativ:
UEFI Specification names ISO-9660: does a real world UEFI reads ISO-9660?
Violate UEFI Specification, do not create “El Torito” boot.
Put both x86 and amd64 efi files inside ISO-9660 file system.
Does real world UEFI boot such a DVD?

[Wonko the Sane]

OK  , -iso-level 4 seems fine (and doesn't have IMHO any particular side effect)    . 
 
 

pEF,e,bc:\winpe_x64\efisys.bin
e Specifies the floppy disk emulation in the El Torito catalog.

Does this asks for floppy disk emulation at EFI?

 
The -eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys.bin -no-emul-boot is what takes care of the emulation type in the mkisofs command line, it seems fine, and the output is seemingly the same as OSCDIMG, it is probably (as often happens) a mis-documentation of the feature on the MS page, the output of OSCDIMG -help -boot:

OSCDIMG 2.56 CD-ROM and DVD-ROM Premastering Utility
Copyright © Microsoft, 1993-2012. All rights reserved.
Licensed only for producing Microsoft authorized content.


Usage: OSCDIMG [options] sourceroot targetfile

Boot options: These options can be used to create bootable CD/DVD images

The following options may only be used for single boot entry images and may
not be combined with any multi-boot entry switches.

-b This option is used to specify the file that will be written in the
boot sector(s) of the disk. Example: -bc:\location\cdboot.bin
-p This option specifies the value to use for the Platform ID in the
El Torito catalog. The default is 0x00 to represent the x86
platform.
-e This option means not to use floppy disk emulation in the El Torito
catalog.

The following options may be used to generate multi boot entry images and may
not be combined with any single boot entry switches.

Each multi-boot entry is seperated via a # token, as well as the number of
boot entries. The options for a boot entry are seperated via a comma token.
Each boot option must specify the boot code for that option.

-bootdata:<num>#defaultbootentry#bootentry2#bootentryN

BootEntryOptions:
b This option is used to specify the file that will be written in the
boot sector(s) of the disk. Example: -bc:\location\cdboot.bin
p This option specifies the value to use for the Platform ID in the
El Torito catalog. The default is 0x00 to represent the x86
platform. 0xEF represents an EFI-based system
e This option means not to use floppy disk emulation in the El Torito
catalog.

t Specifies the El Torito load segment. If not specified, defaults to

0x7C0

Example:
-bootdata:2#p0,bc:\location\etfsboot.com#pEF,bc:\location\ESPBootFile
This specifies a multi-boot image with the default image having an x86 boot
sector that launches the ETFSBOOT.com bootcode, and a secondary EFI boot
image that launches ESPBootFile when booted

 
 
A quick check with IsoBuster of the two created .iso's (one with OSCDIMG and one wth MKISOFS) doesn't show any difference re: booting emulation, so seemingly the tool help is right and the doc page is misleading:

• e
  Specifies the floppy disk emulation in the El Torito catalog.

should have been written as:

 

• e 
  Specifies the floppy disk emulation in the El Torito catalog, setting it as no-emulation

 

 
D@mn  , I am clearly getting older (and forgetful), I completely forgot   about:

Put both x86 and amd64 efi files inside the floppy image.
http://reboot.pro/to...em/#entry192606

Thanks for reminding me about that one .

@Misty
Please try the "final version" with -duplicates-once as suggested by cdob:
 

mkisofs.exe -iso-level 4 -udf -duplicates-once -hide boot.catalog -hide-udf boot.catalog -no-emul-boot -b boot/etfsboot.com -eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys.bin -no-emul-boot -o "%ISODir%\WinPE.iso" "%OutputDir%"

there shouldn't be anymore the huge size difference you experienced.
 

-l"WinPE"

according to OSCDIMG help there is no need for the double quotes, are you sure they are *needed* (or maybe the label actually included the quotes?)
 

Wonko

[misty]

@cdob
Thank you for taking the time out to do some tests/checks with the older supported source files - this is greatly appreciated.

In regards to the example command that you posted -

mkisofs.exe -iso-level 4 -udf -duplicates-once  -hide boot.catalog -hide-udf boot.catalog -no-emul-boot -b boot/etfsboot.com -eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys.bin -no-emul-boot -o "%ISODir%\WinPE.iso" "%OutputDir%"

I notice the use of both the following switches -
-hide boot.catalog
-hide-udf boot.catalog
-no-emul-boot (twice)

Is there any advantage/disadvantage in using the -hide boot.catalog in addition to -hide-udf boot.catalog?

I'm assuming that the second use of -no-emul-boot is not required?
 

...The OS manufacturer uses short names at DVD.
However MistyPE adds programs too. The programs may use long names, now or in future.
BartPE and MistyPE used -iso-level 4 in the past. This worked....

I'd not considered the potential difficulty with added programs using long names. I decided on the need to use -iso-level 4 yesterday in order to support FlatBoot WinPE variants.
 

o Optimizes storage by encoding duplicate files only one time.
Use -duplicates-once instead. There are some duplicate fonts files at RAM load too.

Added -duplicates-once switch to my recent tests.

I can't remember where I copied the oscdimg reference commands from - probably the WAIK for Windows 7 instructions. I don't remember editing the reference commands at all when I added them to MistyPE, other than to change paths and convert to winbuilder syntax. Interesting that the MS reference commands (assuming that I did not inadvertantly edit them years ago) only included the -o switch on the BIOS and UEFI bootable image and not the BIOS only or UEFI only images.

@Wonko

-l"WinPE"

according to OSCDIMG help there is no need for the double quotes, are you sure they are *needed* (or maybe the label actually included the quotes?)

Correct. There is no need. This is a relic from some old code I previously used (predating MistyPE) when I used to have a space in the label!
 

@Misty
Please try the "final version" with -duplicates-once as suggested by cdob:

Done. Works great. Testing an updated script with some added featuritis. I plan to introduce an option for mkisofs or oscdimg, with an additional option to either use -o\-duplicates-once or not. Default option if everything works is to use mkisofs to create a BIOS and UEFI bootable RAM loading WinPE without the -duplicates-once switch in order to save time. End users can then choose to save space by adding the -duplicates-once switch as required.

Misty

[misty]

Test build released. Please use the Tools > Update Project script to download.

Changes/updates -

• mkisofs.exe updated to version included in schily-cdrtools-3.02a07.7z
• Core > Core.script (updated to support PEBakery and an additional minor edit made to ensure that efi folder uses lowercase name)
• Core > verify.script (updated to support PEBakery)
• Boot.Media > create.ISO.script

Feedback welcome re new create.ISO.script - I'm still testing it myself so there may be some bugs.

A massive thanks to both cdob and Wonko for their help with mkisofs.exe commands and suggestions.



Misty

______________________________________

Edit

P.s. I've NOT included the -hide boot.catalog switch suggested by cdob - but can easily add this back in if it's required and/or someone can explain why it should be included.

Default mkisofs.exe command used in the project (converted from winbuilder code) -

mkisofs.exe -iso-level 4 -udf -hide-udf boot.catalog -no-emul-boot -volid "WINPE" -b boot/etfsboot.com -eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys.bin -no-emul-boot -o "%ISODir%\WinPE.iso" "%ISO.Root.Directory%"

Just realised that I've inadvertently included the -no-emul-boot switch twice!

With a simple change of project settings the -duplicates-once switch can be used (Boot.Media > Create ISO script - Advanced tab > set option 5] Optimise to YES).

[misty]

Brief note on testing the updated Create ISO script. There are a ridiculous number of variations possible for some sources, so I've done a few random tests to reduce the risk of coding and testing induced insanity!

For example, Windows 7 SP1 64-bit source files support FlatBoot from CD and are both BIOS and UEFI bootable. With the new project settings that's potentially 3 x 2 x 3 x 2 x 3 combinations - that's 108 combinations!

And how I arrived at these figures. In the Create ISO script there are 5 seperate options hidden in the Advanced tab. Option 1 has three options (RAM or FlatBoot or BOTH), Option 2 has two options (YES or NO), Option 3 has three options (BIOS or UEFI or BOTH), Option 4 has two options (mkisofs or oscdimg) and Options 5 has two options (YES or NO).

Windows 8 and newer do not support FlatBoot from CD/DVD, so there are fewer supported options for these sources. Windows 7 (SP1) and older 32-bit sources do not support UEFI boot, so there are fewer options for these sources.

However the project has been coded to use fallbacks if someone tries to use a none supported options with a particular source - so that's still 108 options for each source.

And there are god only know how many source files available if you include different language builds.

You get the idea.



Misty

[Wonko the Sane]

@Misty

 

Is there a "real", "very noticeable" time difference in using the -o in OSCDIMG (or using the -duplicates-once in MKISOFS)?

 

The difference in size you reported seems "just too much" to think of not using it, in case it should IMHO be rather an "opt out" choice, i.e. user may optionally remove the -o or -duplicates-once.

 

The "-no-emul-boot" is required twice because you are making a "dual filesystem" (and of course you want to hiide BOTH boot.catalog's) AND "dual boot mechanism" .iso:

-hide boot.catalog <- this is hiding the boot.catalog on the "first" filesystem, CDFS

-no-emul-boot -b boot/etfsboot.com  <- this is the boot file and setting (no emulation) for the first boot mechanism (el-torito)

-udf -hide-udf boot.catalog <- this is hiding the boot.catalog on the "second" filesystem UDF

-eltorito-alt-boot -eltorito-platform efi -b efi/microsoft/boot/efisys.bin -no-emul-boot <- this is the boot file and setting (no emulation) for the second boot mechanism (alternate el-torito)

 

Get the (trial version is enough) Isobuster and use it to "explore" the created .iso's with and without the said options:

https://www.isobuster.com/

and you will be able to visualize the existence (and visibility) of the various elements.

 

 

And now, even if it is I believe meaningless for non-flat boot media, let us mention the pe_sort.txt approach (that on "flat" setups can shave off some seconds even from USB devices):

http://reboot.pro/to...-for-pe-builds/

https://web.archive....&st=40&start=40

 

Wonko

[misty]

@Wonko
Thanks for the information. I will include the use of the -hide boot.catalog command.

I'll also be sure to check out Isobuster over the weekend.
 

...Is there a "real", "very noticeable" time difference in using the -o in OSCDIMG (or using the -duplicates-once in MKISOFS)?

Subjectively it felt like a very noticable time difference so I did a quick test with a combined Flat Boot and RAM Boot image.

mkisofs.exe with -duplictes-once switch -

• build time = 59.13 seconds
• iso size = 679 MiB

mkisofs.exe without -duplictes-once switch -

• build time = 12.25 seconds
• iso size = 1.25 GiB

I haven't retested using oscdimg, however this also subjectively felt like a noticable time difference during previous tests.
 

...The difference in size you reported seems "just too much" to think of not using it, in case it should IMHO be rather an "opt out" choice, i.e. user may optionally remove the -o or -duplicates-once....

This matter is definitely up for debate. I'm personally happy to wait an extra 47ish seconds. Anyone else have any thoughts on this?
 

...And now, even if it is I believe meaningless for non-flat boot media, let us mention the pe_sort.txt approach (that on "flat" setups can shave off some seconds even from USB devices):
http://reboot.pro/to...-for-pe-builds/
https://web.archive....&st=40&start=40...

Looks interesting. But way too complicated for me to get my head around and potentially code at the moment.

Misty

[Atari800XL]

Thank you very much for the new PEBakery modifications!

I believe a tiny syntax error has appeared in the new Boot.Media\create.ISO.script, Winbuilder ignores this, but PEBakery notices it:

line 199:

Set,%pScrollBox2%,Equal,Yes

Looks like you copied this line from an "if" line, I think it should read:

Set,%pScrollBox2%,Yes

(remove the "Equal,")

 

Also, PEBakery has deprecated "System,HasUAC" (Core.script), this doesn't produce an error though, I'm not sure how important this is, or why it is used.

[misty]

Thank you very much for the new PEBakery modifications!

I'm still looking forward to testing PEBakery when I get the chance.

I believe a tiny syntax error has appeared in the new Boot.Media\create.ISO.script, Winbuilder ignores this, but PEBakery notices it:
line 199:
Set,%pScrollBox2%,Equal,Yes...

Good find. And the exact same error was repeated on line 226. Both fixed.
 

Also, PEBakery has deprecated "System,HasUAC" (Core.script), this doesn't produce an error though, I'm not sure how important this is, or why it is used.

I can't actually recall why I added it. It currently only produces a warning message anyway, and as it doesn't appear to cause any issues with PEBakery then I'll leave it in for now.

Slightly updated test build released. Please use the Tools > Update Project script to download.

• -hide boot.catalog switch added to Boot.Media > Create ISO script
• Fixed error spotted by Atari800XL

Misty

[Wonko the Sane]

Also, PEBakery has deprecated "System,HasUAC" (Core.script), this doesn't produce an error though, I'm not sure how important this is, or why it is used.

Not really.

 

http://www.msfn.org/...comment=1148116

 

the Author of the (at the moment in development/experimental PEbakery) has chosen to temporarily set the result to "True".

 

As a matter of fact at this stage Pebakery CANNOT deprecate *anything* the goal is to have a number of selected projects (including MistyPE) to build successfully WITHOUT changing *anything* in the scripts already developed in Winbuilder syntax.

 

The very first change - even minor or trivial - made to the source .script to run with PEbakery would undermine the goal of a (much faster) builder 100% compatible with Winbuilder.

 

So, any change in projects/script made to have a successful build with PEbakery should be temporary and the resposability of the tester, then the issue found should be reported to joveler so that he can use the report to increase the compatibility, the Author of the .script or project should never modify anything for compatibility with PEbakery.

 

Wonko

[Atari800XL]

The term "deprecated" was from the build log, not made up by me. It's not important for now. I will certainly not discuss this at length, when there are much more important thing to focus on.

I am in constant contact with Joveler, I think he has done an amazing job so far.

Changes to existing scripts have mainly been tiny syntax errors, he could have opted for supporting/ ignoring these as well, but that's where he draws the line :-)

 

If you get the chance to test it, Misty, please tell us what you think.

[Wonko the Sane]

I am in constant contact with Joveler, I think he has done an amazing job so far.

Surely he has  .

 

Wonko

[misty]

Project scripts updated. This is a test build. Please use the Tools > Update Project script to download.

In addition to the updates already listed in posts #315 and #320, the following changes have been made -

Merged some updates that I'd forgotten to add to MistyPE when Mini-WinFE 2017-04-27 was developed and released.

LaunchBar settings moved from shell script to Core > LaunchBar

Updates to the user interface in the following scripts -

• Programs > aida64
• Programs > Ammyy Admin
• Programs > defraggler
• Programs > DriveImageXML
• Programs > Ghost
• Programs > LinuxReader
• Programs > Partition Guru
• Programs > PTEdit
• Programs > Recuva
• Programs > Drive Snapshot
• Programs > WinHex
• Programs > WoFADK
• WinFE > FTK Imager Lite
• WinFE > X-Ways Forensic

Main change in these scripts is a tabbed style interface. Programs can now be added to the cache using the ADD TO CACHE buttons in the scripts without running the full project. Example from the aida64 script can be seen in the screenshot below -



SysWOW64 support for Windows build 1703 (10.0.15063) and 1709 (10.0.16299) also added - SysWOW64 should now work in these builds if the source files are obtained from a local OS.

If I'm honest this has not been anywhere near as thoroughly tested as usual as my head is hurting from coding. Feel free to have a play and feedback whilst I continue to work on the project.

Fingers crossed nothing was broken in the updates.



Misty

[alacran]

Just made a Win10x64 build using es_windows_10_multi-edition_version_1709_updated_nov_2017_x64_dvd_100289996.iso, so far this are my findings:

 

Log report warnings:

 

1- (AmmyyAdmin.script) aida64 is missing - exiting script...
2- (WinHex.script) WinHex is missing - exiting script...

 

1- Yes I forgot to select the path, but log said aida64 is missing should say AmmyyAdmin is missing

 

2 - I added to MistyPE\Projects\Cache\Programs\WinHex (copy-paste) the old version I have since last time I made a good build, and project builder said someting like there is not x64 version on folder Do you want to use x86 version? but you need sysWoW64 (wich was enabled) I acepted and anyway script failed.   Then I went to http://www.winhex.co...hex-editor.htmland didn't find any x64 version on it, so someting is wrong with this script.

 

Also found a Typo on Boot.Media-Create Iso-Optimise-Help: It should say: At the end of first paragraph "if mkisoft.exe is used".    And at the end of last paraghaph  "if storage optimization is used"

 

I'm going to put AmmyyAdmin in place and put WinHex (new version just downloaded) in x86 folder, make a new build and boot the ISO, after this report back.

 

alacrang