Jump to content











Photo
- - - - -

Chainload directly to WinLoad.exe

grub4dos windows pe

  • Please log in to reply
6 replies to this topic

#1 ZEE

ZEE

    Frequent Member

  • Advanced user
  • 104 posts
  •  
    Portugal

Posted 07 December 2013 - 08:50 PM

Hi nice people...

 

Again I'm having strange ideas for networked things...

 

My question is

 

? can I chainload (chainloader \Windows\system32\winload.exe) directly to winload.exe (Win7/8, PE3/4)

without calling bootmgr...

 

This way I could get rid of the infamous /boot folder and boot partition (the partition already solved) ;-)



#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 December 2013 - 11:52 AM

Again I'm having strange ideas for networked things...

Why not bypassing also Winlolad.exe and directly load the Kernel and Hal? :unsure:

 

I mean, if you have random ideas, think big at least. :frusty:

 

:cheers:

Wonko


  • ZEE likes this

#3 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 08 December 2013 - 09:06 PM

Only bypassing bootmgr seems complicated enough. Good luck coding the new bootmgr. It will certainly require a decent amount of coding time (not to mention the need to first completely and fully reverse engineer bootmgr/winload.exe in order to understand what to code).

 

What exactly do you want to achieve by this?



#4 ZEE

ZEE

    Frequent Member

  • Advanced user
  • 104 posts
  •  
    Portugal

Posted 09 December 2013 - 03:06 PM

Ok... ok... I can see you 2 are very amused with this one (wonko and joakim)... :loleverybody: ...

Well... to cut the story short... I'm having a bit of trouble installing Windows 7 in a Laptop that came with Windows 8

Issues with UEFI bios and certificates...

 

I was fibbling with BOOTICE bcd editor and manage to boot with PE3 (boot.sdi+boot.wim)...

 

My question objective was to see if anyone has already try to call thw winload.exe directly from grub4dos...

maybe doing some environment tweak before...

This way we could skip BOOTMGR... :clapping:

 

Welll I'll investigate this as soon as I have some time... :raygun:

And put here some results...

 

Stay well... :chair:


Edited by ZEE, 09 December 2013 - 03:07 PM.


#5 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 December 2013 - 03:33 PM

ZEE :),

you have to understand how you cannot "invent" something out of thin air, and you should try documenting a bit yourself before going astray with fantasy.

 

The grub4dos right now can chainload a bootloader (like NTLDR or BOOTMGR) because it can act as a replacement of the code contained in a "normal" bootsector (i.e. something like 300 bytes of machine code).

This code simply sets a few parameters and then calls the loader.

Even that is (was) not easy at all to understand and replicate with different code.

 

A NT system loader  like BOOTMGR has more or less in a single .exe a "real mode" operating system (not entirely unlike DOS) and facilities/tools to parse both plain text and Registry hives, it is not something that can be re-written from scratch easily.

 

The good guys @ReactOS are working on writing the FREELDR (which aims to be a replacement for the much simpler NTLDR) since YEARS (and believe me there are among the ReactOS programmers some really good and good at it guys).

It *seems* (but it is not documented clearly) that they managed to boot experimentally a Server 2003 with NTLDR.

 

:cheers:

Wonko


  • ZEE likes this

#6 ZEE

ZEE

    Frequent Member

  • Advanced user
  • 104 posts
  •  
    Portugal

Posted 09 December 2013 - 07:11 PM

Hi, Wonko...

 

That's is very much about the answer I want to have... ?it can be done ?will it work ?if not... why

 

Thanx for share your knowledge... I'll jump to ReactOS site to see what they are doing with the FreeLdr..

 

;-)



#7 Sha0

Sha0

    WinVBlock Dev

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

Posted 15 December 2013 - 03:12 PM

With the introduction of support for (U)EFI, BootMgr helps to abstract the difference between BIOS and (U)EFI. For example, here are two sequences:
  • BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows
  • 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> Windows
WinLoad expects a certain environment (including API) to be present. BootMgr takes care of this, so [almost] the same WinLoad program will work in either environment.

In fact, (U)EFI defines a method for storing and fetching boot parameters, so BootMgr's BCD covers that same purpose, regardless of BIOS/(U)EFI.

But beyond BIOS and (U)EFI differences, BootMgr lets you make a "boot choice," whereas WinLoad boots a particular operating system that it knows how to boot.

Depending on how much of an environment WinLoad expects to be present, it might be possible to invoke WinLoad directly. Michael Brown's wimboot invokes the BootMgr PE[1] directly, so it could invoke WinLoad directly, except that WinLoad probably wants more of an environment. You could try it!

[1] Not to be confused with the BootMgr which GRUB4DOS and Syslinux' chain.c32 can invoke. That BootMgr includes a stub which knows how to invoke the embedded BootMgr PE.





Also tagged with one or more of these keywords: grub4dos, windows, pe

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users