@as702
Can you change the method for finding the cd (don't look for ubcd.ico, unless Victor changes the path of ubcd.ico to \ubcd\ubcd.ico)? Search for the cd in the same way as you look for which version of ubcd it is. Alternatively, you can get the path to dosubcd.igz with the getargs.com program and search for that path to dertermine the cdrom / usb thumb drive location.

See: http://www.ultimatebootcd.com/forums/viewtopic.php?t=1461&highlight=ubcd+ico for the problem when removing the icon from the root folder.

@Victor
Can you place ubcd.ico in /ubcd instead of /? It is annoying to have the icon file on your usb thumb drive in the root folder.
Change autorun.ini to:

Change also ubcd2iso.cmd so that the boot.catalog file gets placed in /isolinux.

Done. I'll include it in the next update.

Thanks.

@ as702 and Victor
Some suggestions:
Add a section in ubcd.bat that looks for \ubcd\dosapps\extra\core\ (out of inspiration ) on the CD / USB thumb drive. This extra folder can contain some extra zip files that must be extracted to the ramdrive but that can't be in the original freedos images due file size limitations.

Also add \ubcd\dosapps\extra\custom\
Make an install.bat file in this extra folder, so that everyone can easily edit it and add something to it without editing files in the freedos image itself

Usefull cases:
- Place in all the NIC drivers (network card drivers) in a zip file in \ubcd\dosapps\extra\core\. Ask in the ubcd.bat if the user want to install an NIC driver or not.
- Add 7z for dos, to \ubcd\dosapps\extra\core\ i(t is quite large (593.4 kb)).
http://www.ibiblio.org/pub/micro/pc-stu ... file/7zip/
If we let ubcd.bat search first for 7z for dos, we can compress all other programs in /ubcd/dosapps with 7z (small size than zip and cab files).
- The user can add an install.bat or a text file with config options to \ubcd\dosapps\extra\custom\ and can add for example: which keyboard layout he wants (so there is no need to edit the freedos image), that he want nfts access by default, ...

Edit the help script:
Remake it in the form of a menu (like the launch part of ubcd.bat . When you select an option of the help menu let the user choose if he want to view the further help text or that he want to launch the program.
Add in every program folder of \ubcd\dosapps a help.txt file, which contains the help text (you can copy the text from the isolinux menu config files. Maybe it is possible to add the help text to the startupl.bat file instead.

Rename startup.bat:
Rename startup.bat files to config.txt (or another name with an txt extension) so you can just open it in an text editor without the need for right clicking and select Edit.... The startup.bat files are now already renamed when they are copied so it doesn't need the .bat extension.

I'll try and address this as best I can...


I have a development version that does exactly that. It operates slightly differently in that it only unpacks the required files for each particular system (i.e. it doesn't stuff everything into ramdrive). I had to modify the msnet/netware modboot to append an additional search path for the required drivers (CD-ROM). Directory structure:



I would REALLY like to see the contents of the UBCD directory merged into the root directory as it was with UBCD4, thus, simplifying the CD layout (but I'm rambling).

I also have a 5.76Mb image which contains all the necessary NIC drivers (I'm running some ideas past Victor on this); ultimately, it's a trade-off between ease of implementation and time. I'm also not keen on rushing out too many sweeping changes without adequate testing in place.

Rest assured, it's being addressed.


It's being looked at...


You're not letting go on this idea.


Not keen on this. The whole purpose of the help option is to quickly familiarise users to the commands available to them at the command prompt (this also includes system commands provided by the freedos image). I think it's good enough as it stands for now.

Of more pressing concern would be to simplify the CD app launcher to include sub-menus to help categorise each class. I'd need Victor's input on this.


I'm currently investigating some alternative methods to the entire approach of launching theses apps. Again, I need to coordinate with Victor before proceeding.

It wasn't meant to unpack them all to the ramdrive, I was just a little bit lazy to write it down completely.


No, I don't let it go . zip files (crossplatform) don't compress very good compared with other compression methods. CAB (good compression) and UHA (very good compression) aren't crossplatform, sadly enough. 7zip is crossplatform and has a good compression ratio.

Thanks for reading all the stuff I posted. They are just some ideas, some can be useful, some maybe not.

i know (-:


All suggestions are welcomed, Icecube. The more feedback we're able to generate the better (faster, stronger, higher ad infinitum etc).

I am able to run the compression tool UHARC 6.0b on linux with the help of wine so we can use it as default archiving type, if you want.
http://appdb.winehq.org/objectManager.php?sClass=version&iId=4003&iTestingId=9023
You have to run wineconsole cmd instead of wine uharc.

You can also install WinUHA in windows or in linux (with the help of wine).
WinUHA is GUI (Graphical User Interface) for uharc. It has also shell integration.
It looks very nice and easy to use (a little bit like winrar and other archivers). So novice users should be able to decompress and compress uha archives very easily.
http://www.klaimsoft.com/winuha/download.php

When you want to run in on linux (else you can't use the uharc part):


@ as702: Where did you found uharc for dos? I found it some years ago, but now I can't find it anymore.

@icecube

I uploaded uharcd.exe (dos) for you to look at.

The only hesitation I have with using it for distribution is that although the compression algorithm is great, it does have some drawbacks (slower to unpack, very processor-intensive compared to the rest AND requires considerably more memory for unpack). I thought it may prove a nice addition for those looking to customise their own set of dos programs on the CD.

For the next release, I may simply include archive support for the lot (uha, 7z, rar etc) and worry about how we distribute the binaries required at a later date (the script I wrote is fairly modular and easy to build upon). As it stands, the current distribution currently supports CAB and ZIP archives out of the box.

Note to self: ...must familiarise one's self with Linux at some point.


Thanks, but I prefer running the CLI version for Win32 (I'm a stubborn c#nt in many respects).

Thanks for uploading the dos version of uharc. Do you have also the link to the original site of uharc?

Yes it requires more time to unpack. But you can make the dictionary size smaller (less memory needed to unpack). Because most data (before compressing) isn't that big, it makes no sense to make the dictionary size 32MB. You have to change the dictionary size to something smaller than the uncompressed size (or a little bit bigger). This should speedup the decompressing speed. Because you like the command line, this will be easy to do. 7zip has also a very large dictionary size when you use the -9 option (32MB I think). If the original data is only 1MB for example, this is a waste of memory. The decompression speed is very fast for 7zip.


I just mentioned that there was a GUI version, because most users don't like or don't know how to use the command line. (See the the problems that a lot of users have with just rebuilding the iso or with putting ubcd on there usb thumb drive.)

Okay, following some discussion I've decided to address some concerns regarding automation and manageability for the next update:

1) Banishing those annoying "dosapp" batch files
For ubcd4.11, these are currently to be found in:

For ubcd5b...

Not very practical or easy to manage. Instead, I decided to remove all those startup.bat files and replace them with the following file(s):

/main.ini


/usr.ini
(optional for users wishing to customise their distribution)




Then, using a nested loop function, we can create the batch files dynamically...







...and here's the result:







Hopefully, Victor will approve of this method for the next beta. At the very least, I'll include support for this functionality in the next release.

2) Customising the default dosapp folder
What I have decided to do is supply 2 locations from which freedos will search for dosapps - main and user. In order to allow users the flexibility to customise and declare their own locations, I've decided to employ the use of a global INI file which users can change to set their own paths.

ubcd.ini
(place this anywhere on the CD)


Simply change these as required and dosubcd.img will search these paths instead (omitting this file entirely will simply set the paths to their default locations).

What are the criteria for placing a program in a certain category? If not based on some settings that must be present, it maybe makes more sense to call them [Category "HD tools"], ... similar to the menus in the isolinux config file (more or less).

You maybe have the same idea to figure out the version of UBCD that is on the CD. Just look for the version name in the ubcd.ini.

User criteria. The idea is for Victor to hopefully adopt this technique in order to replace the existing method. The names I've shown are arbitrary (I simply wasn't going to type out +50 programs under relevant categories for the sake of demonstration).


Great minds. It's already in the build I'm working on.

(-:

Icecube

I have remove the icon and installed my own icon using Icon Edit

as702



Thank you Thank you

Just a quick musing...

I may decide to handle the detection of the dosapps folder(s) and/or archive(s) dynamically instead of relying on users to declare where they wish to set the relative path of the application in question. For instance, the development version I have running relies on using an INI file to set the directories...


Instead, I can create a LUT from within dosubcd.img whilst setting the cd drive...


index.dat contains the entire directory/file structure of our CD. Using this file, I can now dynamically search the relevant application during runtime (i.e. users can place their archives wherever the hell they please).

There a little more error handling involved, but I believe this to be the best strategy(?).

I don't think that this is a good idea. Scanning the cd will take to long. It gives also problem when ubcd is put on a usb stick. Most people add some personal files, which have nothing to do with ubcd, on the usb stick. If they put a zip archive to it, it will get listed in the menu as a program. As long as they put the files in the usr directory, they don' have to change the ini. For a beautiful menu you already have to edit the ini file, so changing the path for the custom folder in that file isn't so much work.

It's a one-off operation. I do concede that I haven't tested it on a real system though (I may try this to see and compare times).


It doesn't affect the menu (the INI file explicitly states the archive prefix and executable from which to build the menu with). If a duplicate archive is discovered when users attempt to launch an application, the script can scan each file in order to determine the correct archive to process. This particular aspect is not really so much an issue.

True. But it's one less set of variables for users to worry about (especially me).

Tricky one...

BTW, is there a text pager like MORE.COM in the FreeDOS boot disk?

@as702: When I updated to R1.28, whenever I try to launch a DOS app, I get an error message eg. intelfid.bat not found.

Couldn't find anything mentioned in your changelog. Is there something I am missing?