What is Open Builder and its history...

I have to admit, I didn't follow the batcher thread on 911cd.net, and I didn't visit the old boot land forum, largely because my own experience of smaller builds was disappointing. The more I cut out, the more it broke.
For new people here, you could do with a sticky post saying what Open Builder is, and maybe what it isn't. I originally thought it was an elaborate postprocessing system, later I thought it might be an oem pebuilder, then finally I saw Nuno's "Why this..." post on the old forum and realised that it is not BartPE at all.
I've still not tried it, so I could be wrong of course...

Welcome to the board.
Thats a good idea. Why dindt I think of that?

And I just read the thread you are speaking of.
Why this when there's bart's PE builder?
http://z3.invisionfr...p?showtopic=110

Why Open Builder? (The philosophical answer)

This is a common question, and probably warranted considering the audience to which Open Builder caters. The answer, however, varies depending on who you talk to, and it should, as I'll explain.

First there was the DOS boot disk. A lot of people used Bart's Bootdisks for various reasons. It just worked. Even to this day, you can get DOS to boot up from floppy on a LOT of network cards that still support packet drivers.

Around the time of Windows XP, though, Microsoft realized there might be a market for an OEM PE tool and made PE more available than it previously was. Windows XP booting from a CD by the community of previous bootdisk makers was the next logical step.

But I think that's where the focus was lost. There are three primary groups of people that get into bootdisk making: the ones that do it for profit (OEMs/manufactuers), the ones that do it for need, and the ones that do it for entertainment and learning.

It shouldn't surprise anyone here that the first group buys WindowsPE, the second group uses BartPE, and the third group uses OpenBuilder.

It is important to note:
There is nothing wrong with this, all three groups can (and should!) coincide.

It makes perfect sense that the same group that evolved from the DOS Embedded OS group, who used DOS for the purposes of standalone apps & etc would now want OEM WinPE CDs for kiosks.

It makes perfect sense that the same group that grew out of the DOS boot disk era, who used DOS network boot disks for troubleshooting real computer problems and easing the computer imaging process, would now want XPE CDs for emergency recovery, backup, and troubleshooting.

The only thing that those of us folks in the Open Builder community are asking is if you can see that it now makes perfect sense that some of us are interested in creating boot disks just to see what can be done with them. Can we boot from a thumbdrive and load the entire Windows OS into RAM? Can we shrink the size of Windows XP down to 10 meg or lower? Can we use files from FreeDOS and ReactOS and other open source projects to come up with a hybrid Windows OS that provides more functionality at a smaller size? Can we run Windows 32-bit apps in DOS? Can we create a LIVE bootdisk that will run ANY ISO we want it to provided the user has a 1 gig empty thumbdrive on hand? Can we get QEMU/VMWare to work off a bootcd and run our OS anywhere we want?

These questions have sometimes been answered easily. Other times they depend on any number of factors. But that's why we use it, to answer questions we pose to ourselves.

The point of Open Builder is not to provide you with an OEM distribution, that's what WinPE is for. The point of OpenBuilder is not to solve a problem, that's what BartPE is for. The point of OpenBuilder is to ask a question, and answer it on your own or with the communities help.

Why Open Builder? (The practical answer)

Open Builder does the following:
1) Allows you to properly prioritize scripts, no convulted (AAA_ or ZZZ_) naming schemes.
2) Allows you to see what each item in a list is doing. The scripts written by others can be modified on-the-fly while you are writing yours if for some crazy reason you need to for something to work.
3) The .SCRIPT system doesn't confine you to one hierarchy or another.
4) The idea to .script time is extremely short. It doesn't take much to figure out how to do what you intend to do.
5) .CAB files give the impression that you're assigning someone else's preordained idea to your XP PE cd. .SCRIPT files, on the other hand, are easily viewable by anyone. It's quicker for someone to spot a mistake you made and correct it. It's not about glory and who made what.
6) No dependency checks are necessary, you've got the whole list of what is going on right in front of you.

Now, please don't construe this as an attack on BartPE. It's absolutely not, it's just that, for some of us, at least, the reason why we've avoided BartPE plugins is because we don't know what they are all doing, and sometimes I get the impression that some of the authors *don't want us to know* what they are doing, because under different circumstances they intend to charge for it or they want fame on the forums.

I'm not saying they definitively do, but I just get that impression. I do think that someone had to license PEBuilder for the UBCD, though. I thought I read that on their forums, somewhere a while back. A good example of something I didn't get was this:
http://www.ubcd4win....amp;#entry18667

A guy makes a utility called unisofs that is just an exe wrapper for filedisk.exe and bootextract.exe, both created by other people, and doesn't really bother crediting either of them for what *they* did, which was essentially write what he is using to perform all the operations. Anyway, I still think it's a GREAT tool, but he could have just pointed people to the utilities he used instead.

@Yorn

But I think that's where the focus was lost. There are three primary groups of people that get into bootdisk making: the ones that do it for profit (OEMs/manufactuers), the ones that do it for need, and the ones that do it for entertainment and learning.

It shouldn't surprise anyone here that the first group buys WindowsPE, the second group uses BartPE, and the third group uses OpenBuilder.

Thanks for your comment.

That's just the reason I'm working here.

To rebuild my Reatogo CD here will perhaps be possible in the far future. But that's not my intention.

Peter

I still haven't started to properly document our developments as I intended, things are moving quite fast and sometimes it's hard to explain what it's being done, or the problems that might occur or how to solve them, I know you've also been around for a long time, but I'll try to do a brief history resume from this whole story up to now to let others understand it a little better..


BartPE has been around us for quite a long time now, and there has always been some discussion on how to proceed to get better results and smaller builds.

I remember reading posts by loony, Troglodyte, solara and others that related wich files could effectively be removed/upxed/cabbed, a while after I've compiled a small list to reduce bartPE onto 35Mb:

http://www.911cd.net...showtopic=12067
(btw: my username was "neue" back in 2005)



At this time all changes had to be done by hand, and the process was kind of lengthy to get started (althought it still valid in nowadays)


But it was still a bit hard to find a way to do them..
http://www.911cd.net...showtopic=15338
http://www.911cd.net...showtopic=14993
http://www.911cd.net...showtopic=12747
http://www.911cd.net...showtopic=13042
http://www.911cd.net...?showtopic=5688
http://www.911cd.net...?showtopic=7697
http://www.911cd.net...?showtopic=3676


These are very good topics here:
http://www.911cd.net...showtopic=10445
http://www.911cd.net...?showtopic=8423

There were also some requests for console mode XP only meant for GUI'less applications:
http://www.911cd.net...showtopic=11594


In the meanwhile I've tried to make some tools to help the testing task here:
http://www.911cd.net...showtopic=12229


But this process was still not good enough for my testings - so I've starting working on other ways to get my testing results faster, that's when .script files first debut their appearance in batcher..
http://www.911cd.net...showtopic=15488


Batcher would use an originally created bartPE build stripped of plugins, then reduce in a very similar way as it could be achieved by the first bart PE in 35Mb batch file.
Had the advantage to allow people to enter their default configuration and be able to automatically do all changes in txtsetup.sif - removing sections, keys, empty spaces and rewritting things as needed..
It would also allow to edit the registry, handle files and run external programs with parameters. Also added a small window to individually select wich commands were ok to processed - easing the task of repeating the trial and error process..

This massive testing eventually led to microPE led by draugen (Martin), wich was the first step towards a way to re-create bartPE on new target dirs:
http://www.911cd.net...showtopic=16528

To some interesting alternative projects like minibox:
http://www.911cd.net...showtopic=16754

And to my first attempts on even smaller builds:
http://www.911cd.net...&...st&p=110159

Wich caused some good reactions:
http://digg.com/soft...g_ISO_(MicroPE)

btw: nanoXP is the evolution from all these works and has more support to hardware, it's not as crippled as this older version was - even when reducing less 2Mb.. more recently psc has suggested some improvements that will surely be taken into account very soon..

And the "Standard" project has inherited most scripts from the scriptPack distributed along side with batcher.



In the meanwhile a few problems started to arise:

Batcher and micrope posts were just getting too awfull long, keeping people away from news to the current state of things and other related posts that just got lost amongst the posting pressure felt in the forums.

Boot Land forums were created to host projects from anyone interested in keep developing new things. Not just related to PE boot disks, but rather a way to discuss all sort of boot disks methods with a few more conditions. This is a fresh opportunity do discuss alternatives and other options not limited to the PE scope, where other issues can be discussed without worries - now a new site is being started here.

But the previous forums can still be found here:
http://z3.invisionfree.com/Boot_Land/

They were hosted by invisionfree, wich worked quite fine - but still limited too much on some things that should be made acessible.

Recently this new site (boot-land.net) was open because it allows to further extend these developments and discussions - files can be uploaded either as attachements or using the download center, no more annoying google ads, IPB is now 2.1.6 (invisionfree was 1.3) and a whole lot more of things can be customized and adapted with time.

Unfortunately the invisionfree places many problems to those seeking to rescue the databases from their hosted forums, so this new site is an attempt to start things from the bare scratch..

I really miss some of the postings in the "old" forums..


With time all sort of discussions kept going, and after a while open builder was released. This new application inherited all functions previously available from batcher, but was re-written pratically from scratch - only the .script engine had to remain compatible with batcher scripts. To avoid the same development issues felt when batcher was being created (wich somewhat caused the long postings for bug fix reasons..) I've decided to ask help and feedback on testings to a few people that followed these works since the beginning.







What is Open Builder?

Open Builder itself is simply a program that will execute intructions from a text file with extension .script

These instructions can include registry and INI file manipulation, hive (un)loading, all sort of file operations and a few other usefull commands - they are all available in the right click menu on the source code editor window.

In these commands it is possible to define variables, compare values, check for the existence of certain conditions and execute files in some unusual modes giving acess to win32 API functions.


Each .script file is composed with three important parts:


Encoded Files
They can include any sort of binary files encoded inside themselves, wich can used to perform exclusive actions, or to be placed somewhere else, like programs destined to be included in the boot cd's. This is possible compressing the binary file using gnuZIP and then using B64 encoding - this allows for anyone to edit or post these scripts here in the forums with some reliability. An internal winzip like support for handling them is included.


User customizable GUI:
Allows to add components such as text boxes, buttons, web links, images and many other objects that can be found from native win32 GUI controls. A section called "interface" holds all data related to this feature. In most cases one line is enough to hold all needed information to create this object.
When the scripts are being executed, the values on the GUI are available using internal variables. For example: You have a "textlabel" object wich can be used to set a title. In runtime the variable %textlabel% will hold the text found in this "textlabel" - the same methodology is used in the other objects.


Script source
This is the part where all action will take place once you press the start button. It will execute all commands (one line=one command - except on If clauses) from the "Process" section. You can redirect the processing to any other section even on any other text file using "Run,ScriptFile,Section" syntax.
Open builder has a source code editor that will allow you to directly add code inside the script - this can be done with any text editor, but this window will allow you to add commands and variables using a right-click menu, this is particulary usefull whenever in doubt about the correct syntax to use. I think the best way to learn is to try these options by yourself and check the results.


What is not?

Taken the features from the scripts and the application itself, Open Builder is definitively not intended to be a bart's PE builder alternative, replacement nor a OEM builder from bart.

Bart's PE builder creates nearly flawless good bootable PE discs.

The script projects currently available are being debugged and improved - wich may result on some flaws handling some windows sources (mouclass.sys can be considered a headache..) - the building process is quite different from bart's wich is entirely based on the txtsetup and INF files from the source, whereas these script projects are based solely on defined needed files.

Currently, the build script projects use registry hives created by bart's PE builder - that is the only requirement to create PE discs, the hives are not included in the scripts, but rather a .reg file exported from a previously created bartPE hive, wich is then used to fill the values on a newly created empty hive.

This process can be replaced by script commands, but .reg files work much faster since and output the needed results, with time I'll try to figure how the dynamic registry hives can be created from the windows source, bart has offered his assistance, but I think he is somewhat reluctant to discard the "inner works" of the software hive.

I've ensured that bart's PE builder copyright license was respected, and the script GUI mentions this, althought I feel that the license is intended for pebuilder.exe, bartpe.exe, netconfig.exe and scangui.exe - I still prefer to give him credits for his work in providing these results and findind how they can be built.

Anyone care to detail on how to create software hives on windows PE?



Openbuilder.exe itself is still being debugged on the behavior of some commands, and other features that are quickly being implemented/improved or bug fixed, but it's not a fully fail safe application to use in the near times..


Boot disk building features

Open builder is entirely based on script projects, meaning that these projects can be edited and changed to perform the separate building steps of PE bootable CD's.

It can probably be used in all sort of contexts - but was designed exclusively for creating customized boot disks.

Different projects use separate settings, and common scripts can be linked to a common location.

Paths are not static, meaning that using %basedir%\folder will use it as a dynamic value converted to the applications path.

Spaces in path names are correctly handled (even mkisofs likes it)

And all sort of free/gnu improvement tools can be added in the Tools folder - 7zip, qemu, mkisofs, autoIt, UPX and CDrecord are also included at this moment and can be used from any script.

Bart's PE builder plugins are also natively supported to some extent - there is an option to convert them to .script syntax in the source code window, or you can just add your plugin folder as a project and run them directly, but please note that this is still a unstable feature - the registry syntax is correctly converted and hives are loaded writing the proper reg keys for each step, but file copy is still a bit messy, since some files come from the script (plugin folder) and others from the windows source (manual fine-tunning is still needed in these cases).

I've added this feature to provide a tool that saves time converting inf plugins to native .script format, more support can be added in the future, but there are a few other priorities at this moment that need to achieve a more stable level..


It will never be linked to any commercial interests or speculation, Open Builder will always be freely available for anyone who wishes to use it (I recommend reading openbuilder.exe license to understand why the source isn't published). And I'm making an effort to make all usefull informations more organized and easier to find.



In conclusion:

This is a good way to keep learning more and more about boot disks, and in my opinion I think that the most important feature in this whole project is that everyone can step in and contribute a little bit to make it better allowing each project to be customized and suit what a person wishes..

@Yorn

A guy makes a utility called unisofs that is just an exe wrapper for filedisk.exe and bootextract.exe, both created by other people, and doesn't really bother crediting either of them for what *they* did, which was essentially write what he is using to perform all the operations. Anyway, I still think it's a GREAT tool, but he could have just pointed people to the utilities he used instead.

I'm the author of unisofs. I understand the point that you're trying to make but unisofs isn't a good example, let me explain why...

The main reason why unisofs exists is that I had a need to extract the contents of an iso image from the commandline and it needed to work without rebooting but nothing like that existed at the time for free.

HERE'S the source code for doing this which I made available to the public the very next day that unisofs was born (notice "filedisk.sys" in the first sentence? I published this code several other places on the net during that next few days and gave credit to filedisk in each one.

Doesn't bother crediting them?

THIS is the post where I mentioned adding BootExtract (note the direct link to thier website?)

Boot image extraction is possible thanks to BootExtract by Jochen Kalmbach.

Maybe you should select another project to pick on? Maybe one that hasn't released it's source code to the public or given credit where credit is due?

I spent ALOT of time trying to make these functions easily adaptable for public use and simply made a working example (unisofs) of what can be done with the code.

Alot of my freeware utilities are meant as working examples for better things that can be done with the code. Alot of times, these utilities are based on code that was previously non-existant (or said to be impossible) and I felt should be public knowledge.

unisofs is a nice utility if you have a need for it but it's simply a "Here's how to implement the code" utility (unless someone else comes along and improves it...).

Tom

dog, you might want to rename the Thread to something like. What is Open Builder and its history. Or something similar.

@Nuno
Cheers, that's one comprehensive answer

@TheHive
Can't see how to do that...

I think you can select - Edit - Full Edit - Then you should be able to change the tittle.

@Yorn
I'm the author of unisofs. I understand the point that you're trying to make but unisofs isn't a good example, let me explain why...

The main reason why unisofs exists is that I had a need to extract the contents of an iso image from the commandline and it needed to work without rebooting but nothing like that existed at the time for free.

HERE'S the source code for doing this which I made available to the public the very next day that unisofs was born (notice "filedisk.sys" in the first sentence? I published this code several other places on the net during that next few days and gave credit to filedisk in each one.

Doesn't bother crediting them?

Fair enough. I didn't know you posted on both msfn and ub4 forums. I just saw the thread for unisofs on ub4 and was testing the file and realized that it was a wrapper and then looked up the source of filedisk myself and figured that a tutorial was probably more in order than a wrapper.

Again, I apologize for insinuating you were trying to take credit for other's work, I wasn't aware that you gave proper credits on another forum after you first made it.

I think you can select - Edit - Full Edit - Then you should be able to change the tittle.

Tried that on the first post, couldn't see a way. Have you tried on one of your threads?

I did it on my topic.

It worked.

Maybe I'm allowed as .script developer, you as member are not.

Questions to the system administration:

Who is allowed to do what?
What about attachement and upload space for the different groups?


Peter

dog, you might want to rename the Thread to something like. What is Open Builder and its history. Or something similar.

@TheHive
Can't see how to do that...

FIXED!




jaclaz

@jaclaz

So, looks like you as Advanced user can edit everything?

Peter

Jaclaz has mod habilities..

Who is allowed to do what?
What about attachement and upload space for the different groups?

This has been implemented so recently that I still haven't add much time to properly explain how it is distributed..

Advanced/.script developers/developers get 20Mb of attachements space, plus the hability do do all sort of stuff inside their own posts like edit, close amongst other features and 1000 storable messages.

Members get the usual features and 500Kb of attachements..

As time goes by, those who are frequent members quickly get promoted to either advanced or .script developer groups depending on each person's personal interest.

Developers is a group reserved for those who choose to host new projects in their own forums here (like guru-p and hoovahhh) but not related to .script developments

And there are some other groups like searcher, people who search and post all sort of informations (jaclaz's case) and beta testers like TheHive's case.

With time other groups can follow, it's an early attempt to match the profile of each person as fair as possible with some relative rules to avoid too many groups..

I'll add people based on their contributions and posts, but this can also be done by other fellows of the group that someone proposes to join, perhaps a poll or just a topic where this could be talked about..


Boot-Land.net has some hosting features, it can create about 75 ftp accounts and host sub-domains, so most frequent contributors can surely count on these features to be available to them as well, I wish I could give more features to everyone, but I'm still trying to distribute these resources in a balanced way..