Not my point, but a maintainer (MDL respected member) could very well accept/reject commits made by anyone. Alternatively, only select MDL members are allowed to make commits while a select few respected members are allowed to accept the changes. I don't quite see what's so wrong about this unless you do not want public from using the program.
Everybody is free to join MDL and offer suggestions, it's MSMG's choice if he implements it, isn't it?
Yeah a collaborative git would be nice, even if he were to allow a fork from the master, That way people could contribute code, like currently i have a separate script that goes through enabling and disabling features, setting up default regions/languages something i requested to be put into the toolkit about a yr ago. but yeah it's his project, so its upto him if he wants to open it to share.
So basically Remove the crap, Addin drivers /custom files /resetbase enable .net 3 add updates check for crap, remove if need (shouldn't need to do this??) ????? Profit.
The standard way of removing Windows Component using DISM won't completely remove all related files/folders as like when it integrates. I do add post-component clean-up for only when it's safe to delete the left out part and it requires a lot of trial installs to known removing which files/folder/services/registry/tasks will break the OS or it's safe. I think WSAPPX is related to APPX Deployment component which I haven't added to the ToolKit for removal as it will remove the functionality to Integrate Apps later.
The Warning Dialogs are for users to know what should be added before using the Integration or Removal process But after the release of Windows 8.1 or to be more precise Windows 10, the order of usage got mixed up.
For next version, I Will add Auto Image Clean-up While using the Apply Source->Save Changes and Unmount if the Pending.xml is not present.
You can just add the path <ToolKit>:\Bin\<Arch>\DISM10\ in you manual script before the DISM.exe and use the script.
Well I'm right here only, I was just busy with ToolKit GUI development and had no time to post here. Will update the Toolkit script in this week. Hosting the ToolKit on GitHub is not a issue only if the ToolKit was just a script but the ToolKit uses Packs which contains MS OS Packages (Feature Packs, Language Packs, FOD) which may become copyright violation and I don't know whether it's allowed on GitHub or not as I haven't used it. For this I have thought different method i.e to download only the required MS packages/files directly from MS Servers using the method where only a part of files are download from a huge ISO files or any other files and then assemble them into the required format to be used by ToolKit.
And Regarding the ToolKit GUI Development, here is the latest update: The GUI version is almost complete with the majority of the modules working fine like: - Select Source Image and Mount - Enable/Disable Windows Features - Integrate Windows/Windows PE Drivers - Integrate ToolKit's Feature Packs - Integrate ToolKit's Windows/Windows PE Language Packs - Intergate Windows/Windows PE Updates - Apply and Save, Discard, Export Image and Rebuild Source - Make/Burn/Extract ISO - Copy Source to USB Now started Tweaking UI Elements and Adding Icons to have a uniform Interface on all Windows HOST OS and still need to work on Registry Handling, About and Settings with MUI Module.
You could kinda take a load off you too if it's on git Simply do not include MS packages. Specify that the user will need to manually (or by script) download these package files. Will you be sharing source code for your GUI version?
Just my 2 cents after seeing the same argument countless times. Save from very large and well known projects, the vast majority of open-source projects usually only have the original developer (or the one who replaced him after the project was abandoned) working on them. I doubt there will be more than 1 or 2 people here who will actually contribute with code. Putting in on github (or whatever) will only give more work to MSMG and to the users that will have to download/prepare packages manually. If you're really interested in contributing, maybe the best choice is to contact MSMG privately and try to work together with him. PS: I do believe that if the original developer is going to abandon the project or if he constantly refuses to implement features that many users ask, he should release the code.
@Enthousiast really all honorables members above need our sincere respect for your big contribution here so I'm sure that MSMG Toolkit stay RESERVED only for members still you make my day posting deserved members for all that yet NO know them
Hello everyone, I will like to integrate themes into my windows 10 custom built iso, in which directory they should go to integrate the themes using MSMG-Toolkit if it's possible? I will using official Windows .theme, .themepack extension. I have done this before using Win Toolkit on Windows 7. Thank you
Hi! MSMG will probably add that feature later... And why not...adding Wallpapers integration too? "Stay tuned"
Step3: Expand all sub .cab in KB3213986 to KB3213986 folder Code: expand D:\ToolKit-v6.2\Packs\WHD\w10rs1\x64\Cumulative\KB3213986\*.cab -F:* D:\ToolKit-v6.2\Packs\WHD\w10rs1\x64\Cumulative\KB3213986 Note1: If decompresseded NetFX3, the command line should include update.mum, or it will fail. Code: dism /image:D:\ToolKit-v6.2\Mount\Install /add-package:F:\microsoft-windows-netfx3-ondemand-package\update.mum Note2: If the latest Servicing stack package (e.g. KB3199986) was integrated prior to the latest CU package (e.g. KB3213986) , there would be no Remote Procedure Call error for boot.wim and winre.wim.