Jump to content











Photo

Windows Image File Boot (WIMBoot)

wimboot

  • Please log in to reply
158 replies to this topic

#151 Biatu

Biatu

    Member

  • Members
  • 55 posts
  •  
    United Kingdom

Posted 4 weeks ago

@Wonko, I have a theory, on earilier version of WinpE everything just uses boot.sdi, which has a small NTFS fs on it. The wim is loaded into ram, and then the wim is overlain over the small sdi in memory, no? If im not mistaken M$ just modified this paradigm for a full system.



#152 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

@Wonko, I have a theory, on earilier version of WinpE everything just uses boot.sdi, which has a small NTFS fs on it. The wim is loaded into ram, and then the wim is overlain over the small sdi in memory, no? If im not mistaken M$ just modified this paradigm for a full system.

 

Yes and no (if I get what you mean).

NTFS inside the boot.sdi is used (this feature is available in NTFS at least since 2K)  i.e. it is a feature (alternative to assigning a DOS drive letter)  as a mount point of the contents of the boot.wim expanded inside memory (a ramdisk).

https://technet.micr...ibrary/cc771845

 

 

The WOF driver directly creates a volume (or however proper pointers to files) directly from the compressed contents of the wim, at least this is my understanding:
http://reboot.pro/to...mboot/?p=187014

http://reboot.pro/to...mboot/?p=187100

The issue (and most probably the reason why wimboot has seemingly been abandoned after 8.1) is that a Wimboot is not serviceable easily as each and every update would go "outside of it" creating a situation with "duplicates" not entirely unlike that of the stupid WinSxS and thus - little by little - hogging disk space (which was the reason for Wimboot in first instance, being able to deploy the stupid Windows 8.1 to stupidly underpowered - diskwise - devices like tablets and similar), and was replaced by compactOS:
https://msdn.microso...ktop/compact-os

 

:duff:

Wonko



#153 Biatu

Biatu

    Member

  • Members
  • 55 posts
  •  
    United Kingdom

Posted 4 weeks ago

ok, then what about mounting a wim on disk? that creates pointer files no?

WinSXS is supposed to be hardlinked anyway, so not dups, unless in the case of WinPE where builders actually copy the files and not linking them (but that don't really matter as wim compression dedups the data)

 

Personally CompactOS is useful, but I think a union-like fs in windows would be extremely powerful...esp in WinPE environs


Edited by Biatu, 4 weeks ago.


#154 Biatu

Biatu

    Member

  • Members
  • 55 posts
  •  
    United Kingdom

Posted 4 weeks ago

For example, using some g4d tricks, you can set the boot image in a WIM on the fly, enabling multiple versions of WinPE in a single WIM, programs drivers etc, mount on the fly only as needed.

Having a layout like this:

Wim/Win7.32

Wim/Win7.64

Wim/Programs

Wim/Programs.32

Wim/Programs.64

Wim/Drivers

Wim/Drivers.32

Wim/Drivers.64

 
Idea for x64:

Link Wim/Win7.32/Windows/System32 > X:/WIndows/Syswow64


Edited by Biatu, 4 weeks ago.


#155 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Definitely I am not following you :(, particularly when you mention (unspecified) grub4dos tricks. :unsure:

 

WinSxs concept is "right" for the hardlinking, it's the issue behind it (DLL HELL) that creates the bloat (as you have n versions of a same dll).

The Windows 8.1 wimboot update would create the same in the sense that latest dll would be outside the wim and inside it there would be an older version, then, little by little each and every file would be updated and thus a large part of the system wuld end up residing outside the wim.

 

:duff:

Wonko



#156 Biatu

Biatu

    Member

  • Members
  • 55 posts
  •  
    United Kingdom

Posted 4 weeks ago

sorry for the confusion, what I was saying is modify the byte that specifies which image to boot in the wim header. 

Ah, i guess ur right about the versioning. Off the top of my head, a solution would be to version the functions instead of the entire lib, and maybe use a JIT like system when something is called so that in memory it would function like the needed version

 

About the reparse points, when a WIM is mounted on a disk (for editing) with DISM, are the same type of links created in that process?


Edited by Biatu, 4 weeks ago.


#157 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Ah, i guess ur right about the versioning. Off the top of my head, a solution would be to version the functions instead of the entire lib, and maybe use a JIT like system when something is called so that in memory it would function like the needed version

Yes, that would have been a nice solution, had it been implemented in a timely manner (around NT 4.00 times).

 

As I see it, a DLL is a library of functions (actually it is a library of functions ;)) not entirely different from a real  library containing books.

 

In a real library, a book is indexed (besides by name) by the area, cabinet,  shelf, and position on the shelf and - of course - before these detailed location data, by the street address of the library itself.

 

Now imagine that every time you replace or add a single book with a new version in the library you build a new building right besides the original building on the south side, put in it first a copy  of ALL the books that were in the original library and only then you add or replace the particular book.

 

It doesn't make much sense, put this way, does it? :dubbio:

 

Additionally, you also make a copy of the street number of the original building and place it on the south side of it, while you put a new one on the north side, so that people coming from the south side will mistake the new building for the old one, whilst the people coming from the north side will see the proper street address ... :frusty:

 

... before or later you will occupy with new buildings all the available space, up to Vista it was possible (with a trick or two) to install on a non-NTFS filesystem, with 7 barely so (probably removing some functionalities), JFYI:

http://reboot.pro/to...rdlinked-files/

 

About the reparse points, when a WIM is mounted on a disk (for editing) with DISM, are the same type of links created in that process?

Yes, the Wim (intended as a file format) is nothing but a form of filesystem representation (compressed), the mounting via DISM is very similar to the mounting of a (plain) volume to a mountpoint (or reparse point).

 

:duff:

Wonko



#158 Biatu

Biatu

    Member

  • Members
  • 55 posts
  •  
    United Kingdom

Posted 4 weeks ago

@wonko, lol neat analogy. I meant literally versioning the exports, or at least implementing a reliable dedup on NTFS.
 

 

... before or later you will occupy with new buildings all the available space, up to Vista it was possible (with a trick or two) to install on a non-NTFS filesystem, with 7 barely so (probably removing some functionalities), JFYI:

http://reboot.pro/to...rdlinked-files/

Like CDFS?

 

 

Yes, the Wim (intended as a file format) is nothing but a form of filesystem representation (compressed), the mounting via DISM is very similar to the mounting of a (plain) volume to a mountpoint (or reparse point).

So, in theory, can we hook into the mounting function, or implement one that will essentially put those reparse files anywhere? Or...mount a wim, then hardlink/symlink needed files elsewhere?



#159 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Like CDFS?

No, like FAT32:
http://reboot.pro/to...files/?p=182890
 
 
 

So, in theory, can we hook into the mounting function, or implement one that will essentially put those reparse files anywhere? Or...mount a wim, then hardlink/symlink needed files elsewhere?

 
The issue is - I believe - that hardlinks that work just fine at the lower possible level (since they are actually duplicated $MFT entries for a same file) are rigorously "same volume/filesystem only" and softlinks (and mountpoints/reparse points) *somehow* (and the actual implementation in different OS  may well vary) are at a "higher level" and they are simpy "not seen" or "not parsed properly" by *everything*, an example (old I know) :
 
http://web.archive.o...showtopic=23626
 
Maybe, just like symlinks need a "special" driver on XP:
http://schinagl.priv...nksforwindowsxp
 but are "included" in later OS, the situation has changed and support for those is "at all levels". :unsure:

There is this thingy here, but hard to say if it works/is maintained, etc.:
http://write-code.bl...h/label/fsredir
http://reboot.pro/to...9-fsredir-v101/
and seemingly it is only x86 :dubbio:
 
:duff:
Wonko





Also tagged with one or more of these keywords: wimboot

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users