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

[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

[felix]

Nuno i wanted to know is it legal to extract some files from Longhorn's CD and use them in a script?
I plan on making a way to "encapsulate" PE projects in Longhorn's WIM fomat (taken from it's boot part of install.wim based of WinPE 1.6) to reduce both size and RAM space.
What if I attach the EULA?

[thunn]

-if I may..

I don't believe so.

Right now I feel it may be unwise to advertise longhorn files for download, but I also could be wrong. Let's have a quick look at the issue as it stands...


Recently there have been a couple of projects that used the abandoned code from longhorn, one you may have heard about came from joejoe.org (I'm a member, but did not take part).

long story short,
MS lawyers contacted the 'Reloaded' team with a resquest to halt production and remove all links which they did.
..
elsewhere,
At msfn a member has documented some techniques and coded an application called 'Windows Designer Studio'. I mention this because the process makes use of files from longhorn which are provided. I was surprised to see the files for 'public' download.

Recently Longhorn has received additional attention. This is likely a result of so many users migrating to Vista and having a bad experience, people now want to know if anything between XP and Vista can be salvaged.

?????????

I made use of the engine from longhorn 4015 and ximage 4007 to wim wrap of my most recent project.

I'd like more than anything to share this with the public but it's too unclear what abandoneware means in this case. I will research this further however, and I'm hopefull.
I'm curious if any additional info was gathered on the longhorn 40xx by anyone (mentioned earlier).
After working with ximage v4007, I discovered the compression is noticably better than the version that followed, ximage 4059. Both are promising though.

I packed a 850 mb. (approx.) image...

ximage v4007 created a 325 mb. wim file
ximage v40059 created a 385 mb. wim file

I ran a few tests with about the same results.

ximage v4007 (sometimes tagged v4008) was, as far as I know, the first release of the tool but seems to work quite well. No driver is installed for ximage.

[AeroXP]

How about getting the files on your own?

[thunn]

You'll have to be more specific.

what files(?)...