Not much idea from my part. I did it many years ago, using ntswitch or tweaknt + post install MCE integration, when XP MCE was actually useful
Like this. Perhaps I'm not sure if in some older XP beta there is the "Emerald" branding, which was the codename of early MCE component
Released Beta 2. Improved the MCE edition. MCE should be installed and run normally. However, you have to download .NET Framework 1.1 from Microsoft's site, rename it to dotnetfx.exe and put the file into \Extras folder. Otherwise MCE wouldn't be able to start. Edit: I forgot to add some of the files. I had to reupload.
I use Server 2003 R2 x64 as the base iso, XP Professional SP3 x86 as the target iso. I don't know which product key to enter when installing. I tried the product key for XP SP2 x64 Edition and the product key for XP Professional SP3 x86, both are incorrect. Can only use the key for Server 2003 R2 x64, but I can't get to the desktop until I log into the system for the first time. Error shows: A problem is preventing Windows from properly checking the license for this machine.
Well, you're not alone. x64 Server to Client conversions have some activation problems as I mentioned in post #62. It must be cracked in safe mode. And I'm not going to provide any cracks.
I've decided to add Windows FLPC SKU. It can be used to install XPe updates. And this is the only possible Embedded SKU for ConvertNT5SKUs. Windows XP Embedded SKU (is installed by ProductSuite value EmbeddedNT) has issues: A) If the registry value is added on text-mode setup, it is impossible to go any further in setup. It restarts itself automatically before GUI-mode setup starts. B) If the registry value is added later in the setup, the OS becomes completely impossible to use. C) Windows doesn't let you modify the registry value after Setup. D) If the registry value is added outside of OS (like WinPE), then it'll cause a BSOD. Rest of Embedded SKUs do not have bitmaps, resources, brandings etc. I don't think they're needed since FLPC SKU is enough. But if you experience problems with FLPC, then I might consider adding them too. Without FLPC key: Spoiler: Before With FLPC key: Spoiler: After This SKU is only useful for 2600.5512 x86 Client. It's useless on x64, Server SKUs, non-2600 builds and non-English versions.
Update for v3.0.0 RC2. I found a way to get Tablet PC edition and components on Windows XP x64. However, I need to find a solution for x64 Freestyle/Media Center Edition. About Starter Edition, I just found out that no strings or brandings for Starter edition exist on 3790. I've checked on win32k.sys. Spoiler: Windows XP Tablet PC Edition (x64)
News for v3.0.0 RC2. Found out the K, KN and N editions for Windows 2000. Like Windows 2000 Home Edition, it doesn't have K, KN or N branding anywhere. It doesn't remove Windows Media Player for KN/N editions. Like Windows 2000 Home Edition I found out earlier, it's only useful if you would like to upgrade to Windows XP K/KN/N editions. For KN/N editions, Windows Media Center is removed during upgrade process. Here, you can see the differences. Same ISO files are inserted to both VMs. Top one is original Windows 2000 Pro, while bottom one Windows 2000 Pro KN. Spoiler: Windows 2000 For Windows XP TPC x64 Edition, I'm having problems when I add the support for conversion to script. For some reason, file replacing tool used by tool does not replace the % character as it takes the %% as variable. While it's supposed to add this line: Code: 2 = "%cdname%","%cdtagfilea%",,\cmpnents\tabletpc\amd64 It adds this line instead: Code: 2 = ,,,\cmpnents\tabletpc\amd64 For Windows XP Server build 2600, I found the permanent fix. However, the problem is I had to use leaked XP SP1 source code. And I really don't want to use it since I'm not sure if that would go against the rules. Code: liccpa.cpl ccfapi32.dll llsmgr.exe llsrpc.dll I added Windows 2000 Client to Server conversion support. I've decided to add this since Windows 2000 Server wasn't released for some languages. Lastly, I've optimized the whole script. I removed unused variables and unnecessary files won't be copied from Target.iso. Saving both time and free space.
I'm sorry, but I'm a little bit confused about the exact meaning/result of applying a convert with a x64 SKU as the base iso and an x86 SKU as the target iso and vice versa. Could it help to manage an in-place upgrade of an installed OS (either Windows XP or Windows Server 2003) from x86 to x64 ?
1. Sorry, the batch script does not support converting architectures. It can only convert editions. If you use x86 ISO as Base and x64 ISO as edition, script won't process it. There's the warning because it could break the whole ISO. 2. I actually remember that I tried to convert x86 XP ISO to x64 by editing dosnet.inf, txtsetup.sif and renaming the I386 folder to AMD64. It actually give an warning when I tried to install into x86 VM. However, the problem is the drivers and some dll files that do not support x64 architecture. I replaced these files. But the best result I got is an BSOD after text-mode setup. However if I could convert the architectures it would be cool. And I would rename this script to ConvertNT5ISOs.
Thank you for this clarification. You don't have to be sorry, but very proud because you are demonstrating what should have been done by design at the origin ! It's so lazy to simply dump at once all your existing customers with x86 systems without providing them even a single path of upgrade! The truth is gradually coming out and the potential of XP/W2K3 is just emerging. I guess a key question is right now to be able to formalize the knowledge about edition/sku/.... into metadata (able to generate, dosnet.inf, txtsetup.sif, .... or cbs for XP/W2K3) and perhaps Windows Embedded/Mantis and later can help doing so?
By "dump at once all your existing customers", I was thinking about the one who deliberately decide to not implement for Windows Server 2003 & Windows XP support for in-place upgrade from x86 Windows image to amd64 deserved by a few millions of customers!!!! It will be worth to investigate all the unsupported ways to achieve x86->amd64, what has been demonstrated possible at least by using Windows 8 beta binaries.
I can try it again if you want to. However, I don't think it would possible to do that since some binaries are only made for x86. Even though I became successful, I think that it would be very unstable. And that unstability might prevent OS from running normally.
BTW, today using tools like forensit (and a bit of experience) migrating a x86 to AMD 64 install (and viceversa), is something that can be done in minutes.