Hi, I disagree. At least if there already IS a c:\dos directory, FreeDOS should stay separate in its own c:\fdos or c:\freedos directory. Otherwise, c:\dos is possible, but it would have to contain the "bin" subdirectory of FreeDOS only. You would still need a separate FreeDOS directory for the rest, which people might forget to look at! That way, they will miss extra features which FreeDOS has but MS DOS does not have :-(.
Similar for some tools which are by design too different from MS DOS tools to use the same syntax. If you rename FDAPM to POWER, for example, you would first be tempted to load it as DEVICE (both not needed and not possible for FDAPM) and then be tempted to use MS POWER syntax (which reaches only a few of the many FDAPM features). I think people will have no problems with FreeDOS because typing DIR and COPY results in the same effect for MS DOS and FreeDOS, even though c:\freedos\FreeCOM.com provides them instead of c:\msdos\command.com or anything... My personal policy is: If it is interactive, it should be easy to use but does NOT have to look like MS. If it is only used in autoexec / config, it is acceptable to have different syntax (e.g. because of other features or other internal workings - like with FDAPM and even more so with LBAcache / CDRcache). People will only have to edit their config files ONCE, and we support separate config files for dual-boot install (fdconfig and fdauto) so different syntax does not really hurt. ONLY if it is not interactive but command line controlled, THEN syntax should be like MS DOS syntax where possible (impossible for the caches, and impossible where protected names like SMARTDRV / MSCDEX cannot be used). This reminds me of SWSUBST: It has more features than SUBST, so you should use the new syntax. But is the SUBST syntax compatibility mode working okay by now? At least FDAPM syntax compatibility mode works okay for me (note that adv:min/adv:max/adv:reg are all the same internally for FDAPM yet). Bugs in the working (e.g. FDISK failing to recognize drives) are more important than bugs in the syntax (e.g. PRINT and PRINTQ being 2 files, not one). For GRAPHICS, you can select yourself: Use my binaries directly or use the supplied batch file which parses MS compatible syntax :-). Please provide a list of programs where syntax differs from MS, with comments on how much it hurts in each case and how good chances are to fix it. For the MEM case, I think the /C FUNCTION should be added, but the LONG syntax variant (e.g. /DEBUG) is less important (note that /D means "drivers" in FreeDOS MEM, but the resulting output is similar to MS MEM /D(ebug) output...). Eric. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
