Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Arvy

Pages: [1]
Research and questions / Acronis True Image Home 2012 Notes
« on: August 27, 2011, 08:52:57 AM »
Not exactly sure where this belongs.  Feel free to move if not correctly located.

The following are just a few notes for any developers or others who may be working on scripts for the newly released 2012 version of the Acronis True Image Home (TIH) backup and recovery utility.

1) TIH 2012 uses a new and different registry [CurrentControlSet] set-up for its drivers and filters. In particular, the UpperFilters entries for Class\{4D36E967-E325-11CE-BFC1-08002BE10318} and Class\{71A27CDD-812A-11D0-BEC7-08002BE2092F} are now "fltsrv" instead of "snapman" and the fltsrv service needs to be added accordingly.  That new arrangement is backward compatibile with some other Acronis apps (e.g., DiskDirector 2011) but not vice versa. So you'll need to ensure that it takes precedence over any previous Acronis utility inclusions in your PE builds.

2) For creating a 64-bit WinPE build, you need to use the version-matched fltsrv.sys, snapman.sys and snapapi.dll files from an existing full TIH 2012 installation under an actual x64 Windows OS. The 32-bit files that are included in the Acronis Plus Pack (or BartPE download) won't work, of course.

3) I've contacted Acronis directly about an error on line 63 in the [SetupReg.AddReg] section of their BartPE acronis.inf file:

0x4, "ControlSet001\Services\fltsrv", "Group", "PnP Filter"
should be
0x1, "ControlSet001\Services\fltsrv", "Group", "PnP Filter"

Unless they have now corrected that mistake in their downloads, any attempt to use 0x4 (dword) for adding a registry string will result in a fatal error in the WinPE build process.

Talk about other things ... / New Host Server
« on: July 08, 2011, 09:57:18 PM »
Further to discussion that started here, I am posting this new topic outside all of the individual project forums because of its potentially broader implications for all concerned.

As discussed at some length under the preceeding topic, I believe there may be some significant potential benefits, both for project managers and for end users, in the availablility of a "non-denominational" host server under which various WinPE projects and related resources could be consolidated.  It would permit the developers and managers of various projects, at their own discretion, to locate any or all of their project resouces at a "unified" location with full administrative access* for managerial convenience.  And it would permit end users readily to find all such resources and tools thus located "under one roof" for their own WinPE building purposes that may often range across several PE# project levels and Windows architectures.

Accordingly, pending further discussion of the concept, I have gone ahead and registered (in my own name for the time being) two new domains ( and as necessary to initiate the establishment and set-up of a server for that purpose with a hosting service.  These domain registrations (with will prevent their registration by anyone else while under discussion here and, once processed by the registrar, will also permit my initiation of a hosting service contract with, one of the largest in North America served by (formerly "The Planet") with multiple heavy pipeline connections to the internet backbone.   For those knowledgeable about hosting services, it would be what is known as a "reseller" account, but without any resale fees or charges.

In anticipation of some possible concerns, let me make one point very clear at the outset.  The "generic" domain names that I have chosen for server setup initiation do not [repeat] NOT exclude or limit in any way the use of other domain names for access to those same server resources or any particular project or other resource component thereof.  Secondly, in offering open free access, my single stipulation is that it is and must remain non-profit, non-commercial and (excepting "promotion" of the project site freeware resources themselves) ad-free.

My initial intention would be to work closely with Galapo and ChrisR, who currently manage subdomains on my own server for their PE1 and PE2/3 projects, toward "upgrading" those current resources onto the new independent server with their own direct "cPanel" administrative access.*  In the longer term, however, I would see the potential for wider participation.  At this point, therefore, I'm inviting anyone who may have an interest to join this open discussion.

Regards to all,
Richard Virtue ("Arvy")

* See "cPanel" demo here.  Complete documentation here.

Gena Support / Two minor questions.
« on: July 03, 2011, 07:18:34 PM »
Lacking any real developmental skill, my efforts to provide some useful help have been focussed mainly on project packaging and the server hosting therof.  In Gena's case, that has raised one minor question about the organization of "appetizer", "meal" and "sweets" scripts on the project server and one about a default setting in a primary build script.

From what I'm able to see, almost all of the scripts that have Download Level=2 (the ones that are included in the "complete" server selection but not in the "recommended" server selection) are located under the Gena-Sweets folder.  And those scripts, in turn, make up the "sweets" addon package.  There are, however, two exceptions:  RemovableDeviceUSB3.script and Acronis-DiskDirector10.script, both of which are Download Level=2 but are located under the main Gena folder when downloaded from the project server.  Should they not be located with all the other Download Level=2 scripts under Gena-Sweets and similarly included in the "sweets" addon package rather than in the main "meal" package?

My other question is about the CoreMain.script default setting.  When downloaded, the option for "Enable CoreMain (Standalone) - Enables CoreMain build fixes when RegFactory disabled" is unchecked.  So, if I understand correctly, unless the user changes at least one ot the project's defaults as downloaded (either enables that option or enables RegFactory) some things don't get included in the PE build that probably should be.  Or have I misunderstood the purpose of that CoreMain option?  Should its compensatory "build fixes" option not be checked by default?  According to what it says, it only applies them when RegFactory isn't enabled anyhow.

Research and questions / WinBuilder.exe - What's the Big Mystery?
« on: June 30, 2011, 09:31:54 AM »
I'm not really sure where this belongs.  If not here, Admins please feel free to move or delete entirely.  It's mostly just the idle curiosity of a retiree with time on his hands.   And please understand also that it's just a question, not an invitation to "religious" controversy.

To begin with, I do not pretend to understand in any detail the inner workings of the WinBuilder executable.  Nor am I especially interested in trying to match the accumulated expertise in that area of those here and elsewhere who have evolved APIs and CAPIs and other such mechanisms for utilizing (and/or circumventing) those inner workings.  I am, however, often puzzled by its apparently unique, critical and (to me) mysteriously essential role in the overall universe of most, if not all, WinPE endeavours.  Fundamentally, my question is: "What makes it so irreplaceable in that larger context?"

From my admitedly limited perspective, it appears to be little more than a somewhat specialized batch processor with some built-in capabilities for downloading/updating scripts from a "flat file" repository.  Having some amateurish knowledge of my own in that latter area, it doesn't seem particularly sophisiticated, nor even especially well thought out to my way of thinking.  I could probably think myself of at least a dozen ways in which some fairly simple structured queries (SQL) might be used to improve the tracking and updating of various components.  In fact, I tried to suggest some several years ago without any real acceptance or success.

Beyond that, however, what batch processing capabilities does it possess that make it so difficult to envisage alternatives?  If AutoIt can't handle everything that WinBuilder can, what consideration has been given to other compilable script processors such as WinBatch, for example?  The latter would require an initial investment (about $500USD for Winbatch + Compiler*), but once compiled by the core developer(s), the end result would involve no further costs, and nor any need for WinBatch addons by either individual script developers nor users.  And the source coding could then be made openly available to anyone who might wish to contribute ideas and suggestions for its core development and improvement.

WinBatch is just one alternative possibility, of course.  But I really would like to understand why pursuing that (or something similar) appears to be such an insurmountable obstacle to overcoming at least some of the widely expressed dissatifactions with the status quo.  In short, could someone please explain (as simply as possible in terms an amateur might understand, please) what the primary inhibiting factor for core-level progress currently is.  To me, it's a big mystery.

* I'm sure some of us would be prepared to contribute something to defray that initial investment cost.

Gena Support / CAPI Revision Check
« on: June 28, 2011, 01:15:44 PM »
Looks like there may be a version checking issue for the latest Common_api.script on the Gena server.  Internally it shows ...

Think that should be Revision=88.

Win7PE SE HomePage / New Images.script Throws CAPI Error
« on: June 25, 2011, 04:03:17 AM »
Just updated complete from the server and the latest Images.script version (006) is giving me an error "V is not a valid integer" when it invokes the CAPI.  When I go back to version 005 of the Images.script everything seems to work fine again.

Never mind.  Was a version mismatch issue.  It needed a newer version of the CAPI but the Common_Api.script didn't update itself with the others on the server.  Once I downloaded manually the current CAPI fixed the problem.

Plugins / Acronis TI & DD Scripts for x64 & x86 PE Builds
« on: June 21, 2011, 07:00:16 AM »
After much amateurish fiddling (kindly assisted by inputs from Lancelot and JFX in another thread) I've finally come up with scripts for Acronis True Image (Home 2011) and Disk Director (v11) that support both x64 and x86 system architectures under Windows PE builds, including Windows 7.  I'm uploiading them here for whatever usage anyone wishes to make of them, including redistribution, modifications, or whatever.  No attributions are required for any purpose.

In fact, the "magic" is not so much in the scripts themselves as in the versioning, selection matching and proper destination placement of the files for the Acronis Snapshots Manager (snapman) and its DLL support.  This requires some rearrangements of and additions to the PE builder files that are supplied by Acronis in its TI "Plus Pack" or downloaded separately as the Acronis BartPE addon packages for TI and/or DD.  So please read the following carefully.

First and foremost, in order to support the x64 architecture in your PE builds, you will need the snapman.sys file and its version-matched snapapi.dll file from your own Windows x64 installation.  The corresponding files that are included in the Acronis "Plus Pack" or in the BartPE download will NOT support any x64 WinPE build at all.

Secondly, the folder tree arrangement for the files that are included in the Acronis "Plus Pack" and BartPE downloads is very poorly organized for any usage in WinPE building inasmuch as its subfolders do not correspond well with WinPE destination placements.  To use either or both of these scripts you MUST reorganize the structure of those Acronis source folders and files and, if they are to be used for x64 WinPE building, add the required drivers as follows:

1) Move the "Microsoft.VC80.CRT" subfolder out of the "Drivers" subfolder and make it directly subordinate to the main "files" folder that contains the application executable files from the Acronis "Plus Pack" or BartPE download.

2) Make a duplicate copy of the "Drivers" subfolder in a subfolder named "Drivers-x64" and then replace the snapman.sys and snapapi.dll files in that "Drivers-x64" subfolder with the version-matched files from the Acronis program installed under your own Windows x64 set-up.

3) The Iscsi subfolder and the A43 files that are included in some Acronis PE support downloads can be omitted completely, or just left in place as they are.  In any case, they are just ignored and NOT used at all by these scripts as they will normally be dealt with by their own separate WinPE builder scripts if selected for inclusion elsewhere in the WinPE build process.

Please note that Disk Director's own internal menu selection for starting the Acronis Recovery Expert utility does not work.  It never has in my own experience.  The Recovery Expert utility is fully functional, however, and the DD script does include a regular WinPE menu "shortcut" for its selection.

And a note about license keys:  These scripts do not include any, not even the ones that are widely available from the Acronis BartPE downloads.  You'll need to enter them yourself the first time that you run the scripts.  Or, alternatively, you can select the option to have them read in from the registry of the host machine on which the Acronis application has been installed.

Lastly, as with any newly created WinBuilder scripts, these will undoubtedly be found to include some imperfections.  Certainly their amateur "first draft" coding leaves plenty of room for improvements.  The author has, however, done as much testing of the end products as practicable within a short timeframe, including the validation of several True Image backups.  Nevertheless, these scripts are offered "as is" with the usual caveats that the author accepts no liability whatever for their usage or any consequences thereof.  USE THEM AT YOUR OWN RISK!

Regards to all

POSSIBLE ISSUE:  Further testing suggests that the ability of Acronis products to handle REG_EXPAND_SZ registry entries for component paths may be highly inconsistent, even amongst various subversion updates released under the same product heading.  In the circumstances, it is probably safest to use RegAddBoot for ALL such component path entries regardless of the PE build level.   The attachment has been updated accordingly.  If you have already downloaded the original scripts, just comment out the relevant conditional  (If...End) lines and make the RegAddBoot section apply to all builds.

Gena Tutorials / Multibooting With Gena And/Or Other PE1 Builds
« on: June 17, 2011, 10:59:45 PM »
Multibooting With Gena And/Or Other PE1 Builds

For most people, a singular Gena PE build (with or without "sweets") will probably provide an amount of protection that is more than sufficient for any emergency when their PC's operating system refuses to boot normally.  Only those "rare birds" like myself who operate multiboot platforms on a regular basis and who therefore need multiple repair and recovery capabilities need bother to read any further.

One of the major frustrations for people wishing to create and maintain multiple preinstallation environments is the necessity for including the complete range of applications and utilities within each PE build.  My own case can serve as an example of the amount of replication and redundancy that is potentially involved in such circumstances.  My multiboot Grub4DOS/BOOTMGR menu looks like this:

Code: [Select]
title Windows XP PE
chainloader /WXPE/SETUPLDR.BIN

title Windows 2003 PE
chainloader /W2K3/SETUPLDR.BIN

title Windows PE Boot Manager (WIM)
chainloader /BOOTMGR
#  {BOOTMGR handles Win7x64 PE, Win7x64 Recovery, Win7x86 PE, Win7x86 Recovery, Vista PE and Vista Recovery}

title Acronis Rescue Media (ISO)
map /SOURCES/AcronisMedia.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)

title Reboot

title Shutdown

Needless to say, trying to keep every one of those bootable options up to date with its own programs folder containing individual versions of every application and utility used by all of them would be a maintenance nightmare.  The obviously preferable alternative is for all of them to use the same programs folder.  But, quite apart from specifying the same programs folder for all of your WinBuilder and/or other PE project builds, how can that be done? [See Note 1.]

For PE2 (Vista) and PE3 (Windows 7) builds the anwser is quite straightforward.  Each one of those PEs can be created as a Window Boot Manager option (.WIM file) that utilizes the same external programs folder as all of the others.  It is then just a matter of using the Windows BCDedit command line utility (or a GUI interface like NeoSmart's EasyBCD) to include them all in a single Boot Configuration Data (BCD) file.

For PE1 (XP/2003) builds the answer is somewhat tricker as, for reasons best known to Microsoft, their PE1 setups can normally be booted only if their system root folder has a singular name which must be either "minint" or "i386" depending on whether it is booted on a hard drive or on a CD/DVD drive.  To boot both of them (along with any others) on the same HDD primary partition and/or the same CD/DVD therefore requires a certain amount of "abnormal" manipulation to overcome those built-in restrictions.

The restrictive limits that need to be dealt with are contained in two files: an ordinary text file (TXTSETUP.SIF) and a binary file (SETUPLDR.BIN).

Any plain text editor can be used to modify the TXTSETUP.SIF file. In most cases, the only entries requiring modifications will be found under the [SourceDisksNames] and/or [SourceDisksNames.x86] sections of that file. In either or both places you'll see a line such as the following:
1="Boot Disk","\WIN51",,\I386

The "\WIN51" (or equivalent) item is a "flag file" entry.  You can change it to something else if you wish, but the Windows setup loader expects to find a file with that name (in addition to ntldr and in the root of the book disk. The file's contents don't matter; even a zero-byte file will do fine.  The \I386 item specifies the name of the system root folder within which the Windows setup loader expects to find everything else that it needs for booting and loading the system.  For reasons which will be made clear later, any change to the system root folder name in the TXTSETUP.SIF file must be limited to four (4) alphanumeric characters and UPPERCASE is best for multiple disc type destinations.

Now we come to the trickier part that involves modifying the Windows binary SETUPLDR.BIN file. [See Note 2.]  This must be done with an editor that is capable of preserving the integrity of binary files.  There are many such "hex editors", but my own favourite is IDM UltraEdit.

Using a hex editor, you must change all of the "i386" and "minint" strings in the SETUPLDR.BIN file to whatever will be used as the name for the system root folder -- the same one specified in the TXTSETUP.SIF file.  A proper hex editor won't let you change the length of any of those strings, but you can "pad" them with hex 00s where necessary.  That is why the chosen system root folder name cannot be longer than four (4) alphanumeric characters.

Changing the "minint" strings as well as the "i386" strings to make both the same avoids the issue of needing different root folder names on different disc types.  Just be sure to "pad" the shorter name strings with hex 00s. At one point you will encounter "\minint\txtsetup.sif" where the hex 00 "padding" must be added at the end of that entire string (i.e. after the txtsetup.sif file name to compensate for the shorter folder name).

For 64-bit editions, also change "\amd64", "\AMD64" to "\EFGHI" and "amd64\", "AMD64\" to "EFGHI\" (where EFGHI is anything you want, 5 characters long).  Do not replace all the occurrences of "amd64" (only the ones with leading or trailing backslashes) as the others refer to a named section of the txtsetup.sif file.

Lastly, but very important, especially if you intend to burn your multiboot package onto a CD/DVD disc, keep case sensitivity in mind for some early parts of the Windows setup boot process. The name of the "boot flag" file, for example is case sensitive.  If you don't run a PE builder finalization script that handles that issue for you, you'll need to do it yourself manually when copying the files from the project's target output folder to your multiboot destination.  In Gena projects, the "standard" default CreateISO finalization script will do it for you automatically.

Good luck, and happy multibooting!
[Posted here by request.]


[1] This "tutorial" deals mainly with the specific setup boot loader (setupldr.bin) issues involved with the inclusion of PE1 (XP/2003) builds in multiboot environments.  It is not intended as a comprehensive guide for the creation of multiboot discs (CD/DVD, USB, eSATA, et al) using Grub4DOS, Windows Boot Manager and other multiboot loaders for which many other fine guides exist elsewhere.  See, for example, the many other online tutorials available in these forums and at and that cover the specifics of preparing and using various destination disc types for multibooting with WIMs, ISOs and other PE builder outputs and "rescue" utilities.

[2] Special handling is required for the setupldr.bin file of the following Windows editions:
•Windows Server 2003 SP1 and later
•Windows XP Professional x64 Edition
•Windows Server 2003 x64 Edition

In those cases, setupldr.bin has a built-in checksum which must be handled to avoid "NTLDR is corrupt" errors.  With your favorite hex editor, go to hex address 0x2060 and change "74 03" to "EB 1A".

Other World / "Weekend Chat"
« on: June 17, 2011, 10:52:00 PM »
Lancelot suggested in my other thread that we meet here for a chat during what may be his last weekend fully onboard this train.

To be honest, however, i'm really not sure what to chat about.  Since Galapo very kindly helped me to understand the very confused and confusing situation elsewhere (and got himself re-excommunicated there for doing so) I've come here to find out what the so-called "rebels" were actually up to.  And I have read some (not all) of the background posted here.

To me, while I missed almost all of the background events when and where they occured, and I certainly don't pretend to understand all of it, a lot of it looks quite familiar -- in fact, much too familiar.  When the egos and/or personal agendas of people in some kind of authority get bruised by real or imagined slights to that status (no matter how petty it may be) they very often tend to exert whatever discretionary authority they may possess in a way that they believe refutes its perceived belittlement.

As I said in another comment here, most people are able to accomodate and even embrace a wide range of viewpoints without incurring personal animosity.  Unfortunately, some people can't.  Simple as that really.  And it's the ones who can't who are ultimately the losers.  I'm not sure if there's much else to be said about it.

Win7PE SE HomePage / Win7 64-bit PE Builds.
« on: June 17, 2011, 06:50:00 PM »
I'd be very interested in some feedback from those involved in developing Windows 7 preinstallation environments regarding the usefulness and utility of 64-bit PE builds.

My own luck with them has been virtually nil.  In particular, I've found it impossible to build a 64-bit Win7 PE that can support the apps and utilities that I rely on most heavily for "rescue and recovery" purposes.  I can't, for example, get either Acronis True Image (Home 2011) or Disk Director (v11) even to load properly, let alone run.  And neither, apparently, can Acronis themselves.

In the circumstances, my impression is that 64-bit PEs are almost useless.  Would anyone here, much more knowledgeable than I on the subject I'm sure, care to argue that point one way or the other?

Gena Support / System Root Option?
« on: June 14, 2011, 12:41:30 AM »
Is there an option somewhere that I've missed to allow us multi-PE booters to modify the system root to something other than i386 or minint?  I can do it myself manually by editing the SETUPLDR.BIN and TXTSETUP.SIF files, but just wondered if I might have overlooked a feature already available in one of the existing Gena scripts or "sweets" somewhere.

Incidentally, just so that you're aware, that bug workaround for preventing WinBuilder User Agent insertions into the registry doesn't kick in until the main script is triggered.  So, if you're just messing around with various "customization" and so forth, that damned spurious UA entry gets inserted.  The ultimate solution, of course, is the final step in your "todo" list already planned.  Hope it's coming in the not too distant future.  :wink:

Gena Support / Issue with Gena recommended WB version
« on: June 13, 2011, 01:16:34 AM »
I had almost forgotten an issue that I had reported a long time ago with WinBuilder version 77.  It has since been corrected in more recent WB versions, but that older one insists on putting totally uncalled for and useless User Agent entries into the Windows registry such as the following:
Code: [Select]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform]
"User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; "=""

It may appear harmless enough and probably doesn't bother a lot of users at all, but many securely managed internet domain servers (including my own block that User Agent as a bad bot.  As a result, anytime I run a Gena build using its recommended WB version 77, I end up locked out of my own web site until I remove that spurious UA insertion from my Windows registry.

Is there any particular reason why Gena build cannot or should not be run with a more recent WB version?

As a newcomer here (but not to the PE universe) that sounds good.  I'm looking forward to experimenting with my first Gena-based PE build.  And I sincerely hope that the freedom and flexibility includes a little more tolerance for "rebel" efforts (someone else's word, not mine) than seems apparent elsewhere.  Rebellion is not, after all, an entirely negative attribute under some circumstances.

Anyhow, without wishing to say too much, I just wanted to express my personal thanks to Galapo for helping me in "another place" to sort out my befuddlement about the current situation.  And I'm very sorry if my confusion there contributed in any way to the "excommunication" that was imposed on you as a consequence.  :sad:

Pages: [1]
Powered by EzPortal