Hi, commenting on several comments here... Tom: > BC xx wouldn't have worked > after my HMA additions. I hope you make that clear somewhere. Otherwise, people try to use BC...
> >It would be helpful to have some port MASM --> NASM document. Two solutions: Use Arrowsoft ASM (freeware). It supports not-too-complex MASM/TASM files. Good for the existing code base. And tell people how to port to NASM (I can help with some FAQ entry about it or something, preferrably after YOU told me the URL of a package which I should use as an example for MASM vs NASM differences). But it would be too far-fetched to require all non-NASM assembly to be ported to NASM any soon. For newly written code, NASM should be used. > >I know Jim can phrase the change of the reference tools so that Turbo C > >becomes a backup-solution, not to be turned down immediately. And I really hope that it will be possible to compile the kernel with Turbo C in the near future. Not optimized but a cute little compiler, only 1 MB to download the whole thing including the IDE. I even ported FORMAT, EDIT and "the parts of MODE which were submitted by Aitor for DISPLAY interfacing" from BC3 down to TC2, was not too hard to do. Jim (kind of): > http://fd-doc.sourceforge.net/spec/spec.html > "Our reference standard for a C compiler will be Borland C 3.1. Our > reference standard for Assembly will be Microsoft MASM... > The existing code base was also a deciding factor in choosing a reference > standard." I hope that is obsolete now. I suggest that everything be at least compileable with FREE compilers: if it is TASM/MASM, make sure that ArrowASM can process it (exception for now: EMM386, too complex for a quick port). If it is BC3, take care to port to TC2, should be easy. If it is NASM / OpenWatcom / DJGGP (the latter only for 32bit stuff like DOSFSCK / in the future also SCANDISK), even better. > is it something like the bible, or should it be something > reflecting (intended) reality ? I suggest that it describes reality, but that original intentions are not removed but just marked as obsoleted. Examples: Please compile everything for 8086 by default, and mark 386 compiles clearly as such. Exceptions are obvious cases like EMM*386* and XMS-using programs which can assume a 286 to be present. I violate the rule myself by having XMS-using caches which require a 386, but on the other hand, HIMEM does the same :-). I wonder if we should try to make CD-ROM drivers for < 386 available. What else is 386-only now? DOSFSCK (good because it needs lots of RAM for FAT32!) for example. What else did I forget? (Anybody knows if any SMARTDRV version ran on < 386...?) Config sys compatibility: For ME, non-menued (DOS 5?) config sys is fine, and I am not worried by the fact that our menu language is different. Might be a point which is open for discussion. Reading http://fd-doc.sourceforge.net/spec/config.html I see that we do not have secondary buffers (which are used for read-ahead) and that our COUNTRY does ignore the codepage and filename. How hard would it be to add that, so that I could start writing NLSFUNC...? As far as I understand, most NLS functions are already there, so not much more than NLSFUNC (the "hub" of the codepage change propagation system) should be missing. DRIVEPARM is missing but SUPPOSED to be easy to add for a kernel expert. Even implementing DRIVER SYS as a variant of DRIVEPARM should not be too hard. Are you sure that there can be up to 64 STACKS? I thought only 8..16? http://fd-doc.sourceforge.net/spec/commands.html is a quite frequently updated document. It even drops APPEND as not-so- useful-on-modern-systems. Then I wonder why we have DRIVEPARM / DRIVER in the other spec... Is CHCP already there (but inactive, NLSFUNC missing)? I wonder why DISKCOPY /1 is in the spec... And EDIT /G (disable CGA snow waiting)... EMM386 W=... is kinda pointless (Weitek FPUs were never widespread and are even out of business now). While it is marked as DROPPED, FASTOPEN might be useful to speed up directory access. Test results would be useful (it caches dir entries, and a disk cache only obsoletes PART of that function). Did FC really have an /LBn option? Does FORMAT really have to ignore "k" or "kb" or "m" or "mb" strings after size values and accept both "1440" and "1.44" and so on?? Should GRAFTABL really be dropped? You know my opinion about GRAPHICS /LCD (see post 1.0 list). The MEM spec mentions /P as "program". Should better be "page", as in the more popular MS MEM versions. RECOVER got dropped. I already explained what it does and why you (do not) want to use it in file / drive mode. File mode might actually be useful, BUT I recommend implementing that as "XCOPY /ignore_errors" which would copy unreadable sectors as filled with "*" and skip over unreadable directory data. Okay for me to drop SETVER. UNDELETE: Compare current syntax with the spec... Should a delete-tracker (log first char of deleted files) and a trashcan (turn DEL into MOVE and log) TSR be requested on the spec? UNDELETE is not even by MS... Similar for the "spec-ed" UNFORMAT syntax. Rest looks okay. Can somebody please make a list of date-displaying programs which do not yet support NLS / COUNTRY settings? Same for time. I think most programs will only be affected by the "request to support NLS" because they display long numbers, if at all. But the spec only requests NLS date/time display, not NLS number display, and the 1.0 TODO list requests NLS for everything, kind of inconsistent. I vote for "request NLS only for date/ time for now". FIND/SORT already use it for sorting and case sensitivity, too. FORMAT uses NLS for number display and EDIT for time display. Etc.! The spec also requests that all things be GPL preferrably. I think we should be more realistic and explicitly allow public domain and similar licenses as well. Will not hurt the open-ness of FreeDOS, only push the GNU movement a bit less. Still GPL is preferred, of course :-). Nice that there is already an explanation of "bundling with non-open software into a distro is no problem". That was quite a long mail, sorry X-). Eric. PS: fprintf -> write saves much space, but fprintf -> prf.c printf already saves a lot, too. In that context: People, use prf! But be warned, prf does NOT support floating point and (!) it does not support %h... short ints, at least not in the smallest prf.c versions. Otherwise it is trivial to use, just link it into your binary and it will replace the bigger default printf (and sprintf). ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
