16 replies to this topic

[misty]

I was doing a bit of research and came across several references to Windows 10 using a Compressed Operating System - see https://www.thurrott...n-in-windows-10.

Haven't found much decent information so far. Checked out the DISM Image Management Command-Line Options reference and noticed the following -


Option: /Append-Image

Use /WIMBoot to append the image with Windows image file boot (WIMBoot) configuration. This only applies to Windows 8.1 images that have been captured or exported as a WIMBoot file.

Important
This feature isn't supported in Windows 10.

Option: /Apply-Image

/WIMBoot: Windows 8.1 only: to apply the image with Windows image file boot (WIMBoot) configuration. This only applies to Windows 8.1 images that have been captured or exported as a WIMBoot file.

Important
This feature isn't supported in Windows 10.



/Compact: Applies an image in compact mode, saving drive space. Replaces WIMBoot. Windows 10 for desktop editions (Home, Pro, and Enterprise) only.

/Apply-Image lists the /WIMBoot switch as deprecated!

One of my favourite Windows 8.1 features axed. Or is it? Interestingly I was playing around with wimlib-imagex last night before reading about this and managed to wimboot Windows 10 Enterprise LTSB without any issue - at least any issues I was aware of anyway!

Regards,

Misty

[Wonko the Sane]

Wimboot is deprecated because of this:

http://www.msfn.org/...ates/?p=1098319

 

That it still works are good news .

 

Wonko

[alacran]

New install/Compact is just a variation of the old NTFS compress

 

Take a look here: http://reboot.pro/to...-10-compact-os/

 

To deploy Windows 10 from Windows Setup in compact mode

• Use an unattend.xml file with the setting: Microsoft-Windows-Setup\ImageInstall\OSImage\Compact

WinNTSetUp new beta version is capable to make wimboot and also compact install for Win7/8.x/10 see:  http://www.msfn.org/...51#entry1104194

 

I haven't tested this new version yet but this is the info:

 

Version 3.8.5 Beta 1

- fix boot partition mounted as A: or B: wasn't recognized
- fixed Windows 10 installing from Windows XP host
- minor improvements
- fixed wimgapi loading bug running on windows 8.x
- added GUI option for compact mode
- downloads WofAdk and makes volatile driver install
- offline windows tools will attach WofAdk
- adding WofAdk driver to new installations, if compact or wimboot made is set
- using exclusion filter to enable wimboot/compact mode for all Win7 sources and later

Best Regards

[Wonko the Sane]

Hi Simon,

still unbanned in Bangladesh?

http://reboot.pro/to...-hardware-mods/

 

Wonko

[alacran]

Why is this guy here again?

 

Please, a moderator should ban him again, all his post are spam.

 

alacran

[Wonko the Sane]

Since you seem so sorry about the fact that WIMBoot is deprecated, it would certainly help if you could be more appreciative of the efforts of third parties who are maintaining and updating the technology.

Well, the Wimboot thingy is/was nice, but all in all is (and has always been) more a workaround to a problem than anything else.

The problem being of course the (totally unneeded) amount of BLOAT the OS represents, the good MS guys forgot circa 2006 the basic principles (write compact code) and their OS's grew besides control, and of course the new Windows 10 and the continuous update model put an end on the short lived Wimboot technology.

I understand how you (for a mere 30 bucks or so) are offering a piece of software that may help in mitigating the impact of the BLOAT on low powered (storage wise) machines, but it's not like that is a solution, it is another workaround.
 

Is your definition of spam something that you cannot prove wrong, or similarly, something that proves you wrong? If so, you won't like this: Your statement that "New install/Compact is just a variation of the old NTFS compress" is wrong.

It seems to me that NTFS compression has alway been file based, and alacran stated how the new "compact" is a variation of it, he never said it was a variation of Wimboot.

The new compact.exe provides not one, not two, not three, but four new compression algorithms on top of the previous LZNT1 algorithm. And unlike LZNT1, files compressed with these algorithms do not stay compressed when they are updated.

Here I am starting to have difficulties following you, did you actually invent the new groundbreaking Lempel-Ziv-Simon algorithms or (as you have done in the past) you are just changing names to existing technologies developed by someone else and/or taking merits about someone else's ideas and work?


Wonko

[Wonko the Sane]

In other words, and as expected BTW, there is no such thing as a Lempel-Ziv-Simon compression algorithm, there are a number of variations of the Lempel-Ziv compression algorithm implemented by Microsoft in the OS that the "Simon" driver (possibly) uses and "combines and interleaves" that have been arbitrarily named as LZSnnn and misrepresented as (new) algorithms while they are more like a (possibly clever) wrap around way to achieve (hopefully) better compression using existing compression algorithms in Microsoft's own OS code.

 

 

Wonko

[alacran]

Using WinNTSetup, Win10x64 Pro Compact install Xpress8k in VHD is 5.70 GB (31.32% smaller) and standard install in VHD is 8.3 GB, (both not containing page file and hiberfile).

 

This test was made using Windows API's, but you can also use wimlib in WinNTSetup, to see if you can get a better compression and time score.

 

alacran

[john0011]

In other words, and as expected BTW, there is no such thing as a Lempel-Ziv-Simon compression algorithm, there are a number of variations of the Lempel-Ziv compression algorithm implemented by Microsoft in the OS that the "Simon" driver (possibly) uses and "combines and interleaves" that have been arbitrarily named as LZSnnn and misrepresented as (new) algorithms while they are more like a (possibly clever) wrap around way to achieve (hopefully) better compression using existing compression algorithms in Microsoft's own OS code.

 

 

Wonko

 

If an algorithm is defined as follows:

 

An algorithm (pronounced AL-go-rith-um) is a procedure or formula for solving a problem. The word derives from the name of the mathematician, Mohammed ibn-Musa al-Khwarizmi, who was part of the royal court in Baghdad and who lived from about 780 to 850.

 

Then you have no ground to claim any misrepresentation. Lempel-Ziv-Simon Disk Compression solves a very challenging problem (32-bit and 64-bit transparent disk compression) for the first time in over two decades; Microsoft came close but did not travel the last few significant miles as described above.

[Wonko the Sane]

The original Lempel Ziv compression algorithms have been published in 77 and 78.
A number of variations were published afterwards:
https://en.wikipedia...i/LZ77_and_LZ78
 
The LZS acronym has already been in use to mean the Lempel-Ziv-Stac compression algorithm:
https://en.wikipedia...Lempel–Ziv–Stac
 
You could get the Stacker trademark  however .... no, wait, you already did that :
http://reboot.pro/to...pression-betas/
http://tsdr.uspto.go...pe=statusSearch
 
But it would be advisable, even when and if you will have developed an actual compression algorithm, call it with a different name, as LZS may generate confusion.
 

Wonko

P.S.:
Just for the record, soon after this post:
http://reboot.pro/to...betas/?p=185296
the Drivespace trademark has also been acquired by Simon King:
http://tsdr.uspto.go...pe=statusSearch

[Wonko the Sane]

Just for the record in Simon King's own words, on his own forum:
http://www.zipmagic....c.php?f=1&t=103
 

The fact is, Lempel-Ziv-Simon Disk Compression is the first and only full-service transparent disk compression provider for both 32-bit and 64-bit Windows. While it does not introduce a new compression algorithm, this point is highly irrelevant. Compression algorithms have been highly commoditized in the 21st century, where the best ones are free such as 7-Zip - which outperforms every other file archiver out there without question, and is fully supported in ZIPmagic's file compression suite, of course - with greater performance and higher ease of use compared to the default 7-Zip implementation.

 

 

Sure , relevance, like beauty, is in the eye of the beholder.

 

Wonko

[alacran]

This guy is only using other people work to make money, it is the most dishonest way, because How can you put a price for something which is FREE software?

 

And I know at least two FREE software that can make same thing without any cost: wimlib-imagex and WinNTSetup, you can make a full Compact XPRESS16K or go as far as Compact LZX install from both, I usually don't like to go that far, putting so much load to the CPU that's why I prefer Compact XPRESS8K, it seems a good relation between compression and CPU load to make it almost not perceptible, that makes sense to me, and as the chunk size makes bigger you are also wasting more storage space for small files and for the last piece of big files.

 

My last test using WinNTSetup v3.8.5 Compact XPRESS8K gives this results:

 

Win10-Pro-x64.vhd is 5.59 GB

Win10-Pro-x86.vhd is 4.05 GB

Win10-Home-x86.vhd is 3.87 GB

 

Win8.1u1x64-Pro.vhd is 4.88 GB

Win8.1u1x86-Pro.vhd is 3.55 GB

 

And a third way, of course you can also use MS own way:

 

To deploy Windows 10 from Windows Setup in compact mode

• Use an unattend.xml file with the setting: Microsoft-Windows-Setup\ImageInstall\OSImage\Compact
• (this is XPRESS4K)

I'm not totally sure (as i haven't tried it) but I think here you can specify compression mode.

 

EDIT: Added final size of expandable VHD's after deploy Win 10 and 8.1u1

 

alacran

Edited by alacran, 29 September 2015 - 08:13 AM.

[alacran]

I asked JFX about Swap file still present even if you select No Hiberfile and NO Pagefile, his answer is he fixed it in WinNTSetup v3.8.5 released today:

 

 

Final version of 3.8.5 is out.

 

- disable pagefile should now disable swapfile too

 

Link: http://www.msfn.org/...inntsetup-v385/

 

alacran

[pscEx]

I've declared john0011 as spammer and have hidden all of his posts.

 

Peter

[vicshein]

I was doing a bit of research and came across several references to Windows 10 using a Compressed Operating System - see https://www.thurrott...n-in-windows-10.

Haven't found much decent information so far. Checked out the DISM Image Management Command-Line Options reference and noticed the following -


Option: /Append-Image


Option: /Apply-Image

/Apply-Image lists the /WIMBoot switch as deprecated!

One of my favourite Windows 8.1 features axed. Or is it? Interestingly I was playing around with wimlib-imagex last night before reading about this and managed to wimboot Windows 10 Enterprise LTSB without any issue - at least any issues I was aware of anyway!

Regards,

Misty

 

It has been previously reported here and elsewhere that WIMBoot has a significant space bleed problem. Therefore, it soon becomes a cure worse than the disease unless it is periodically cleaned up by removing files which are deleted/updated inside the base WIM image.

 

 

Since Microsoft have failed to provide their own tooling to do so, that might explain why they felt it necessary to deprecate it. Of course, this has no impact on third party tooling which remains available, despite Microsoft's own disinheritance of WIMBoot.

 

I believe such third parties need to be supported, because transparent disk compression has many useful applications - from increasing the storage capacity of non-upgradeable tablets like the Surface series, to making SSDs cheaper, and extending the life span of remote servers.

 

Could someone benchmark the read speed increases afforded by transparent disk compression on modern 32-bit and 64-bit Windows operating systems? My preliminary results seem to indicate that disk read speeds increase, even on already super-fast SSDs such as the Samsung line found in Surface's.

[savedisk]

 

It has been previously reported here and elsewhere that WIMBoot has a significant space bleed problem. Therefore, it soon becomes a cure worse than the disease unless it is periodically cleaned up by removing files which are deleted/updated inside the base WIM image.

 

 

Since Microsoft have failed to provide their own tooling to do so, that might explain why they felt it necessary to deprecate it. Of course, this has no impact on third party tooling which remains available, despite Microsoft's own disinheritance of WIMBoot.

 

I believe such third parties need to be supported, because transparent disk compression has many useful applications - from increasing the storage capacity of non-upgradeable tablets like the Surface series, to making SSDs cheaper, and extending the life span of remote servers.

 

Could someone benchmark the read speed increases afforded by transparent disk compression on modern 32-bit and 64-bit Windows operating systems? My preliminary results seem to indicate that disk read speeds increase, even on already super-fast SSDs such as the Samsung line found in Surface's.

 

great observe !

[pscEx]

Simon congratulates Simon!

 

Peter