As mentioned before is this really meant for SSDs around 120 gb? Mine is only 60gb until I can upgrade to a bigger one. Shall I just wait? I do have the iso created though.
One last question then I'm gonna want till next month ( btw i was able to free up 5 more GB changing the recovery it looks like installing it now and gonna test it. ) MY question is i looked and didn't see it any place in the WDK Docs. IS there a way to auto install it like the Setup.exe . right now or the only way is with diskpart ? .
I'm starting to . well now my try's work every time I don't use your exact guide just what i need and my VHD is this winsetup 3 .3 I found love it .....with all windows updates etc no other stuff like games etc . i got it to 99 % by 99% i don't mean im using 99 % I'm using 1 % according to the UI , with all most the same amount of space i had before . I lose 4.93 GB now which is no bige ..
i saw i gotta learn how ... any ty Once I know more and have a set way i see me saving activation unlike before i could but this is AWESOME how much more i can do this way .
How much space savings are we talking about if you use this wimboot method instead of classic reinstall? Also do you have to deploy it to reference PC (VM), audit it and then capture it? I'd prefer to somehow just make install.wim from Windows 8.1 Update 1 ISO bootable without any unnecessary steps, if that's possible.
I'm just catching up on this subject, as I have an Atom x86 tablet that I'd like to test this on now that the update is out officially. Why is there specific mention of x64 when it says that all architectures are supported (i.e. x86)?
Hmm... well it mentioned UEFI bootable, but I'm not sure that it was required. AFAIK all Windows versions that boot into UEFI have to use a 64-bit os, but it could be like the SSD thing, just a recommendation. It could also be that there are issues with not using UEFI such as waking from sleep, etc.
UEFI can be 32-bit. Most UEFI is 64-bit (and the OS must match the UEFI's uarch), but there is one area where 32-bit UEFI is common: tablets. It comes down to Connected Standby, and how Connected Standby with Bay Trail was simply not ready for 64-bit when the first Bay Trail systems were shipping. This is why all of the Bay Trail tablets on the market are 32-bit, even though they use UEFI. So there's no rule saying that UEFI must be 64-bit; 32-bit UEFI is possible. It's just that if you're going to make a system new/modern enough that it uses UEFI, why would you want to make it using an obsolete uarch? Which is why all UEFI (until Bay Trail) were, in practice, 64-bit.
Never knew that about tablets. Learn something new every day I knew it was possible to use UEFI on non-x64 os; just MS usually prevents it.
Just FYI, I tried setting up a x86 BIOS/MBR based WIMboot on VMware and it seems also working (at least in VM). I can do it by using nearly same procedure as UEFI/GPT systems except for the partitioning scheme and partition layout (but on a traditional hard drive as I don't have SSD). If one can also use it on physical PCs and there is no additional problem compared to UEFI/GPT, I guess the UEFI thing is also just a recommendation as the SSD requirement.
ok there's a new technet article for wimboot. It points out the glaring utility that I missed before. You can also use this wimboot image as the restore image, further saving room on these solid state devices. Do you get it now? You're hard-linking to the wim for system files, and it's also a recovery image. Now it's starting to seem like a pretty damn good idea for tablets. I put the link in the OP
I thought I mentioned that in my post on the first page. Last bullet point. I'm going to try deploying WimBoot on my tablet some time in the next week or two. Should be fun.
I don't think it's necessarily a huge space saver unless you also use a recovery image (on the same drive). If you also use a recovery image, it will use a lot less space.