and other tricks, but the specific version of the forum board software (phpBB in this case) should be able to support those characters, or should know how to parse the equivalent specific html code, which is very frequently not the case.

So:1_ Avoid using "special" characters in urls if at all possible.2_ Avoid posting temporal links (use "code" tags instead).3_ If #1 is not possible, use “code” tags.

If really needed, for further discussion about it please open a topic in the chat subforum.

_ fdubcd.iso -> fdubcd.img -> dosapps -> ubcd.ini: hddera33 command == hdderase command. Couldn't this be a problem when all cabs are initially expanded? I think the filename "hdderase.exe" in hddera33.cab should be changed to avoid potential overwriting. Am I wrong?

_ I noticed that inside fdubcd.img 52a1, the file names are not uppercase as they used to be (uppercase is the normal standard DOS 8.3 format), so lowercase is (unnecessarily) using long file names support, which potentially occupies more space and it's harder to read.

_ What's ettool.com for?

_ Which exact version of the FreeDOS kernel is being used in fdubcd52a1?

I have not finished testing, so more comments may come in the next days...

edit: as of removing Alegr Memtest: I solved the problem with incompatibility with FD-UBCD by creating a separate image.

Thanks! Tested and added to 5.2a2.

Quote:

Yeah, Parted Magic 11-30 has been released two days ago.

Will update in 5.2a2.

Quote:

Please differentiate between "updates" and "ports" and "forks". xosl 1.1.5 should be kept, whether others are included or not.

I will include both in 5.2a2. Based on my research, it seems XOSL-OW may have its problems too with certain PC hardware, so including both will ensure the widest range of hardware is supported.

Quote:

I believe this is a mistake. SG2D doesn't support grub legacy. Grub2 is completely different than grub legacy. It is correct that SGD is no longer developed, but grub legacy is still in use. There are alternatives for rescuing grub legacy systems, but they are MUCH bigger in size than SGD. Please maintain SGD included in UBCD.

OK, will reinstate SGD in a2.

Quote:

FDUBCD can be started in several "modes", including customizing each startup line with F8. So I don't understand the reason not to include AleGr as it was before.

FDUBCD requires some form of HIMEM.SYS to be installed, otherwise certain modules will refuse to work subsequently. If you boot in "Clean" mode, you will have no access to the CDROM drive and the toolchain required to identify/extract the CAB files. Hence, having its own boot image probably makes the most sense.

Tested on VMWare and the two laptops that I have access to, with the same problem.

Quote:

It should be noted that 4.2a3 is an ALPHA version only and was never finished. The previous version is STABLE. The program is "too powerful" to be "messing around" with it.

I did some Googling and didn't find anyone complaining about data destroying bug in 4.2a3. 4.2a3 is the LAST version that the author deemed acceptable to put on his website with a clear message that there will be no further development. I think that says a lot.

Quote:

Perhaps you could include pcisniffer.pdf from Miray Software's website. You didn't include it in UBCD 5.1.1.

Will be ignored by normal user. But useful for advanced user to pass args to mkisofs without editing the script. For example, I use it to make mkisofs ignore certain directories ("website") when generating the alpha ISO image.

Quote:

Please update: ./ubcd/tools/win32/unxutils/bin/xz.exe

Done.

Quote:

-> line 4, correct typo to "readme".

Done.

Quote:

Couldn't this be a problem when all cabs are initially expanded? I think the filename "hdderase.exe" in hddera33.cab should be changed to avoid potential overwriting. Am I wrong?

No a problem. The files are expanded to different directories, so there will be two "hdderase.exe", but in different directories.

Quote:

What's ettool.com for?

"ettool.com" and "etdump.com" can be found here. They are for debugging problems related to eltorito.sys. I included them so as to make it easier for us to debug the CDROM problem under grub4dos. In the next release, I will move "ettool.com" to "bin" (where etdump.com) can be found.

Quote:

Which exact version of the FreeDOS kernel is being used in fdubcd52a1?

It just "sounded" strange to see the link to CMOSPwd in KeyDisk (which has its own page too) but not in the CMOSPwd entry, that's all. Since you don't usually add the links to the help text... Not at all a big issue, or not an issue at all .

The hlp file name extension under Windows makes unnecessarily "complicated" to read or edit the content of those files. Thus the change to txt.

About F8 and F9, it would leave the more usual/common F1-F7 for (future) UBCD itself (or for customizations), instead of using them for pmagic. BTW, pmagic has its own F1-F12 help files too. I could had also suggested F11-F12, but I'd rather avoid F10-F12 if F1-F9 are available.

Will be ignored by normal user. But useful for advanced user to pass args to mkisofs without editing the script. For example, I use it to make mkisofs ignore certain directories ("website") when generating the alpha ISO image.

Could you please add this as REM comment in ":_help" (Usage) in the script? An example in the script in ":_help" (Example) would be welcomed too (I think as REM would be enough).

Quote:

Quote:

Quote:

Which exact version of the FreeDOS kernel is being used in fdubcd52a1?

About 100 different keyboards compared to about 20? Just have a look at /FREEDOS/PACKAGES/BASE/KEYBX.ZIP.

Bad news. It will be quite difficult to replace mkeyb with keyb in FD11. The two programs are just too different. It will require the current keyboard cab to be redone from scratch.

Well, I am not really surprised, if it was a short hack as integrating the kblang= parameter I would have offered yet my result instead of asking you. Btw, will you use this modification to the keybrd.cab (ntegrating the kblang= parameter) that I made, just in case somebody else would also like to make use of it - in the official release? I mean, not because it would save me some minutes each update

The hlp file name extension under Windows makes unnecessarily "complicated" to read or edit the content of those files. Thus the change to txt.

Those two files are not pure text files. There are two control characters inside when decoded in ASCII. FF (0x0c) and SI (0x0f)Are you sure there will be no problem editing them in Windows' Notepad?

Yes, I am sure they can be edited with any text editor. In fact, they can be edited almost exclusively by text editors. You can also generate a new simple text file and display it with F1-F12 (and there are other alternatives too) from the Syslinux boot menu.

I wouldn't get here into the details of (so-called in Syslinux) DISPLAY files format, so to maintain the discussion on-topic. If there is interest in adding help files (F1 - F12 and other methods) to UBCD boot menu, or to discuss this specific suggested change, lets open a new topic just for it. Just let me know, or start it and I'll gladly reply .

Btw, will you use this modification to the keybrd.cab (ntegrating the kblang= parameter) that I made, just in case somebody else would also like to make use of it - in the official release? I mean, not because it would save me some minutes each update

The hlp file name extension under Windows makes unnecessarily "complicated" to read or edit the content of those files. Thus the change to txt.

OK. Sure.

Quote:

About F8 and F9, it would leave the more usual/common F1-F7 for (future) UBCD itself (or for customizations), instead of using them for pmagic. BTW, pmagic has its own F1-F12 help files too. I could had also suggested F11-F12, but I'd rather avoid F10-F12 if F1-F9 are available.

F1 is typically reserved for "Help", so I think it makes more sense to preserve F1-F2.

Quote:

Any reason not to use 2041?

I was using the kernel from FreeDOS 1.1, which is 2040. I will check out 2041. Thanks!

About F8 and F9, it would leave the more usual/common F1-F7 for (future) UBCD itself (or for customizations), instead of using them for pmagic. BTW, pmagic has its own F1-F12 help files too. I could had also suggested F11-F12, but I'd rather avoid F10-F12 if F1-F9 are available.

F1 is typically reserved for "Help", so I think it makes more sense to preserve F1-F2.

That's exactly my point. UBCD's help should be F1. The boot entry for PMagic is the only place that F1 is mentioned to the user. Change that line to F8 (together with the changes I already mentioned) and the help for pmagic will use F8-F9, leaving F1-F7 for UBCD help files (that could be developed for future releases after 5.2 gets out - no rush).

Additionally, many multiboot tools and distros use also F1-Fn, so leaving them clean makes it easier for the user to combine UBCD with them. If F1 was used for UBCD's help, that would be more reasonable (as pmagic itself uses F1 too).

Anyway, this is just a very minor detail.

On another issue, what's the need for fdubcd -> ETC -> config.sys and kernel.sys ? I mean, why in that directory?

Currently, we have the full ISO, gzipped. But the only file really necessary is the DBAN.BZI file. The size would be about the same (for sure not bigger). Instead of booting it with memdisk -> isolinux, we can just boot it with isolinux directly (as we do with other tools).

The only "con" would be that DBAN.BZI is not an iso/img image, as the rest of the files in the "images" directory.

Ideally, we could use a subdirectory to add all the relevant info (F1-F12, DBAN.BZI, the different boot entries...). If you would rather leave the "images" directory with iso/img images only, we could move it to "/ubcd/boot/" as other tools have been moved in the past.

If you are interested, I could prepare the relevant isolinux files and updated boot entries. Let me know.

So in fact, by skipping the antivirus databases in the original release of UBCD, you save time. I can only see pros, no cons.

OK, point taken. Lemme think about it. I hope the others can chime in on this as well.

I have liked being able to scan a system without internet access which requires having databases, but I could just download those to a flash drive before I go to the system. The saved space by NOT including the databases would allow for adding other tools, distros, etc.

So in fact, by skipping the antivirus databases in the original release of UBCD, you save time. I can only see pros, no cons.

OK, point taken. Lemme think about it. I hope the others can chime in on this as well.

I have liked being able to scan a system without internet access which requires having databases, but I could just download those to a flash drive before I go to the system. The saved space by NOT including the databases would allow for adding other tools, distros, etc.

@The Piney,

If UBCD would get out today with current databases, and you were going to use the same antivirus database 6 months from now, the result of such scan would not be really relevant in most cases. It gives a false sense of security, which can potentially be even worse than not scanning at all. So you would need to download updated databases again anyway. Hence, the initial databases are a waste of space and bandwidth (except for the very first short period after UBCD gets out).

Currently, we have the full ISO, gzipped. But the only file really necessary is the DBAN.BZI file. The size would be about the same (for sure not bigger). Instead of booting it with memdisk -> isolinux, we can just boot it with isolinux directly (as we do with other tools).

I prefer the current approach.

1) If we load dban.bzi directly, we miss the main menu2) If we chainload isolinux.cfg, that won't work with grub4dos

If UBCD would get out today with current databases, and you were going to use the same antivirus database 6 months from now, the result of such scan would not be really relevant in most cases. It gives a false sense of security, which can potentially be even worse than not scanning at all. So you would need to download updated databases again anyway. Hence, the initial databases are a waste of space and bandwidth (except for the very first short period after UBCD gets out).

I will release a version without the antivirus defs for those who want it that way. For the default version, I would still prefer something that works out of the box.

1) If we load dban.bzi directly, we miss the main menu2) If we chainload isolinux.cfg, that won't work with grub4dos

I respect your preference for the current approach, but just to be clear, I don't understand the 2 points, specially the first one.

The "official" dban image uses the boot prompt. In my customized UBCD I use UBCD main boot menu -> dban boot menu (instead of cli). So I don't understand what you meant with your first point.

Regarding grub4dos, I guess you mean that the script to translate from syslinux to grub4dos boot menu would require a custom part just for dban. Is that it?

Victor Chew wrote:

I will release a version without the antivirus defs for those who want it that way. For the default version, I would still prefer something that works out of the box.

Nah . Users' tendency will be to download the default bigger ISO image, and those that want to use updated antivirus definitions (should be anyone and everyone interested in these tools) will update them anyway.

My argument is about wasting less time, less bandwidth and less space, also reducing the "false security". With 2 alternatives, the result will be exactly the opposite, both for users and for you. If you are going to provide a download that already includes the antivirus databases, then IMO just provide that one and nothing else.

Who is online

Users browsing this forum: No registered users and 6 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