375 replies to this topic

[Akeo]

Since last we spoke ReactOS did merge the USB features from a branch into trunk

OK, then I'll have to test that.

FreeDOS kernel 2041 has your requested patch implemented I think, according to the patchnotes.

I also think that is the case, since I got a notice from the developer that it was now integrated.

On the other hand, regular floppy creation is nice to have but not that important.

This is my current view as well. I'd like to see a real demand before anything else.

[bblaauw]

Adding Syslinux even in a DOS-only bootable USB-stick can be quite annoying:
* file LDLINUX.SYS needed (main Syslinux kernel)
* file SYSLINUX.CFG needed (config file)
* bootsectorfile or chain.c32 needed (to boot DOS).
* Syslinux (and MEMDISK, but in a different way) toggle A20 switch/line, which confuses some programs, like XMGR (XMS driver) and possible some DOS kernels.

[Akeo]

RMPrepUSB can extract directly from an ISO (albeit via 7zip) if specified in the Copy Files box, is almost as fast, and can install grub4dos at the click of a button too...

Which makes me wonder, since it wasn't exactly my intention to compete with RMPrepUSB, why do people seem so adamant with having features that RMPrepUSB already provides (and probably does a very good job at providing) integrated in Rufus?

[Akeo]

Adding Syslinux even in a DOS-only bootable USB-stick can be quite annoying:
* file LDLINUX.SYS needed (main Syslinux kernel)
* file SYSLINUX.CFG needed (config file)
* bootsectorfile or chain.c32 needed (to boot DOS).
* Syslinux (and MEMDISK, but in a different way) toggle A20 switch/line, which confuses some programs, like XMGR (XMS driver) and possible some DOS kernels.

Why would you want to boot DOS using Syslinux, when you can boot DOS, well, using DOS?
Also Rufus does include ldlinux.sys, and already creates a syslinux.cfg to reference isolinux.cfg. Embedding chain.c32 is something I anticipated doing, but which I haven't found a need for yet. As a matter of fact, there is a currently unused copy of chain.c32 in the Rufus git repo. The A20 point is a good thing to know though.

[sambul61]

Why do people seem so adamant with having features that RMPrepUSB already provides (and probably does a very good job at providing) integrated in Rufus?

Its hard to figure out, because you're not familiar with Reboot community. There are a lot of people, who wanted to use it for advertising future commercial tools, but then gone. Some have taken quite a few ideas and solutions along the way. Meanwhile, none of them shown interest to actually learn and understand, what these guys are doing here, even less to contribute to common tasks.

Closer to the topic, since some devoted enough time to show others how to boot ISOs and install OS from them without unpacking, they're well familiar with advantages of this and other mentioned things. Like people here know well there is no rational in unpacking someone's product, while it prevents end user from growing to using multiboot. These things don't make the tool harder to use or interface more elaborate, it just requires more knowledge from its developer. I was trying to convey this earlier - when someone is so confident they do superior job, but from aside it looks a promising beginner's effort, people try to suggest improvements (not request features) they know exist, while the author doesn't. If it doesn't work - at least they tried.

So, why you keep getting suggestions about Grub4DOS? Because it just doesn't look smart to drop thousands of OS files onto a slow Thumb, when next day one may want to delete them all, and drop an updated or different tool. And if someone is happy with a single ISO image - then be it, but when another guy wants to add a second image - give him a chance. Remember, single button mouse arrangement had all features of a 3-button mouse and more, only implemented in a more elegant way.

[saddlejib]

I think Akeo has stated his intententions perfectly, his replies are clear & concise like his web page.
As he has stated in his "mission" definition he wanted to upgrade and ease the creation of a certain type of bootable usb stick maintaining clarity and definition.
To which end he has suceeded (p.s it sees my usb HDD as a single partition) it would be better if it did'nt see it.It is partitioned. But hey
I feel he can fulfill everyones criteria by creating different versions of this software from novice to expert depending what you require !
We all forget the novice.
From acorns grow Oaks.

He reads like a new Wonko or Jacklaz and yours Steve of RMPre

Who's work I admire.

Edited by saddlejib, 25 February 2012 - 12:03 AM.

[sambul61]

We all forget the novice.

Being a novice user has nothing to do with how the tool internally works. A user doesn't even need to know that. The author opened discussion about his tool on Reboot forum, and he is getting what this forum has to offer - friendly suggestions. That's always done, when a new tool is offered, aiming to improve. Some call it "peer review". Would you like a thousand of empty "Great!" posts instead that lead nowhere?


Peer Review

[saddlejib]

I agree with you entirely. The spirit of any good forum is to share knowledge. Which fortunately we can now do globally.

Occasionally some good ideas are born of clear objectives, all I am saying is this tool should be refined as is, thus meeting Akeo's objectives and a new release with all the above mentioned features should be released in the future but as a new entity. (stepping stone)
Thus allowing new users to move on progresively. If they desire.
I for one could'nt speak when I was born but I can now count to ten in decimal,hex and binary.
No disrespect meant or felt.
Just my opinion as a plebiscite.
Thus to this end that's why I enjoy steve's tutorials (RMPrep) Wonko and as was and allways is Jacklaz.

Edited by saddlejib, 25 February 2012 - 12:56 AM.

[Akeo]

Its hard to figure out, because you're not familiar with Reboot community.

Indeed I am not. I see reboot.pro as a platform, which I'm happy ot participate in, but that isn't the one-entity-to-rule-them-all that should trump all of the other means I have of interacting with people and identifying the features I should provide to them. You take pride in your community, I get that, and it looks like a nice place indeed. But you should also appreciate that some people do see it as just one community, among many, and may not decide to invest as much time in it as you would like.

Meanwhile, none shown interest to actually learn and understand, what these guys are doing here, even less to contribute to common tasks.

Then let me ask you this: if his is indeed the case, have you ever stopped and wondered why none appear to have shown further interest? If I saw many people come to visit my place, but then seem to leave in a hurry soon after, I'd probably start to question myself.

since some devoted enough time to teach others boot ISOs and install OS from them without unpacking, they're well familiar with advantages of this and other mentioned solutions.

Yet some will still advocate a solution and others another. I'm seeing quite a bunch of very popular tools that do extraction, and I also engaged with knowledgeable people who seem to see extraction as a perfectly fine solution (if not better because it makes it possible to fix/customize things). Therefore, I'm quite puzzled at the number of people who apparently got it "wrong" when it should be so obvious that they are mistaken...

For example, people here know well there is no rational in unpacking someone's works

Then people here need to learn about customization or wanting to test one of the installation of the numerous distro-current trees that most Linux distros provide. They also need to look around at what a major corporation such as Microsoft does with regards to converting installation ISOs to USB.. If I had to take a vote between who of the reboot.pro community or Microsoft may have more authority with regards to the direction to take, I would pick Microsoft, mostly because they are supposed to have the resources to study a question thoroughly, especially if it involves trying to figure out user needs, and make an decision based on more than a few factors.
By the way, and this is a real question, how are Apple USB installation media provided for OSX? They obviously don't provide OS-X on USB as a monolithic ISO, and I would guess it probably is something close to PE. How does it work? Do they have a monolithic file? Or a myriad of packages? How does it differ from the ISO media content they provided previoulsy?

when more efficient methods exist

Well, the case you made for it didn't really strike me as a model of efficiency, since apparently one needs to extract a handful of files from the ISO anyway (which ones?), fiddle with configuration, and last time I checked, optical drive emulation was far from being a silver bullet and costly in resources.
Please stop insisting the the method you want to champion is better - instead start proving it with facts.
How well do all of the ISOs I listed as compatible with Rufus work with your method? And what would actually be required from my program, apart from the installation of grub4dos, to make it work? It seems some files still may have to be extracted - what are they? You're the specialist there, so please enlighten me. Does grub4dos (or something else) really offer the ability to take any ISO and make it work out of the box? What about loading speeds ? What about additional resource usage and the cost of emulation? What of installation media that want to see an optical drive? How does the grub4dos transparent ISO emulation work? Obviously, it has to fake what the BIOS presents to the bootloader/installer from the ISO to make it believe that a drive exists while there isn't one. And it also has to be smart enough not to let this emulation be detected/reset by the installation process. The way I see it, if it was that simple, it would have been done a long time ago, tools like Syslinux wouldn't have spent effort into hybrid ISOs, and this is what Microsoft and others would be using for ISO -> USB, so there are probably some caveats. What are they?

also empower end users to do more if desired without extra features added, but using smarter knowledge based code.

If you are indeed talking about end users, then you are wrongly assuming that most people who want to boot "stuff" want to learn how the boot process works. Most will just want their "stuff" to boot, period.

When someone is so confident they do superior job, but from aside it simply looks a promising beginner's effort, people try to suggest improvements (not request features) they know exist, while the author doesn't. If it doesn't work - at least they tried.

Please go tell that to Microsoft, HP as well as Ubuntu, whose tools I followed very closely when deciding how I should go about the boot process with Rufus.
Beginners indeed!

[saddlejib]

I guess all I'm trying to say is let the reboot community refine this tool 'as is', which I know you're collectively able to do.

Then move on to the next step and redefine objectives expand this and re-release as a new tool to be perfect in it's new objectives.

Incremental steps.

No dis, just logic.

[Akeo]

Would you like a thousand of empty "Great!" posts instead that lead nowhere?

Just for the record, I agree with that statement as well. Getting praise is nice and all, and appreciated of course, but doesn't bring much in the long run.

However, I do have a concern when I start to get the feeling that people in a community would like to have a free pass at acting like the next Steve Jobs and order developers to work on "their vision". I don't consider it as a big deal, since I too have my own "vision" of things, and I don't mind confronting ideas, but if it's going to to hinder progress, we may want to reframe things a little.

If you want to show me you know best (or why you think you know best), then I'd appreciate if you tried to back it up with somehing that can be construed as clear evidence than it will benefit the community at large (and not just the reboot pro one). Likewise, if you feel that some of the arguments I make may be lacking in evidence, please don't hesitate to ask for it.

An "I believe Rufus should go in this direction, because...", with a technical comparative explanation of why an option would be better than the alternative for users at large, can go a long way...

[sambul61]

If I had to take a vote between who of the reboot.pro community or Microsoft may have more authority with regards to the direction to take, I would pick Microsoft..
...
What would actually be required from my program, apart from the installation of grub4dos, to make it work?

Don't be so confident about that. Some Reboot developers put extraordinary efforts to uncover jams, carefully hidden by MS, and go further, like developing virtual device drivers that work in tandem with G4D. As a result, Reboot members easily install OS from ISO, and boot OS from USB Thumbs for years, while it was never officially supported by MS. Same goes for other OS suppliers. Installing Windows from ISO requires a virtual disk driver to be auto-added to WinPE at its boot from ISO which then mounts the ISO - its all done by G4D and WinPE with no dev's effort. I don't want to add complexity to this picture perfect talk, it may be reserved for another time slot if you insist.

As to Grub4DOS, Steve, Wonko and Icecube are better sources of advice on that, and hopefully will be glad to help. And luckily they're all connected to your topic: you already know Steve, spoken to Wonko The Finder, and Icecube is a big Linux and G4D fan, developer of PartedMagic OS and ISO. A couple of things I can suggest to begin with is Grub4DOS Guide and Grub4DOS ISO mapping reports among others in that section, where you can find G4D menu examples for most of your Linux distros. Only a few Distros would need a few files to be extracted, and that is also explained in examples - use Google Search restricted to the forum. If you want to play with G4D, the easy way is to add it (called Neogrub, with empty Menu) to Win7 Boot Menu from EasyBCD.

What I can suggest is to add a Win7 BCD store to an empty Thumb, then add Grub4DOS as a menu entry to Windows Boot Menu (see linked Guide), and once a user clicks on that entry, s/he will be presented with a list of ISOs to boot and extra Syslinux entry (for a few ISOs not bootable via G4D). It might be a fare deal, given Windows share among users. Start from a single ISO added to G4D Menu, and make it work with your tool. The rest will be easier. Of course, another option is to install G4D as the only Menu (makes booting VHDs harder), or adding it to MBR.

Pls understand, no-one here expects to benefit from your tool in a way you think. Read this thread to see similar discussion. You are right, it requires a new version of your tool for would be mass multibooters , which will absorb eventually your earlier version. It can still be based on a Single ISO vision, but expandable by a user, meaning an option to either ADD or REPLACE an image on the Thumb.

P.S. At earlier forum soft update some CODE sections, including G4D Menus, get corrupted (red text), so use Wonko's Botched Content Converter.


Apple Single Button Mouse is covered all around by multi-touch sensors - its simple to use, but the design isn't primitive.

[ilko]

...The one trick one needs to be aware of is that after you install the NTFS boot sector and copy bootmgr, you must remount the volume so that Windows updates the NTFS records. Rufus does it automatically, but if this doesn't occur, your media will not boot unless you re-plug it and let Windows mount and "fix" the volume...

Have you tried if IOCTL_DISK_UPDATE_PROPERTIES issued after recreating the disk structure helps for this issue?

By the way, it seems quite similar to this one:
http://reboot.pro/5059/

[Wonko the Sane]

I might have missed something in the river of words that submersed this thread , but, just for the record, there is no real "reason" to "install" grub4dos.
Grub.exe is a Linux kernel (besides a DOS executable) so all it is needed is a line like LINUX /grub.exe in a Syslinux .cfg to add grub4dos to *anything* Syslinux based.


Wonko

[sambul61]

That may be true, except mass user will be interested primarily in Windows stuff, hence there is no real "reason" to have this tool "based" on Syslinux rather than Windows BCD. Syslinux when needed can be jumped to from Grub4DOS (Tut 62). You missed the part where testers suggested to copy original ISOs to the Thumb instead of extracting, which (apart from being highly inefficient long run) blocks a user from converting a single boot experience to multiboot. So, the tool now works like a hand brake... The author seems to realize this can be solved.

I wonder, how long is the Record, you keep so eagerly?

[Wonko the Sane]

It seems like a carpenter's comparison is needed.

How should a swing be built?

Spoiler

http://www.scandocs....ingDesign02.bmp

Wonko

[sambul61]

I know, there is always gratification in calling Wonko an expert...

[Akeo]

Don't be so confident about that. Some Reboot developers put extraordinary efforts to uncover jams, carefully hidden by MS, and go further, like developing virtual device drivers that work in tandem with G4D.

I'm sure of it. But does the reboot.pro community have access to general user panels, and has its all business placed on identifying user trends to ensure that their next software meets the demands/needs of the masses?
This is what I'm talking about when I say multiple factors. Being able to solve a technical problem is only one of the problems that software designer need to address. There's also UI, support, consistent upgrade paths, target demographics, etc. Disregard those at your own risks!

As to Grub4DOS, Steve, Wonko and Icecube are better sources of advice on that, and hopefully will be glad to help. And luckily they're all connected to your topic: you already know Steve, spoken to Wonko The Finder, and Icecube is a big Linux and G4D fan, developer of PartedMagic OS and ISO. A couple of things I can suggest to begin with is Grub4DOS Guide and Grub4DOS ISO mapping reports among others in that section, where you can find G4D menu examples for most of your Linux distros.

Thanks. I haven't had an in depth look yet, but the thing that concerns me is that it seems like there isn't a generic way to set an ISO and have grub4dos boot it. Instead it appears one needs to provide parameters to grub4dos, that may differ from one ISO to the next (apparently not by much, but still). This creates quite a few issues:
- If there is no easy way to figure out what these parameters should be from one ISO to the next, then the application needs to be content aware (i.e. maintain a list of ISOs it knows how to handle), which makes it difficult to be future-proof and requires users to upgrade the app on regular basis.
- Even if maintaining such content awareness is not an issue (eg. there's an online DB filled by volunteers or something, that Rufus can communicate with), when provided with an ISO, one still needs to identify its entry in the DB. Using the filename seems a bit foolish to me, since there's no guarantee a file hasn't been renamed. Using an md5 or CRC32 may be better, but means extended delays when scanning the ISO, and also will not work in the case of someone creating their own PE ISO or something.

Now, my assumption is that there's probably a way to have a look at partial content of the ISO, to identify the grub4dos parameters that should be used, and to be fair, I'm already doing some of that in the current Rufus (I already search for what looks like an isolinux/syslinux cfg or a /bootmgr, to determine how the ISO should be handled).
However, if I am to do it in Rufus, then why shouldn't grub4dos be the one doing it?
If I am to solve the problem above (provided that this is an actual problem, and I am not misinterpreting what I see), then it must mean that grub4dos could also very much solve it on its end.
Why should I have to identify the grub4dos parameters that Rufus should specify then, when, if not provided with options (or a "defaults" one) grub4dos could also detect the ISO content and set everything in the same way I would be asked to do in Rufus?

In other words, if genericity is not currently available in grub4dos, I don't think I should be the one compensating for to make it generic (which is what very much want: Rufus should be able to pick any ISO and transparently make it bootable without user interaction).
I think grub4dos should be the one doing that instead, since it'll make it a lot better for all grub4dos users and not just indirect users of grub4dos from Rufus, and I'd rather wait until they do.
Now, if they haven't done it, or say they can't do it, it must mean that, maybe, it's not as straightforward as it seems, which is all the more reason to be cautious about rushing head first into adding grub4dos support in Rufus...

What I can suggest is to add a Win7 BCD store to an empty Thumb, then add Grub4DOS as a menu entry to Windows Boot Menu (see linked Guide), and once a user clicks on that entry, s/he will be presented with a list of ISO (...)

That's multiboot, which most users I am targeting with Rufus won't care about (or, worse, that's a requirement for content awareness, which I explicitly am working towards avoiding).
One of my established goals is to make Rufus as generic as possible and hide any complexity. What you propose is going against that goal, to satisfy what I identify as a minority of users. Why should everybody else be penalized (by being provided with options that they may find confusing) to satisfy a minority?
Again, I am pretty confident that most users of Rufus will want to boot one ISO, and one ISO only. Therefore, even if we can make the selection hidden when only one ISO is available, I don't see much of an advantage in using grub4dos rather than what I am currently doing, even more so if my concerns above hold.
One of my established goals is making ISO support in Rufus as generic and transparent as possible, since this is what I believe users of an ISO -> USB application deserve.

You are right, it requires a new version of your tool for would be mass multibooters , which will absorb eventually your earlier version. It can still be based on a Single ISO vision, but expandable by a user, meaning an option to either ADD or REPLACE an image on the Thumb.

To tell you the truth, if the reboot.pro community wants an advanced version of Rufus, I would very much prefer if they do it themselves.

As you can expect my development time is limited, even more so as I have my fingers in more than one pie, so I doubt I will personally have much time to produce a Rufus-advanced that meets the expectations you guys have. If I had all the time in the world, I wouldn't mind, because it looks like fun, but I don't. Others have also suggested I make Rufus accepts modules or something, but I see this as too much of a time investment when I can simply leave people who want to extend my work do it themselves. The whole source is 100% free, and you also don't have to pay one cent to produce your own derivative version of Rufus, as there's absolutely no trickery to it. Rufus can be compiled with MinGW32 or the WDK, that are 100% freely available to anyone, so there's no even a barrier with regards to development tools. As a matter of fact, the executables I provide are not compiled with Visual Studio (which is also supported) but MinGW32.

Thus, if you are really that interested in an advanced version of Rufus, how about you get a bunch of reboot.pro developers together and create a "Rufus-advanced" fork or something?

[bblaauw]

You're right that no universal conversion method exists. So far the following seems to exist:
1) unpack ISO (as RUFUS does)
2) load ISO in RAM by Grub or Syslinux+Memdisk, requires ramdisk-aware drivers/scripts inside the ISO (FreeDOS, some Linux distro's like PartedMagic, maybe even some Windows special variants)
3) map ISO located on USB (actually, the sectors it occupies) as a CD, as Grub can do, and maybe some MEMDISK.C32 module in the future
4) hardware presentation of 1 or more ISO as (virtual) CD (as Isostick can do)
5) extract/duplicate some kernel + initrd (that will locate/load ISO on USB or other devices) and place ISO plus these bootfiles on USB stick (benefit: init USB drivers to full speed when BIOS sucks)

And ofcourse there's still PLoP as fullspeed-USB enabler, which is best loaded from the USB-stick itself, chained from syslinux (which in itself is a case for adding Syslinux).
My personal preference is "boot manager" -> "ISO mount/boot module" -> "ISO file" (option 2) as that in best case means only adding 1 single file (the ISO file itself). However the operating system inside the ISO has to be aware that it's dealing with data inside an ISO9660 filesystem that's not necessarily attached to a physical optical drive but might be a ramdisk or part of an USB stick (or harddisk).

RUFUS as-is is already perfectly suitable for its intended goal of providing bootable USB sticks. Thanks for that.
As mentioned before the A20 thingie is an annoyance with Syslinux. However having syslinux (or grub) available even in a simple config allows adding additional operating systems much easier.

[sambul61]

One of my established goals is to make Rufus as generic as possible and hide any complexity...
Most users of Rufus will want to boot one ISO, and one ISO only...
My development time is limited, even more so as I have my fingers in more than one pie.

When you say Rufus can boot "any" ISO" its not true. It can boot only a very limited set of selected by you and pre-analysed & pre-processed images. Adding extra image requires all the leg work from you, as with other images. In that sense what one needs to do to add Grub4DOS support - find or figure out at times special G4D menu extra lines - is no different, and as you get more experience, you'll be able to make this approach more common or often avoidable. To some degree of course, given a broad variety of developers working on various Linux distros without any notable co-ordination or industry standards mandating compliance.

So basically, what you're saying is: I already learned, how to extract ISOs, no way I will learn how to use G4D - that's way too much for me. Well, this is your choice. You wanted suggestions - you get ones, now its up to you whether ignore them or follow. One thing is for sure - you can't speak as "mass user representative", because you're not - you represent only yourself, and with the same certainty one can claim, you have no idea what mass user wants. Which particular "only one" ISO a mass user wants to boot? Why then you list the supported selection - list only ONE... Another thing is for sure: you are offered a pathway that enables mass users to grow. Instead, because you don't want to grow, you elect to restrict all users from growing, as... you know better what they need. This philosophy is familiar, but at the very least fundamentally float.

Referring to MS studies is also float - did you try to place any suggestions on MS feedback sites and then see them implemented? Their analysis accounts for user opinion in very last place. Saying a user will be confused if needs to select an ISO to boot out of 3 added earlier - is laughable. Imaging yourself - finding on the web and adding 2-3 ISOs for the tasks you need - and then get so confused when presented with the list of 3 ISOs to choose one? If one is so helpless - why adding them to begin with? Still must select the one from your supported set, right: out of 10-20? As to why Grub4DOS developers don't generalize ISO boot, you gave the answer - its too diverse, and the distro versions change frequently. And there is only ONE active developer in G4D today (surprised?) who can work in Assembler, and tries to add extra features to this very restricted in size and reach in features program.

So lets leave it "as is" - you do what is good for you, and users will decide if your tool is right for them. There isn't much to fight here for - there are better programs, someone will be happy with yours, and all this may vanish one day following the ISO format. Good luck with your project!

[Brito]

I like to use a simple and straightforward tool, rufus is simple.

Keep it up.

[Akeo]

When you say Rufus can boot "any" ISO" its not true. It can boot only a very limited set of selected by you and pre-analysed & pre-processed images.

No. That's what you don't understand.
Rufus should work with any isolinux/syslinux and bootmgr based ISOs, whether they exist now or are created tomorrow.
The ISOs I list are the ones that I personally tested. But I don't have time to test them all. And every single time I mentioned the list I said it wasn't exhaustive, which means this is just a limited subset of all the ISOs I expect to work.

The only limitations are that:
- if isolinux/syslinux based, then the installation process should be USB aware, which most current Linux and other distro processes are
- because syslinux broke compatibility of some c32 modules between 4.0.x and some earlier versions, you may find some images where the graphic menu isn't displayed. But you can still very much get to select each menu option and boot them by pressing Tab, so it's more of an inconvenience than an actual failure to boot.

Adding extra image requires all the leg work from you, as with other images.

Not at all. Right now, you should be able pretty much any Linux distro and it should boot with Rufus. Why? Because I'm not aware of a Linux distro that doesn't use isolinux, and I made sure that isolinux support in Rufus was as generic as possible (which wasn't that hard, and especially didn't require to maintain a list of known distros). The only issue I had to fix for that was the disk-by-label option, which I think should be okay now. There are probably some ISOs out there that have additional quirks, but I genuinely expect the vast majority to boot fine, including, and this is the important part, future distros (that is, unless Syslinux breaks compatibility again, but I'm pretty sure they aren't going to do so without very careful consideration).

As to bootable ISOs that aren't bootmgr/isolinux based, which I estimate to be a minority, I am working on adding generic XP PE support. After this is done, I believe Rufus will have covered the vast majority of bootable ISOs users may want to convert to bootable USB, and done so in the most generic manner I can think of.

So basically, what you're saying is: I already learned, how to extract ISOs, no way I will learn how to use G4D - that's way too much for me. Well, this is your choice. You wanted suggestions - you get ones, now its up to you whether ignore them or follow.

Not at all. I am saying that my process is good enough if not better than the G4D one, because it doesn't require one to maintain a list of compatible ISOs (which is costly, time consuming and requires users to update on regular basis), it also ensures that maximum reading speed is achieved during boot (because there's no extra emulation layer) and as far as I could so, it also means that I can keep the size small.
I still haven't seen any convincing argument that a G4D approach was better.
You're unhappy that I didn't pick your favourite horse. Either deal with it, or show that it can actually win the race.

You can't speak as "mass user representative", because you're not - you represent only yourself, and with the same certainty one can claim, you have no idea what mass user wants.

I can't speak for them, but I damn sure can make an educated guess, based on factors such as my experience in software development and support, as well as the target demographics of Windows usage, which aren't difficult to estimate. Given it's worldwide reach as the dominant OS, how many users of Windows do you think are power users? Considering that I see half of Rufus users being interested in Windows installation media and the other half in Linux or recovery, and even if Rufus users are only expected to be a small minority of all Windows users out there (and probably closer to power-users than regular joes), here is my estimate: 90% or Rufus users will not give a damn about multiboot or want to be faced with anything extra during the boot process. All they will want is their USB to boot with the media they selected, so that they can run whatever that media has to offer. And yes that will be a single media. Same goes for wanting the target to be formatted using a single partition.

There is genuine interest for people who never installed Linux before to give it a try (see the overall Ubuntu success). And as regular joes get access to more computers, their need to be able to run Windows installation images increases. There's also all the people who experience a problem, and are smart enough to google around to end up with an repair/recovery utility in the form of an ISO, that they would like to run on USB rather than optical.
Do these people want to have any idea that there is more to booting than just running a small utility like Rufus? I think not. And I am very confident that these people will make the majority of Rufus users, therefore the ones I need to cater for first and foremost.

Another thing is for sure: you are offered a pathway that enables mass users to grow.

Do you seriously want to posit that most people who want ISO -> USB want to become knowledgeable about the boot process? Occam's razor tells us that is someone wants to convert an ISO to USB, it's because they want to run that ISO content in a manner that is more convenient than from an optical drive, while still getting the exact same apparent behaviour.
Else, what you suggest would be akin to a Linux distro interrupting it's boot process with something like "Hey, I know you'd like to move on to installing this distribution, but wouldn't be interested to know how you actually managed to get there? It's a very interesting story. You see, in every computer there exists a BIOS, whose role is to..."
Doing so just wouldn't make any sense.
Just because you are interested in something doesn't mean that everybody else is, or wants to be. Anything that pertains to the boot process, that users would not have to deal with if simply popping an optical media in a DVD drive, and that can be hidden, should be hidden. And that's the approach that Rufus takes.

Referring to MS studies is also float - did you try to place any suggestions on MS feedback sites and then see them implemented? Their analysis accounts for user opinion in very last place.

[citation needed].
How do you know that Microsoft places user opinion last? Maybe that's something that only developers would be familiar with, but have you taken a look at the MSDN documentation lately? People are encouraged to comment on the articles there and Microsoft welcomes it and makes it exceedingly easy to do so. I used that feature a couple of times myself, and found that my comments were reviewed properly (even as one of them turned out to be a report for a bug that didn't actually exist, which they could easily have ignored altogether). And like most companies producing software targeted at the mass market, they are known to run user panels when deciding on major UI features. Heck, they even provide a complete preview of their future OS months in advance, to anybody who wants to try it, and encourage feedback. I also recently contacted a Microsoft employee, as a complete outsider, which I knew was working on some USB features that were of interest to me, and was pleasantly surprised that, not only Microsoft was happy to engage in communication, but also actively asked for feedback through the project manager. Since I'm far from being happy with everything Microsoft does, I was almost annoyed that, when it came to this specific feature, I didn't have anything but positive to say...

Saying a user will be confused if needs to select an ISO to boot out of 3 added earlier - is laughable.

Then have a good laugh on me. But not at the expense of all the people in the world who use computers but aren't that knowledgeable about them. Maybe it's just me, but it's the vast majority of the people I meet.

As to why Grub4DOS developers don't generalize ISO boot, you gave the answer - its too diverse, and the distro versions change frequently. And there is only ONE active developer in G4D today (surprised?) who can work in Assembler

LOL. Is that supposed to impress me? I stopped tracking count of the assembly languages I can work with years ago. And I did some extensive work in some of them too... Heck, I'd deal with assembly all day long if I could, because this is where the most fun is to be had...

and tries to add extra features to this very restricted in size and reach in features program.

And that guy has my sympathies. I know what it's like.

So lets leave it "as is" - you do what is good for you

I'm fine with leaving it as is, but you're wrong with the last part. I do what I believe is best for users at large, not for me. That is and has always been my motto, and the main reason why I will often clash with people who I feel seem to place their own interests above what I estimate to be the interests of users at large.

and users will decide if your tool is right for them.

And I couldn't be more fine with that. That's also one of the reason I release everything I do as FOSS, because if anybody wants to produce a derivative with their own improvements, they can.
The more competition, the better, especially as, as demonstrated in this thread, not everybody wants the same features.

Good luck with your project!

Thanks. And good luck with your endeavours as well.

[Akeo]

You're right that no universal conversion method exists. So far the following seems to exist:
1) unpack ISO (as RUFUS does)
2) load ISO in RAM by Grub or Syslinux+Memdisk, requires ramdisk-aware drivers/scripts inside the ISO (FreeDOS, some Linux distro's like PartedMagic, maybe even some Windows special variants)
3) map ISO located on USB (actually, the sectors it occupies) as a CD, as Grub can do, and maybe some MEMDISK.C32 module in the future
4) hardware presentation of 1 or more ISO as (virtual) CD (as Isostick can do)
5) extract/duplicate some kernel + initrd (that will locate/load ISO on USB or other devices) and place ISO plus these bootfiles on USB stick (benefit: init USB drivers to full speed when BIOS sucks)

Thanks for the detailed list. I do agree that there isn't anything universal and that each method has its pros and cons.

My personal preference is "boot manager" -> "ISO mount/boot module" -> "ISO file" (option 2) as that in best case means only adding 1 single file (the ISO file itself). However the operating system inside the ISO has to be aware that it's dealing with data inside an ISO9660 filesystem that's not necessarily attached to a physical optical drive but might be a ramdisk or part of an USB stick (or harddisk).

The major problems I see with anything but 1) is the extra resources consumed (RAM, non reusable mapped sectors, drive emulation), which 1) does not have. But just like 2), 1) needs to have some non-physical ISO awareness as well.
5) is of course the best option in terms of speed and resources, but unfortunately the less generic to implement (and also requires non optical ISO awareness).

As mentioned before the A20 thingie is an annoyance with Syslinux. However having syslinux (or grub) available even in a simple config allows adding additional operating systems much easier.

Yeah. I'll probably add an option that allows Rufus users to install a bare Syslinux, so that they can use it to multiboot or chain load.

[saddlejib]

Did I notice a "blush" in one of Wonko's replies or was I mistaken ?
We should start a new thread:
Lets's call it Wonkopedia.
I'm trying to say 'Let's not be so heavy'
Excellent Forum.

" A Suffusion of Red "

Edited by saddlejib, 26 February 2012 - 01:08 AM.

[sambul61]

Hi Akeo,

Excellent post! Lets make it clear - nobody is clashing with you, its a friendly discussion that you personally requested. And the last thing I want is to discourage you, since doing creative work is IMHO the best activity people can devote time to. And I see, you seems to understand it somehow.

You almost convinced me to abandon everything else (including VHDs ), and start promoting Rufus. I even put forward a small marketing plan, but then decided to validate it on my own skin. So, what I did: looked at your list of ISOs (that you personally checked out of those that are all supposed to be supported by Rufus) and wanted to select the only ONE, I can expose my Flash to.

Here I faced with a serious dilemma: usually the way I select a tool to use time-to-time is by trying how it works. Since I'm severely limited to one (and only ONE) - yes ONLY one - ISO, I need to somehow pick it out of many - without testing, right? Or, do you suggest me to copy fist one thousand files to my dear Flash, run it once, then wait 20 min until they are all erased (because I don't like that one), then copy another one thousand files to my (now pure) Flash.... and go on, until the very last ISO in your carefully pre-tested list is done, and I finally happy with it - right?

Still I've a problem though... The problem is, my Windows doesn't boot - so I need to use Rufus to start WinPE from the Flash - you know one of these PEs Reboot guys crafted... But, this is today... Yesterday I had a different problem - I've got a new hard drive and needed to have it checked with Victoria and partitioned for Windows and Linux. So I needed to use Victoria floppy IMA and Paragon trial ISO for that - of course only with Rufus. Tomorrow I'll have another headache - my niece lost access to her HD right in the middle of her class, she doesn't know yet about Rufus, so guess what - she called me. Yes, because she suspects, I can do something about it. But - luckily I already know about Rufus, this is my TOOL of choice now, so what I will do - yes, erase the 3d thousand of files from my (long thick) Flash, and load another portion to it - now its going to be R-Studio ISO I borrowed from a friend (sorry, didn't use you choice of distros ).

So, lets calculate: 5 thousand files dropped on the Flash during 3 days being a regular Joe - my Flash is no more, its actually gone, meaning of course not only it can't post on this forum, by also it refuses even to listen to me. Guess what - until I buy a new Flash on Ebay, my niece is going to classes without a Netbook. I have a determination though - as soon as the new Flash is home, we are going to the web adventure together - to find the right ISO - yes, that ONLY ONE which is going to suffice all my needs now and ever.

Pls be with me, the Report is not over...