EFI Boot: Two independently bootable physical hard drives?

Question

Im trying to create a WIC codec in c. As far as i am concerned, the functions that the different interfaces implement, are recognized and called by them having a specific name.

In this case i am trying to implement the function GetPixelFormat from the IWICBitmapSource interface. This i am trying to do by initializing the function in a header, then defining the body in a source file, and implementing this into an interface with the DECLARE_INTERFACE_ macro.

The problem being that the GetPixelFormat function from the BitmapSource interface shares it's name with the function GetPixelFormat from the wingdi.h file, which is an include in wincodec.h, which is an include i need to create the function in the first place.

So to sum up my question:

Do the functions to be included in the codec interfaces require the same name as the names of the functions in the original WIC interfaces, e.g. does my GetPixelFormat function need to have this name to be recognized as the WIC function GetPixelFormat?

and

if yes : How do i implement this in a way that wont be disturbed by the original implementation?

if no : How do i implement the function into an interface in such a way that WIC will recognize the function as being the GetPixelFormat function?

Example of implementation in headerfile:

#undef INTERFACE
#define INTERFACE MgfFrameDecoder
DECLARE_INTERFACE_(INTERFACE, IUnknown) {

    BEGIN_INTERFACE

    STDMETHOD(QueryInterface)  (THIS_ REFIID riid, void **ppv) PURE;
    STDMETHOD_(ULONG, AddRef)   (THIS) PURE;
    STDMETHOD_(ULONG, Release)  (THIS) PURE;
    STDMETHOD(CopyPalette) (THIS_ IWICPalette* pIPalette) PURE;
    STDMETHOD(CopyPixels) (THIS_ const WICRect* prc, UINT cbStride, UINT cbBufferSize, BYTE *pbBuffer) PURE;
    STDMETHOD(GetPixelFormat) (THIS_ WICPixelFormatGUID* pPixelFormat) PURE;
    STDMETHOD(GetResolution) (THIS_ double* pDpiX, double* pDpiY) PURE;
    STDMETHOD(GetSize) (THIS_ UINT* puiWidth, UINT* puiHeight) PURE;
    STDMETHOD(GetColorContexts) (THIS_ UINT cCount, IWICColorContext** ppIColorContexts, UINT* pcActualCount) PURE;
    STDMETHOD(GetMetadataQueryReader) (THIS_ IWICMetadataQueryReader * *ppIMetadataQueryReader) PURE;
    STDMETHOD(GetThumbnail) (THIS_ IWICBitmapSource * *ppIThumbnail) PURE;

    END_INTERFACE
};

Example of implementation in source file:

static HRESULT STDMETHODCALLTYPE GetPixelFormat(WICPixelFormatGUID* pPixelFormat) {

pPixelFormat = &GUID_WICPixelFormat32bppBGRA;

return S_OK;

}

Solution

First, you must be very clear about whether you're booting in BIOS/CSM/legacy mode or in EFI/UEFI mode. Mixing boot modes is also possible on most computers, but greatly complicates matters in most cases, so I recommend strongly against a mixed-mode setup. Your description is not entirely clear, but it sounds like you're using EFI-mode booting. Running the Boot Info Script, posting the RESULTS.txt file that it generates to a pastebin site, and posting the URL for the document here would clarify matters.

Assuming you're doing an EFI-mode boot, I recommend you read a bit to understand the EFI boot process. Two documents I've written may help:

• My Linux EFI-mode installation page is a general tutorial on EFI-mode installation. It won't directly answer your questions, but it provides some basic information that should help you understand what's going on.
• My EFI Boot Loaders for Linux page covers EFI boot loaders for Linux. Its Basic Principles sub-page is particularly relevant to building an understanding.

Basically, you want to create a separate EFI System Partition (ESP) on each disk and set up boot managers and/or boot loaders on both of those ESPs. Given your needs, my rEFInd might be a good choice because it builds its OS list at boot time, so it will omit loaders for any OS on a disk that's become unavailable. You could use something else, though, and just ignore entries that you know will be non-functional.

One caveat: EFIs have their own boot managers, which maintain a list of boot entries in NVRAM. Some EFIs will "helpfully" remove boot entries that are invalid. The result is that boot entries for a disk that you've removed may disappear permanently, necessitating adding them back. This can be very annoying in some cases. The usual solution is to put a boot manager in the fallback position (EFI/BOOT/bootx64.efi on the ESP). Most EFIs will recognize this and give you an option to boot it.

Comments

[kobaltz]

Do the two installations have different data on them or are they basically mirrors of each other? If they're mirrors then you should look into a RAID1. Though, a RAID1's size will only be as big as your smallest drive.

[adrelanos]

Do the two installations have different data on them or are they basically mirrors of each other? - Different data. I want them to be totally independent.

[Hans Passant]

No, names don't matter. The DECLARE_INTERFACE macro declares a struct to represent the v-table of the interface, the members are function pointers. Missing in the post, in the implementation you have to define the struct, that's where you initialize the function pointers to point to the functions. Function names can thus be anything. Be sure to read and understand this article.

[adrelanos]

I don't have Windows and that tool is according to wikipedia windows-only.

[Ramhound]

@adrelanos Grub2 has similar tools built into it. You should update the question to reflect the fact you don't have access to a Windows installation

[adrelanos]

Updated question. grub2 might have it, I guess that is likely, but how to archive what I asked in my question?