Okay. Yes, Alacran, the preinstallation environment should boot faster than the full desktop environment, and if the required binaries to boot to notepad and open the configuration files on the EFI partition are already present on the system, then correspondent entries should of course be added to the boot menus (and this is not limited to legacy Grub4DOS). I never used the preinstallation environment; I understand I still would have to download it. In my thinking it gets a new section number. Here I see the question how to edit configuration files more in general, as one that must be answered for every operating system I'm currently testing, and not as a problem I couldn't solve at all.
Concerning section 9, Wonko said in his previous post:
Proposed BIOS booting sequence:
BIOS-> MBR code->partition address within MBR code->bootsector code->whatever loader the bootsector code invokes
I understand this is the intended behavior of your mbrfat32GPT program, Wonko. Your post covered precisely the field of my wondering: Why do you somehow seem to "not like" Chenall's UMBR solution, to not be quite content with it? Now my impression is you missed the step I took at the beginning of my previous post, which was to test an option explicitly mentioned in the syntax help but seemed to be untested yet, namely to provide a partition instead of a file as argument. When I say "umbr (hd0,0)+1" and am answered "(hd0,0)+1 success:[66a5]", then umbr does not know that I'm about to install grldr.mbr and grldr. Instead, as you said, it addresses and executes the partition boot sector code. Just like, not in contrast to, your program, which surely has quality of its own, and deserves further development and a dedicated thread. I feel it means something precious to you. I just cannot appreciate this and help you tweak remaining details because of my close-to-zero experience with assembly language.
So I think you’re mistaken when you reduce UMBR to this behavior:
UMBR BIOS booting sequence:
BIOS->UMBR code in the MBR->grldr or glrdr.mbr in a fixed position on disk
I feel misunderstood. And I want to be allowed to seriously answer to objections and to resolve misunderstandings without immediately being torn out of context and taken to the dumpster. This thread wasn't "started by Gerolf", as is falsely stated on top. Instead, my postings were moved here without my approval, and I find myself, on a platform highly frequented by international IT professionals, under my real name, presented as the guy who doesn't know counting starts with number one. I'm not even given edit permission for my own posts to correct the now misleading references. So I also feel disrespected.
Though I think our communication has been productive so far, now I'm tempted to stop contributing. I do my very best to not be confusing when writing about new things of complexity. To get a dual-mode machine running, with the help of "Grub4EFI", but interwoven with legacy code, is mind-opening for me. I was in a state of flow, I had energy. Now part of my reporting is moved without any trace, and some of the older posts I mentioned got a different number. Now I'm "promoting disorder". Please move this back. The next thing I wanted to write about is how to edit the customized configuration files for the involved boot managers with the help of Kolibri for UEFI, which may work with "Grub2EFI" but fail with "Grub4EFI", whereas Grub4DOS will happily boot legacy Kolibry. Will my menu.lst just need a little tweak I wasn't aware of, or is it an issue with either "Grub4EFI" or Kolibri?
I need a test machine to be more precise and help "Grub4EFI" get out of beta state. There are more such issues to come. How does “this thing” behave on internal disk? It's not that the "Grub4EFI" thread, at the beginning, had always been more to the point or covered the full spectrum opened by its title when revolving about booting from external disk and into RAM. I feel that Zammibro, who was told that "it is not intended for novice users", had a reason when asking, on page 12 of the thread that I was now removed from: "how to add this thing to a Windows PC?"
It's not that I was being boring. In one post, titled as section 9 of my reporting about the setup of a test machine for "Grub4EFI", I gave the summary of a solution that took three months and three pages to be found. Then it took me two more posts to improve it a little. I did not intend to extend this section too much. It was the other way round, I wanted to help novice readers set up a dual-mode test machine so that they can provide more meaningful context information when their switching from BIOS to UEFI fails, unlike in the case of the frequent-reader-turned-new-member who had to be told to read and follow the manual; a homework which by the hour seemingly isn't accomplished yet.