Jump to content











Photo
* * * * * 1 votes

Boot into 3rd-party EFI application via BCD?

efi uefi chainloader grub2 bcd bcdedit

  • Please log in to reply
53 replies to this topic

#1 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 17 October 2012 - 07:53 PM

Can someone tell me whether or not it is possible to chainload a non-MS-signed EFI application from the BCD?

I'm attempting to add a GRUB2 EFI build to the BCD, but no matter what I try the bootmgr insists that the application is missing or invalid. Also, it seems to be not possible to chainload a bootsector on an EFI PC - even though you can boot from a USB with that same bootsector.

I can understand the latter (though I would welcome workarounds, if there are any). But why can I not load the GRUB2 EFI application by creating either an application or bootsector app in the BCD w/ the path set to grub2.efi?

grub-mkimage was invoked with -O x86_64-efi

Edited by Computer Guru, 17 October 2012 - 07:56 PM.


#2 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 17 October 2012 - 08:02 PM

...
Also, it seems to be not possible to chainload a bootsector on an EFI PC - even though you can boot from a USB with that same bootsector.

I can understand the latter (though I would welcome workarounds, if there are any).
...

(U)EFI is not BIOS. Boot-sectors like MBRs and "VBRs"/"PBRs" use BIOS interrupts, such as INTerrupt 0x13. This doesn't make sense under (U)EFI, since there is no BIOS.

However, some (U)EFI systems offer a "legacy mode" or "BIOS mode" where a BIOS is emulated or otherwise operational. This mode is most likely being engaged when you say you can boot from the USB device.

In fact, I think that on some systems, the BIOS is "actually there," and it is the (U)EFI that sits on top of it.

#3 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 17 October 2012 - 08:16 PM

@Sha0: Yes, I understand that. That's why I'm not relying on the MBR-based USB boot support (which may, in the future, be dropped as the world moves to UEFI) and why I *need* to figure out how to load a UEFI app w/out superseding BOOTMGR.

#4 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 17 October 2012 - 08:21 PM

@Sha0: Yes, I understand that. That's why I'm not relying on the MBR-based USB boot support (which may, in the future, be dropped as the world moves to UEFI) and why I *need* to figure out how to load a UEFI app w/out superseding BOOTMGR.

That might or might not be straight-forward: Find out if the internal HDD has a UEFI partition. If it does, you will find surprises inside. If it doesn't, how does it know to load BootMgr? Is it engaging "BIOS mode" to boot BootMgr, and BootMgr is returning the system to (U)EFI mode?

#5 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 17 October 2012 - 08:22 PM

The PC I'm working on most-definitely has an EFI partition, uses EFI to load Windows, uses the bootmgr.efi app, and loads the Windows UEFI app (winload.efi). It's UEFI from start to end.
I just can't inject the GRUB2 efi app in the middle.

#6 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 17 October 2012 - 08:34 PM

The PC I'm working on most-definitely has an EFI partition, uses EFI to load Windows, uses the bootmgr.efi app, and loads the Windows UEFI app (winload.efi). It's UEFI from start to end.
I just can't inject the GRUB2 efi app in the middle.

How about sharing a directory listing of the files inside the EFI partition?

#7 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 17 October 2012 - 09:01 PM

This hasn't anything to do with the system EFI. This is on the next level.

Anyway, I think I have the gist of it. The standard EFI format differs from the Microsoft EFI format. I created my own EFI sample app to confirm - the headers and package format match the grub2 EFI format. But they differ from the winload.efi format.
Only question is, how can I convert one to the other, I wonder...

Edited by Computer Guru, 17 October 2012 - 09:01 PM.


#8 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 17 October 2012 - 09:14 PM

This hasn't anything to do with the system EFI. This is on the next level.

If you're not interested in sharing the listing, then that's too bad, but best of luck to you.

Anyway, I think I have the gist of it. The standard EFI format differs from the Microsoft EFI format. I created my own EFI sample app to confirm - the headers and package format match the grub2 EFI format. But they differ from the winload.efi format.
Only question is, how can I convert one to the other, I wonder...

Maybe they're using signed UEFI images.

The initial program to be loaded is probably stored in NVRAM. Why don't you load GRUB first, then choose whether or not to load the Microsoft BootMgr?

#9 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 17 October 2012 - 09:21 PM

I am working within certain constraints which I have already specified. I wish I could go through GRUB2 first; I can't.

It's not (just?) a matter of signed UEFI. The subsystem flag for the winload.efi is 0x10, the subsystem flag for grub2.efi is 0xA. The PE headers are different.
If you don't mind, let's wait for someone who has experience with building UEFI apps.

Edited by Computer Guru, 17 October 2012 - 09:21 PM.


#10 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 18 October 2012 - 02:13 AM

I am working within certain constraints which I have already specified. I wish I could go through GRUB2 first; I can't.

How do you know this isn't like an "X Y problem"? If you'd share a bit more about your scenario, you might find out about alternatives in discussion. You haven't even shared what BCD entries you've tried, so nobody has any clue as to what BCD object type you have.

It's not (just?) a matter of signed UEFI. The subsystem flag for the winload.efi is 0x10, the subsystem flag for grub2.efi is 0xA. The PE headers are different.

The subsystem field is not a flag. WinLoad.efi's image type is IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION. Same as BootMgr.efi, MemTest.efi and others. GRUB's EFI build's image type is IMAGE_SUBSYSTEM_EFI_APPLICATION. Same with lots of other (U)EFI applications.

There is no reason why Microsoft's BootMgr should allow you to chain arbitrary images, since by the time you've booted it, you are no longer in a (U)EFI-only environment. As an example, the entry-point for these boot images might receive different, Windows-boot-manager-specific parameters instead of the usual (U)EFI ones, allowing for the applications to interface with the boot manager and, for example, its BCD and image-loading capabilities.

If you don't mind, let's wait for someone who has experience with building UEFI apps.

I installed and built Intel's UDK2010.UP3 some time ago. I have a git repository for EDK2. I have read the entire PE COFF specification a looong time ago (and still have it handy) and have read much of the UEFI 2.3 specification (and still have it handy) some time ago. I have built UEFI applications and run them under the Nt32 environment. Long ago, I have browsed the source code for rEFIt and the UEFI portions of gPXE and obviously the developer code in the UDK/tianocore.

If one of your goals was to offend someone with some experience trying to participate in discussion of another of your goals, congratulations on your success. Why don't you go and drink a glass of water?

#11 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 18 October 2012 - 02:26 AM

I apologize if I came off a little harsh, but it seemed that we were dancing around the problem rather than facing it head on.

The image type *is* determined first by a flag (bitfield, really) (and I didn't mean in the BCD, I meant in the PE header itself), then by the sections.
Both winload.efi and grub2.efi are PE files, the differences start w/ the subsystem flag in the Optional Header's additional fields structure. In fact, the very definition of the constant names you post are originally from the subsystem bitfield in the PE header:
http://msdn.microsof...9(v=vs.85).aspx

The BCD allows you to chain arbitrary applications in an MBR environment, I am hoping (perhaps against hope) that the same can be said for the UEFI-based environments as well.


Anyway, by hacking the GRUB2.EFI from IMAGE_SUBSYSTEM_EFI_APPLICATION to IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION, updating the rest of the PE header fields as needed, recalculating the checksum, and tacking on a driver signature pointer, I got the BCD to load the file, though now it is complaining about the signature so I'll try to take care of that.

Prior to this, I had tried (and possibly exhausted) just about all the methods of defining a EFI entry in the BCD:

Windows Boot Loader

-------------------

identifier              {a5d8c209-f0a6-11e1-aad7-9ef4fb42ac84}

device                  partition=C:

path                    usersUEFIDesktopgrub2.efi

description             GRUB2 EFI Test

osdevice                partition=C:

systemroot              windows

resumeobject            {fe4d9bc9-189c-11e2-b354-806e6f6e6963}



Real-mode Boot Sector

---------------------

identifier              {a5d8c20a-f0a6-11e1-aad7-9ef4fb42ac84}

device                  partition=C:

path                    UsersUEFIDesktopgrub2.efi

description             GRUB2.efi bootsector



Real-mode Application (10400009)

--------------------------------

identifier              {a5d8c20b-f0a6-11e1-aad7-9ef4fb42ac84}

device                  partition=C:

path                    UsersUEFIDesktopgrub2.efi

description             GRUB2.efi startup



Resume from Hibernate

---------------------

identifier              {a5d8c20c-f0a6-11e1-aad7-9ef4fb42ac84}

device                  partition=C:

path                    UsersUEFIDesktopgrub2.efi

description             GRUB2.efi resume



Inherited Settings (20200005)

-----------------------------

identifier              {a5d8c20d-f0a6-11e1-aad7-9ef4fb42ac84}

device                  partition=C:

path                    usersUEFIDesktopgrub2.efi

description             GRUB2.efi inherit memdiag



Inherited Settings (20200001)

-----------------------------

identifier              {a5d8c20e-f0a6-11e1-aad7-9ef4fb42ac84}

device                  partition=C:

path                    usersUEFIDesktopgrub2.efi

description             GRUB2.efi inherit fwbootmgr



Windows Boot Loader

-------------------

identifier              {a5d8c211-f0a6-11e1-aad7-9ef4fb42ac84}

device                  partition=C:

path                    UsersUEFIDesktopgrub2.efi

description             GRUB2.efi copy

locale                  en-US

inherit                 {bootloadersettings}

recoverysequence        {a5d8c203-f0a6-11e1-aad7-9ef4fb42ac84}

recoveryenabled         Yes

osdevice                partition=C:

systemroot              Windows

resumeobject            {a5d8c201-f0a6-11e1-aad7-9ef4fb42ac84}

nx                      OptIn


None of that mattered. BOOTMGR refuses to load IMAGE_SUBSYSTEM_EFI_APPLICATION.

Edited by Computer Guru, 18 October 2012 - 02:26 AM.


#12 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 18 October 2012 - 04:20 AM

I apologize if I came off a little harsh, but it seemed that we were dancing around the problem rather than facing it head on.

Thanks.

The image type *is* determined first by a flag (bitfield, really)

It's not a bit-field, nor a flag. It's a 2-byte field. I've been assuming you're talking about the PE optional header field at offset 0x44.

(and I didn't mean in the BCD, I meant in the PE header itself),

Yes, of course.

then by the sections.
Both winload.efi and grub2.efi are PE files, the differences start w/ the subsystem flag in the Optional Header's additional fields structure.

Not a flag.

In fact, the very definition of the constant names you post are originally from the subsystem bitfield in the PE header:
http://msdn.microsof...9(v=vs.85).aspx

Where are you reading "bit-field," exactly? The subsystems are mutually exclusive choices, so they are not represented as flags in a bit-field of flags.

The BCD allows you to chain arbitrary applications in an MBR environment, I am hoping (perhaps against hope) that the same can be said for the UEFI-based environments as well.

Maybe.

Anyway, by hacking the GRUB2.EFI from IMAGE_SUBSYSTEM_EFI_APPLICATION to IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION, updating the rest of the PE header fields as needed, recalculating the checksum, and tacking on a driver signature pointer, I got the BCD to load the file, though now it is complaining about the signature so I'll try to take care of that.

I doubt this approach will work. Please consider this: Each of the boot applications (like BootMgr and MemTest) can be compiled for either (U)EFI or for BIOS. I doubt that their source code is going to change much (via #ifdef or other preprocessing) before being compiled, so their entry-points are likely going to be the same function-type.

Why does this matter? Because (U)EFI dictates a particular entry-point function-type for EFI applications, along with certain parameters that will be passed. So assuming what I've said about compilation is correct, then BootMgr and MemTest aren't like EFI applications because their entry-points aren't like EFI applications.

Or, if they are, then Microsoft does something weird and their MemTest.Exe for BIOS platforms has an entry-point that conforms to the (U)EFI specification, and receives mysterious (U)EFI parameters in a non-(U)EFI world. That seems silly and thus unlikely.

Prior to this, I had tried (and possibly exhausted) just about all the methods of defining a EFI entry in the BCD:
...

It's not so exhaustive. I don't see type 0x10100001, for example.

Can you please share why you need to satisfy the constraints you've mentioned? Right now I'm assuming that you're a student in a classroom who wants to be able to use F8 to boot Linux on a classroom computer without any evidence of that capability being available to other users of the same classroom computer. Perhaps you're actually doing something more interesting that others here might be interested in, so it'd be wonderful if you shared a bit more.

#13 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 18 October 2012 - 07:59 PM

Can you please share why you need to satisfy the constraints you've mentioned?  Right now I'm assuming that you're a student in a classroom who wants to be able to use F8 to boot Linux on a classroom computer without any evidence of that capability being available to other users of the same classroom computer.  Perhaps you're actually doing something more interesting that others here might be interested in, so it'd be wonderful if you shared a bit more.


It is not good to jump to assumptions.
This is me: http://j.mp/EasyBCD

#14 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 18 October 2012 - 10:35 PM

If you don't mind, let's wait for someone who has experience with building UEFI apps.

It is not good to jump to assumptions.

Oh, I see. :dubbio:

This is me: http://j.mp/EasyBCD

Well that is certainly more interesting than what I assumed! Terrific product! It seems to help many people.

So, did type 0x10100001 work for you?

#15 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 19 October 2012 - 04:44 AM

It is not considered a valid state to have multiple {fwbootmgr} (fwbootmgr being the friendly name for 0x100001). It fails verification/validation.

The 0x20200001 you see is inherited from {fwbootmgr}.

#16 Sha0

Sha0

    WinVBlock Dev

  • Developer
  • 1679 posts
  • Location:reboot.pro Forums
  • Interests:Booting
  •  
    Canada

Posted 24 October 2012 - 08:09 AM

It is not considered a valid state to have multiple {fwbootmgr} (fwbootmgr being the friendly name for 0x100001). It fails verification/validation.

The 0x20200001 you see is inherited from {fwbootmgr}.

Sorry, I don't understand what you mean. I have a 0x10100001 entry and I don't see any issue with verification/validation. No matter, if it doesn't work, it doesn't work.

In other news, I've done some WinDbg (what fun!) recently and when I looked at what WinDbg reported as being the arguments passed to the MemTest.efi Boot Application, I did not see the expected-for-UEFI SystemTable parameter. This suggests to me that Boot Applications are unlike UEFI applications.

That also fits with the following theory: Even though there are different builds for each of the following tools, it's simplest if the entry-point for the function doesn't change... Why?:

For a real UEFI application, the application can use the SystemTable to eventually access the UEFI environment, including, let's say, a function to print to the screen. But in a non-UEFI environment, that function isn't available, so a program has to use some other way to print to the screen. But if we are writing the source code for a program, it would be unpleasant to have to write code for each case.

So if we keep the program entry-point the same and get the same parameters (if any) from BootMgr in both UEFI and non-UEFI environments, then there are fewer conditions for the compiler and the coder to be concerned with. One implication of this is that such Boot Applications will either rely heavily on calling BootMgr functions, or they will be almost entirely self-sufficient. It looks to me like they are more the latter than the former.

Consider all the build combinations:
  • 32-bit (IA32)
    • PC/AT
      • BootMgr
      • MemTest
      • WinLoad
      • WinResume
    • EFI
      • BootMgr
      • MemTest
      • WinLoad
      • WinResume
  • 64-bit (AMD64 or x86_64 or X64, whichever you like to call it)
    • PC/AT
      • BootMgr
      • MemTest
      • WinLoad
      • WinResume
    • EFI
      • BootMgr
      • MemTest
      • WinLoad
      • WinResume
(And who knows, maybe IA64, too!)

Anyway, it might be fun to try to write a Boot Application... Maybe one that can load a UEFI application if there's a UEFI environment. What do you think, Computer Guru?

#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 October 2012 - 09:09 AM

OT :ph34r:

Terrific product! It seems to help many people.

And uses neogrub! :dubbio:: (which is the "normal" grub4dos - possibly slightly edited) and points people to GRUB (legacy) for reference instead. :w00t:
Computer Guru, really, you could IMHO fix a little the page:
http://neosmart.net/...ay/EBCD/NeoGrub
ideally avoiding the re-naming of grub4dos - possibly giving some more credits to tinybyt, chenall and alia or at least point to the "right" documentation/links, basically this forum, the diddy's grub4dos help page and Steve6375's tutorials, besides the original grub4dos page by chenall.
Also, according to the GNU license, you should make available the source of neogrub....

:cheers:
Wonko

#18 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 24 October 2012 - 04:35 PM

Sorry, I don't understand what you mean. I have a 0x10100001 entry and I don't see any issue with verification/validation. No matter, if it doesn't work, it doesn't work.

In other news, I've done some WinDbg (what fun!) recently and when I looked at what WinDbg reported as being the arguments passed to the MemTest.efi Boot Application, I did not see the expected-for-UEFI SystemTable parameter. This suggests to me that Boot Applications are unlike UEFI applications.
...
Anyway, it might be fun to try to write a Boot Application... Maybe one that can load a UEFI application if there's a UEFI environment. What do you think, Computer Guru?


Then you've surpassed me. On my end, everything is on hold while I wait for Symantec to issue me a cross-signed certificate. Last time I needed one was years ago!
I do agree that would be a most interesting adventure, though I wonder if there's an easier way than recreating the UEFI info. Perhaps if we just identify where BOOTMGR stores the UEFI table in its own memory space and simply expose that to ourselves and pass it on to any UEFI apps being loaded?

I also don't think IA32 EFI has seen the light of day other than on Macs? You'd know better, given the nature of the posts on this forum...


OT :ph34r:


And uses neogrub! :dubbio:: (which is the "normal" grub4dos - possibly slightly edited) and points people to GRUB (legacy) for reference instead. :w00t:
Computer Guru, really, you could IMHO fix a little the page:
http://neosmart.net/...ay/EBCD/NeoGrub
ideally avoiding the re-naming of grub4dos - possibly giving some more credits to tinybyt, chenall and alia or at least point to the "right" documentation/links, basically this forum, the diddy's grub4dos help page and Steve6375's tutorials, besides the original grub4dos page by chenall.
Also, according to the GNU license, you should make available the source of neogrub....

:cheers:
Wonko



EasyBCD was using Grub4Dos way before there was a rebootpro and before grub4dos was hosted on boot-land/rebootpro. I only recently became aware of the grub4dos subforum here, I had been exclusively using tinybit's Chinese site, and when that went down, chenall's google code repo. I have no idea who Steve6375 is.

The source *is* most definitely available, EasyBCD strives to remain compliant and respect all licenses: http://neosmart.net/opensource/ (Link is in the installation and in the LICENSE file in the EasyBCD Program Files folder), stating:

Our loudest and most-heartfelt gratitude goes out to the developers of GRUB and GRUB4DOS who have both worked long and hard to bring a powerful and flexible bootloader to the world of open source. EasyBCD uses an internal copy of GRUB4DOS to help chainload certain operating systems and script boot-time tasks.



I think that is clear enough?

EasyBCD's about window also thanks grub4dos. The page you linked to does the same:

NeoGrub is made possible thanks to the efforts of the Grub4Dos project and their work on a Windows-compatible GRUB bootloader.



NeoGrub did not use to be just grub4dos, I had added a few extra commands that were not available in grub4dos. It is common courtesy *not* to use the same name for a fork as the upstream code name. This was all done w/ the knowledge and help of tinybit and bean123 back in the day (are they active here on this forum?). tinybit later added some features to do what I needed it to do, and I moved back to the unforked code.

To put it bluntly: EasyBCD/NeoGrub predates everything you've mentioned. By a lot. To get a feel of just how long ago all this was, you can take a look at the EasyBCD changelog: NeoGrub was added to EasyBCD in December of 2006. No one has approached me to express any dissatisfaction whatsoever in all that time, so please don't assume I'm trying to rob anyone of their credit here.

Edited by Computer Guru, 24 October 2012 - 04:42 PM.


#19 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 October 2012 - 06:12 PM

No one has approached me to express any dissatisfaction whatsoever in all that time, so please don't assume I'm trying to rob anyone of their credit here.

I never said that you "robbed" credit, I said how IMHO there could have been more credit given to the right guys, and - JFYI - this Forum is the UNofficial (but "Western official") grub4dos forum since July 2006, i.e. more or less when you started developing EasyBCD (and seemingly BEFORE you added Neogrub), and how it is mainly senseless pointing to the GRUB legacy documentation (which misses most if not all the commands normally used in grub4dos).

Currently the referred to page is not "current", at least I have an EasyBCD 2.1.2.exe that has NOT any Neogrub, but it contains a "normal" grldr and grldr.mbr, more specifically a GRUB4DOS 0.4.5b 2011-11-27 UNmodified (as BTW clearly stated in the license file :)):

This EasyBCD distribution ships with standalone components that are only allowed for use by licensed customers of Microsoft Windows ™:
* bin/bcdboot.exe
* bin/bcdedit.exe
* bin/bootsect.exe

This EasyBCD distribution ships with standalone components (Grub4Dos and UltraDefrag) that are separately licensed under the terms of the GPLv2 license.

The GPLv2 license, the full text of which is reproduced below, applies exclusively to the following files:

Grub4Dos:
* profiles/grldr
* profiles/grldr.mbr

UltraDefrag:
* bin/udefrag.dll
* bin/udefrag.exe
* bin/udefrag-kernel.dll
* bin/zenwinx.dl

Source code for these projects is freely available at http://neosmart.net/opensource/ in compliance with the GPLv2.


Whether you actually have MS permission to redistribute NON-redistributable files, is another matter, and essentially a SEP for me.

What the later version (freeware for registered members/Commercial) contains I cannot say.

What I am saying is that right now the page:
http://neosmart.net/...ay/EBCD/NeoGrub
seems either obsolete, incorrect (or both) AND points to the "wrong" GRUB legacy related pages.

Additionally the address:
http://neosmart.net/opensource/
resolves to a Login page:
http://neosmart.net/...splay/FOSS/Home
which though cannot say if complies with the GPLv2, at least it sounds a lot like NOT being "open".

:cheers:
Wonko

#20 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 24 October 2012 - 06:30 PM

this Forum is the UNofficial (but "Western official") grub4dos forum since July 2006, i.e. more or less when you started developing EasyBCD (and seemingly BEFORE you added Neogrub)


It definitely didn't come up in Google searches back then, and the "western official" support forums for grub4dos were definitely ubunutforums, where tinybit & co. were actively developing grub4dos. This is all besides the point, anyway. We're not squabbling about representation of rebootpro, after all.

Currently the referred to page is not "current", at least I have an EasyBCD 2.1.2.exe that has NOT any Neogrub, but it contains a "normal" grldr and grldr.mbr, more specifically a GRUB4DOS 0.4.5b 2011-11-27 UNmodified (as BTW clearly stated in the license file ):


Yes. How does that make the page not current? 2.1.2 is from Nov. 28, 2011. The bundled grub4dos is exactly one day old. I already explained to you that NeoGrub *now* is stock grldr. So, yes, you'll find the stock and unmodified grldr and grldr.mbr there. The source for that build is viewable in the archives for the EasyBCD open source page: http://neosmart.net/...pageId=27131997

Obviously I'm not going to keep the *main*/most recent EasyBCD open source page pointing to the GRUB4Dos distribution from a 2 year old EasyBCD build. EasyBCD 2.1.2 is no longer distributed by us, EasyBCD 2.2 is, and that's what the associated source downloads on current open source page are for.

What I am saying is that right now the page: http://neosmart.net/...ay/EBCD/NeoGrub seems either obsolete, incorrect (or both) AND points to the "wrong" GRUB legacy related pages.


EasyBCD is a one-man development project and two other part time volunteers helping out with the support. That NeoGrub page is particularly old, and predates EasyBCD 2.0. What of it?

EasyBCD's use of NeoGrub is *not* to take advantage of all the really cool grub4dos features, but rather to provide a copy of GRUB legacy that can be installed and configured from a NTFS partition. For our users, the official grub documentation is perfectly sufficient. See http://j.mp/NeoGrubLinux

Again, this is all besides the point. Our users use particular features of Grub4Dos, we have documentation tailored to their needs. I don't see what that has to do with anything.


Additionally the address:
http://neosmart.net/opensource/
resolves to a Login page:
http://neosmart.net/...splay/FOSS/Home
which though cannot say if complies with the GPLv2, at least it sounds a lot like NOT being "open".

:cheers:
Wonko


That was apparently a permissions issue introduced in the latest update. Thanks for bringing it to my attention - fixed.

Check again, you'll see that it is indeed 100% open: the source is there, the attributions are there, etc.


What the later version (freeware for registered members/Commercial) contains I cannot say.


EasyBCD does not require registration. It is a 100% free download, sharing your email w/ us for our mailing list is optional. As it says on the site:


Hi there! We're glad you're downloading EasyBCD and we'd like to give you a heads-up when a new version becomes available. Please enter your name and email below; we promise not to bug you, and we'll never, ever give your email out to anyone. You can leave it blank if you like, but we'd really like to stay in touch!


Edited by Computer Guru, 24 October 2012 - 06:38 PM.


#21 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 October 2012 - 06:56 PM

EasyBCD is a one-man development project and two other part time volunteers helping out with the support. That NeoGrub page is particularly old, and predates EasyBCD 2.0. What of it?

Nothing :), as said that page
http://neosmart.net/...ay/EBCD/NeoGrub
is either obsolete, incorrect or both, nothing more, nothing less.
Most probably noone pointed this fact to you, now I have.

That was apparently a permissions issue introduced in the latest update. Thanks for bringing it to my attention - fixed.

Check again, you'll see that it is indeed 100% open: the source is there, the attributions are there, etc.

Very good. :)
Though it is pointing still to the obsolete grub4dos sourceforge site, and the source code is locally hosted, so that anyone looking for the "real thing" (the current chenall grub4dos site):
http://code.google.c...ub4dos-chenall/
will never get there (or at least not easily)

EasyBCD does not require registration. It is a 100% free download, sharing your email w/ us for our mailing list is optional. As it says on the site:

Good :), though personally (and I presume that a few people will also do the same) I will never press a "Register" button if I don't want to register, to be later said that registration is optional, it is a case of what I personally consider "deceiveing" methods.

:cheers:
Wonko

#22 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 24 October 2012 - 07:09 PM

Nothing , as said that page is either obsolete, incorrect or both, nothing more, nothing less.
Most probably noone  pointed this fact to you, now I have.

Thank you. I'm aware parts of the documentation are out of date, just haven't had time to take care of that.


Good , though personally (and I presume that a few people will also do the same)  I will never press a "Register" button if I don't want to register, to be later said that registration is optional, it is a case of what I personally consider "deceiveing" methods.

I'm of the opposite opinion. To press a button that says "download now" then be asked to register is deceiving. Being asked to register, than having the option of not registering is the opposite and a good thing.

Though it is pointing still to the obsolete grub4dos sourceforge site, and the source code is locally hosted, so that anyone looking for the "real thing" (the current chenall grub4dos site):
http://code.google.c...ub4dos-chenall/
will never get there (or at least not easily)


That is not the link to the source code (as you mention), it is the closest thing that I could find to the "official grub4dos project page". I don't know what to put there, as there seems to be zero central organization for grub4dos, or perhaps it exists but only on the Chinese web. I'm not looking for a link to source code nor a link to support forums, more a link to the actual G4D project page that explains what it is and what it does and who is behind it. Because I'm not trying to rob anyone of credit.

----

All that said, I'm not a guy that discourages advice. Give me your suggestions for what you feel would be improvements to the NeoGrub page, and I'm willing to work them into there.

At the end of the day, the whole point of FREE software is to attract more users and make their lives easier. I want YOU to be able to recommend EasyBCD, not say "stay away from it" or "I don't recommend it."

What would that take? Also, what is your affiliation with G4D, if any?

So, tell me. Instead of sourceforge, where do I link? Again, not looking for support forums but for a project info page.
I'm linking to the legacy grub4dos documentation because the last time I checked, that was the most complete reference. G4D documentation said "look at <link to official grub legacy docs> for more info on this...." while primarily focusing on g4d features. Is diddy's g4d page on the old boot-land the recommendation? Or is it no longer maintained? You see my conundrum? No official pages anywhere.

Guides. You say Steve6375. All I find on Google are people talking about his guides, not his guides. And some YouTube links (and I refuse to link to YouTube tutorials, just as a matter of principle).

I am not the enemy. I am a friend to the open source community and have contributed to open source projects, including sharing some EasyBCD code that for a few years was the basis of Wubi's bootloader installation in Ubuntu. My GitHub page is full of NeoSmart contributions and forks of other projects w/ minor improvements.

I'm currently in contact with the developer of Grub2Win for the possibility of integrating that - at his request!

Heck, if you want a login to the Wiki so you can update and/or maintain the Linux and G4D-related stuff, let me know. Do you see what I'm saying here? EasyBCD is a tool that is built on the shoulder of giants. Aside from our own (extensive) tech in EasyBCD, we sometimes adapt existing tools into easier to use forms, at the cost of sacrificing some extensibility. Not everyone is looking for source code and configuration files, a vast majority of (esp. Windows') users just want a point and click solution, which EasyBCD gives them and then some. It is a complement to these solutions, not a rival/alternative.

#23 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 October 2012 - 08:02 PM

I am not the enemy. I am a friend to the open source community and have contributed to open source projects, including sharing some EasyBCD code that for a few years was the basis of Wubi's bootloader installation in Ubuntu. My GitHub page is full of NeoSmart contributions and forks of other projects w/ minor improvements.

I am pretty sure you are not an enemy, let alone "the" enemy :).
The point is that the development of grub4dos is actually carried by chenall on the mentioned page:
http://code.google.c...ub4dos-chenall/
there is NO "official" project page (in the sense of an English project page), the diddy's guide is also becoming obsolete (but still it contains most of the enhancements of grub4dos over GRUB legacy),simply "keeping track" of the various sites that one time or the other hosted the project (since the sourceforge page was "abanodned" in 2006 has been already an issue).
If you take some time here in the grub4dos forum you will see how many people comes here with an obsolete version of grub4dos or with obsolete (in the sense of replaced by newer, "better" approaches) menu.lst/settings and what not.
So, if you want to point to a project page, you should IMHO point to the project page ;): http://code.google.c...ub4dos-chenall/
If you want to point to some documentation (as said now becoming partially obsolete, in the sense that newer releases of grub4dos have added features) you should any way point to diddy's grub4dos help pages:
http://diddy.boot-la...os/Grub4dos.htm
If you want to point people to an English support forum (normally with latest news and a number of examples) you will have to link to reboot.pro: http://reboot.pro/forum/66/
If you want to point to "advanced" or "latest" tutorials making use of grub4dos, you will have to link to Steve6375's tutorials, which are here:
http://www.rmprepusb.com/

This is what is "available" AFAIK.

My personal opinion on EasyBCD is not at all relevant, I don't use it and won't probably never actually use it, but this is not because of any actual "issue" within the program, I don't like the general approach (which doesn't mean that the program is not working well or that it is not useful to a lot of people :)), simply it doesn't fit my "vision".

I tend to list it as a possibility, though (example):
http://reboot.pro/7476/

I'm of the opposite opinion. To press a button that says "download now" then be asked to register is deceiving. Being asked to register, than having the option of not registering is the opposite and a good thing.

You see, the good thing :thumbup: about opinions are that they are free (both as in freedom as in free beer), but now you know why you lost at least one potential user, now it's up to you seeing if the number of people that share my opinion about NOT clicking on a button with "Register" on it is relevant or not (and which percentage of your potential user base they represent - possibly it is just me).

About the Neogrub pages, since Neogrub is not shipped anymore with EasyBCD, what about removing it and/or change it specifying how that was old info that doesn't apply anymore and that you are using grub4dos in recent/current versions?

For the record, I have no particular "affiliations" with grub4dos, I believe it is a great little project, and try doing my best (and within my limits) to support it.


:cheers:
Wonko

#24 Computer Guru

Computer Guru

    Newbie

  • Members
  • 17 posts
  •  
    United States

Posted 24 October 2012 - 08:27 PM

there is NO "official" project page (in the sense of an English project page), the diddy's guide is also becoming obsolete (but still it contains most of the enhancements of grub4dos over GRUB legacy),simply "keeping track" of the various sites that one time or the other hosted the project (since the sourceforge page was "abanodned" in 2006 has been already an issue).

So we are of like mind on this problem.

The point is that the development of grub4dos is actually carried by chenall on the mentioned page:
http://code.google.c...ub4dos-chenall/


Yes, that is where I get grub4dos builds from. Will update the sourceforge link to that one instead.

About the Neogrub pages, since Neogrub is not shipped anymore with EasyBCD, what about removing it and/or change it  specifying how that was old info that doesn't apply anymore and that you are using grub4dos in recent/current versions?


The reason it is still called NeoGrub is for legacy reasons. We have users who were using "NeoGrub" for years, to tell them EasyBCD no longer has NeoGrub but has "Grub4Dos" would confuse them and obviate all our old documents and guides, as well as thousands of web resources from 3rd parties on the matter. I have no problem updating the NeoGrub page to say that NeoGrub is now synchronized with and identical to the chenall Grub4Dos releases.

#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13230 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 October 2012 - 09:35 AM

The reason it is still called NeoGrub is for legacy reasons. We have users who were using "NeoGrub" for years, to tell them EasyBCD no longer has NeoGrub but has "Grub4Dos" would confuse them and obviate all our old documents and guides, as well as thousands of web resources from 3rd parties on the matter. I have no problem updating the NeoGrub page to say that NeoGrub is now synchronized with and identical to the chenall Grub4Dos releases.

Well, then - and if I may - you should go back the NST path, as most of the guides/web pages I have seen assume that menu.lst, is actually in C:NST1menu.lst, example:
https://wiki.archlin...B2#With_Windows
or write somewhere in BIG LETTERS how that path is not anymore used. :unsure:

Sorry for the OT, but I think that something useful has come out of it anyway. :smiling9:

Back to topic, if I get this whole thing right, the issue is that you can from GRUB2 (EFI) boot the Windows EFI files (but not viceversa :() and what Sha0 proposed is to have an intermediate tool that can be loaded from the Windows EFI files and that will load the GRUB2? :dubbio:


:cheers:
Wonko





Also tagged with one or more of these keywords: efi, uefi, chainloader, grub2, bcd, bcdedit

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users