misty

Now there's a phrase I never though I'd hear! You are right - time permitting I will try to trace this myself. Thanks for the tips. If I'm honest, I've been lazy due to distractions with other projects and not enough time. Thanks Wonko - Atari800XL linked to the folder in an edit to his post. You have summed up the situation perfectly. The problem at the moment is that there's just so much stuff I want to test and not enough hours in the day.

Whilst some versions might be better than others, I don't really like any of them as they all seem to give mixed result and random partially unmounted wims. I miss the old imagex.exe from Vista days - it was great fun playing around with it back then. That version may also have been buggy as hell too - I haven't used it for years. These days I'm more inclined (storage space permitting) to use wimlib to apply an entire boot.wim rather than running mount and unmounts operations. Depending on the size of boot.wim and the system hardware it doesn't feel like it takes much longer. Only time I need to do this is when applying a package. If only some genius could trace which minimum set of files need extracting from boot.wim so that DISM can be used to successfully apply a package to this smaller file set - without the need to fully apply the contents of boot.wim. And entirely removing the need to mount the image. Misty

@JFX - are older version of GWT available for download. The current version appear hardcoded to download the Windows 10.0.16299 version of DISM and dependencies. Whilst the need is not widespread, there may be some instances where it would be useful to download other Windows 10 versions. I believe that these may be coded into some of the previous GWT releases? Misty

Ah. Now that's not so good! Is it likely that this downloading of unneeded data could be avoided if a native tool was developed? Or the functionality added to GWT?

I think that such a program would be useful, although probably not to a large number of people. It's a specialist tool and in the days where many have relatively fast internet connections and unlimited bandwidth most users will probably just download the whole file for convenience. A good user case! I am not familiar with compression blocks - how much additional data are we talking about here to download the needed file? Misty

Very quick file extract test. Using following command - java -jar re7zip.jar -t=cab -a=http://download.microsoft.com/download/3/8/B/38BBCA6A-ADC9-4245-BCD8-DAA136F63C8B/adk/Installers/a32918368eba6a062aaaaf73e3618131.cab -e=fil3a96a4ae37b2d6a62b94d42e1126dde0 -o=fil3a96a4ae37b2d6a62b94d42e1126dde0 Some output from the cmd (including time of the extracting/download) - blah blah blah Percentage : 99 Reading 27892006 of 27971974 bytes Percentage : 99 Reading 27924774 of 27971974 bytes Percentage : 99 Reading 27957542 of 27971974 bytes Percentage : 100 Reading 27971974 of 27971974 bytes Done. Downloaded in 0 minutes and 16 seconds. (extracted) File size of fil3a96a4ae37b2d6a62b94d42e1126dde0 = 26.6 MB I haven't checked what this file actually is yet. I'll report back in later.

Maybe not for you!!!!! I can't program for toffee! BTW - that would be great if you are offering. I believe that I have also sparked some interest from Erwan.l on the reboot.pro forums.

Just installed java and will test properly later. I've Just used the following command to list the contents of one of the .cabs you linked to (redirecting to a text file as the first attempt had too many lines to display in my command prompt) - java -jar re7zip.jar -t=cab -a=http://download.microsoft.com/download/3/8/B/38BBCA6A-ADC9-4245-BCD8-DAA136F63C8B/adk/Installers/a32918368eba6a062aaaaf73e3618131.cab -l > list.txt Output from running the above command (which completed very quickly) - Opening HTTP archive 'http://download.microsoft.com/download/3/8/B/38BBCA6A-ADC9-4245-BCD8-DAA136F63C8B/adk/Installers/a32918368eba6a062aaaaf73e3618131.cab'. Archive 'http://download.microsoft.com/download/3/8/B/38BBCA6A-ADC9-4245-BCD8-DAA136F63C8B/adk/Installers/a32918368eba6a062aaaaf73e3618131.cab' is open. Number of items in archive: 1044 Size | Compr.Sz. | Filename ----------+-----------+--------- 417530 | null | cata32918368eba6a062aaaaf73e3618131 66912 | null | fil00017d5d130dd3712deefa17129c07a3 213014 | null | fil01375048c9afcfe2c7a68837d535cb33 54507 | null | fil01851f57ed63bc2e447a76be7360d0d4 484400 | null | fil0211b8650a7bb0f22cd7cee59c811174 45912 | null | fil026bc6d8ecbf9756e1935d13bc142127 114671 | null | fil03b70e534d0911f7dbe2d02aa47bd78e 142124 | null | fil03bb4fbdecc0ff199fc267741c51a06e 45408 | null | fil03f4493ddd337bfd130773c1ade312f4 79200 | null | fil03fa8321a8a1610cd34dcea9e1dfa151 etc

Thanks JFX Thanks for the information. A lot of the stuff I need is in the 2 big cab files that you mentioned. Any suggestions regarding alternatives? I looked briefly at re7zip (http://reboot.pro/files/download/224-re7zip/), however the java dependencies make this a no go for my needs. BTW, Get WAIK Tools is a(nother) fantastic application. Very well done to you and everyone else involved. Misty

Hi JFX, Can you please confirm whether Get WAIK Tools is redistributable? I am thinking of including it in a PEBakery / WinBuilder project if it is - and with your consent. Also, can you (or someone) please advise on how best to obtain the offsets for a file contained in a .cab - required for the GWT -range command? This relates to a topic discussion on reboot.pro - http://reboot.pro/topic/21668-minimal-fileset-for-installing-an-adk-optional-component/ And more specifically this post - http://reboot.pro/topic/21668-minimal-fileset-for-installing-an-adk-optional-component/?p=205560 Regards, Misty

Please do not apologise for adding support for a useful utility. It's not your fault that wimgapi is buggy. I also found issues with unmounting being due to Explorer being open. I swear the mount feature now feels more buggy (and slower) than when the WAIK for Windows Vista was first released!!! wimlib does support mount - just not on Windows. This feature is limited to Linux only. Thanks - I honestly wasn't sure if this was more wimgapi bugginess. Misty P.s. Slightly offtopic. I found some issues with the ADK script in MistyPE and have updated the project. See here for more information - http://reboot.pro/topic/18917-mistype/?p=205342

@Joveler Thank you for the addition of the WimMount and WinUnmount commands. I'm not sure if this is a bug or not, however the progress bar is only displayed if the Build Project or Run Plugin buttons are pressed. If the commands are executed from a button embedded in the script then the progress bar(s) are not displayed. This is also an issue in WimBuilder (e.g. with WebGet). I experienced some issues with the new WimUnmount command failing... WimUnmount - The process cannot access the file because it is being used by another process (WimUnmount,%MountDir%)), ...however I believe that this is a wimgapi issue rather than a PEBakery issue. I stopped using the (DISM) mount command some years ago as I found it buggy with issues arising from mounted files not being fully unmounted and appearing locked. I have resorted to using wimlib to fully extract and repack a wim rather than mounting and unmounting, although this is a time consuming process. Injecting files with WimLib however is lightning fast. Wimib rocks! I'm pleased to read that you will be implementing this library and am looking forward to seeing how you implement it. BTW, I'm assuming that changes to the mounted image are not committed? Or am I doing something wrong? Misty

Thanks my friend. And that's why it's useful to ask instead of trawling through lots of posts on different sites. I think it can be both. Obviously that will ultimately be up to Joveler. Having looked at topics on theoven.org there seems to be a strong emphasis there on trashing all things winbuilder and moving forwards with the new builder and introducing new commands to replace their macro library. I get the impression that breaking WinBuilder compatibility might actually be one of the goals in mind! Some of the new commands may well be useful for all and PEBakery looks like it's already evolving from WinBuilder - a builder that hasn't had any development for a number of years. These new commands might already result in WinBuilder errors if a project is not coded to build on what are ultimately two separate platforms that are likely to increasingly diverge. That does not mean to say that PEBakery cannot become a full drop in replacement for Winbuilder, just that if you want a project to work in both builders and take advantage of new features in PEBakery then a workaround of some sort will be required. My own wish would be for new PEBakery and WinBuilder commands that replace all of the external programs currently required in MistyPE. That is not going to happen with WinBuilder as Peter and Nuno do not appear to have any plans to continue development. Some of the commands currently dependent on external programs may well be implemented in PEBakery in the future and I'd personally like to take advantage of this whilst ensuring that MistyPE still works on WinBuilder - which still works on Windows XP and without .NET! The fact that WinBuilder still works at all is testament to the work that went into it. I think that this is likely and possibly inevitable. We can but dream. Just remember though, that compared to the WinBuilder 201X release the old/legacy WinBuilder is human readable! In the case of MistyPE, lots of external programs are already used as workarounds due to the limitations of WinBuilder. PEBakery has drawn my attention to a number of syntax errors that have been cleaned up - for the good of both builders. The only significant change has been coding to take account of a 64-bit builder. As WinBuilder is 32-bit only a workaround was implemented to account for sysnative redirects when copying files from a 64-bit Host OS - in PEBakery the redirects were not required. The good news is that with the release of PEBakery there is now a future to WinBuilder - a new/easier scripting language would be a great future goal. Misty

Thank you for the positive feedback. Brief information about exporting logs has been added as suggested. The updated instructions are in the new MistyPE (build 2017.12.26) download and online (http://mistyprojects.co.uk/mistype/mistype.docs/readme.html and http://mistyprojects.co.uk/mistype/mistype.docs/readme.files/instructions_pebakery.htm#basics). Done. Trust me, the honour is mine. Thank you for consent to distribute PEBakery, and also for the vast amount of your time that I suspect you have already put into it. I do not know enough about .NET to comment on this. I rarely have anything other than OS included .NET version on my systems and on the rare occasions that I've installed a different version I've usually reverted to a clean OS backup soon after. It's an indication of how much I've been enjoying and value PEBakery I may have to keep .NET permanently installed The fixes are very much appreciated - particularly the two mentioned above. I have not found any errors so far. In regards to new ideas on the other hand, you may regret asking that! Some thoughts and suggestions for now. Where doees PEBakery go from here? From my own selfish point of view I'd love PEBakery to continue to provide backwards compatibility with WinBuilder. Ideally I'd like the same MistyPE to continue to run on both builders, whilst still taking advantage of any new commands and features that are implemented in PEBakery. Unlike others, I am not looking for a WinBuilder replacement. WinBuilder has some advantages over PEBakery - think older operating systems and also where it might not be practical to install the .NET dependencies. I very much see the two builders as complimenting each other in regards to MistyPE. A feature request that would facilitate this is a means of checking from a script whether it's running on PEBakery. Apologies if this is already implemented - I'm late to this party and am playing catchup. My suggestion would be setting an environment variable automatically if PEBakery is running that can be checked in all projects? Let's say for example that a variable %PEBakery% is automatically set as YES, then a project script could run commands that are specific to PEBakery without causing errors in WinBuilder. E.g. - If,%PEBakery%,Equal,YES,Begin mycommands End Else,Begin mycommands End Native wim support All Windows from Vista up have been distributed using the Windows Imaging Format. If PEBakery is being released as a Windows PE builder, then native .wim support via PEBakery commands would be very useful. MistyPE can continue to use ShellExecute commands to call wimlib-imagex.exe, however if it's possible to add native commands for .wim support via the wimlib library (libwim-15.dll - see https://wimlib.net/apidoc/index.html) then this would be useful across multiple projects. Whilst 7-zip may provide some .wim support, Eric's work is in my opinion the industry standard. PEBakery Roadmap In your own words, "...PEBakery works as a drop-in replacement of WB082...". In MistyPE this would appear to have been achieved following the correction of some scripting/syntax errors that I had not picked up on that were running in WinBuilder (and probably shouldn't have been). From the information I've so far skimmed, not all WinBuilder commands have been fully implemented. Please can you let us know what you plan to concentrate on to avoid you being bombarded with feature requests. For example are you wanting to focus on tests/bug fixes, or documentation, or full WinBuilder compatibility, etc. Also, PEBakery is being discussed across multiple sites/forums including here at MSFN, and reboot.pro, and theoven.org and mdl. Where would YOU prefer posts to be made? Fantastic work. My last suggestion would be to consider calling this a Beta release rather than Alpha. Kind regards, Misty

Quick post before I go out for more Christmas activities. MistyPE updated and is available from - http://mistyprojects.co.uk/download.htm The amazing PEBakery (Build 20171225) is included in the download. Thank you Joveler Changelog - http://mistyprojects.co.uk/mistype/mistype.docs/readme.files/Changelog.txt It is not possible to update from within the project so you will need to download the full project package - sorry. Misty P.s. More later - I still haven't responded to Joveler's update.

@Joveler I look forward to testing the new build. I will respond more fully in a few days - the household Christmas preparations/celebrations are about to start with the Christmas Eve church service and a ban has been imposed on my computer use over the festive period. Looks like am impressive number of fixes and additions in the latest build. Happy Christmas Misty

More great news. Any idea when the next build is likely to be ready for release? I have been working on updating the MistyPE documentation to include the latest project updates and using PEBakery in addition to WinBuilder. Latest (and hopefully final) draft is available - http://mistyprojects.co.uk/mistype/beta/doc_update_pebakery/readme.html. Comments welcome - particularly if they are positive . I'm like to include the next release of PEBakery (with the above fix) in the MistyPE download package once it's been tested - any thoughts? Misty

@Joveler I've been thinking about a straightforward workaround to the System,REFRESHINTERFACE issue I reported in the preceding post. How about implementing an option (set as default, but with the ability to turn it off as required) to run the System,RESCANSCRIPTS command automatically when the Build button is pressed - but before the build process actually starts? This feature request would ensure better compatibility with my own projects without the need for me to edit a number of individual scripts - a much uglier workaround in MistyPE as the project will continually be rescanning for scripts whenever a tab menu button is pressed. Misty

Minor issue in the MistyPE main project settings script. May also effect some of the other project scripts if they have a tabbed style interface. When one of the options tabs are changed the project is scripted to do the following - Write the new interface name to the [Main] section, Interface= value write the settings in the current interface to the script send a System,REFRESHINTERFACE command The new Interface is then displayed and any changes made in it should be parsed when the project is executed. This works fine in WinBuilder and the values in the currently displayed interface are all parsed correctly, with other values obtained from the writes made to the script in step 2 (see above). This appears to work fine in PEBakery, however the values in the currently displayed interface are not parsed when the build process is started. As an example, in the screenshot below the Options 1 tab was displayed when the project was loaded by PEBakery, then the Options 2 tab was selected and the Build process started. The values from the Options 1 tab were obtained ok from the script, however the options from the Options 2 tab that was displayed when the build process started are not. In the screenshot below we can see that Language=%pScrollBox_B3% and Method=%pScrollBox_B1% are clearly not parsed and are incorrect. Build subsequently fails - Unless a fix is implemented in PEBakery there are two current workarounds possible. Press the Refresh Project button in the PEBakery UI. Add the System,RESCANSCRIPTS command to relevant sections to automate the refresh. In regards to workaround 2 for example, change the following - [Change.To.Tab.A] IniRead,%ScriptFile%,Main,Interface,%Current.Tab% Run,%ScriptFile%,Save.Settings IniWrite,%ScriptFile%,Main,Interface,TAB_A_Menu System,REFRESHINTERFACE To [Change.To.Tab.A] IniRead,%ScriptFile%,Main,Interface,%Current.Tab% Run,%ScriptFile%,Save.Settings IniWrite,%ScriptFile%,Main,Interface,TAB_A_Menu System,REFRESHINTERFACE System,RESCANSCRIPTS Joveler - I'm not sure if this affects other projects. Any scripts with multiple interfaces may be effected. Misty Edit P.s. Basically when the System,REFRESHINTERFACE command is executed PEBakery would need to be coded rescan all settings contained in the new interface section to fully replicate WinBuilder.

Possible third project compatible with PEBakery - Mini-WinFE. Main page here - http://mistyprojects.co.uk/documents/Mini-WinFE/index.html Project is available for download here - http://mistyprojects.co.uk/download.htm (use the alternative download link) Description - "This project is based on MistyPE. It's been scaled down and developed specifically for digital forensics acquisitions. Mini-WinFE has been co-developed with Brett Shavers to facilitate a simplified method for building a Windows Forensic Environment (WinFE)...." As it is essentially MistyPE with a few minor modifications, the latest test build should hopefully be fully compatible with PEBakery. The current download (see link above) will need updating from within the project. Extract the project from the download file Mini-WinFE.2017.04.27.zip Copy/extract the PEBakery files to the root Mini-WinFE folder extracted in step 1 (the folder containing WinBuilder.exe). Start Launcher.exe Goto Tools > Update Project script Hit the RUN button Regards, Misty

This is a controlled error and is required to delete the registry key if the other Opera script (included in the project download) is executed first. The error can be safely ignored. Fixed in update available here - http://mistyprojects.co.uk/mistype/packages/Opera1218_Package_v2.zip Another error was also fixed - I'd failed to add code to copy the locale folder into the build. The new script also contains an option to set the required language. Download and add to the project using the Tools > Add Program script. Fantastic news on both counts. Misty

A test build of MistyPE is available. The test version is hopefully fully PEBakery compatible - I've done a few initial tests using PEBakery version 0.9.1. alpha (Build 20171216). Update the MistyPE project using the Tools > Update Project script whilst MistyPE is loaded (in either PEBakery or WinBuilder). A number of scripts have been updated. I can't remember all of the changes/updates as the reboot.pro site is down - a number of the changes are listed on the reboot.pro site following the release of other test builds since the MistyPE April Fools release (build 2017-04-01). Changes since the last test build (2017-12-17) that Alacran has been very actively testing include - - wimlib updated to version 1.12 (as suggested by alacran) - Spelling corrections to some scripts (as suggested by alacran) - Main project script option 6] Set 'Install.wim' Image Number - index/number increased to 9 (as suggested by alacran) - JustManager (file manager) included in the project - WinHex script updated - Evaluation version can now be downloaded Following programs updated - - dmde - Q-Dir - HWiNFO Regards, Misty

I spotted this during my lunch break, but thanks anyway. There are also issues with quotation marks in a number of other scripts - some reported by PEBakery as Syntax error () and some reported as Doublequote's number should be even number (). Effected scripts include new Ghost and Create ISO scripts. Old (2014-04-01 build) scripts effected include HWiNFO, WinFE, ADK and Cache Files. Note to Joveler - all of these errors were difficult to find and involved visually scanning code. Any chance of a reference to the offending code's line number in a future release? Currently working on Sysnative redirects issue in Cache Files script. Update coming soon. Misty

Found a problem in MistyPE. If the Options 2 tab is selected in the main project script (with settings for Build Method, Keyboard Layout, etc) then the build fails. Clicking on the HELP button for Option 7] Build Method also fails. The error appears to be due to the content of the message in the [HELP.7] section of the script. I can't actually see what code in the Message is causing the issue and am about to leave for work. Not sure if it's my code or a PEBakery issue. Regards, Misty

Fantastic project. Can't wait to see how it develops. I've posted some feedback on reboot.pro (see http://reboot.pro/topic/21647-new-pe-builder/?p=205219) Regards, Misty