I wanted to throw an idea out there to find how interested the community is in a graphical interface to rebuilding the UBCD iso image and allow the easy addition of commercial software, trial-ware, and other open source software not included in UBCD.

I envision a Windows program (possibly cross-platform) that would allow the user to point to the UBCD iso image, point to the installation directory of a commercial software (such as Norton Ghost), and type in a new name for the iso image. The software would perform all the necessary tasks to explode the iso, build the disk image or copy the executables to the dosapps directories from their locations in the commercial software's install folder, modify the menu configuration files, and rebuild a new bootable iso image. This would also allow the user to add some trial-ware software like McAfee VirusScan Command Line Scanner to UBCD.

The design of this software would be based on "mod packages". These would be plugable modules including information and scripts to handle a particular piece of software (Norton Ghost 12.0, McAfee VirusScan 5.02, etc). These would be easy to create and would be specific to a particular piece of software. The graphical interface would read in all of the "mod packages" in its directory and provide these as options to the user. The user would be able to select only those software packages they wanted to include in the UBCD. The use of the "mod packages" allows the software to be expanded by the user without having to recompile any code.

Since the modified CDs might contain commercial software, they of course cannot be distributed. The goal would be to allow people who already own the commercial software to provide an easy method of combining it onto a single CD with the other great UBCD utilities. The modified UBCDs wouldn't have to contain commercial software. Victor mentioned that he wanted to trim down UBCD 5.0 to a more basic set of core diagnostic and recovery utilities. If users enjoyed using some of the open source software that was previously included in UBCD, this software would allow them to add it back in.

I have done everything this proposed software would do by hand. It is repetitive work, so I was considering writing some Linux shell scripts to automate the process. If there are enough people interested, though, I don't mind writing a graphical interface and making it easier for non-programmers to use. What I would want mainly is UBCD community support and testers. There is no point in writing the software unless the UBCD community thinks it would be a valuable tool. I would also need some additional people to help test the software. Of course, if anyone is interested in helping program, they would be welcome to contribute. I plan on releasing all software and scripts under the GPL.

"mod packages" ??? you mean something similar to the bartPE/UBCD4Win plugins? I don't use Linux all that often (shame on me), but I'm sure others might be interested(?).

Personally, I prefer to go right to the metal when it comes to these types of modifications since I like to know explicitly how and what's being modified; a tutorial section in the forums would suffice for me. Previous experience with such scripts has led me to be somewhat cautious of adopting such techniques; they're rarely retro-active by design and may introduce compatibility issues if these scripts are dependent on modifying shared components.

Of course, it's likely that others may not share this viewpoint. Just sounds like a LOT of work, buddy.

"mod packages" ??? you mean something similar to the bartPE/UBCD4Win plugins?

I believe so. I am not very familiar with BartPE or UBCD4Win, so I can't confirm definitively. "Plugin" is probably a better word than "mod packages".

as702 wrote:

Previous experience with such scripts has led me to be somewhat cautious of adopting such techniques; they're rarely retro-active by design and may introduce compatibility issues if these scripts are dependent on modifying shared components. Of course, it's likely that others may not share this viewpoint. Just sounds like a LOT of work, buddy.

I am not sure what compatibility issues you are thinking of; and there will be no shared components involved. Basically, I am proposing a point-and-click GUI for those users who aren't familiar with the command prompt. In addition to exploding the iso image and using the existing ubcd2iso batch script, the GUI will use the plugin's install script. It is actually not that much work. All it requires is to slap together a simple GUI, programatically modify the menus, and define the plugin's info file so the GUI can gather any needed info. If the GUI was to support creating the bootable floppy images, that might take a little more work but wouldn't be bad. The only reasons it would be dependent on the version of UBCD is that it would 1) modify the menus to include the user's program and 2) depend on the directory structure on where to place the components.

For example, I really like the editor Vim. So here is a bash script to add the Vim editor to the dosapps folder and rebuild the iso image. This would be a rough example of the installation script required by the GUI.

Of course, if anyone is interested in helping program, they would be welcome to contribute. I plan on releasing all software and scripts under the GPL.

I will try to help. Are you going to make it a shell script? There are a number of GNU utilities native ported to Windows. If we need some tools that aren't included, we always can use the tools of the cygwin project.
http://sourceforge.net/projects/unxutils

I have thought about something similar some time ago, but I didn't had time to make it. For the freeware programs of non-freeware programs that can be downloaded via a direct link we can use wget to download it. We can make a file which contains the program name, version number, download link localion, checksum of the downloaded file (to see that we have the file (archive, installer) from which know how the files are organised, which can change in another release of a certain program).

Are you going to make it a shell script? There are a number of GNU utilities native ported to Windows. If we need some tools that aren't included, we always can use the tools of the cygwin project.

I wasn't aware of these utilities; they're awesome. I wanted to stay away from cygwin because I have had cygwin DLL conflicts that were not easy to fix. These utilities, however, don't require the cygwin DLL and would be perfect.

I was thinking about a two step approach to this. First create some perl scripts that would explode the CD, call the plugin scripts to install the additional programs, and rebuild the iso image. The plugin scripts could be written in Borne Shell (sh). This will work under Windows using the utilities you linked to. After this first step is complete, rewrite the perl scripts as a Java GUI using Swing. The perl scripts will be much easier to modify to get everything working as needed so it would be much better to use in the first step. The Java would provide a much easier to use graphical interface.

This method would allow the GUI and the install scripts to work under Windows, Linux, and Mac OS X. The only downside to this two-step approach is that it would require the user to have a version of Java installed (we would include all the other programs such as sh.exe). However, I do not think the Java requirement would be unreasonable. We could always distribute a JRE with the program. What do you think?

First create some perl scripts that would explode the CD, call the plugin scripts to install the additional programs, and rebuild the iso image.

To extract the iso from the command line we can use 7z.exe from the 7zip program. It works on linux too.

Code:

7z x -oPathToToExtractTheISO ubcd50.iso

Maybe instead of using perl we can use python (see below: GTK+ Phyton bindings).I have never made a decent program with a GUI (except in Visual basic some years ago ) so I don't know in which language we can write the GUI the best. Maybe we can try to use the GTK+ platform, which is also cross platform and also a lot smaller download than JRE. (Firefox uses GTK and its download is less than 10 MiB.) But because you are familiar with Java, it will probably be better to use java at least for the moment. If we write the test program without GUI in Python, if hopefully won't be to hard to convert the program to a GUI program with the python bindings which are available for GTK+.

Quote:

GTK+ is a highly usable, feature rich toolkit for creating graphical user interfaces which boasts cross platform compatibility and an easy to use API. GTK+ it is written in C, but has bindings to many other popular programming languages such as C++, Python and C# among others.

To extract the iso from the command line we can use 7z.exe from the 7zip program. It works on linux too.

I was thinking the same thing. I would like to keep all the utilities we use to only open source software. That way we can distribute them with the software.

Icecube wrote:

I have never made a program with a GUI (except in Visual basic some years ago ) so I don't know in which language we can write the GUI the best. Maybe we can try to use the GTK+ platform, which is also cross platform and also a lot smaller download than JRE. (Firefox uses GTK and its download is less than 10 MiB.) But because you are familiar with Java, it will probably be better to use java at least for the moment.

I selected Java since I am the most familiar with it; I believe I can write the Java GUI within three days. Qt, wxWidgets, and FoxToolkit are other options; but I am not familiar with any of them so they would take considerably longer. Hopefully the user has already downloaded the JRE for other software packages and will not have to download it again.

Icecube wrote:

For which programs do you want to write plugins?

I was planning on writing the Java GUI and perl scripts myself. Others are welcome to contribute, but these programs are not very complicated and will be pretty quick to write. The main area I would need help with is writing the plugin scripts. These scripts will not be hard to write (see below), but hopefully there will be a lot of them. As for which programs to write for this is largely up to the user community. I am gathering a list of programs commonly used by my company's IT staff which I will be writing scripts for (the main reason I decided to do this). However, everyone is welcome to suggest their favorite applications for inclusion!

I have already started to work on this and have got quite a bit done. I have a perl script that will look in the "plugins" directory and read in and execute all scripts. It will then append the necessary information to the menu.cfg files. The next step will be to tie in 7zip and mkisofs to rebuild the CD. Currently the format of the plugin scripts follows (this one inserts Norton Ghost 2003 binaries to the dosapps folder):

Now that I am writing some code and others can begin to contribute, where should we put the code. I would like to use SourceForge's Subversion version control system. Would it be better to put the code under the UBCD project or to create a new project for it.

So the bash script should also zip the files into a zip archive (with 7z or zip).

Can you explain all the parameters in the script?

Code:

NAME="Norton Ghost 2003" ==> Name that gets displayed in the menuDESC="Full system backup and recovery software" ==> Help text that gets displayed in the menu CATEGORY="hdd/clone" ==> in which config file the app will be placedTYPE=dosapp ==> type of application (dossapp / disk image / kernelLICENSE=commercial ==> I don't know where you can see it. Get it added in the menu after the program name?LOC=norghost ==> Where should the files be placedEXE=ghost ==> not sure if this adds something usefull (or is it just info)# END Header

Maybe instead of using perl we can use python (see below: GTK+ Phyton bindings).

Icecube wrote:

If we write the test program without GUI in Python, if hopefully won't be to hard to convert the program to a GUI program with the python bindings which are available for GTK+.

I would be open from moving from Perl to Python. I have already got the core of the script written in Perl (one of my favorite languages), but Python is gaining in popularity and it would be fun to learn.You will have the same issue of an extra download with the JRE as with GTK+. GTK+ looks like it is about 4MB while the JRE is 14MB. I plan on writing the GUI in Java, but someone else is welcome to write a GTK+ GUI.

Icecube wrote:

For writing the plugins, a bash script will probably do the job the best. It is also very easy to make or edit one for another program (users can write and submit there own plugins).

Agreed. However, I would stick with Borne Shell (sh) of which bash is based. Borne is more widely supported and, as you mentioned, they are available for Windows through the unxutils package. The difference between bash and sh is mainly a technicality, but should be mentioned since bash has much more functionality that will not work under the unxutils Windows executables.

Icecube wrote:

I don't know if you have downloaded the last version of ubcd (ubcd50b3), but the dosapps layout has changed.

No, I am still working with version 4.11. I will download the new version soon and update the scripts. The scripts are not ready for release quite yet as there is still more work to do that will change the format of the scripts. It will not be hard to use 7zip to handle the compression/uncompression of the dosapps.

Icecube wrote:

Can you explain all the parameters in the script?

I will need to add more, this is just a start. Your assumptions are correct about the parameters. The CATEGORY is an abstraction that will be mapped to the menu directory of the current UBCD. It was deliberately made different to separate it from the menu's file structure. The LICENSE is just for info. This might be good to have to indicating which plugins can be legally distributed. The LOC is where the files should be placed (under /dosapps, /images, etc). The EXE is the name of the executable file. This is used to generate the startup.bat files.

As you mentioned earlier, since this is based on UBCD4.11 it will have to be updated to work with UBCD5.0. I plan on trying to get the scripts working as they are before I update them.

Another feature that might be useful to add to this GUI is to create a new 'user.cab' file inside dosubcd.igz that contains their favorite programs they want available in all dos boots. In my case that would be the latest version of Vim.

I have gotten a preliminary version of the software made. It is a Java graphical interface that can extract and create UBCDs. Currently, it doesn't support the plugins I discussed earlier; however, it will soon.

I have also included the ability to "patch" a CD. This allows you to extract the contents, apply a patch (it extracts a zip file over the contents replacing the old files), and then recreate the CD image. This would allow distributing a smaller file for incremental updates.

I have published what I have now under the GPL and tested it on my machine with no issues. However, I need more testers! Please download the program and see what you think. I will be adding the plugin feature in the next few weeks.

The project is hosted on SourceForge (http://ubcdcreator.sourceforge.net) so please go download the software (it requires Java 1.5 or higher) and give me some feedback on the forums (at UBCD Creator).

I need a lot of people to use the software and post bugs on the Tracker to make it more stable. I look forward to your comments!

I say occassionally cause no real idea what it'll look like, however a tool to update the virus/spy definitions and create a new iso would definitely be useful, depending on how it develops perhaps it'll be a more used tool by myself.

... however a tool to update the virus/spy definitions and create a new iso would definitely be useful...

I also like this idea, UBCD4Win does something similar.

It may also be worth having a "master list" of updates (which may negate the need for ubcd "patches"), a centrally managed list of modules/plugins to update/replace existing packages on the CD. This may need the updated sw to be repackaged and hosted (somewhere), and the "master list" (which would need to be online in a consistent location) to hold a reference to the new files and download locations. A user could then download the latest list of updates (some of which could be automatically selected for download, others would be optional), and allow the user to choose which plugins to install. After the user has selected it would check the local cache download folder, download any required updates which are not already downloaded, and then apply the updates. This would also allow updates to be distributed quicker as plugins can be created/updated individually as software is updated.

You could also use the "master list" as an easy method for distributing plugins which are for commercial software (in this case the plugin would just contain the script etc. to build the package), obviously in this case it should not be selected for download by default.

I'm not suggesting this would be the only method of getting plugins - users should also be able to create/manually download individual plugins - however this may just offer a way to make a standard list easier to download and install..

...however a tool to update the virus/spy definitions and create a new iso would definitely be useful...

This is a very good idea. I will add an update button that will allow the program to connect to the internet and fetch any periodic updates and apply them to the extracted CD image. Beyond antivirus definitions are there any other programs that have regular updates (to data or the programs)?

beermatt wrote:

This may need the updated sw to be repackaged and hosted (somewhere), and the "master list" (which would need to be online in a consistent location) to hold a reference to the new files and download locations.

This is exactly the capability of the not-yet-complete "plugin" functionality. A "master list" is unnecessary. The software will read in all the files in the "plugins" folder to load the needed information. These files will contain all the information needed for the software to fetch (either locally or over the web) the application, verify its integrity (md5 hash functions), rebundle the software into the UBCD format, and add/modify the necessary UBCD menu items.

The user will get new plugins as they are published (downloading them either automatically or manually) from the UBCD Creator website. The user will select which plugins they want to install, then UBCD Creator will go and fetch the files (for free software) from the internet or fetch the files from CDs or the user's hard drive (for commercial software) and execute the plugin shell script to rebundle them into the UBCD format. UBCD Creator will then modify the UBCD menus to add/update the component to the menus and then build a new ISO image from the updated files.

beermat wrote:

You could also use the "master list" as an easy method for distributing plugins which are for commercial software (in this case the plugin would just contain the script etc. to build the package)...

The plugin capability is also intended for commercial software. The plugins will be written in the Borne Shell (UNIX shell scripting) language. This will allow the plugin to perform unique tasks such as modifying configuration files, etc to create the UBCD component to install. An example of a plugin for Norton Ghost 2003:

In this example, the plugin copies three files from the Norton Ghost 2003 program directory under windows (selected by UBCD Creator and passed to the script as $1) to the temporary destination directory $2 for UBCD Creator to zip to create the dosapp.

I am still working on the plugin functionality, so I have not defined the complete plugin format or even identified all the needed meta-data. This functionality will not be available for awhile as I need to gather several different examples to properly define the plugin files.

What is the Linux command to extract files from the ISO. I thought I had this working on a linux machine, but neither 7z under Mac OS X fink nor 7za under CentOS 4.4 seem to be able to extract ISO files.

This may need the updated sw to be repackaged and hosted (somewhere), and the "master list" (which would need to be online in a consistent location) to hold a reference to the new files and download locations.

This is exactly the capability of the not-yet-complete "plugin" functionality. A "master list" is unnecessary. The software will read in all the files in the "plugins" folder to load the needed information. These files will contain all the information needed for the software to fetch (either locally or over the web) the application, verify its integrity (md5 hash functions), rebundle the software into the UBCD format, and add/modify the necessary UBCD menu items.

The user will get new plugins as they are published (downloading them either automatically or manually) from the UBCD Creator website. The user will select which plugins they want to install, then UBCD Creator will go and fetch the files (for free software) from the internet or fetch the files from CDs or the user's hard drive (for commercial software) and execute the plugin shell script to rebundle them into the UBCD format. UBCD Creator will then modify the UBCD menus to add/update the component to the menus and then build a new ISO image from the updated files.

Fine - I guess I was anticipating the plugins being hosted in different locations, therefore a need for a master list to refer to them. However if you're intending to host them all on the UBCD Creator site, and the program will have the capability to checks for plugin updates from the site that will cover it. I was just thinking how the Creator could be made useful for all users rather than just making things easier for those users that are already able to customise & rebuild.

melee wrote:

beermat wrote:

You could also use the "master list" as an easy method for distributing plugins which are for commercial software (in this case the plugin would just contain the script etc. to build the package)...

The plugin capability is also intended for commercial software. The plugins will be written in the Borne Shell (UNIX shell scripting) language. This will allow the plugin to perform unique tasks such as modifying configuration files, etc to create the UBCD component to install. An example of a plugin for Norton Ghost 2003:

<snip>

In this example, the plugin copies three files from the Norton Ghost 2003 program directory under windows (selected by UBCD Creator and passed to the script as $1) to the temporary destination directory $2 for UBCD Creator to zip to create the dosapp.

I am still working on the plugin functionality, so I have not defined the complete plugin format or even identified all the needed meta-data. This functionality will not be available for awhile as I need to gather several different examples to properly define the plugin files.

All sounds good - I also think Ghost is a good first choice (likely to be popular).
A plugin for Spinrite should also be fairly simple (only needs to find/copy spinrite.exe).

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum