Thanks, I will fix a typo. Thats easy. This compression seems weird as we extracting VHD. I need to try it myself on testing machine. Have you encountered unbootable build caused by NTLDR / BOOTMGR compression?
To me seem the cause, not weird... You extract in a folder which inherits the compression flag, hence everything inside will be compressed as well Yep. Decompressing them manually fixes the the problem The last time I checked wof.sys / wofadk.sys didn't work even on Vista, Is there a patched version for XP ?
If is solution to decompress NTLDR / BOOTMGR files, I can add command to decompress command for NTLDR before capturing. And also one for BOOTMGR on ISO too. XP2ESD currently require Windows 7 and newer to run, so no problem with COMPACT command. It also exist in XP, but I never tried it. If I add support for building under XP host in future, I can try it too.
Yep, that should be enough. You can do that w/o any check (uncompressing a file that is already decomprssed, just does nothing) You are mismatching things. The compat command and the NTFS compression are with us,possibly since winnt 3.x, and works transparently with any windows that support the NTFS filesystem Since Win8.1 ms introduced various compression things and four new compression schemes which are different from the old NTFS compression, such compression schemes are way more effective but not retroactively compatible. Also they aren't visible from the GUI (no blue files, no compression flag). Also unlike a "blue file" a file compressed with the new schemes doesn't inherit the compression flag, so a modified or overwritten file becomes uncompressed. In win8.1/win10 you can use those compression schemes with the same old compact command which has new switches You can add the required wof.sys (or wofadk.sys) in w7 and w8 to make them compatible and bootable on a Xpress or LZX compressed disk, but AFAIK that driver isn't working in 2k,xp and vista. I hope is clear now
What I meant was simply the compact.exe command, to compact/decompact from script. I'm aware that NT - 7 does only support EXPRESS.
Also, now I've found out I can do a WIM Repack with NT 4.0 if I install SP6a and VBox guest additions. It actually worked. I wasn't expecting it to work to be honest.
I think wold be very useful to have a semi automated process with the option of fully automated one Something like ----------------------------------------------------- Push 1 to unpack the iso Push 2 to start nLite integration Push 3 .... [...] Push 0 to fully automated process ----------------------------------------------------- This way one could skip not needed steps (like starting from xpmode.whd, or from a manually created MCE vhd which is notoriously hard to slipstream) It's a general rule, fully automated processes are incredibly amazing things when they end doing what you expect, but are also incredibly frustrating when they don't
If you want to skip nLite touch it's possible. I have already added some options that can be enabled / disabled during whole process. Media Center and Tablet PC can be easily created using addons. XP.vhd from Windows XP Mode is not good choice for real HW. And also it's old SP3 build, main goal is to get "FINAL" XP / 2003 images.
Ilooked n to it and I can't see how start from an already made vhd, for example, i cant see how to start a non silent VBX installation, I can't see how to make it wait before shutdown. Obviously unless I start to mod the batch myself AFAIK you can get what I call the "ghetto" ones no way you can get a proper MCE/Tablet PC using an XP pro key Who said that? (and who said the ISO is good just for real HW? One may wants to use it to install XP on VMware, or in Linux using KVM, Xen or whatever, or using Parallels on Macos). BTW xpmode is just a standard XPSP3 + the virtualpc integrations, + custom OEMBIOS files., and (AFAIK) nothing removed. ON real HW (or different Hypervisor) it accepts a standard KEY just ike any other XP. Clear and good. But someone else may like to have just the modern/fast setup part, because he want to update later, because don't trust the unofficial update packages or for whatever other reason. I'm not saying your points are wrong, just that the process may be improved to please a broader audience.
Me, I don't think Microsoft have implemented HAL handling in XP Mode.vhd. Thas why we use modified Longhorn NTLDR in Auto-Sysprep. These advanced options are useless for 99% users. If you want, you can always prepare your own install.wim and place it inside XP2ESD root. That's much better than adding new custom steps into complex process And don't forget XP sysprep is not realy sysprep like we know from Vista and newer.
Not going to argue in to this because because I'm not really an expert of that detail, but at the same time the last time I had to dive in to it was in the w2k era (or when I wanted have the PAE Patch in place). Your opinion, I disagree here. Say ever used MSMG? It works by steps that can be optionally automated, and no one has blamed the MSMG guy for that. I never said to add complex steps, I just suggested to (optionally) break the whole thing in steps. I can do that myself but that wold be useful just for one person (Me), unless I start to really fork your work and republish it, which is something I don't want to do for a long string of reasons (respect for the original coder first) Yep but it does what is supposed to do. Once it makes the thing bootable on a foreign HW, everything else is relatively easy to fix.
I will try to explain it more. 1) XP Sysprep doesn't really make system bootable on different HW configuration (when you try it on many machines you will find unbootable systems many times), unless you use custom solution MyFactory on which is based Auto-Sysprep. Drivers handling and HAL detection is not implemented in XP / 2003 sysprep - Microsoft introduced this firsty in Vista 2) Yes, I used MSMG Toolkit in 2014 / 2015. XP2ESD will not be developed too long as is for abandonded system. I think 1.6 / 1.7 will be mostly final release. I hope for it as I want to release another tools this year too. 3) I still don't understand why you would like break AutoSysprep in script. If you already have VHD ready for capture, you can simply capture it using CaptureVHD.cmd - you can prepare image on your own. If you really want to break up this process, search in Auto-Sysprep scripts - they are messy, but works - it's part of abadonded project MyFactory If you have good idea I can investigate it, but currently I don't see any benefits in breaking up AutoSysprep process with another options. Thats why I added CaptureVHD.cmd to make capture easy for everyone. But as I said sysprep on XP really doesn't do what you think correctly on all scenarios. So it's better to use already known and working solution.
Ok, clearly I'm lucky. I even have a syspreped VHD I use to boot it natively on real HW. I just copy it add to grub4dos bootloader and it boots at least on common scanarios (intel ide, amd ide, AHCI..) probably the matter becomes more complicate for uncommon controllers raid mode configs or alike. I hope you continue, even if at a slower pace, being a tool plenty of brilliant solutions. Because I think that functionality and simplicity aren't mutually exclusive I try to explain, with an example. Since the beginning of the internet era the most customizable browser was Opera (and today his son Vivaldi). You can use them just like IE6, to browse a page at a time and nothing more. OR you can use an endless string of features, panels, integrated email, tabs groups, content blockers, and you can tailor practically every bit of the UI. Does this hurt a beginner or a grandma? Not at all. There is a demand for basic and power users features, and both can be fulfilled by a single program. Well I think that my idea is a good idea, to be precise I think fully automate a process is usually a huge work (but in our case is already done), while breaking an already automated work in smaller semi-automated steps is a little work for a comparatively great flexibility in return. That's all. It was a suggestion. It can't be more for a free personal work.
Hi George King, this is so cool! You have motivated me to build one last XP source. If I remember, @ricktendo64 has made a Windows XP Spanish update pack in the past. I'll look it up and see if it can be used with your tool. Hopefully you'll find the time to maintain it, although I do understand that it's not a priority anymore. Edit: Found it, update pack latino 2.06 seems to be the latest. It has updates until 2015, it will do for now. Cheers.