can we use WIM for XP/2003 based projects?

Can this be possible :
1) Create an XP/2003 based PE from say BartPECore without building the final ISO or using RAMBOOT method.Just the PE files.
2) Create an empty RAW disk image , mount it with VDK or any other software.Format it with NTFS.
3) Copy the PE files to it.
4) Make an image of it with ImageX using LZX compression.
5) Use VistaPE's bootloader to copy it in RAM and boot from it the same way it does with WinPE 2.0

Steps 1-4 are possible.If step 5 is possible too then the XP/2003 based PE's will benefit a lot from it as it does VistaPE :
Ablity to write to the system drive.Free space user definable like VistaPE.
LZX compression on all files.No more bothering finding which files can be UPXed / CABed as the entire fileset gets compressed.
Single instance storage.Different builds in one WIM image maybe i don't know.
Less RAM usage.If VistaPE goes from 300MB down to 150MB including writeable space think about XP/2003 builds which are smaller.Plus faster booting due to smaller image size.Also with a comparable size one can fit more stuff like software and drivers.

In RAMBOOT based projects you can use CAB compression on the ISO/IMG file which gets loaded in memory.This reduces CD space usage but increases boot time a little bit as the ISO gets decompressed in RAM.Also the ISO image loaded didn't retain the compression level offered by the CAB format.This way i can fit an nLited XP (with driverpacks and some software integrated) and a customized BartPECore PE into one CD having to carry only one disc.Plus not all PCs got DVD drives so it can be used on older hardware too.

What do you think?

I would have thought this to be impossible!

You made me actually want to get Vista to try your neat idea.

All you wrote, including step 4) appears reasonable and possible.

Unfortunately , my guess us that step 5) will probably result in a 0x0000007b error, I am afraid.

Or is there a RAMDISK driver compatible with the way the Vista bootloader loads into ram working from XP/2003?

Or a way to use the Vista one under XP/2003?

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

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

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



jaclaz

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?

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.

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.

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.

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...ult.aspx?loc=en
http://board.iexbeta...showtopic=51516
http://www.iexbeta.c...i/index.php/WIM
http://technet.micro...a/aa940981.aspx

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!

@Nuno
Get this one:
http://download.micr.....le Format.rtf
then look in the WAIK for the " Windows Imaging Interface Reference"



jaclaz

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?

-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.

How about getting the files on your own?

You'll have to be more specific.

what files(?)...

Just for the record, Windows Designer Studio is registered on SourceForge as having a GNU GPL license /Public Domain :
http://uberplay.org/default.aspx
whether it uses "legally redistributable" components or not I cannot say....

... but surely a "home page" that hosts a GNU GPL project, on SourceForge, WITHOUT giving the Source NOR including a copy of the GPL license itself does smell a bit fishy...


On the MSFN topic:
http://www.msfn.org/...ha-t100722.html
the Author affirms that the app for the moment include Longhorn files, and that they are (have always been Freeware)

WIM Beta 1 can be read and unpacked by the original 4074 Panther setup engine, also located in this folder. As a long term goal, my application would use its own windows setup routine, also based on WIM, in order to make the setup independent from Longhorn files. As a short term goal, based on the Longhorn 4033 SDK / WAIK, which has always been freeware.

I guess, that if the SourceForge and MSFN Administrators allow that on their respective sites, it's allright FOR THEM.

Personally, I do not like "less than kosher" ANYTHING hosted on boot-land, but the only person able to allow or disallow something like that is of course Nuno.

jaclaz

... but surely a "home page" that hosts a GNU GPL project, on SourceForge, WITHOUT giving the Source NOR including a copy of the GPL license itself does smell a bit fishy...

Well, the longhorn files are not freeware. Some may even think this wds author coded the panther engine.

The files appear to be the panther engine files required to perform a setup from a running windows, they come from builds 4074 and 4028 and are packaged as an 'sdk'.

oh well.

As a short term goal, based on the Longhorn 4033 SDK / WAIK

Which I'm not familiar with.
But hey, I hope I missed that one!

I've got terror bytes of windows and no lh 4033 sdk. .

Got the winfx bits though.


But hey, I think we're off in the wrong direction.

...
You asked before...

Or is there a RAMDISK driver compatible with the way the Vista bootloader loads into ram working from XP/2003?

Or a way to use the Vista one under XP/2003?

If you look at some of my project's final tweaks scripts, they may include a test section for adding a wim driver, but txtsetup must also be updated.

I'll try to work on this.
It's likey a driver from a vista beta version will work, but unlikely the (final) rtm driver works.

a good place to begin the investigation ~
http://www.stoyanoff...l-files-viewer/

and then there's this...
http://www.microsoft...;displaylang=en

-------------

Well, the longhorn files are not freeware. Some may even think this wds author coded the panther engine.

The files appear to be the panther engine files required to perform a setup from a running windows, they come from builds 4074 and 4028 and are packaged as an 'sdk'.

But hey, I think we're off in the wrong direction.

...<snip>... ...adding a wim driver, but txtsetup must also be updated... It's likely a driver from a vista beta version will work, but unlikely the (final) rtm driver works.

a good place to begin the investigation ~ http://www.stoyanoff...l-files-viewer/

and then there's this... http://www.microsoft...;displaylang=en

Any new info on this project, or is it dead (ATM) due to the lack of redistributable binaries?
--R

Any new info on this project, or is it dead (ATM) due to the lack of redistributable binaries?
--R

No news on this project, but something else that may be "ported back" has started (not completed yet, but promising):
http://www.boot-land...?showtopic=5308

jaclaz

I know this isn't a perfect answer to this question, but if you're looking to redistribute wimgapi.dll without downloading the whole WAIK, you might consider downloading SmartWIM. I am a developer for SmartWIM and we recently got permission from Microsoft to include wimgapi.dll with our stuff.

Since SmartWIM is now free for personal use and very cheap for companies, it's an option at least. I know this doesn't solve things for all of you, but I figured it was worth mentioning. (And, in addition, SmartWIM does add quite a bit of new stuff -- such as applying an image from spanned media without needing to copy all the files over to the drive.)

Anyway, like all of you, I'm really looking forward to an open source ImageX...

I know this isn't a perfect answer to this question, but if you're looking to redistribute wimgapi.dll without downloading the whole WAIK, you might consider downloading SmartWIM. I am a developer for SmartWIM and we recently got permission from Microsoft to include wimgapi.dll with our stuff.

Since SmartWIM is now free for personal use and very cheap for companies, it's an option at least. I know this doesn't solve things for all of you, but I figured it was worth mentioning. (And, in addition, SmartWIM does add quite a bit of new stuff -- such as applying an image from spanned media without needing to copy all the files over to the drive.)

Anyway, like all of you, I'm really looking forward to an open source ImageX...

You seem to have the wrong link there, no 'SmartWIM' and definitely NOT free

You seem to have the wrong link there, no 'SmartWIM' and definitely NOT free

Well, SmartWIM was renamed the "imaging component" and that really is the new link to it. If you click on the "Download" link, you can get a free copy for personal use. Commercial license is $29. But, seriously, you don't need a license key to just mess with it. It's not open source, but it's free as in beer.

My main point was that wimgapi.dll is included, so it's one way of getting that lib without downloading all the whole WAIK.

Well, SmartWIM was renamed the "imaging component" and that really is the new link to it. If you click on the "Download" link, you can get a free copy for personal use. Commercial license is $29. But, seriously, you don't need a license key to just mess with it. It's not open source, but it's free as in beer.

My main point was that wimgapi.dll is included, so it's one way of getting that lib without downloading all the whole WAIK.

Understand now, the naming thing threw me off - Thanks!

Well, SmartWIM was renamed the "imaging component" and that really is the new link to it. If you click on the "Download" link, you can get a free copy for personal use. Commercial license is $29. But, seriously, you don't need a license key to just mess with it. It's not open source, but it's free as in beer.

My main point was that wimgapi.dll is included, so it's one way of getting that lib without downloading all the whole WAIK.

Thanks for the heads up , though, with all due respect, I have seen better worded licenses, cannot see anywhere anything related to the "free for personal use" thingy.

If the point is "you can download a trial version and keep some components from it" it's allright.



jaclaz