Their current start-up process in WinPE environments seems to be have the "good intentions" of ensuring that the user will see drive letters assignments "as expected" -- i.e., corresponding to those assigned when Windows starts normally. For that purpose, it appears to load and read the SYSTEM hive on what is normally the C: drive. Unfortunately, the process can totally screw up the program drive letter assignment of the Winbuilder PE project itself and it also seems to involve some drive letter mapping that can sometimes result in one or more drives disappearing completely from the Windows Explorer.

The resulting mess can usually be undone manually via the PE build's drive managment interface, but it's one of those cases of "good intentions" paving the path to hell. Otherwise, I like their backup utility very much, especially the user interface which is much superior to Paragon's IMO, and I've purchased a full single Reflect Pro license for further experimenting. It's required for entry into Macrium's own forums, BTW.

I'm still looking for whatever WinPE setting or component triggers that Reflect behaviour, but I've had no luck so far and I've heard nothing further from Macrium. (Typical British reticence. Copy of my follow-up below.) If anyone else succeeds in discovering that trigger, please pass it along.

Hello John.

Thanks for your kind consideration of my developmental inputs. Much appreciated. In the meantime, however, if it's not a deep dark secret, perhaps your developers might be persuaded to reveal the "trigger" for that Reflect behaviour in Windows PE environments. If allowed to know what WinPE component or setting causes it, especially the drive letter re-assignments, I might be able to find a temporary workaround pending the developers' ultimate decision about providing a start-up command switch.

I do realise, BTW, that it is done with the best of good intentions -- i.e., recreating the "normal" drive letter assignments for the end user. Unfortunately, however, it completely messes up Windows PE environments where the application programs drive letter is specified by the PE build itself. Other than that, I like the Macrium backup utility very much, especially the user interface which is much superior to Paragon's IMO. (The less said about Acronis' latest misadventure, the better.) I've now purchased a full single Reflect Pro license for further experimenting since it's required for entry into Macrium's own forums.

Best regards,
Richard Virtue

Well, that was quick. They'll "consider" my request for disabling their WinPE misbehaviour. Here's their brief reply verbatim:

Hi,

Thanks for your interest in our software.

The licensing is per machine, so a single license will cover all you windows installations on that one machine.

We will consider your requirements regarding the windowsPE behaviour, and thanks for the note on the envar expansion.

Kind regards
John Pendleton - Macrium Support

Known issues:

- screen resolution switch to 1024x768 on start macrium reflect

- automatical autoassign driveletters on start macrium reflec

Very annoying. In other ways I like the latest Macrium Reflect proggy very much, but it's insistence on re-assigning drive letters and so forth is just not accptable for many (most?) Winbuilder WinPE multipurpose set-ups. Here's a copy of my inquiry about it and I'll post any response from them if/when i get one.

I've been evaluating the Macrium Reflect "Pro" edition (reflect_pro_v5.0.4368 trial setup) and have a couple of pre-sales questions for you, the second of which may need some input from your technical support staff.

The first relates to multiple installations on a single physical machine. My primary working platform is a multiboot system that can boot to either a 32-bit environment (WinXP or Vista) or a 64-bit environment (Windows 7). My question is whether a single Reflect Pro licence would permit and support installation and registration under all three OSes on that single platform.

My second question relates to Macrium Reflect's behaviour (I'm tempted to call it MISbehaviour) when it runs in a Windows PE environment. I like to create my own WinPE builds (using WinBuilder) and have no problem with including Reflect Pro as one "rescue utility" (among others) in any of my own 32-bit or 64-bit WinPE builds. When initialized, however, it insists on re-assigning drive letters, changing screen resolutions and creating non-functional (* see note) file associations. My question is whether there is any way to disable that strange behaviour or its triggeing mechanism with some kind of start-up switch parameter.

Thanks in advance for you assistance,
Richard Virtue

__
*NOTE: Tell your developers that file association commands that use environment variables such as %ProgramFiles% in registry entries must be entered as REG_EXPAND_SZ values. Plain REG_SZ entries don't work with envars. Strangely, they've done it properly for the file association icon entries, but not for the actual command entries in the registry. And pre-entering one's own correct REG_EXPAND_SZ values in a WinPE build doesn't help. Macruim Reflect Pro insists on overriding them when it is initialized in a WinPE environment.

Confirmed. The Paragon HDM-12 script has been revised (current version 005) and uploaded at http://reboot.pro/16493/

Once again, thanks very much, Erik.

Script revised and updated (v.005) to handle the HDM-12 "Pro" edition by including "Dont_Eject" parameter in shortcuts. However, individual users may still need to make corresponding revisions in the program's ExpLauncher.ini file. For details please see ErikFL's comments at http://reboot.pro/16...post__p__151525

WOW! That was quick detective work. Looks like you've nailed it dead on the money, Erik.

Pargon's own WinPE package for their HDM-12 Suite ("non-pro" edition) already includes that "Params_6=Dont_Eject" entry in its ExpLauncher.ini file and, in fact, a similar "Dont_Eject" entry for almost ALL of the sub-menu items in that .INI file. Maybe they figured the "pros" didn't need it. Or else they just forgot.

Anyhow, in the circumstances, it seems unlikely to be any problem with including that parameter in the shortcuts that are created by the script. I'll verify that directly within the next day or two and, if confirmed as I expect, I'll definitely revise and repost the script accordingly.

THANK YOU very much for your excellent and most welcome contribution. Great effort!

Thank you, Erik, for that very clear explanation of the situation you've encountered. As the "non-pro" edition of Paragon's HDM-12 Suite starts and runs fine under both 32-bit and 64-bit Winbuilder PE builds using a normal shortcut for its "launcher.exe" executable, I would expect these issues must be related to some component of the "pro" edition only. Possibly even a deliberate effort to limit its portability,

Unfortunately, I don't currently have a copy of that "pro" edition myself to confirm. If you are successful in developing a script modification that can rcognise and compensate for the "pro" versus "non-pro" differences and will post a follow-up here, I'd certainly be interested in adopting any such solution.

All users of Paragon products should also be aware that they have recently announced termination of their redistribution agreement with Microsoft for their own pre-packaged WinPE "rescue and recovery" package. Apparently they'll be providing some kind of WinPE self-building alternative in the future (presumably requiring a full WAIK download by the user) but the details remain somewhat unclear at this point. See this thread in the Wilder Security forums.

And thank you too. Don't hesitate to add the new HDM-12 script to your own download listings if you wish. You're entirely welcome to do so. I really don't care one bit about having my name on anything.

Howdy. And thanks for the info. Recognition and credit isn't really any concern to me, but I guess I should do my own uploading work. I didnt know that I had that option here myself. I couldn't add it to the scripts that The Hive had already uploaded for me. So I created a new one at http://reboot.pro/fi...aragon-hdm127z/

File Name: Paragon-HDM12
File Submitter: Arvy
File Submitted: 08 Mar 2012
File Updated: 29 Mar 2012
File Category: App scripts

Winbuilder PE1/PE2/PE3 projects script for:
Paragon Hard Disk Manager 12 Suite

An all-in-one suite to protect, maintain and manage your PC includes:

• Every essential solution to manage today’s hard drives
• Full range of backup, recovery and partitioning solutions
• Fast migration to new HDDs, SSDs and virtual machines
• Efficient disk maintenance and optimization

For additional features information, see the Pargon HDM 12 Feature List.

For additional script development information, see this Winbuilder forum thread.

Click here to download this file

I've uploaded a script for the newly released Paragon Hard Disk Manager 12 Suite to my own server if The Hive or anyone else would like to add it to the Winbuilder repository with the others.

As before, I've tested it with the current Win7PE SE project (both x86 and x64 builds) but it should work equally well with any other Winbuilder PE1, PE2, or PE3 project. The only changes are in the support driver and DLL files that are embedded in the script. It should be noted, however, that Paragon's utilities run with their own virtualization capabilities which may not run well on top of other virtual environments. That's inherent in the applications themselves, not a script issue.

Tried with and without UIM and same. x86 only.
However on Install into Running PE, did NOT try without Hotcore

I have a suggestion for you. Before including the Paragon app in your PE build and running it in Vbox, try disabling the application's own virtual mode. You can either do so via the application's user interface: Tools -> Settings -> AllowVirtualMode:Off. Or you can edit the program/settings.xml file directly: <AppVirtualOperations>false</AppVirtualOperations>.

I suspect the combination of "virtuals" (Vbox + the app itself) may be causing a problem for you.

Amazing. What will they think of next?! Don't remember seeing that one before. Thanks

Fixed in version 003. See OP. Original download files updated.

UPDATE -- Version 002 -- 2012-01-22 -- Both Scripts -- See OP for download links.

Version 002 adds MSXML4 support for the Paragon help files reader and an option for installing Paragon's old pre-VSS "Hotcore" device class filter service. Usefulness of the latter in a WinPE environment seems questionable, but the option (unchecked by default) has been added in response to a request. Note that selecting the "Hotcore" installation option may overwrite UpperFilters values entered by other applications for the Volume device class GUID={71A27CDD-812A-11D0-BEC7-08002BE2092F}. And, of course, the reverse is also possible depending on the PE build order. It just an inherent problem (for software developers, not just me) in selectively handling such REG_MULTI_SZ registry insertions.

Actually, ATIH 2012's "rescue disk" ISOs are probably the least of its many issues. Compared with its "system takeover" device class filter services and drivers that bypass your operating system's normal hardware abstraction layer, their bootable ISOs are relatively innocuous. And some of the current ATIH 2012 release's new "features", such as it's so-called "syncronization" capabilities, are marketing gimmicks of questionable value at best, assuming you're willing to pay for the required multiple licenses and can get them working at all with their new "phone home" activation nonsense. Don't take my word for it. Check the many end user reports in Acronis' own forum such as this one.

PLEASE take my advice and do a full-system backup before installing ATIH 2012. Even if you only install it on a trial basis, those OS HAL bypass filters can be nearly impossible to get rid of without BSOD problems if you try to uninstall Acronis and switch to anything else. For anyone who may be interested in further details about the registry CurrentControlSet leftovers that may persist indefinitely with system-altering effect, I've posted some additional info at Wilder Security.

Strange. Does it matter whether or not you select the "Install Universal Image Mounter" option? UIM doesn't appear to be of much use in a WinPE setup anyhow and these scripts don't include any option for installing Paragon's old pre-VSS "hotcore" device class filter. I thought about it and could add if anyone wants it, but one doesn't normally anticipate a requirement for live disc "shadow copying" under a WinPE environment in any case. The only other driver seems to be biontdrv.sys (some kind of video helper I think) and it is included within the program folder but not initialized by the script. Loaded by the proggy startup itself perhaps?

I've also "advertised" availability in Paragon's own forum, but It may be a while before you get many other responses from end users as it's still quite new.

Thank, your help would be welcome ...

I looked all over for that old PHP script of mine but can't seem to find it anymore, So guess I can't give you much help after all. But i'm sure you've done something quite similar yourself.

These script must be run from Ram in VM, it may be different when burned to Media, (HAVEN'T TESTED YET)

Not sure that I understand. Are you suggesting that you'd like to see a "Run from RAM" option in the scripts themselves? They work fine for me when either app is installed under the %Target_Prog% folder for the bootable WinPE media. Haven't actually tried them in Vbox myself.

If you think I can help in any way, let me know. I think I recall developing a PHP script to do something like this a long time ago just for my own fun. Or maybe it was the opposite: converting from updates.ini file listings into MySQL database records. Can no longer remember the details.

Didn't really intend to suggest any serious need, Nuno, although some kind of "common repository" might might be worth thinking about for scripts that have "universal" applicability for all Winbuilder projects. If nothing else, it might help to provide better focus and consolidation for some of the maintenance and updating efforts for both developers and users. On the other hand, it might be one of those "herding cats" ideas.

I'm fine, but not getting any younger, of course. Been around from time to time and even tried visiting the "breakaway group" a while back. Bitter territory that is. Wasn't well received. Anyhow, the less said about that the better, I suppose. Hope all's well with you too.

Okay, thanks again. No big deal about the winbuilder.exe Downloads tab. I was just curious. Maybe some of the individual WB projects managers will pick them up for their own HD Tasks inclusions later on.

Sorry about not changing the internal version number. Guess I should have, but thought I caught it quick enough not to bother. If you have a chance to test/verify yourself and find any other goofs, please let me know so I can fix my own originals.

can you please confirm if the p2p feature is supported in HDM11 Suite ?

Yes, in fact the P2P Adjust OS feature has been updated in the Paragon HDM Suite version 11. Full feature list at http://www.paragon-s...l/features.html

Thanks, TheHive. Much appreciated. Does this mean that they'll now be available for PE builds from within the winbuilder.exe Downloads tab?

There were two small errors in the initial scripts uploaded to my own web site which I corrected as soon as I noticed (fixed now) but I don't think I got them quick enough to prevent them getting into your "relayed" uploads here. They're non-fatal checkbox reference mistakes, but the fixed versions should be re-uploaded for yours when you have time. Errors were the same in both scripts. For any other fast downloaders, lines 38 and 42 should refer to CheckBox1 (not CheckBox2) as follows.

If,%pCheckBox1%,Equal,True,Run,%ScriptFile%,Process-InstallUIM

...

If,%pCheckBox1%,Equal,True,Run,%ScriptFile%,Process-InstallUIMx64

I've made for my own use a couple of Winbuilder scripts for Paragon Software's latest releases of Backup and Recover 2012 and Hard Disk Manager 11 Suite. FWIW, I'd like to offer them to the Winbuilder community, but since I don't maintain any online Winbuilder project repository myself, I'm hoping that some person or group who does may see fit to "steal" the scripts and maintain them as their own. Anybody is entirely welcome to "customize" them in any way they wish, including the authorship identification. They have been tested with both x86 and x64 builds using the current Win7PE project release, but they should work with any Winbuilder PE1, PE2, or PE3 project. Unlike Acronis, EaseUS and some others, Paragon does not (Thank You!) use clunky device class filters to bypass the operating sytem's own hardware abstraction layer. So these Paragon scripts should support any storage device supported by your OS natively.

For now, they can be downloaded here: Paragon Backup & Recover 2012 Script and Paragon Hard Disk Manager 11 Script They will NOT be maintined there by me for the long term.

PLEASE NOTE: Both scripts include a few support *.dll and *.sys files that are common to all of Paragon's current software and that have been made publicly available in their free CNET download package. These few common files were embedded to facilitate the "Install Universal Image Mounter" option that is included in both scripts. (In fact, the scripts are almost identical except for interface cosmetics.) To actually use either of them, however, the script's "Path to Files" entry must point to the licensed and installed Paragon application, even in the case of their free editions for home users.

__

Original Download Files Updated 2012-01-23 -- Version=003
HistoryNotes=
History002=Added option for installing Hotcore device class filter
History002=Added msxml4 support for Paragon helpfiles reader
History003=Added RegMulti APPEND handlling for device class filter (for WB version 80+ only)

__

2012-03-06: Script added for newly released Pargon Hard Disk Manager 12 Suite .

Is it just me, or has the lastest version (v19) of the Internet Explorer 8 script introduced some new problems for others as well? So far, I've only tried using it with a Win7x64 source and I get fatal errors for each build attempt. The problem (or at least part of the problem) seems to arise from the revisions to the [CopyFilesPRG] section which is currently as follows:

DirMake,"%Target_ProgDir%Internet Explorer"

FileCopy,"%Source_ProgDir%Internet Explorer*.*","%Target_ProgDir%Internet Explorer"

DirMake,"%Target_ProgDir%Common Filesmicrosoft sharedVGX"

FileCopy,"%Source_ProgDir%Common Filesmicrosoft sharedVGXVGX.dll","%Target_ProgDir%Common Filesmicrosoft sharedVGX"

In previous versions, it was as follows:

DirMake,"%Target_ProgDir%Internet Explorer"

FileCopy,"%InstallSRC%Program FilesInternet Explorer*.*","%target_prog%Internet Explorer"

DirMake,"%target_prog%Common Filesmicrosoft sharedvgx"

FileCopy,"%InstallSRC%Program FilesCommon Filesmicrosoft sharedvgxVGX.dll","%target_prog%Common Filesmicrosoft sharedvgx"

The old way seemed to work okay, but the revised coding produces a fatal "unable to copy" error for me. Complete log on request.

Might be useful to add WinSCard.dll to the 5-Wow64.script as its usage appears to be increasingly common in some recent "rescue utility" application releases that rely on WOW64. One example is the most recent Paragon Hard Drive Manager 11 Suite which is now very "portable" for all 32-bit and 64-bit WinPE builds. No more stupid device class filters, but it does need WinSCard.dll in the WindowsSysWOW64 folder.

You're welcome. You might want to wait a while before upgrading as the intial Acronis release is (as usual) not completely "bug free." In any case, to avoid installation problems, be sure to UNinstall any previous version completely before installing the new one.

The "tricky" part for any WinPE scripting is accommodating both x86 and x64 builds which requires some reorganization of the Plus Pack (or BartPE download) to add those 64-bit fltsrv.sys, snapman.sys and snapapi.dll files. And, for x64, snapapi.dll needs to be copied to the "%target_win%\SysWOW64\" folder instead of the "%target_sys%\" folder. The relevant ControlSet001 entries are then handled as follows:

Hive_Load,HKLM

reg_add,0x1,"%reg%\ControlSet001\Services\fltsrv","DisplayName","Acronis Storage Filter"

reg_add,0x2,"%reg%\ControlSet001\Services\fltsrv","ImagePath","system32\drivers\fltsrv.sys"

reg_add,0x4,"%reg%\ControlSet001\Services\fltsrv","ErrorControl","1"

reg_add,0x1,"%reg%\ControlSet001\Services\fltsrv","Group","PnP Filter"

reg_add,0x4,"%reg%\ControlSet001\Services\fltsrv","Type","1"

reg_add,0x4,"%reg%\ControlSet001\Services\fltsrv","Tag","8"

reg_add,0x4,"%reg%\ControlSet001\Services\fltsrv","Start","0"

If,Not,%SourceArch%,Equal,x86,reg_add,0x4,"%reg%\ControlSet001\Services\fltsrv","WOW64","1"

reg_add,0x1,"%reg%\ControlSet001\Services\snapman","DisplayName","Acronis Snapshots Manager"

reg_add,0x2,"%reg%\ControlSet001\Services\snapman","ImagePath","system32\drivers\snapman.sys"

reg_add,0x4,"%reg%\ControlSet001\Services\snapman","ErrorControl","1"

reg_add,0x4,"%reg%\ControlSet001\Services\snapman","Type","1"

reg_add,0x4,"%reg%\ControlSet001\Services\snapman","Start","0"

If,Not,%SourceArch%,Equal,x86,reg_add,0x4,"%reg%\ControlSet001\Services\snapman","WOW64","1"

reg_add,0x7,"%reg%\ControlSet001\Control\Class\{4D36E967-E325-11CE-BFC1-08002BE10318}","UpperFilters","fltsrv"

reg_add,0x7,"%reg%\ControlSet001\Control\Class\{71A27CDD-812A-11D0-BEC7-08002BE2092F}","UpperFilters","fltsrv"

Hive_Unload,HKLM

Note in particular the "WOW64" entries for for x64 builds.

Not exactly sure where this belongs. Admins please 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 the 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.

I have a much better idea. Why don't you "steal" both those scripts and turn them into something decent.

Actually, I'm serious about that. I just wrote 'em for myself so that I could include those apps in my own multi-boot PEs because I couldn't find any others that would support both 64-bit and 32-bit builds. I figured others might have the same problem and so thought I'd share 'em here for whatever help they might provide to real script writers and PE project developers. I was really hoping that someone in that latter category would take them over as their own. My dev capabilites are strictly amateur and, since they do what I need, I really don't have much interest in any further work on them myself.

PLEASE take them. They're all yours.

Yeah, winsxs can be a real pain. I'd be happy to see it die completely. Perhaps an easier alternative would be just to put the DLL files direclty into the programs folder.

Anyhow, glad to hear that you ultimately got everything working okay.

================================================================================
C:\Program Files\Acronis\Media Add-ons\BartPE\
--------------------------------------------------------------------------------
WinPE.zip 46,240,345 7/6/2011 15:26:32
--------------------------------------------------------------------------------
1 file(s), 0 folder(s) 46,240,345 bytes
================================================================================
[...]
================================================================================
C:\Program Files\Acronis\TrueImageHome\BartPE\
--------------------------------------------------------------------------------
WinPE.zip 46,240,342 7/6/2011 15:26:32
--------------------------------------------------------------------------------
1 file(s), 0 folder(s) 46,240,342 bytes
================================================================================

Looks like you actually have two(!) source choices for some reason. (Both True Image Plus Pack and a separate Bart PE TI add-on installation perhaps?) In either case, you first need to UNzip one of those WinPE.zip files and then organise its contents as explained in my orginal posting here. It's the extracted Files contents from that zip file that the True Image PE script is looking for. So, after you've unzipped and arranged its Files contents, you need to tell the script to look for it in that folder or wherever else you decide to put it.

Acronis is VERY inconsistent and their PE layouts are very poorly organized for WinBuilder usage. In the case of DD, yes it does locate its PE Files addon under Program Files\Common Files\Acronis\DiskDirector\WinPE\ which, depending on the DD release subversion, may either be zipped or unzipped there already. In the latter case, it's just a matter of arranging them as explained above and pointing the DD script to that Files location.

Sorry for the confusion, but it's difficult to write a simple-to-use script for these particular apps, especially when their installation packaging and operational quirks seem to vary widely from one release to the next and Acronis itself, despite several requests, provides no help at all for 64-bit WinPE support. I was actually hoping that someone else might improve my very sloppy "first draft" script coding. For my own multi-boot platform usage, I was trying to make them as "universal" as possible (multi-PE# and multi-architecture builds) and they do work once they have been properly sourced, but I'm not proud of their crude internals.

It needs to find the Acronis Bart PE or Plus Pack files in the folder location that is specified by the entry in the "Path to Acronis PE files" box. In addition to the progam executable (TrueImage_starter.exe for TI or ManagementConsole.exe for DD) it also needs to find the required driver files in a subfolder as explained above. For a 32-bit build, it looks for them in the %pFileBox1%\Drivers subfolder, and for a 64-bit build, it looks for them in the %pFileBox1%\Drivers-x64 subfolder.

If any of those executable and driver file requirements aren't met, it exits with a "Not Found" error message. To provide more specific help, I'd need to know more about the actual location and layout of the Acronis BartPE and/or Plus Pack set-up on your system. Usually, for example, the location for the required True Image files would be specified something like "C:\Program Files\Acronis\TrueImageHome\BartPE\Files". But many people, myself included, relocate and rearrange them for their own particular PE building convenience.

After much amateurish fiddling (kindly assisted by inputs from Lancelot and JFX in "http://theoven.org/index.php?topic=147) 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 posting it here for whatever use anyone wishes to make of it without any limit or restriction of any kind, including redistribution, "rebranding", or whatever. No attribution is required for any purpose.

The critical usability factor 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 Windows 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 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 caveat that the author accepts no liability whatever for their usage or any consequences thereof. USE THEM AT YOUR OWN RISK!

Regards to all
"Arvy"

 AcronisScripts2.7z   5.89KB   1514 downloads

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.

Old Boney had some very interesting ideas, like marching into Russia, but "controlled chaos" seems more like an oxymoron than a wise strategic philosophy. If that's what he was trying to do at Waterloo, it didn't seem to work out so well for him in the end.

Ahhh, thanks for that clarification. I guess I misunderstood your earlier response saying that "this issue was fixed long ago in my projects." I took that to mean that your projects provided a direct solution to my orignal issue with the WinBuilder-LiveXP project itself and its component scripts. In fact, you are offering a self-contained alternative to that project. I'll have a look at it along with all the others.

Thanks for the suggestion. Looking on the positive side of the expanding chaos of PEs, pre-built "rescue" disks, and so forth, it certainly does provide a wealth of options and possibilities to try.


....


P.S.: For those who, having followed this somewhat convoluted discussion and who may be curious about the end result, here's what I ended up doing as a "stopgap" solution until I have more time to explore that vast and chaotic universe of other options out there --

I extracted the 7-Zip v9.20 files from the newer 7-Zip_File_Manager_SJL.script (v31) and used them to replace the encoded files in the older 7-Zip_File_Manager_SJL.script (v25) that works with the LiveXP package that is currently available from the "official" WinBulder project server.

Now, having pretty much reached the limit of my tired old brain's capacity for befuddlement here, I think, just for a change of pace, I'll sneak on over to "rebel" territory (Nuno's word, not mine) and see what they're actually up to over there. Happy WinBuilding to all and thanks for ALL the various comments and suggestions.

Are you serious? I'll answer that if you'll first tell me what war commentaries have to do with the proper management of preinstallation environment projects and providing public support for them here or anywhere else.

@Arvy


This issue was fixed long ago in my projects, give 'em a try; if you have specific issues, I'm here to help.

Now I'm REALLY confused. Exactly what are "your" LiveXP projects and where might WinBuilder find them? They don't seem to be where my WinBuilder.exe itself looks for current LiveXP downloads.

When I checked my own LiveXP setup under WinBullder against the "complete" downloads available from the LiveXP WinBuilder projects server, it said that everything I had (both apps and tools) was fully up to date. However, my LiveXP script for installing 7-Zip still showed as script version 25 and the 7-Zip exectutable files contained therein as version 4.65. That script does work fine. However, I wanted 7-Zip version 9.20 for my PE buld and so I found a more recent 7-Zip_File_Manager_SJL.script (v31) elsewhere and tried that. It was that version 31 of the 7-Zip_File_Manager_SJL.script ("borrowed" from another WinBuilder project and containing version 9.20 of 7-Zip) that wouldn't work for me. Where would I tell WinBuilder to look for your LiveXP project updates?

As I said, "chaos" may have some theoretical attractions for some people, but practicable, orderly and consistent project support for end users doesn't appear to be one of them as I see it. From this peasant's perspective, it's more like a big confusing mess. Not laying any particular blame on anyone; nor am I questioning anyone's good motivations. Just saying how it seems from one "outsider's" point of view.

No it does not. Chaos, if anything, prevents wars.

Chaos may disrupt some of the hierarchical communications that facilitate organized warfare, but it's questionable whether the hierarchy or the peasantry suffer most from that communications breakdown in the long run. This particular peasant (amongst others, I suspect) relies on some semblance of ordered information and communications to find his way through the maze.

Thanks, agni. I appreciate the advice, but it doesn't really address my particular issue.

Don't get me wrong. Although I've been playing with PEs since before that tutorial was written, I can still use all the help anyone can offer. But knowing how to use LiveXP and others, however, isn't really my current problem. It's finding my way through an increasingly disparate universe of PE options and what appears to be a growing range of divergences throughout that universe. I'll get there eventually once I've sorted out my own minor confusion with some new directions and trends here and elsewhere.

Okay, thanks for the "living PE1 project" links. I'll definitely have a close look at ALL the options. It's always good to have some voluntary "free market" choices.

It's too bad about the underlying disagreements here, but unfortunately it sometimes seems that not all divergent viewpoints can be accomodated forever within a singular communal framework. Such frictions are certainly nothing new and no one should let them occupy too much mental or emotional territory for too long. IMHO competitive thinking and ideas should actually be regarded as an asset rather than otherwise.

Thanks for the suggestion. I had hoped simply to include Windows 7 own "native" defragger in the PE build, but if that's not available, the Pirisoft defrag utility would be an acceptable alternative, I guess.

I see. Thanks for that response, Peter.

I guess I missed that "confrontating discussion" here (probably just as well) but some of the more recent comments seemed to suggest that some such "parting of the ways" had occurred. That's unfortunate, but it seems to happen all too frequently with many volunteer projects for various reasons. Too bad. I really liked LiveXP and it's taking me a while to become fully comfortable with some of the Win7PE alternatives. Mostly just because of my aging brain, I suppose.

I'll take a look at that MultiPE project. I did try one of its earlier postings and it aborted with some message about a missing file (project4.ini I think it was) but I haven't tried its most recent update. I'll give it another test run and see how it goes.

Is there a script available somewhere (or an option checkmark that I've missed somehow) for installing Windows 7 own disk defragmenter into a Win7PE SE build? Either 32-bit or 64-bit would satisfy me. I apologise if I've missed it, but I've searched to the best ability of my tired old eyesight and can't seem to find one.

The linked Wikipedia article regarding WinBuilder projects still lists LiveXP under "Actively Developed Projects", but it appears that it may be getting left behind by some recent developments. I've noticed, for example, that the most recent 7-Zip_File_Manager_SJL.script (v31) for installing the current version (v9.20) of 7-Zip doesn't seem to work when used in the current LiveXP project download with the current WinBuilder.exe release. It installs the 7-Zip FM executable and other program files okay, but not its registry associations and its context menu for Windows Explorer.

Is this just a transient phenomenon with some utility modules as the WinBuilder core itself undergoes developmental changes, or should we expect some ongoing and continuing divergence in script support for some of the older projects? And what role (if any) does the Common_Api script play in this overall scenario? Will it also be updated in the LiveXP project?

Personally, although I've "bitten the bullet" and updated my own platform to Win7x64, I still rely on the LiveXP preinstallation enviroment for running many "emergency" recovery and utility apps and would be unhappy to see it fall completely out of the WinBuilder project's updating process.

Got 'em. Thanks.

Very nice job on that Attribute Changer script. You must have run the originator's setup twice on your own system in order to extract all the necessary 32/64-bit files for inclusion in the script. I may be forced to use it and give up my longstanding reliance on Properties Plus. It will be a sad farewell and will take this old codger some time to get used to the new one.

Oh, lighten up, for pete's sake. The only thing senior about me is my age.

Yes, I did make a similar suggestion for other WinBuilder PE projects a long time ago. I just thought that they might also be worthwhile inclusions within the Win7PE project itself.

Anyhow, it's no big deal. I (re)made my own for Win7PE (32-bit only) that includes Properties.Plus along with the Explorer options to display a file attributes column and ISO international format date-times. The registry keys are the same (more or less) as with Vista, except that Win7 uses sShortTime under the Control Panel settings. A copy of my script is attached if you or anyone else wants it.

I haven't made a 32/64-bit script for Attribute Changer (as I personally prefer Propeties Plus) but I can if anybody wants one. I do understand that all the "senior" WinBuilder developers are much too busy arguing about CAPIs and APIs and so forth to be bothered with such trivial end user concerns.

Interesting discussion -- perhaps in the same sense as that old Chinese "interesting times" curse.

I only know that some Winbuilder scripts that I wrote myself several years ago (when XP was the "latest and greatest") still work just fine today when included in a Win7PE SE project build. So, from my perspective, it looks like somebody must be doing something right.

To be honest, I've never really looked very carefully at the "inner workings", and I really don't care much whether you call them collectively a CAPI or a plain old API. In fact, I suspect that at least some parts are a bit of a mess. (Spaghetti code is a common occupational hazard.) But they mostly seem to work okay and that makes at least one "satisfied customer".

Just an outsider suggestion, but more focus on engineering "perfect" end user results and less on "perfect" methodological dogmas might reduce the bumpiness of the road to progress. Or is that perspective too facile?

That sounds reasonable. It's certainly better to err on the side of more certainty for various hardware configurations.

Just a few minor suggestions for "tweaks" whenever your dev team has a bit of spare time on its hands. :

- add an option to display explorer date/times in ISO international format (YYYY-mm-dd hh:MM),
- add the abilty to include other columns in explorer, especially the file attributes display column,
(sort order options would also be nice)
- add an option script for "properties plus", or if 64-bit support is desired, for "attribute changer".


With the possible exception of 64-bit "attribute changer", all of them have been done before in other projects, but would make good optional inclusions in your own Win7PE SE, I think.

THAT FIXED IT! And I'm VERY happy with it. Merci mille fois, Chris!

In fact I'm typing this from IE8 in Win7PE SE running as an ISO loaded by Grub4DOS on my eSATA drive. (Haven't yet tried it as a direct Grub/Bootmgr WIM mount, but no reason why that wouldn't work just as well.) Perhaps I was just too impatient before, but I would suggest making the CdUsb operational wait time a configurable option in its script.

Apart from that single "glitch", it looks to me like an excellent PE builder. I created my build by running it under Win7x64 (but using a Win7x86 source) and it worked just fine. The end result lets me run ALL of my favourite recovery apps, inclding Acronis True Image and Disk Director with no problems at all. I ran a validation on a previous True Image backup just to be sure.

Excellent! Thanks again for the help.

__
P.S.: Just for your info, Win7's "security essentials" is suspicious of WinBuilder and pops up a warning at the end of the build process. Just click the "Ignore" button.

Okay, thanks Chris. I'll give that extended (60 seconds) wait script a try and report back with the results. It'll probably be tomorrow before I get an opportunity to run another test.

Sure hope that it resolves the CdUsb detection and drive letter assignement issue required for using Win7PE on my eSATA drive. It's big and fast and I've never had any problem using it for anything (ISOs, WIM mounts, PE/recovery builds, etc., etc.) that Grub4DOS can boot on a USB drive. So this peculiar issue is a bit of a mystery.

Attempting to run a Win7PE SE build on my eSATA drive doesn't seem to work when I enable the CdUsb script. I've tried lauching it (using Grub4DOS) both as a "standalone" ISO file and as a WIM file with the CdUsb.Y file in the root of the boot drive with the same results in both cases. I end up with a screen that displays the wallpaper and a mouse cursor, but NO SHELL (explorer) at all.

Everything seems to work fine in Win7PE SE builds if I disable the CdUsb script -- except, of course, I then end up without any proper registry and menu entries for programs that aren't included in memory (i.e., in the WIM image itself) as there appears to be no other equivalent for Nightman's old process that assigned a %CDDRV% value during the boot-up.

Any suggestions? Workarounds? I'd really like to get this working on my eSATA drive as it's much faster than either CD/DVD or USB.

Wow! What a tempest in a teapot! Some people seem to have misunderstood my suggestion as some kind of "back to less ... just plain stupid" idea about limiting winBuilder project options. In fact, it was nothing like that. To the contrary, let the project developers include any and all bells and whistles that they think might possibly come in handy for anyone under any circumstances at all.

My suggestion was really quite simple and seemed (to me at least) to make perfectly rational sense. Let end users make their own positive selections of non-essentials for inclusion in their own preinstallation environment builds rather than having some subset pre-selected arbitrarily based on some developer's notions about what the "average user" should want. Some may disagree with that approach, but I fail to see how it's any more "stupid" or irrational than the current situation whereby pre-selections for "out of the box" PE build inclusions often appear to be little more than accidental or whimsical.

And yes, as pscEx (formerly just psc) mentions, I recall very well when he himself was a very strong advocate for minimalist "out of the box" operability for winBuilder projects. Things seem to have changed somewhat since then.

Yeah, you're probably right, and I suspect I'm just wasting space here. But just a little project coordination and leadership could go a long way toward making things much easier for people who, like some who've posted here, would like to start small and simple and then (maybe) work their way up gradually to the more complex non-essential stuff.

Believe it or not, getting the whole kitchen sink tossed into an initial start-up PE build does tend to overwhelm some people.

All of this leads to a question which, although it would seem to be an obvious one here in this development forum, is probably going to bring me a lot of flak for asking. But, what the heck, I'll ask anyway. At my age, I've long ago developed a hide that is pretty much flameproof.

Why is it that so many WinBuilder projects include so many non-essentials that are pre-selected for inclusion in their PE builds?

The Win7PE_SE project (from which this "skeleton" was extracted) is certainly not alone in that repect, but I'd almost given up on it until al_jo showed us exactly how minimalist it could be made. I can understand that human nature and the desire to "show off" any project's full potential are probably significant factors. But, from the standpoint of not overwheming the end user, wouldn't it make more sense to pre-select ONLY the barebones essentials and let the user add all other options according to his or her actual needs?

Especially for poor old geeks like me who are never quite sure what can safely be eliminated (and who are a bit lazy besides) it seems like a reasonable question. But for those who are strongly inclined to the opposite opinion, please aim carefully at the target and don't hit any innocent bystanders.

Follow-up as promised:-- BEAUTIFUL!!! Absolutely beautiful. That last posted Winbuilder project runs perfectly under my Win7x64 setup without needing any driver installations or other additions of any kind.

I didn't actually burn the ISO file, but I copied it and also the WIM (\sources) file to my multiboot USB drive and made the appropriate entries in the Grub4DOS menu.lst file there. It boots fine either way, but only the ISO boot displays the pretty new Windows 7 startup dynamic.

As an added bonus, it runs most of the 32-bit applications that were already installed by other WinBuilder projects on that USB drive, including my favorite text editor (UltraEdit) and file comparator (Beyond Compare) so that I only need to add their shortcuts and context menu items to this Win7PE project. Unfortunately, my Acronis proggies (True Image and Disk Director) will require a little extra work to make them run with an x64 PE build. If anyone has already done that for the 2011 Home editions of Acronis TI and DD, please post a link.

Congrats, al_jo. Very well done!

This is for those skeptics who thought that Mickeysoft would never catch up with the decade-old WinPE-on-ISO building capabilities of BartPE, let alone approaching anything like the multiboot WinPE-on-USB portability endeavours developed and developing here.

Oh ye of little faith, the answer to everyone's(?) prayers is near at hand. Windows 8 WILL BE PORTABLE on a USB stick! With luck, you might even be able to run Notepad -- but definitely no built-in capability to accommodate third-party apps.

In the meantime, those looking for an official MS-supported solution will just have to be satisfied with their marginal "recovery disk" efforts. Win7 ISO downloads here for anyone who may want one.

What means "need more work to run on x64"? -.- Can you please explain what to attend to run Lighty7PE on x64?

I just meant that, when I tried to run al_jo's project as originally posted in this thread under my Win7x64 setup, it wouldn't run and I had to reboot my system into an older 32-bit Windows OS to make it work. I must admit that I really didn't try very hard to make it work under Win7x64. If I remember correctly, it gave me a error message saying that some required WinBuilder tools were missing for x64 operation.




Okay, thanks, al_jo. I'll download that revised Win7PE64 package and give it another try running under my Win7x64 setup. Probably not today, but I'll definitely follow up here with the results as soon as I can.

Frankly, I have no problem with other WinBuilder packages that provide more (Minimal, Recommended and Complete) options for downloading. But I found that most of them wanted to send me hunting around for additional files (from WAIK, etc.) in order to work. And I'm a very lazy old geezer.

Nice effort. Seems to need a little more work to fully support x64 setups. In my own case, at least, I had to reboot into a 32-bit OS to run it, but it then built okay using my 64-bit Win7 source. Unlike some others, your inclusion of all the necessary files (imagex.exe, wimgapi.dll, etc.) to work "out of the box" is convenient and appreciated.

Just to second the sentiment expressed earlier, if some people would just work a little bit more cooperatively around here, the end result could surely be a truly fantastic product for the "end user", but I suppose that's asking a lot.

Aha! That certainly would explain the absence of any "enterprise" registration.

Yes, I would think you'll need the fully registered version for any serious purpose. That 100MB limitation makes the demo pretty much useless for anything other than a "first glance" in today's world of drive hardware.

And, if you'll take my advice, it's usually wise to uninstall ANY old software before installing new versions, no matter what the promotional material may tell you. Saves a lot of conflicts and confusion in my experience, and you can always put it back again if you change your mind.

Whatever you may find under Acronis\Acronis Disk Director\Settings will NOT help you at all with DD11. It appears that at least a part of your confusion may be due to having previously installed DD10 and not having removed it completely. In any case, whatever the reason, that "key" entry is NOT what you want. DD11 doesn't use it at all.

A proper and successful installation of DD11 onto your local machine hard drive should normally uninstall all those old DD10 entries and install DD11's "enterprise" registration instead, along with that WinPE sub-folder and files that I mentioned to you previously. But if, in fact, you do not have DD11 installed properly and working successfully on your hard drive, you're going to have a very difficult time setting up a fully functional DD11 inclusion in any PE build.

I thought you said in the Acronis forum that you had it working "perfectly." Did I misunderstand your comment again? Both dera and I would like very much to help you, but the complete picture of your situation is somewhat unclear. Could you post another link showing your registry's Wow6432Node\Acronis\DiskDirector expanded instead of Wow6432Node\Acronis\Acronis Disk Director.

No problem. The only thing that matters is to get it working for you.

I'm not dera, but as I told you elsewhere, you want the value from your registry for the Aconis\DiskDirector "enterprise" entry. It gets entered into exactly the same place in the registry for your PE build. For a Bart PEBuilder .inf file, that would be done as follows:

[Software.AddReg]

0x1, "Acronis\DiskDirector", "enterprise", " xx xx ....(etc.).... "

Ah, I see that you did follow my reference here from the Acronis forum. Your answers there made me think that you had rejected that suggestion and were following the old Acronis DD10 instructions which definitely will not work for DD11.

Anyhow, all's well that ends well. Glad you got it working.

For others who may prefer the RegAddBoot approach over using a particular drive letter specified by the script itself, the following substitutions are needed in dera's script.

In the HKU section:

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector","RecoveryExpertPath","%PE_Programs%\%ProgramFolder%\RecoveryExpert.exe"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","fnls.dll","%PE_Programs%\%ProgramFolder%\fnls.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","ftrace.dll","%PE_Programs%\%ProgramFolder%\ftrace.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","icu38.dll","%PE_Programs%\%ProgramFolder%\icu38.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","rpc_client.dll","%PE_Programs%\%ProgramFolder%\rpc_client.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","resource.dll","%PE_Programs%\%ProgramFolder%\resource.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","gc.dll","%PE_Programs%\%ProgramFolder%\gc.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","thread_pool.dll","%PE_Programs%\%ProgramFolder%\thread_pool.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","ntmsapia.dll","%PE_Programs%\%ProgramFolder%\ntmsapia.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","libcrypto9.dll","%PE_Programs%\%ProgramFolder%\libcrypto9.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","libssl9.dll","%PE_Programs%\%ProgramFolder%\libssl9.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","events_trace.dll","%PE_Programs%\%ProgramFolder%\events_trace.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\CommonComponents","core_workers_shared_context.dll","%PE_Programs%\%ProgramFolder%\core_workers_shared_context.dll"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\Settings","WorkingDir","%PE_Programs%\%ProgramFolder%"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\DiskDirector\Settings","SystemInfoPath","%PE_Programs%\%ProgramFolder%\systeminfo.exe"

RegAddBoot,HKLM,0x1,"SOFTWARE\Acronis\WinPE","A43","%PE_Programs%\%ProgramFolder%\A43\A43.exe"

And in the HKLM section:

RegAddBoot,HKLM,0x1,"SYSTEM\ControlSet001\Services\mms","ImagePath","%PE_Programs%\%ProgramFolder%\mmsBundle.dll"

So far as I can determine, when those RegAddBoot items are used, adding the DD11 program folder to the Windows search path is not necessary.

For the curious among you, my problem was none of my above guesses. It was my silly assumption that ANY modern Windows application, especially one intended for use in a preinstallation environment, would be designed to handle registry entries specifying component paths based on Windows environment variables (e.g., %SystemDrive%). Acronis TrueImage and DD10 can. DD11 can't!

DD11 doesn't mind using REG_EXPAND_SZ (0x2) registry entries as such. It just can't handle any environment variables contained therein. The system drive and/or program drive letters must be specified explicitly. So it's back to the old RegAddBoot approach for all of its PE builds I guess.

SHEESH! I wonder what "improvements" Acronis will come up with for their next "upgrade".

Thanks, dera. That works.

Now I just have to figure out what stupid mistake or omission I was making. I got the DD11's license pickup okay, but I think I may not have added its path to the environment as you did. Either that or my use of DirCopy to replace a lot of those individual FileCopy items resulted in some mislocations.

Anyhow, you got it! Thanks again.
__

P.S.: I hope you won't mind, but on the very likely supposition that other Acronis DD11 users may be having similar problems, I've linked to this thread from the relevant item in the Acronis forums.

Has anyone come up with a working LiveXP (or other) plugin for the newly released version 11 of Acronis Disk Director? I'm just about ready to toss this so-called "upgrade" in the garbage and revert back to DD10 for several reasons.

The Acronis DD11 release package includes files that they claim will work in a Windows preinstallation environment, but I've had no success at all with "translating" their .INF file into a usable LiveXP plugin. Both of my DD10 PE and TrueImage PE plugins work fine, but when I attempt to run the DD11 executable from a LiveXP build, it just sits there doing absolutely nothing at all. No functionality, no error message -- NOTHING!

Incidentally, for anyone else who may be tempted to "upgrade" from DD10 to DD11, my advice would be don't. The latter version is missing several features (disk editor, etc.) that were included in the former. Looks to me like another one of Acronis' recent crippled "home" packages designed as a marketing "teaser" ploy to get people to buy a fully functional "professional" package. Great way to double the corporate profits - NOT!
__
EDIT: I've just noticed that the .INF file included with the Acronis DD11 release specifies copying MachineInstanceProvider.dll to the PE build, but that file is nowhere to be found in the DD11 release package. I suppose that might account for at least a part of the application's start-up problem in the Windows preinstallation environement, although it is also absent from the primary DD11 installation on my hard drive which seems to work okay.

Yes, okay. Thanks dera.

In any case, what I was really curious about were JonF's final methodological approach for determining the drive letter variable to be entered into the registry and his placement of that part of his process into the overall VistaPE start-up sequence.

As you point out, the latter factor appears critical to the ultimate impact (if any at all) of the EnvUpdate() function. I'm puzzled about why it should be necessary to keep it in memory if the session manager is actually able to establish it subsequently as it does with all the other entries that are held under the same environment key in the registry.

Sorry. I meant the script that your link (above) pointed to. Anyhow, I'll be very interested in seeing JonF's final solution if he's willing to post his Preloader.au3.

@dera: If you're asking me, our findings appear to be similar with respect to the start-up sequence and EnvUpdate() results. The reason my AutoIt script checks ALL drives for the flag file (not just CDROMs as in your script) is because I sometimes boot VistaPE and its programs located on a USB drive.

This file ran a compiled AutoIT program which put CDDrive in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and ran the envupdate function ...

Interesting. I'm very curious about that part of your process. Perhaps you'd be willing to show us your PreLoader.au3 script file. Whatever method Nightman was using to establish his %CDDrive% envvar for VistaPE's RegAddBoot process, it seems quite transient and not available at that point in any case. I found that I had to do something like this:

#NoTrayIcon

$cddrv = EnvGet("CDDrive")

$drives = DriveGetDrive("ALL")

If NOT @error AND NOT $cddrv Then

	For $i = 1 to $drives[0]

		$flagfile = $drives[$i] & "\vistape.cfg"

		If DriveStatus&#40;$drives&#91;$i&#93;&#41; <> &#34;UNKNOWN&#34; AND DriveStatus&#40;$drives&#91;$i&#93;&#41; <> &#34;NOTREADY&#34; Then

			If FileExists&#40;$flagfile&#41; Then

				$cddrv = StringUpper&#40;$drives&#91;$i&#93;&#41;

				ExitLoop

			EndIf

		EndIf

	Next

EndIf

RegWrite

&#40;&#34;HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment&#34;, &#34;CDDrive&#34;, &#34;REG_SZ&#34;, $cddrv&#41;

EnvUpdate&#40;&#41;

That's the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment entry I've dbeen doing.

Understood. But your comments about using the EnvUpdate function made me think that you were trying to resolve some post-initialisation problems with the propagation of that system variable.

Propagation rather than setting is also the problem with my own suggestion, BTW. There's no difficulty at all in setting any HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment entry via the vistape.cfg route. However, the initialisation sequence appears to be such that it does not get propagated as a system variable when that method is used. It will definitely require something such as your proposed pre-loader that occurs earlier during start-up process, following quite soon after identification of the %CDDrive% letter.

@JonF: You might consider Window's own setx.exe -- http://technet.micro...104(WS.10).aspx

Setx, in the case of system variables, basically does what you've tried with the session manager and then broadcasts the changes so that it doesn't need a system restart for propagation. It can thus add and change system and/or user variables while the session is running.

It may also be worth noting that the PE Shell Swapper has the ability to set and propagate an environment variable.

However, to be universally effective at start-up, you'd really need to get that envvar into the session manager's registry entries before initialisation somehow. Is it not possible for vistape.cfg to handle that singular session manager setting in lieu of all those other %CDDrive% entries it currently handles for individual items? If either it or your own pre-loader does so early enough, most of the latter could then use that system environment variable except for those few cases where their own individual RegAddBoot entries might actually be necessary.

I'm sure my simple minded analysis must be overlooking some impediment. What am I missing?

__

I feel you will be a good member of "Porcupine fight club"

Thanks for the welcome and invitation. Actually I've been around for a while, although not so much recently. However, I usually try my best to stay clear of situations where porcupines (or people) are in a defensive mood. I find that it seldom results in the most rational decisions developmentally or otherwise -- not to mention my aversion to sharp quills.

Not sure about ANY, but the most common usage of 0x2 (REG_EXPAND_SZ) registry entries is to allow environment variables to be used in locating executables (EXEs and DLLs) and default icons (often numerically identified within an executable). I suppose there may still be a few "old clunkers" around, but I can't recall seeing any recent cases under either XP or Vista where that doesn't work just fine. In fact, there are some CurrentControlSet instances where ImagePath entries just use relative paths (e.g., system32\DRIVERS\ACPI.sys) but they're not really relevant to this discussion.

The large majority of REG_EXPAND_SZ registry entries are based on the %SystemDrive% or %SystemRoot% environment variables, but there certainly are some that use %ProgramFiles% such as the entry for WordPad in most Windows installations. In any case, it would have to be a variable available to the shell on start-up. Other than that consideration, however, I've not seen any other restriction that would prevent the general approach from being widely used -- EXCEPT, as I say, the fact that there is no "across the board" program location variable applicable to all PE variants. Where there are "Run from RAM" options for individual applications, that can also, of course, add to the complexity of any "one size fits all" solution. Some kind of logical "decision tree" may be possible.

P.S.: Your English is just fine. Sometimes my comments may be less explicit than they should be in providing relevant details.

Actually, it has been a long time since I can remember ANY case of an application that works under either XP or Vista that does not work with REG_EXPAND_SZ entries using environment variables to point to an executable or default icon. Are there really any still around? The actual impediment to using it in all cases seems to be that not all PE's have a consistent program location variable equivalent to the %SystemDrive% and %SystemRoot% variables.

If RegExpVar is used for the RegAddBoot process, it appears that the path entries all get converted to literals prior to entry into the registry in any case, regardless of whether they are scripted as 0x2 or 0x1 entries. So that's largely a question of efficiency and boot-up timing.

Well, thanks to EVERYONE in the "prickly porcupine community" who was involved. It certainly was a relief finally not to have to delete that spurious user agent entry every time.

Oh well, a little redundant info never hurt, especially with Mickeysoft weirdness and it's too late now to delete mine.

You can even go in circles. If you include c:\grldr.mbr="Start GRUB4DOS" in boot.ini for ntldr, that choice will also show up directly in your BCD selections. It almost appears as if MS started out to build a truly versatile bootmanager and then quit halfway.

Incidentally, I think setting the timeout for grub4dos to 0 (zero) means waiting indefinitely for a manual selection from the menu.lst if I recall correctly. Probably doesn't matter if there's just one.

Just to elaborate slightly on jaclaz's response, it is possible to use BCD to start one of those other bootmanagers -- either ntldr or grub4dos (grldr.mbr) -- and thus get to DOS via that secondary bootmanager's menu -- either boot.ini or menu.lst. If you make it a single default menu item for the secondary bootmanager, you'll hardly notice the intermediate step.

Until now, I wasn't aware of anything going wrong with the _calculate calls.

You're not alone. I wasn't either until recently when circumstances forced me use some platforms outside my usual "home base" for running it. On the other hand, there's nothing really unusual about them. They're all quite normal and relatively "fresh and clean" Intel-Windows set-ups. So, if psc is right about it being some kind of "timing / sharing / access" issue, I'm not sure what its precise origins would be.

Anyhow, the news with my BootSDI.script revised in accordance with your suggestion remains good. No recurrence of the problem since then. Thanks a lot for your help. Much appreciated.
__
P.S.: I guess this item can be considered as solved so far as I'm concerned. I'll mark it so.

Hmmmm. Well, I suppose any group sharing any common interest can be considered as a "community" -- even an irritable gathering of prickly porcupines.

This didn't seem to fit under any particular forum topic, but I just wanted to say thanks to whomever is responsible for the latest WinBuilder's no longer modifying Internet Settings\User Agent in the host platform registry.

It was an minor issue, but annoying for those of us who manage servers with .htaccess exclusions for potential "bad bots". In the past, after running WinBuilder, I frequently found myself locked out of my own web server until I got rid of that spurious user agent entry.

Thank you for the fix!

Merriam-Webster gives several defintions for "skirmish" including "a minor dispute or contest." So a "minor skirmish" would, I suppose, be a very minor dispute or contest. As I read the original exchange, it seemed to fit, and I wanted to be very clear that I had no such intention in any case.

As for my modified script, I just followed Galapo's suggestion for restoring the existing lines that had been commented out. Copy attached as requested.
 BootSDI.zip   705.31KB   419 downloads

As written before, nobody can be sure

@My friend Lancelot:
I'm very sure that I am more familar with StrFormat than you.
Should I try to give you a _calculate-free version of BootSDI.Script?
(Would cost you two beer if we next time meet in Kusadasi)

Jeez, I seem to be provoking some minor skirmishes around here. I assure all concerned that has not been my intention. Just reporting my own observations and personal comments thereon for whatever they may be worth as I promised that I would in response to Galapo's suggestion.

Yes, one can seldom be absolutely certain about transient "glitches", but on the other hand, all of the results so far, including the logged outputs, do seem to point in one single direction.

As for "a _calculate-free version of BootSDI.Script", I'll happily pass my own modified version along to anyone for half a beer, or even a glass of water.

... timing / sharing / access issues ...

That certainly sounds plausible as the kind of situation that could arise at irregular intervals depending on a range of circumstances in any given case.

No problem. I didn't expect you to reproduce my own exact situation. Actually, what I had in mind was a "dummy" script that could call/run the Common API _Calculate function under a variety of test conditions -- with and without pre-existing calc.txt, sCalculate.exe files, etc. -- to see if it produced a "silent hang" in any case.

As matters stand, it appears fairly certain (as certain as one can be in the circumstances) that my hang up was occuring somewhere in the midst of that "workaround" function. I'm not quite certain whether it's getting stuck on the WebGetIfNotExist for sCalculate.exe or the following ShellExecute: [Hide] command. I'll try more experimentation later when I have more free time and report here if I can reach any more definite results. For now, I'm just happy that it hasn't recurred since I changed the BootSDI.script to use the built-in WB calculation and I'm able to get on with the job at hand.

As promised, here are my results using the same platform, the same WinBuilder (WB078sp4), and all of the same LiveXP scripts that I was using when the problems occurred. As noted above, the log seemed to indicate that the runtime hangup occured at a point where the BootSDI.script called the Common API (v15rev3) to carry out a _Calculate function which, in turn, uses sCalculate.exe and a temporary calc.txt file.

So, as suggested by Galapo, I modified the [Auto], [Optimized], [ImaFile] and [ImaFileTest] sections of the BootSDI.script (version 120) that are involved in ImgSize calculations. In each case the _Calculate "workaround" was commented out and the corresponding lines to use WB's built-in FOLDERSIZE, MULT, DIV and INC functions were restored.

Since making those changes, I have run four identical LiveXP builds -- two where IMdisk/AWEalloc was pre-installed and two where it was installed by the BootSDI.script. So far, there has been no recurrence of the problem. Because the problem was transient, that result is not actually conclusive proof of anything, of course, but I'll report here if it happens again.
__
P.S.: Just a passing thought FWIW, but it might be worth testing to see if a "silent hang" occurs in any script when there's a problem with the temporary calc.txt file output from the sCalculate.exe executable. Unfortunately, my own free time is severely limited right now.

there is a warning on bootsdihelp.rtf but i admit this is not noticable (i wrote that part of the rtf but i also forget this issue sorry ).

Don't be sorry. It's impossible to anticipate every eventuality. In any case, I'm slightly doubtful about that being the root of the problem because, as mentioned, IMdisk did mount and dismount a RAM disk successfully prior to the hangup. However, as you say, it's very difficult to be certain of anything in these circumstances. IF it does turn out to be related, perhaps the warning could be incorporated into the pre-build project verification.

I can probably only get to this after the weekend -- busy few days ahead with other things in life. If you have time yourself, there lines are already in the script and just have to be uncommented and then comment out the corresponding _calculate lines.

Don't worry. Having other things to deal with seems to be a very common problem. Darn it! Unfortunately, I'm away from home right now myself and also somewhat constrained by other people's agendas, but I'll certainly do my best to try that and get back to you ASAP.

__
UPDATE: I've just had exactly the same problem on an identical build run on the same platform, but this time with IMdisk/AWEalloc already installed prior to the run. In the circumstances, I think we can say with reasonable certainty that the issue is not dependent on pre-existing availability (or otherwise) of the IMdisk service on any given platform. I'll report back as soon as I've had a chance to try Galapo's suggestion about using WB's built-in calculation capability in place of the Common_Api.script's version. Probably not until tomorrow evening.

For now, I can only report that it worked once on the same platform where the problem arose previously -- which proves nothing, of course, but it's none the less encouraging. At least it may indicate that some of those calculation "workarounds" are no longer needed with WB078sp4.

Sounds promising. If you'll post or PM whenever the revised version is ready, I'll try to check it out right away on this same platform. However, I can't promise a quick definitive response as I thought I had it licked once before.

It's not consistent, not even in my own case, and such transient events are always the most difficult to pin down. We may never actually get to the bottom of it.

I hesitate to offer more input that may turn out (once again) to have no direct causal significance, but in cases like this, it's almost impossible to know what facts may be relevant. I'll mention, therefore, that this latest glitch occured during a run when the BootSDI.script itself installed IMdisk/AWEalloc onto the build platform. I then rebooted, leaving that installation in place and, thereafter, two subsequent BootSDI builds ran without any problem. Again, that may be purely coincidental.

Unfortunately, I didn't actually check MMC services during the problematic first run to ensure that the IMdisk service was actually running. But I would assume that it must have been because it did mount and dismount a RAM disk (as drive Z:) during its initial iteration. The hangup, whatever it is, appears to follow that initial dismount.

Well, I thought I had it beat, but the BootSDI.script hung again today. The only changes since my last successful run were a few updated LiveXP items, including Galapo's latest Common_Api.script update (v15rev3 for LiveXP) and the most recent update for the BootSDI.script itself (Version 120).

There are still no error messages of any kind whatever, other than the manual abort STOP after waiting for about half an hour. The first iteration of the script's RAM disk building process completed and dismounted succesfully and it deleted that preliminary BOOTSDI.IMG file. After that, it appears to hang while using the API to process a Calculate function! It never gets to the second RAM disk building iteration that normally follows and creates the final BOOTSDI.IMG output.

I'm baffled. Maybe the attached zipped copy of the complete log will offer you a clue.
 log.zip   532.91KB   378 downloads

(changing all scripts today with txtsetup flag and again changing all for the new flag (what ever the path, maybe only replacing) is a bit too much work, I hope you understand my reason of waiting which i guess will not be too long.).

Yes, I understand your reason. However, it took me less than 20 minutes to revise the 8 or 9 scripts involved using a text editor (IDM UltraEdit) that handles regular expression "search and replace" functions. And it would take even less time to "undo" now that their process branching is based on a single flag item. Anyhow, if anyone does want the revised versions "ready made", they can be downloaded from my own FTP server at ftp://ftp.virtech.org -- login with user name: anonymous@ virtech.org, password: anonymous (Use a proper FTP client rather than a browser.)

Just an idea, have you tried vdk option instead of imdisk ? (with using regaddboot lines on 7z)

No, sorry, I haven't tried that. Having made the above-noted script revisons, I no longer have any runtime problems with BootSDI. In fact, it now runs perfectly even if I deliberately set the script process selection flag falsely to make it use RegAddBoot in all cases. I guess, as you say, it's just one of those mysteries that may resurface with more and clearer info later on.

I wasn't referring to anyone in this particular discussion, Lancelot. Looking beyond, however, can you not perceive any vague similarity to any individual anywhere who currently eats no hay himself but who bars from the manger those lesser creatures who are trying their best to get there? If not, just forget it. It was merely a passing reflection of my own perspective on the more fundamental "roots of the problem" that you mentioned.

As for waiting to choose a path, that would be fine. But, in fact, you haven't actually just waited, have you? To the contrary, you've actually eliminated (commented out completely) during the interim one alternative in favour of another. I, on the other hand, was offering to whomever might find it worthwhile (and have actually implemented for myself) a middle path that allows both optional methods to co-exist during the "waiting period" based on setting a single flag, either in the common API or at the top of any individual script.

As I said, I thought that's more or less what you yourself were suggesting earlier, and it seemed at least partially consistent with Galapo's concerns as well.

My %IsPE1% example was only intended as an illustration of the general methodology. As you say, it worked for my own particular purpose and so was not "wrong" in that limited sense. But the true/false test conditions could, of course, be whatever might be considered appropriate for any wider set of API distinguishment circumstances which would allow the same general approach to the overall issue.

The real "root of the problem", as I see it, is a whole range of activities whose possibilites are currently restricted and more or less "locked in place" by some "proprietary" constraints of a previous developer who appears to be no longer actively engaged in the developmental process.

In the circumstances, recalling your earlier question about script writers(!) being "selfish", one is tempted to wonder about the true applicability of the old "Dog in the Manager" fable, but I suppose I'd better not. The issue of who should be accomodating whom is always a matter of some judgement.

I guess coincidental
http://lancelot.winb...1123_195635.rar

Perhaps. But whatever the underlying problem may be, it was definitely NOT a dismount failure in my own case. I checked everywhere very carefully for any such message or indication of any kind.

ps: grouping workground is a bit .... , For now I prefer waiting news from JonF preloader.

Huh?! Grouping script items for conditional execution is a bit what? If there's some real issue with conditional execution groupings, the simple alternative would set an initial true/false variable and preface the relevant individual script lines accordingly. Preferable to just commenting them out entirely IMO. For example:

[variables]

If,ExistFile,%source_win%\TXTSETUP.SIF,%IsPE1%=True

If,Not,ExistFile,%source_win%\TXTSETUP.SIF,%IsPE1%=False

...

[process]

If,%IsPE1%,Equal,True,reg_add,0x2,...

If,Not,%IsPE1%,Equal,True,RegAddBoot,...

I thought I was doing something more or less equivalent to your own earlier suggestion for using a RegAddBootIf process. Anyhow, it cured my own BootSDI.script runtime problem, whatever it was. Just thought I'd mention it here FWIW.

Sorry for late response, batches working fine on x64 (no waik installed etc ;>)

Are we seeing here some possible "light at the end of the tunnel" for some of the much larger "dead end" issues arising from PE2/3's current reliance on certain "proprietary" aspects of earlier development work?

Or am I reading too much into this announcement?

Am I alone in noticing recent problems with LiveXP's BootSDI.script hanging between the first and second iterations of its RAM drive building process? There is no error message, but it just sits there forever with a "PLEASE WAIT" message, apparently spinning its wheels until cancelled manually. (I've waited for up to an hour before finally giving up.) Thereafter, the log shows no error other than the manual abort STOP.

Don't know if there's any connection, but I noticed no such problems prior to the recent addition of all those RegAddBoot "compatibility" lines to some of the LiveXP scripts. It may be coincidental. But, in most cases, notably with the 7-Zip_File_Manager_SJL.script which contains many of them, the BootSDI problem seems to disappear when I converted* all those script lines back to reg_add,0x2 equivalents.
__

* Actually, I just grouped them all into their own script section to run conditionally for VistaPE, Win7PE, et al: If,Not,ExistFile,%source_win%\TXTSETUP.SIF, ...

Perhaps we're both too simple-minded, but it certainly seems logical and even obvious. It would appear, IMO, to have some major practical advantages over sacrificing project advancements for the sake of "lowest common denominator" compatibility.

In fact, it almost seems like something that should be an integral part of the core infrastructure and thus capable of being used by all projects. I don't mean the actual EnvVar setting and propagation process, which could only be done during the initial stages of a build's boot-up. But a common trigger/flag item for that process could allow any project whatever manipulative flexibility might be needed for various options. Based on that trigger, maybe something like EarlyStarter (or even earlier CurrentControlSet Session Manager?) could handle the flag discovery and EnvVar setting.

So, is there anything to prevent the establishment and propagation of a Windows environment variable for %ProgramsDrive% (like %SystemDrive%) that is usable within scripts and/or via ExpEnvVar as needed? In that case, you'd just have to get agreement on its consistent usage.

If I recall correctly, the "old" VistaPE originally had several loading configuration options for "Force All to RAM", "Mount Programs Folder as Drive Y:", etc., so that you could end up with individual applications either collected all together or scattered amongst locations that could be determined only during the boot process. And, to further complicate the situation, some could be located under a "Programs" folder on the boot drive while others were loaded under the WIM's "Program Files" folder. Since I don't have access to a WAIK platform at the moment, I'm not sure about all of Vistacapi's current options and, of course, Mickey$oft's incessant whims and whimsy constitute a whole other development factor for all concerned.

Frankly, IMO, a full "cross-scripting" goal, especially if it includes any "backward compatibility", appears much like a valiant but practically impossible dream, and the LiveXP project might best adopt a "lead by example" approach. It gets very tricky for other projects with program location options that are variable by the end users with no consistent relationship to %SystemDrive% or other pre-determined environment variables. In the circumstances, I'm happy if LiveXP's own RegAddBoot/ExpEnvVar features are fully capable of handling the cases where particular applications can't deal with 0x2 (REG_EXPAND_SZ) registry entries.

That's merely my own POV, of course -- perhaps overly pessimistic. Maybe Windoze own %ProgramFiles% variable could be "tweaked" somehow to compensate.

Only problem is that the 7-Zip.DLL file used for its CLSID {23170F69-40C1-278A-1000-000100020000} shell extension appears to be missing from the package that is extracted to the program folder.

Follow-up: I see the problem.

In 7-Zip_File_Manager_SJL.script change line 456:

FileDelete,%Target_Prog%\%ProgramFolder%\$R0

to read as follows:

FileRename,%Target_Prog%\%ProgramFolder%\$R0,%Target_Prog%\%ProgramFolder%\7-zip.dll

Excellent job with the revised 7-Zip_File_Manager_SJL.script!

Only problem is that the 7-Zip.DLL file used for its CLSID {23170F69-40C1-278A-1000-000100020000} shell extension appears to be missing from the package that is extracted to the program folder. If I recall correctly, when I was developing my own script, I think I had to add it separately.