can we use WIM for XP/2003 based projects? External links Options

[was_jaclaz]

Just found this (SHAREWARE):
http://www.winmount.com/

I cannot test it right now, due to a problem I have with my Registry ( I guess I fiddled with device drivers one time too much ), but it seems like it can mount a .wim file using a different approach, i.e. a (fake, I presume) generic USB SD Card Reader driver.

Maybe one canget something out of it?

jaclaz

[ktp]

Step 4 & 5 are what I wanted to do using grub4dos as in this thread:
http://www.boot-land.net/forums/grub4dos-e...rror-t3287.html

[was_jaclaz]

@ktp
Well, NO , you were/are trying using a RAW image, felix is talking about a .WIM one.



jaclaz

[Nuno Brito]

Can't grub4dos "learn" how to read WIM images?

The WIM format might be well documented on the 7zip source code and with some luck we'd be able to directly boot any WIM image straight from DOS on any boot device..

Maybe tinybit finds some available - this would an interesting option don't you think?

[felix]

From what i know Longohrn 4xxx builds use the WIM Beta 1 format for deployment.
The best part is that the Longhorn 4xxx builds are based on NT 5.1 codebase (WinXP NTLDR).
Just like Vista WinPE (1.5 or 1.6 i can't remember) has to be used to deploy the OS image.
The downside of WIM Beta 1 is that it didn't support mounting/unmounting operations.
Creating a new INSTALL.WIM and replacing the old one solves this.
Longhorn's Ximage.exe not Vista's ImageX.exe can create Beta 1 WIMs.
The problem is "faking" the bootloader to recognize the changed image.
Also forgot to mention that Longhorn build 4xxx has been abbandoned by MS so if they don't want it we can put it to good use.

@jaclaz
With Vista "maybe" its possible but we should study how its boot procedure works and how can WIM Mini Filter or Wimgapi.dll help.
I know Winmount v2.1.5.
Its good but there is a catch : right now archives are mounted as removable drives with FAT32 FS.
Plus its kinda slow (reading from them) if archives are heavily compressed (7z / RAR / WIM / CAB).Think about it on a DOS envoirnment.

@Nuno
WIM uses a more advanced CAB archive format with some extra data on the header.Thats why 7zip can extract them.It reads CABs data structure.
Latest Uniextract 1.6 beta uses this method too to extract WIMs.
Uniextract 1.6 beta changelog
If only grub could read the CAB structure and extra info contained in WIM without extracting it but mounting it as a drive instead...

The only possible way i see right now is Longhorn's build 4xxx bootloader.I'll try to find out more.

[Nuno Brito]

Hi Felix!

Your help on this matter is very welcome - I would like to understand more about this matter myself.

Do you know any documentation that details what is written in the header of these WIM files?

-------

Whenever possible it would be wise to avoid boot loaders from any longhorn simply because MS won't likely consider it abandonware and let us distribute these binaries to public domain.

On the WinRoot project discussion topic we're discussing a complete replacement of the XP/2003 boot loader files using open source versions from tinykrnl - AeroXP is bringing these binaries back into the surface again and it's a promissing work.

With some luck this could lead to start creating a new boot loader from scratch instead of hacking or borrowing the current boot loaders from other OS's.

Adding WIM support would then be a good possibility if merged with the likes of a program like grub4dos to manage several compressed images inside the same media using only our own custom apps.

[felix]

I didn't notice the WinRoot project.
And yes you are right its better not to mess with MS especially on such delicate matters as OS binaries.
I'll lend my help whenever possible.

[was_jaclaz]

I think we need to clarify this point, the following are just my ideas, that, though proved by countless (failed) attempts to do otherwise, may also be completely wrong :
Here everyone seem (ktp and Nuno) to miss this fundamental point:
a. NT based systems need a (miniport) driver to access the boot device.
b. this (miniport) driver needs to be invoked in the early stage of booting by the OSLOADER.EXE contained into NTLDR/SETUPLDR.BIN (cannot say - I really have NO idea - how Vista BOOTMGR works)
c. the OSLOADER.EXE can load this driver from either info gathered from BIOS (and opportune BOOT.INI or WINNT.SIF + Registry settings), this is the case of Dietmar's way to boot XP from USB on motherboards which BIOS support USB booting and (partially) euhenio's RAMDISK way, or from internal somewhat "hardcoded" structures, and this is the "other half" of euhenio's way and the "normal" RAMDISK PE boot.

If the above is true, there is NO sense in just making grub4dos (or another bootloader) be able to mount and access .wim images, we would be in the same EXACT situation in which we are now with grub4dos, Isoemu or Avlgomgr with .iso or RAW .img, the bootloader can access and boot allright these kind of images, AS LONG as they comtain a DOS based system (that uses "blindly" BIOS info to access the mounted image) or a Linux based one (for which the needed driver is "by default" loaded/started or whatever - knowing very little on how Linux actually works, my guess is that this is due to the Unix-like concept of "everything is a file").

The only ways to work around these problems are, as I see it:
1) "Nuno's" idea of rewriting from scratch not an actual bootloader (like grub4dos), but rather an "OSloader" (NTLDR and SETUPLDR.BIN are at the same time bootloaders AND OSloaders)
2) Find a way to somehow make existing NTLDR/SETUPLDR.BIN "hook" another driver instead of those "suggested" by BIOS, in either of two ways:
2.a by writing an extended BIOS stack to add to grub4dos (as an example) AND writing a (miniport) driver capable of accessing RAW image files.
2.b by writing a (miniport) driver, calling it RAMDISK.SY_/RAMDISK.SYS and make use of the already existing loading capabilities of NTLDR/SETUPLDR.BIN
3) "felix's" idea to "abandon" RAW images in favour of .wim images and use BOOTMGR, though (having no experience with Vista) I am afraid that something similar to steps 2.a or 2.b above will be nonetheless needed

jaclaz

P.S.: @Nuno: Read these as a start:
http://www.microsoft.com/technet/technetma...ult.aspx?loc=en
http://board.iexbeta.com/index.php?showtopic=51516
http://www.iexbeta.com/wiki/index.php/WIM
http://technet.microsoft.com/it-it/windows...a/aa940981.aspx

[Nuno Brito]

Jaclaz - you live up to your "Finder" rank again!

The last two links you've mentioned are very elucidative.

We can either build a raw WIM reader/writer(?) or simply use the funcions built inside WIMGAPI.

According to MS - it was created for use from third party developers and *may* be distributed without MS restrictions since we have the precedent of Vlite (sucessor of nLite) distributing the same file and using it extensively.

Maybe it is a "safer" solution to handle WIM images - galapo mentioned that there was only one tool capable to display the progress of a WIM packaging operation but the ms page refers that it is possible to get the progress data using the DLL API.

It refers Windows Imaging Interface Reference as the paper to read detailed documentation to use this DLL, do you know where to find it?

Thanks for the help!

[was_jaclaz]

@Nuno
Get this one:
http://download.microsoft.com/download/f/e...le%20Format.rtf
then look in the WAIK for the " Windows Imaging Interface Reference"



jaclaz