Jump to content

getwired

Member
  • Posts

    231
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

About getwired

getwired's Achievements

0

Reputation

  1. getwired

    WinPE 2.0

    If you disable the compression, you should generally find that it can keep up with, if not exceed, the speed of Ghost (or PQDI - which Ghost is now based upon). It's apples to oranges to compare a WIM doing compression with a Ghost or PQDI image that is simply picking up sectors (and yes, throwing out the blank ones, as PQDI can do).
  2. XImage has few dependencies. It should not require any specific version of WinPE, and should work from a 32-bit WinPE to capture 64-bit images or vice-versa.
  3. Bart isn't exactly a lawyer, and his "license" kind of bypasses the EULA that comes with Windows AND the one that would be on a properly licensed copy of WinPE... So...
  4. To justhink: Unless you have permission to include junction in there, and I doubt you do, you are violating Sysinternals' copyright which accompanied the version of junction you downloaded.
  5. getwired

    WinPE 2.0

    Sigh... it's MASSIVE...
  6. getwired

    WinPE 2.0

    winpeshl is at a much higher level. The WIM format at that point is read by the actual Windows setup/boot loader. Winpeshl is much more like userinit is in Windows normally. In fact winpeshl performs several of the same tasks.
  7. getwired

    WinPE 2.0

    It's not released with it - it's included in it. Also, that version of WinPE is intended just for use by setup - odds are it's missing some features - and it doesn't include any of the tools you would need to rebuild it.
  8. The WIM has to be read at several levels.. The first issue you saw is a generic registry read failure. That's why copying setupreg.hiv out made it make it farther in the boot process. If you remove setupreg.hiv from a standard WinPE CD layout and boot - you'll get the same error. If the filter isn't loading, it can't see in the WIM. Even if the first loader sees into it, that doesn't guarantee the second filter has started. You don't need to give me broad elaborate answers... just the basics. I co-invented the WIM-boot technology - and though it has changed somewhat since I left Microsoft, the underpinnings have not - and the errors you are getting are pretty much the standard ones we worked through as we built it.
  9. There's something missing in your process then. The problem you are seeing is that your loader isn't able to see into the WIM at all. The next step in the boot process is loading setupreg.hiv. By moving it out, you've just made the boot process get one step farther - the registry is loaded, but then the kernel barfs - most likely because the next component that the kernel is looking to load can't be found... I'd be VERY surprised if it is anything else. Really.
  10. What build is the XImage you are using? If it's not the same as the version of the loader you are using, this would be quite expected. I also don't believe that error is occurring for the reason you think it is.
  11. If you use the Windows Server 2003 SP1 version of the OPK and Windows Server 2003 SP1 (X64) as your source, this will "just work".
  12. You'll probably have better luck in a BartPE related forum, as that is where people who enjoy cramming stuff back into PE tend to haunt.
  13. That is normal. It must go through both phases. Stupid, I know. But setup couldn't be redesigned in Whistler to do it more logically.
  14. Grab a copy of regmon (www.sysinternals.com) and see what it's doing... you are in uncharted waters, as WinPE was not designed or tested to have the MMC running on it.
  15. Unlike video, there is no "universal" driver for audio cards at the present time. You need to either find drivers for that card, or use a card with X64 drivers available.
×
×
  • Create New...