Posted 28 December 2008 - 09:38 PM
Okay.... so far so good!
I am running a dual-boot machine with second partition for creating the PE disk (lets call it "Builder Host" OS). On my Builder Host OS, I have set up a Virtualbox running Vista 32-bit for making the PE ISO ("Guest OS").
First and foremost: I read somewhere on these fora that Winbuilder had not been tested with a 64-bit Builder Host since 12b2. I can confirm that it works as well as it should! By that I mean Winbuilder 12 RC1 does what it is intended to do flawlessly from a Vista 64-bit Builder Host OS with WAIK installed and a 32-bit Source. [See Footnote below for how to ensure the scripts behave as well as Winbuilder]
Now for my question::
Since I am building the ISO on the Guest OS, should I block any "finalize" scipt that wants to test my build in a VM, as that would result in my Guest OS becoming a Host OS for a Further-embedded 2nd Guest OS? IT sounds too much like facing two mirrors towards each other... image within image within image... and I feel like Kramer when he is in the phonebooth at 1st and 1st!
Put another way: as set up, Winbuilder 12 RC1 will test your build in a Virtual Machine before finalizing the ISO. But I already have Winbuilder running in a VM on my in the first place. Hence, these scripts will result in a Virtual Machine within a Virtual Machine... and just the thought of that sounds bizarre to me. So before I send my computer down some vitrual rabbit hole, I have disabled it. However, I'd like the option to preview my build, but first want to know if this is acceptable practice, and Nuno's screenshots would seem to suggest that it is.
Thanks for the levity jaclaz, although for some of us, hitting a ball with a bat *is* hard. So I guess everything is relative. For example, I've passed my Physics Qualifier Exam, Two state BAR exams, and the Patent Bar. But to me, *this* is very hard. Not hard in the sense that I can't edit a WIM and get the functionality I want. In that sense, this stuff is not hard... just time consuming. What's hard is finding a way to make it easy to re-build (also I have no idea how to edit a shell to make it look nice); I think winbuilder can do that for me, only now I realize that I need to help winbuilder help me. For example, it does work perfectly on a 64-bit Build Host OS, but many scripts are not set up properly... so now that I have proven to myself I can do it (with everyone's help, of course)... to do it easily, it should be build using a 32-bit Host OS.
Footnote (should probably be in its own thread):
Winbuilder works fine with 64-bit Vista as Build Host OS:
PROVIDED THAT you ensure the scripts you include (as opposed to Winbuilder itself) account for at least the following three things: 32-bit drivers, 64-bit Vista's permissions, and its file structure. Specifically:
A: don't let 64-bit drivers get mixed in:
All scrpits that pull drivers from the Builder Host OS will be pulling 64-bit drivers. These have to be replaced by the corresponding 32-bit drivers. For example, Acronis uses snapman.sys, which itself changes with each build. Left to its own devices, Acronis scripts will use your 64-bit snapman.sys (and 4 other files). This will not work in your 32-bit VistaPE and so you must adjust the script, your build folder, or both.
B. Vista's Permissions:
UAC is a real issue here. Sometimes running WinBuilder as an Administrator is not good enough. Acronis is a good example again: it wants to take your license info from the registry. When run as an Admin, Winbuilder won't find those registry entries unless you installed Acronis as an Admin. So the script needs to be adjusted to look to the Current User's reg. keys and not the Local Machine keys. i.e., change "HKLM" to "HKCU" or, better yet, copy them right into the script.
C. Vista's Windows On Windows moves files to directories with different names than their 32-bit counterparts... OR, even if named the same, the path to get to a directory may no be different (e.g. User's Settings for a program is blocked via Documents and Settings and now must either bypass directly to "Users...App Data... Microsoft/Windows/Roaming" or via the "ProgramData" directory):
Many scripts pull files from the programs directory and/or the user's directory. If Vista 64 is your Build OS, then any scripts that look for files in the "Program Files" directory or via "Documents and Settings" likely will not get the files and fail. This is because 32-bit programs (and almost all are) are run via WOW and put into the "Program Files (x86)" directory. Again, the older Acronis scripts (such as for Echo 9.5 that I use) provide a great example of this. Those scripts need to be edited to use generic paths (e.g. %ProgramFiles%, %WinDir%, %SystemDir%, etc...) or else point to the proper directories by name.
[NOTE: While Acronis was used here as an example, please understand that this was just an example based on Acronis' official WinPE solution, which is to use the official BartPE script as modified per Acronis' instructions. It is Acronis' workaround to their own previous workaround that does not work with 64 Vista as your Build Host OS. From what I can tell any and all recent Acronis scripts written by user ctmag account for all of the above issues. When/if he gets around to Acronis TI Echo Workstation 9.5 build 8163, I suggest using that. But again, it was just an example]