Hi, On Thu, Jul 4, 2013 at 7:04 PM, Matej Horvat <matej.hor...@guest.arnes.si> wrote: > > Since there is a discussion about FreeCOM on the freedos-user list, I > thought I'd share some of my thoughts about its flaws and suggestions on > how to fix them.
The online .LSM says FreeCOM is maintained by Blair Campbell. He is (or was) a great contributor, but I haven't seen him around in forever. Maybe he still lurks here, dunno. Long story short, I'm not sure how realistic it is to expect much help on this, especially with no active maintainer. Though honestly, the most recent work has been done by good ol' Bart Oldemann (another guru), so perhaps he's your best bet (and he has SVN write access, unlike me). I'm not really in frequent contact with him (me = useless), but he's apparently been busy with "real life" (tm). So you can probably email him, but please be patient. :-) > 1. I think the beep on automatic filename completion should either be > removed or there should be a way to disable it. Sure, I can compile my own > version of FreeCOM to remove it, but I think the end user should have a > way to disable it too, and I think most people would prefer having that > long and noisy beep disabled by default. Agreed, but IIRC it even did something weird (not just printing a 0x7 BEL ASCII char), maybe direct port write for special chirp. I think even Eric Auer once said it hung on beep for him on certain hardware. (And not all PCs come with the buzzer these days.) I wonder if a "visual bell" (a la vi) would be nice here. > 2. As it appears to have been suggested a long time ago ( > http://www.mail-archive.com/freedos-devel@lists.sourceforge.net/msg05963.html > ), DIR /? should mention the /LFN option, because until I looked into the > source code and archives of this mailing list, I didn't even know it > existed! (And how is it not ignored anyway? optScanFct in cmd\dir.c lists > it after the /L option! Does it work by chance because of undefined > compiler behavior?) 0.82 is the "stable" version (preferred by Eric Auer) and the only one on SourceForge, but 0.84 is somewhat preferred by others (at least me). 0.82 doesn't support LFNs, that was a later addition (by Blair Campbell?, also added DESCRIPT.ION support). http://sourceforge.net/projects/freedos/files/FreeCOM/ http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/ > I can mention it in my localization file for Slovene > (SL - available on the FreeDOS localization project), but I'd like to see > other localization files include it too. Also, maybe it should be set by > default in DIRCMD so new users (who install FreeDOS from the CD) can see > that FreeCOM indeed supports LFNs. It may be slightly buggy. Can't remember, something like only on default drive or only C:\ or only works if C:\ supports LFNs. I don't know, can't remember. All I know is that Eric always said that 0.84 wasn't heavily vetted for changes. BTW, there are some switches that seem to disable LFN in FreeCOM output. So I'm not sure of the full ramifications. But yes, I do personally "set DIRCMD=/od /lfn"; nevertheless, that won't help for other shells (0.82, 4DOS, etc). > I myself was skeptical of FreeCOM's LFN > support until I tried using some of its internal commands (MKDIR, COPY, > etc.) with LFNs because - so I thought - if LFNs are supported, then > surely the DIR command should show them? What's the point of using LFNs > anyway if you can't see them in a directory listing? There's still some quirks and bugs. IIRC, you still have to also separately say "lfnfor on" and "lfnfor complete on". Also it has some problems with files with multiple dots in their names. (BTW, 4DOS supports LFNs if you enable it in the .INI file. I don't think /LFN works there, maybe not even %DIRCMD%.) BTW, the shell's built-in DIR doesn't have to be exclusively used. IIRC, the old 1DIR utility supports LFNs too (among others, e.g. DJGPP / GNU ls). And some file managers (Doszip, NDN, Emacs' Dired) also support LFNs, so it's not totally dire. > 3. What's the deal with DOSKEY features? FreeCOM claims to have them > built-in (if compiled with them of course), but the text string > TEXT_CMDHELP_ORIGINAL_DOSKEY (which I've never encountered because DOSKEY > /? displays TEXT_CMDHELP_DOSKEY - is the former unused?) says that, for > example, F7 and Alt+F7 are supported. Using them just makes FreeCOM beep > at me. Were those features implemented and removed, or never implemented > at all? I would like to have a way to clear the command history. I think it's only partially complete, never fully implemented. Yeah, kinda annoying, I personally almost just want to disable it entirely in lieu of an external util (e.g. Toddy), but it was never important enough for me to bother recompiling. (I actually like recompiling stuff, but FreeCOM comes across as very brittle, so I don't fool with rebuilding it much. At least, my gut says it's too complicated, but I've not stressed myself trying to hack it yet.) > Also, while this is not a suggestion for improvement, it is related to > FreeCOM anyway: when I compiled my own FreeCOM with my Slovene > localization file, it compiled fine "out of the box" with OpenWatcom 1.9 > (I changed nothing; only did the minimal changes to get it to compile on > my system), but the resulting COMMAND.COM can't be made a permanent shell > in FDCONFIG.SYS. If I do set it as a shell, I get "MCB chain corrupt" > errors when loading drivers, and that can't be good. My workaround so far > has been to load the original English COMMAND.COM as the first permanent > shell, then load my translated COMMAND.COM in AUTOEXEC.BAT with the /P > option. Does anyone have any ideas? It's not fully translated to OpenWatcom yet, IIRC. Bart did some work a year or two ago, but he never finished. So it's buggy. The official compiler that works is Turbo C (or whatever variant). So, for now, I would suggest sticking with that, if you can. > Also, for some reason, the English > COMMAND.COM is 66K, while my translated version is 83K, and I believe they > have the same functionality compiled in. I don't know, it always confused me too. Surely somebody around here knows. Maybe it was UPX'd after strings were appended?? Dunno. Well, it would only be truly worse if it ate more RAM (does it?). Honestly, I don't know if it always keeps the strings in RAM or not ("/MSG" by default??). Personally, I'd almost rather just strip out all the help text (for my own private use) as I don't need it anyways. > I apologize if any of this sounded too harsh, but my intention was only to > give some suggestions because I'd like to help improve FreeCOM. It's not harsh at all. FreeCOM works very well but can still be improved in various ways. Unfortunately, a lot of it seems to have been heavily modified by Steffan Kaiser, and I haven't seen him around in recent memory, so he's unlikely to be much help. Similarly with Blair and Bart (or even Eric these days, where'd he go?), everybody else is just ultra busy, I suppose. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
