Discussion in 'MDL Projects and Applications' started by Smorgan, Jan 15, 2015.
You need to login to view this posts content.
Reserved. For now
I have the feeling this will be a great contribution from yours Smorgan.
Finally your habit of thinking large will be tangible now lol
Due to the enormous nature of the project it is going to take me time to finalize. At the present time this represents the Framework for Universal Support amongst operating systems for Windows. It is not ready for people to copy and paste into a Windows ISO. Also this project has been slow due to the amount of testing required.
I've always thought big this just defines how big I go...
We are going to do Server conversion to Workstation as well.
PLEASE NOTE THIS PROJECT HAS BEEN MODIFIED TO FIT FORUM RULES.
You need to login to view this posts content.
In addition to this private testing will be happening there will be an effort to finish the copy of the script convert it for use on MDL forums.
Please be mindful as well as patient this is not a short project it is very complex. All of the ideas from a coding perspective were created by me as the idea for a oem pack that covers a wide variety of Windows operating systems is not new. The only issue was doing so in a fashion that is simple yet elegant.
I am also pushing for this to be moved to the MDL Project page. This is a very big project... I do not have the resources to do the testing required. It would take a machine with roughly 64 GB of Ram. That is just to test it in a virtual setting. However I am quite happy in that I managed to get support for about 75% of the operating systems I had in mind. The next step will be finishing the Server 2008 / 2008 r2 side and the Windows Embedded Product Family from 7 onwards. Given the simplicity of the coding I know it will work the concept itself has been validated.
Ok its been decided in order to conserve space for low bandwidth users that there will be 2 Packs. One will have Office and the other will not. However the scripting will remain the same as we can do a file check in order to keep everything going. It will also make it so that the script does not crash if office is not present in the form of a compressed SFX directory. This will complete the modular aspect to the scripting which will make me happier as well.
This should reduce the size of the pack considerably.
Nightly testing will continue until the server side has been finalized. Then we can start proceeding to forum testing. The problem is I don't have the hardware to test a dozen operating systems at once for compatibility. While having enough RAM to pull it off because it would bring my desktop to its knees. I would need 2 machines with 64 GB of ram in all honesty as I'd start looking at the 32 bit side as well. My 16 GB of ram desktop just can't do it all and most of the development happens on my laptop.
Ok Guys I need some thoughts on Modules.
I'm thinking of actually take each aspect of the project and forming up modules.
1. Tweaks Module
2. Office Module
3. Privacy Module
4. A Software Module
We can take these modules and form up Packs so each part is encapsulated. This would mean that packs can be visualized as a giant bubble with parts that are added and taken away at request of the user. Powershell scripters would have it easier as they can do all of this on the fly. We would need a new standard to pull this off properly.
I need some ideas on doing this as I wanna improve on the concepts I have. I figure we can take each module compress it to a winrar sfx executable then unpack them with the powershell script inside em.
Then have the setup.ps1 and starter.ps1 respond to them in such a way that adding components / modules are easier. I know this project is still in Beta but I wanna push the envelope so every option can be seen with it. I'm excited with what can be done now
The last piece of the puzzle is to make each module fully operable by itself. This would mean just having a Module Controller. I think I have a solution to this puzzle
I'm thinking of a way to make a OEM Pack that can have modules added without any requirement. These would be standalone that function as a means to expand components of that module.
As one might say... eureka.
I've started the process of implementing an automated Server conversion script for Server 2008. This would bring compatibility to the full range of Operating Systems being aimed at.
That being said at the present moment the scripting has been split up so each ps1 has different areas. This means that when there are new things added or changed for Server 2012 it will not affect the script which governs Windows 7. This should mean when testing and development occurs we will not be having stuff not meant to be run on an OS its not meant to run on. In addition to the created sub areas on the scripts I have made universal areas which implement changes to all Operating Systems supported on the Windows side.
Tested works well thus far improvements are being made daily it seems Smorgan is doing a great piece of work here...
Really this post should be a "sticky" subject
The last piece of the puzzle is being solved which is that of how to do a standalone module which has no dependencies. While being so simple that everyone can make such a module in terms of feasibility. I have an idea that should work. However it needs to be tested.
It uses concepts that are borrowed from some stuff here and there. Also to add support for the 32 bit guys!
This is going to be epic.
One more update.
At the time I'm working on adding the 32 bit support which will alter the structure of the pack. And make it more flexible in terms of what Operating Systems it works on for the 32 bit side. However...
Once that is finished while private testing is going on a framework will be posted onto the forum to enable the full nature of the powershell setupcomplete method. This will mean having the folder structure online with the scripts in order allow a very good level of modding. This open framework will represent the first step as it is the semi modular step in the development process. At that time the forum will be able to take advantage of the project.
At that time we can start adding separate projects in order to be slip streamed into the pack. This will be interesting...
First off I have to say this...you need to empty your pm's so I can reply back to you. lol I thought I would comment here on what I thought of the presentation.
Your presentation was very straight forward in its accomplishments. Now I understand what you are trying to do...before I was a little confused. lol Can I ask why you don't include a possible offline install of powershell for vista support? If not already installed for vista then use offline installer. Just asking because some out there don't know how to slipstream nor do they wish to learn. Just saying. Other then that little qwork for vista support I like it.
I just cleared the inbox. Now as for vista the issue there lies in the powershell support. I was busy nailing down the conversion for Server 2008 r2 / Server 2012 / Server 2012 R2 / Server Tech Preview. The process of making the script and command compatible with all of them was somewhat tricky which meant using dism and add-WindowsFeature commands. However Offline wise my thought there was to add an option so that if Windows Vista was detected then the setupcomplete.cmd would run the Powershell installer. However it would skip running the Powershell setup instead waiting for Powershell to install. I'm going to need time to think that one up because id need to call the starter.bat which is written by the setup.ps1 at the moment.
Then we could get the powershell to work along with vista support. However the main goal was to nail down the support for native powershell operating systems. This would mean adding support for 32 bit as the pack in its current form only does 64 bit. The development plans are just that meaning they are a means to add support however they have not been finalized as I wanted few other views on this. Seeing as there are a number of ways to add support for 32 bit.
The road map calls for the adding of 32 bit then thinking of a means to make a full modular system so that each modular is independent of the pack. Independent in terms that only 1 command is needed for it to run . Ya it should be obvious why I'm taking a break at the moment lol.
Ok Added another thing to the development track to increase flexibility.
Base images are in testing with Script updates. This means I can do script changes on the fly in the development process so I can upload a script which takes seconds to do.
It also means I can look at different ways the scripting can work and make it more efficient. While working towards fixing the Server side
I've been playing around with the Server end. I still haven't gotten around Server 2012 not allowing .net Framework 3.5 to enable. However the entire Server area has been made modular. That means we can take the entire Server Folder / Server Registry folder and throw it in the trash without the script breaking. I should have the newest base build done pretty soon.