[Mexxi]

I'm trying to multiboot a disc with XP and Win7 on it. I realized that whenever I used UDF (plus Joliet and ISO9660) XP would error out with "NTDETECT Failed", but Windows 7 worked. If I leave out UDF and only use Joliet and ISO9660 then XP boots, but Windows 7 complains about not being able to find winload.exe when loading setup. I'm using the latest win32 compile of mkisofs (cdrtools-2.01.01a71) and my commandline is as follows:

mkisofs -follow-links -cache-inodes -volid test -allow-multidot -no-iso-translate -relaxed-filenames -allow-leading-dots -udf -N -l -d -D -joliet-long -no-emul-boot -b bcdwboot.bin -gui -o c:\test.iso -sort FileListsort3.txt c:/final

Is there a switch I'm missing? Also, is there a way to use a less space-hogging way of implementing UDF? Adding UDF wastes a whopping 30MB of mostly empty sectors and I'd like to keep that to a minimum. Can I force XP to ignore UDF and read the ISO/Joliet-part instead?

This post has been edited by Mexxi: 11 January 2010 - 02:41 PM

[cdob]

Yes, setupldr.bin/ntdetect.com dosn't like -udf.

Just croschecked

Quote

bin\mkisofs -volid test -allow-multidot -no-iso-translate -relaxed-filenames -allow-leading-dots -N -l -d -D -joliet-long -no-emul-boot -b bootmgr -o test.iso ../W7

Windows 7 does intall fine.
Maybe there is another reason.

Quote

I'm using the latest win32 compile of mkisofs (cdrtools-2.01.01a71)

There is a72 ftp://ftp.berlios.de...cdrecord/alpha/
Did you compile the version? Do you use cygwin or mingw32 environment?
-follow-links and -cache-inodes is default enabled since several years at cygwin environemnt.

Isn't winload.exe part of boot.wim? When do you get the missing winload.exe?
Do you sort boot.wim too?

Setupldr.bin access first 4 GB of media. No idea about bootmgr.

What's your final ISO file size?

http://www.msfn.org/board/multiboot-erd-co...pid-902469.html

Another approach to XP32 / XP64 layout
http://www.msfn.org/board/windows-xp-profe...vd-t126480.html

A approach to create a sort list file, single boot so far.
mkISO_RAMload_sort.cmd http://www.msfn.org/.../7-t137714.html


BTW: -iso-level 3 and up support files greater 4GB.

[Mexxi]

Thank you for your quick reply.

Quote

There is a72 ftp://ftp.berlios.de...cdrecord/alpha/
Did you compile the version? Do you use cygwin or mingw32 environment?

Unfortunately, I'm not savvy enough to compile my own versions. At least all open source programs I tried had problems compiling. I'm too much of a rookie when it comes to coding to make my own compiles.
I downloaded the a71-version pre-compiled off a webpage. Since it doesn't require cygwin to run I guess it uses mingw32.

Quote

Isn't winload.exe part of boot.wim? When do you get the missing winload.exe?
Do you sort boot.wim too?

I can only assume that winload is a part of boot.wim, because the error contains a full path including "windows\system32..." which is not present in the sources-folder.
I get the error about the time, after the initial setup loader of Win 7 has finished loading files for the gui-based setup and just before starting it. I guess at
that time, the loader switches from iso-reading to UDF-reading. This must be a static pre-coded change since the path to the "missing" winload.exe is fully iso9660-compliant.
I never heard about the method of sorting wim-files, so no it's in its original state.

Quote

What's your final ISO file size?

4.38GB. Nothing out of the extraordinary. I also made sure that the loaders for the included operating systems are placed at the front part of the disc.
The sorting can't be the culprit since my test with and without UDF uses the exact same commandline with the exact same sort-method.

Thanks for the hint with the 4GB-support. My install.wim is only 2.7GB and I even splitted it to make sure to keep my disc as compliant as possible, so
file size is not the problem.

As a test I switched to CDimage and created a UDF-bridge-based image with its "u1"-switch. UDF-bridge is a mix-format of ISO 9660 and UDF and is used to ensure
compatibility of discs towards older and newer devices. While mkisofs supports specifying certain complexity levels for ISO9660, Joliet and RR, it only supports
UDF-bridge 1.02. According to wikipedia all operating systems from Windows 2000 on need at least UDF 1.50, which luckily is the version that CDimage produces.
I guess that is the reason why mkisofs' UDF breaks WinXP. CDimage's iso is compatible though and allows me to boot XP and Windows 7, but it introduces two
new issues: it doesn't support file sorting and it breaks ERD Commander 2005... I can live without file-sorting. In fact, I already renamed my directories to
resemble the sorting I used with mkisofs sort-switch. I guess for ERD I'll have to switch to RAM-loading. May be this will finally allow me to finish this pain-in-the-
neck project...after a couple more days... It would be so much easier if there was an mkisofs with support for newer UDF...

Thanks for your links. They'll hopefully come in handy when I try to iso-load ERD


Edit: Just checked out cdrtools a72 and the readme mentions nothing about any added UDF-features. This version only offers two minor fixes which are not related
to this problem. May be I should try growiso for a change.

This post has been edited by Mexxi: 11 January 2010 - 06:40 PM

[cdob]

Previously file system ISO9660 and Joliet did work: Windows 7 setup did complete.

Tried again: file system plain ISO9660:

added one big 5GB dummy file, sorted between boot.wim and install.wim.
Install.wim is at end of a 8GB ISO image.
Setup does load boot.wim and finish loading files for the gui-based setup.
Next there is a error message, no DVD drive found, load drivers.
Shift-F10 shows the mounted DVD drive d:

big 5GB dummy file added, sorted at end of media.
Install.wim is after boot.wim, within first 4GB of media.
Windows 7 setup does fully install Windows 7.

Windows 7 setup does not require Joliet or UDF. Plain ISO9660 is sufficient.
Sort order is importand!

Mexxi, on Jan 11 2010, 06:33 PM, said:

4.38GB.

Try create a ISO file below 4GB.

Quote

I already renamed my directories to resemble the sorting I used with mkisofs sort-switch.

Be aware: Cdimage sort by directory deep, Win32 ASMS files goes to end of media.

Quote

According to wikipedia all operating systems from Windows 2000 on need at least UDF 1.50

Do you have a link?

http://en.wikipedia.org/wiki/Universal_Dis...tive_OS_support
Windows 98 can read UDF 1.02.
Windows 2000 file system driver udfs.sys can read UDF up to 1.50. This includes UDF 1.02.
Windows 2000 udfs.sys can't read UDF 2.0 and up.
A DVD-Video uses UDF 1.02. Windows 2000 can read a UDF at a DVD-Video.

Quote

Thanks for your links. They'll hopefully come in handy when I try to iso-load ERD

The firadisk floppy image should work at ERD.

[Mexxi]

Quote

Windows 7 setup does not require Joliet or UDF. Plain ISO9660 is sufficient.
Sort order is importand!

Interesting, but you certainly did not use "plain" ISO9660, but rather ISO level 4
and while that might work for Windows 7 it breaks bootability of XP and ERD.

The fact why you couldn't have used the true ISO-standard is because the Win7
installation folder contains files like these:

"microsoft-windows-iis-clientcertificatemappingauthentication-deployment-dl.man"

This file has 74 characters in its name plus a file ending. This goes against any ISO-
standard there is (unless you use level 4). Also, there are tons of forums out there
were people complain about MS requiring UDF to make it bootable:

http://forums.techar...ems/1098166.htm

Quote from that link:

Quote

windows vista bootable requires UDF file system & the above command creates the iso image with UDF file system.

Also, in the RC was a readme that said: "This disc contains a "UDF" file system and requires an operating system that supports the ISO-13346 "UDF" file system specification."

http://www.sevenforums.com/installation-se...udf-format.html


May be Microsoft used UDF because it is a standard contrary to ISO level 4. I assume you made this iso with
mkisofs. Did you try to include an XP-setup? Did it boot? Did you check the iso in Isobuster to verify that the iso-maker
in fact only used an ISO-filesystem?

I don't think that the sort order is my problem, because the Win7 setup starts at around 1.5GB which is way below
the 4GB limit. Since my install.wim is split, the very first install.swm is also within the 4GB range, so that's no problem.

Quote

Be aware: Cdimage sort by directory deep, Win32 ASMS files goes to end of media.

Thanks for the tip. I realized that when I tried to figure out why ERD wouldn't boot. Although the directory
was the first alphabetically, it was spread all over the disc. OSCimg does the same.

Quote

Quote

According to wikipedia all operating systems from Windows 2000 on need at least UDF 1.50

Do you have a link?

It was on german wikipedia. Unfortunately I don't have access to the site. For some reason it has been timing out
for the last couple of hours. But I have something better. The built-in help of the latest OSCDimg contains information
about the UDF-support by Windows:




I might have mixed up the version numbers, but on second thought that info doesn't mean much. The question is
which filesystems Windows supports during installation and booting and not after it has been installed, because then
you can support virtually all kinds of filesystems if you have the drivers. I doubt that the udf-driver is loaded during
install to ensure readability of UDF-based discs. The fact remains that mkisofs' UDF 1.02 doesn't work with Windows 7,
while CDimage's and OSCDimg's UDF 1.5 miraculously fix all errors.

Quote

The firadisk floppy image should work at ERD.

I checked out the post. I haven't worked with anything else than BCDW yet, except for some meddling with
CDshell that lead me nowhere, so the learning curve for me to get started with grub4dos or other loaders that
support firadisk or other RAM-loading mechanism would be pretty high. I'd like to see that only as a last resort
and would rather get into this method for my next project, unless there was a sure-fire easy-peasy way for dummies
to implement that in a couple of minutes



I would like to use your iso-settings if they also work with with XP/ERD, especially due to the massive overhead that
UDF creates. Could you please test your settings with an XP-install? In one of my attempts I tried to use compliant
ISO for XP and an extended Joliet format for Win 7 and that didn't work, so if ISO Level 4 is incompatible with XP's
setup then UDF should be the only choice left. For further tests I updated OSCDimg
to version 2.55 which finally supports not just UDF much better than mkisofs and also allows to load a sort-
file. I'm currently compiling an iso with it. Speed is painstakingly slow, but if it works then that's all that counts.

This post has been edited by Mexxi: 12 January 2010 - 12:22 PM

[jaclaz]

Actually -iso-level 4 is normally used in 1.x PE's, AFAIK:
http://www.msfn.org/board/create-iso-file-...ofs-t95805.html

jaclaz

P.S.:
And yes, the -R should be a -r

This post has been edited by jaclaz: 12 January 2010 - 12:48 PM

[cdob]

Mexxi, on Jan 12 2010, 12:05 PM, said:

Interesting, but you certainly did not use "plain" ISO9660, but rather ISO level 4 and while that might work for Windows 7 it breaks bootability of XP and ERD.

Well I'm using draft ISO9660:1999 since several years.
There hasn't been a issue so far. I feel free to name draft ISO9660:1999 as plain.

Quote

Also, there are tons of forums out there were people complain about MS requiring UDF to make it bootable:

Granted MS uses UDF as default. Maybe most people use this setting too.
Well, I prefer own testings. There is no need for UDF so far.

Quote

I assume you made this iso with mkisofs. Did you try to include an XP-setup? Did it boot? Did you check the iso in Isobuster to verify that the iso-maker in fact only used an ISO-filesystem?

NT4, 2000, XP (32bit and 64bit), 2003 and Windows 7 does boot and install from a -iso-level 4 media.
Yes, there is ISO-filesystem only.

Setupldr.bin and bootmgr find uppercased file names at ISO9660 only.
Uppercase required directory and file names.
Bootmgr find lowercase file names at UDF.

Quote

I don't think that the sort order is my problem, because the Win7 setup starts at around 1.5GB which is way below the 4GB limit. Since my install.wim is split, the very first install.swm is also within the 4GB range, so that's no problem.

I don't have a explanation. Are both files fully within the 4GB range?

Quote

why ERD wouldn't boot

Which ERD do you use at all?
Most likely there is no UDF driver loaded at boot. This may cause a error too, if you use UDF filesystem.
A serupldr.bin ERD does work with -iso-level 4.
The RAM laod approach may get different results.
A 2003 SP1 setupldr.bin based ERD support RAM loading. Add a proper winnt.sif.
Or don't use UDF, but sort required files.

[Mexxi]

Thanks guys for your replies. Since iso-level 4 worked for you I gave it another shot while OSCDimg is still compiling a UDF-based image. Result:

Using iso-level 4 allowed me to start my XP-setup, but I experienced tons of reading errors, because it couldn't find the I386-directory. ERD didn't work any more ("Insert Disc to resume installation of Server 2003"-error). I also have a RAM-loading version with Flyakite's SETUPLDR.RAM trick and it tells me NTLDR DETECT error...

Starting Windows 7 starts Windows XP setup. So basically everything is screwed and nothing works. I made another test-build where I omitted iso-level 4 using only I9660 with relaxed naming conventions and suddenly Windows 7 started properly again. This time without crashing. Thanks to cdob's hint I gave the sort order another look-see. Install2.swm was placed before install.swm. Also some of the dll-files in the root of the source-directory were placed behind these files, so that was the reason for the error. I didn't try the installation yet and aborted it at the edition select screen, so I don't know if it would work flawlessly without iso-level 4, but i'll try it as soon as I find a way to make erd and xp behave correctly again.

Quote

Which ERD do you use at all?

I use the 2005 edition.

Quote

The RAM laod approach may get different results.

Possibly. It would certainly help stopping OSCDimg and CDimage from cluttering up the OS if you use them without sort-option.

As a side question: Does anyone have experience with OSCDimg's sort option? The program only crawls with this option and even stops working while the command window stays open signaling progress.

This post has been edited by Mexxi: 12 January 2010 - 03:25 PM

[cdob]

Mexxi, on Jan 12 2010, 04:17 PM, said:

Using iso-level 4 allowed me to start my XP-setup, but I experienced tons of reading errors, because it couldn't find the I386-directory.

Do you have lower case names? i386 is not I386

Filecase.exe can uppercase directories and files at hard disk. Create the ISO image next.
-iso-level 4 use this names then.
http://www.stevemiller.net/apps/
Simple approach: uppercase whole \I386\, \BOOT\ and \SOURCES\ and sub directories.

Quote

As a side question: Does anyone have experience with OSCDimg's sort option?

Sorry, only open questions.
http://technet.microsoft.com/en-us/library...243(WS.10).aspx
http://www.msfn.org/board/index.php?s=&...st&p=856888
Does oscdimg support full path only? What about directories and wild cards?

[Mexxi]

Quote

Do you have lower case names? i386 is not I386

Filecase.exe can uppercase directories and files at hard disk. Create the ISO image next.

Everything is uppercase. I already used filecase at the very beginning to avoid this problem. I guess I'll start over with this setup and see if I can make it work.
The strange thing is that I'm using a full XP and an nlited version. The full XP installs fine, the nlited one fails due to not finding the I386-directory. Due to
optimization the files for both versions have the exact same sort order (well they are practically the same files) yet the install fails even though it worked before.

Quote

Does oscdimg support full path only? What about directories and wild cards?

In regard to the sort function? Not as far as I know. The help only lists the sort-file as an option and no wildcards.

What specific feature do you have in mind regarding directories?

[Mexxi]

Finally! Everything seems to work now with pure ISO and I'm not even using level 4

The last problems I had were due to massive path changes in sif-files which I hadn't updated
after renaming my folders once more to influence OSCDimg's sort order (the old one that didn't have
that option yet). I just installed Windows 7 successfully and I couldn't be happier

There's only one thing I have to work on. Mkisofs cropped some filenames of some Windows 7
manifest-files. I guess using the level 4 switch should remedy that. Thanks for all your patience cdob

[cdob]

Mexxi, on Jan 12 2010, 05:58 PM, said:

What specific feature do you have in mind regarding directories?

Old habits: basic sort at directory level. Special sort at file level in addition.

Mexxi, on Jan 12 2010, 08:46 PM, said:

The last problems I had were due to massive path changes in sif-files

I prefer to change as less as possible: set SetupSourcePath and BootPath
http://www.msfn.org/board/windows-xp-profe...vd-t126480.html

Mexxi, on Jan 12 2010, 05:58 PM, said:

BootPath Mkisofs cropped some filenames of some Windows 7 manifest-files. I guess using the level 4 switch should remedy that.

ISO9660:1999 allows a path up to 207 chars. Windows 7 default names are within this limit.
If you add custom names longer 207 chars, use UDF.
NT4 and up does read ISO9660:1999. ISO9660:1999 dosn't bite you and won't harm.

[jaclaz]

Mexxi, on Jan 12 2010, 11:58 PM, said:

The strange thing is that I'm using a full XP and an nlited version. The full XP installs fine, the nlited one fails due to not finding the I386-directory.

It is possible that nlite edits a path somewhere (.sif or similar files) using lower case characters.

jaclaz

[Mexxi]

Quote

Old habits: basic sort at directory level. Special sort at file level in addition.

I'm not sure if I understand what you mean. Mkisofs places all directories at the beginning of an image and then appends the files according to the specified sort order. You make it sound like there was a way to specify a sort order for directories too, but that wouldn't have much impact.

Quote

I prefer to change as less as possible: set SetupSourcePath and BootPath

Same here. May be "massive" was a bit of an exaggeration. I merely replaced I386 with my new folder name. It did help solving some boot errors, so this trick was essential.

Quote

ISO9660:1999 allows a path up to 207 chars. Windows 7 default names are within this limit.
If you add custom names longer 207 chars, use UDF.
NT4 and up does read ISO9660:1999. ISO9660:1999 dosn't bite you and won't harm.

Good to know. I hope this won't change in the future. Just wondering: Did you ever try reading such a disc in Win9x or DOS?

Quote

It is possible that nlite edits a path somewhere (.sif or similar files) using lower case characters.

Thanks for the hint jaclaz. In this case it was my own fault. I had edited the file and forgot about updating it after changing the folder name

[jaclaz]

Mexxi, on Jan 14 2010, 12:27 AM, said:

Thanks for the hint jaclaz. In this case it was my own fault. I had edited the file and forgot about updating it after changing the folder name

Pheew : both nlite and iso level 4 are can then be acquitted on the grounds of not having committed the crime.

jaclaz

[cdob]

Mexxi, on Jan 13 2010, 06:27 PM, said:

I'm not sure if I understand what you mean. Mkisofs places all directories at the beginning of an image and then appends the files according to the specified sort order.

Sorry for the confusion. Yes, directories are not sorted themselves.
There are Path Table Records at ISO9660.
ECMA 119 is also approved as ISO9660. http://www.ecma-international.org/publicat...ds/Ecma-119.htm
6.9.1 Order of Path Table Records request the sort order.
Some hardware rely at this sort order. As far as I know all applications create the Path Table Records to the specification.

I'm used to set a weight at directory level, mkisofs set this level to all files within this directory and all sub directories.
E.g. a weight to I386 includes all files from I386, I386\ASMS\1, I386\ASMS\10 and I386\ASMS\1000
Textmode boot files are sorted in addition.
Example: part of sort.txt by mkISO_RAMload_sort.cmd

 
./boot.catalog 10000
./bootsect.bin 9990
./WIN* 9978
./AMD64/* 1100
./AMD64/SYSTEM32 9000
./AMD64/COMPDATA 20
./AMD64/LANG 1000
./AMD64/WINNTUPG 1000
./I386/* 1100
./I386/SYSTEM32 9000
./I386/COMPDATA 20
./I386/LANG 1000
./I386/WIN9XMIG 1000
./I386/WIN9XUPG 1000
./I386/WINNTUPG 1000
./DOCS -1000
./DOTNETFX -1000
./WIN51IP 9899
./WIN51IP.SP3 9898
./BOOTFONT.BIN 9897
./I386/*.SY? 9010
add_copy_sort_files -1
./I386/_DEFAULT.PI_ 7999
./I386/1394.IN_ 7998
./I386/1394BUS.SY_ 7997
./I386/1394VDBG.IN_ 7996
./I386/1394VDBG.SY_ 7995
./I386/8514FIX.FO_ 7994
./I386/8514OEM.FO_ 7993
./I386/8514SYS.FO_ 7992
./I386/61883.IN_ 7991
./I386/12520437.CP_ 7990
./I386/12520850.CP_ 7989
add_boot_sort_files -1
./I386/SPCMDCON.SYS 9896
./I386/TXTSETUP.SIF 9895
./I386/BIOSINFO.INF 9894
./I386/NTKRNLMP.EX_ 9893
./I386/NTOSKRNL.EX_ 9892
./I386/BOOTVID.DL_ 9891
./I386/SETUPDD.SY_ 9890
./I386/SPDDLANG.SY_ 9889
./I386/SETUPP.INI 9888
./I386/KDCOM.DL_ 9887
./I386/SETUPREG.HIV 9886
./I386/CTYPE.NL_ 9885
./I386/LOCALE.NL_ 9884
./I386/L_INTL.NL_ 9883
./I386/SORTKEY.NL_ 9882
./I386/SORTTBLS.NL_ 9881
./I386/UNICODE.NL_ 9880
./I386/SETUPLDR.BIN 9600
./I386/WINNT.SIF 9599
./I386/BOOTFIX.BIN 9598
./I386/BOOTFONT.BIN 9597
./I386/NTDETECT.COM 9596
./I386/SYSTEM32/$OEM$/* 9596
./OEM/* 200
./$OEM$/* 100
./$OEM$/TEXTMODE/* 9950 

Quote

Just wondering: Did you ever try reading such a disc in Win9x or DOS?

Given a ISO9660:1999 disk:
MS DOS mscdex.exe find 8.0 upper case directory names and 8.3 upper case file names, longer names are not acessible. Basically all DOS files are accessible.
FreeDOS shsucdx does find long ISO9660:1999 names, lower case is possible.
No idea about Win9x.

Quote

I hope this won't change in the future.

Well, I hope this too.
Contrary as you indicated already oscdimage with ISO9660, Joliet and UDF is another working approach.
Maybe I'm forced to use this file system mix in future.

[jaclaz]

cdob, on Jan 14 2010, 08:41 PM, said:

MS DOS mscdex.exe find 8.0 upper case directory names and 8.3 upper case file names, longer names are not acessible. Basically all DOS files are accessible.
FreeDOS shsucdx does find long ISO9660:1999 names, lower case is possible.
No idea about Win9x.

I may add:

• mscdex reads iso-level 3 and partially iso-level 4 as detailed above
  
• shsucdx (that can be used under MS-DOS allright) reads iso-level 4 allright
  
• NT/2K NTLDR/SETUPLDR.BIN read iso-level 3 but has usually problems with iso-level 4
  
• XP SETUPLDR/NTLDR read iso-level 4 allright

jaclaz

[Mexxi]

Quote

Pheew : both nlite and iso level 4 are can then be acquitted on the grounds of not having committed the crime.

Quote

I'm used to set a weight at directory level, mkisofs set this level to all files within this directory and all sub directories.

Interesting method. I once tried sorting with wildcards sicne the documentation said that mkisofs supported that, but it didn't work for me. May be I did it wrong, may be the compile was just buggy. In any case it's nice having seen an example. This should really speed things up for creating sort-files for multi-boot projects.

Quote

Contrary as you indicated already oscdimage with ISO9660, Joliet and UDF is another working approach.
Maybe I'm forced to use this file system mix in future.

Well. I don't mind using Joliet. It's pretty efficient for the features it offers, but UDF is just terrible. It created a 35MB TOC for my ISO which had only 15.000 TOC-entries. After having maxed out a DVD-R's capacity this really was a blow. The bad thing about UDF is that it isn't flexible enough. It reserves the same space for meta-information for every file, even if none is available. You'd think that those oh so clever engineers who developed this format would have thought of wasting another few bits to implement flags to signal the length of the following meta-data. This way each entry could have a variable length which would have made UDF quite a good filesystem.


Thanks for the very specific in-depth info on the readability of iso level 4 discs guys

This post has been edited by Mexxi: 14 January 2010 - 04:17 PM

[Innocent Devil]

i had no problem with doin XP vista multiboot. http://www.msfn.org/board/bootmgr-based-mu...sta-t99823.html

only thing u need a UDF bridge filesystem for Vista/7 and joliet extesions for XP
This command works nicely (i didnt tried mkisofs)

cdimage -lXP_Vista -j1 -u1 -e -m -h -bD:\vista-l\boot\etfsboot.com D:\vista-l d:\xp-vista.iso

note -j1 -u1

This post has been edited by Innocent Devil: 14 January 2010 - 10:24 PM

[cdob]

jaclaz, on Jan 14 2010, 03:59 PM, said:

[*]NT/2K NTLDR/SETUPLDR.BIN read iso-level 3 but has usually problems with iso-level 4

I've different experience:
NT4 SP1 boot sector and setupldr.bin does work at -iso-level 4. The installation does complete.
2000 SP1 boot sector and setupldr.bin does work at -iso-level 4. The installation does complete.

Innocent Devil, on Jan 14 2010, 11:22 PM, said:

only thing u need a UDF bridge filesystem for Vista/7 and joliet extesions for XP

No, you do NOT need UFD bridge for Windows 7. ISO9660 is sufficient.
Yes, the -j1 -u1 is another solution. However this require addional space.