To: fd-dev AT list DOT freedos DOT org, opendos AT delorie DOT com References: <34A10B3A DOT 1CFB AT iop DOT com> Message-Id: From: "Arkady V.Belousov" Date: Wed, 24 Dec 1997 22:31:17 +0300 (MSK) Organization: Locus Reply-To: ark AT mos DOT ru Subject: Re: Kernel status (was interesting phenomenon and Super Improved Freedos?) Lines: 87 MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Precedence: bulk X-Comment-To: Pat Villani Hi! 24-δΕΛ-97 08:16 patv AT iop DOT com (Pat Villani) wrote to FreeDOS Developer's list : > For future FreeDOS versions, I don't see how you can expect to get > everything on your wish list in a 16-bit OS. You have to keep in mind > that as a real-mode kernel, all your requests take up a lot of space and > 640K is very little space to play in. Yes, this is true, but this is not totally correct - 640K not competely exhaust their potetnion. What I mean? Although 640K not enough for complex systems and tasks now, but often this caused by bad development instruments. For example, what you can say about 1 Mb (one megabyte!) for utility for OS/2, which simply tracks Numlock status? My favorite example - PC Magazine's old attrib with about some hundreds bytes in size and 11 packed kilobytes of MS's attrib. B-\ I use in my work BC++ 3.1 and often check compilation results through "bcc -S" - this is nightmare... :( By manual code tailoring and rewriting some modules in my lib onto asm I gain about 10-20% size and speed improvement, but no more, although code remains very bad... I cry, when look at code generation for my String "module"... :( So, what I want to say. DOS as prior _can_ (although MS's tools very often not allows this) cover many requests for specialists, who itself don't want complex kernel like Windows and Unixes (although I itself use Windows as simple DOS multitasker) and advanced, but badly automated, GUI. DOS can serve as working and repair environment. But must exists set of appropriate developments tools from assemblers through C/C++/Pascal compilers, which must generate small and fast portable code, to command line interpreters like AWK, PERL, REXX and even Java, which require not considerably more resources, than shells like command.com and 4DOS. What we can see nowadays? Assembler too plain, so assemblers exists in sufficient amount. But assemblers not very suit for most task, which is larger, than trivial - I think, _only_ reusable components like kernels, drivers and libraries _must_ be written in asm). Also exist some amount of _old_ (!) C compilers - TC, MSC, some free subsets implementation. But C is weakly protected from bugs (nearly like assembler), not enough sofisticated nowadays (i.e. not allows write _integrated_ libs), and at that eat very many resources for code becuase weak optimization (look above for attrib's comparision). May be, I must care considerate C--. Pascal compilers also exists - StonyBrook, TMT, _old_ Borland's TP. But pure Pascal is toy, and current implementations is strange _subsets_ of Modula-2 and Object Pascal and also haves weak optimizations (although TP in comparision with BC wins for executables size - even if BC generates .com). So, Pascal can be good language for utilities, but they not very portable and spread. _In particulary_ becuase no portable sources (I know about TP6 disassembled sources). C++ is _almost_ ideal as language for medium scale works (not larger - C++ not have modules), but I don't know good DOS implementation. :( BC++ is obsolete and have _very_ bad optimization (nearly as missing), GCC (DJGPP) works only onto and for 386+ and requires too many in terms of environment (for example, imagine 260K of DOS4GW for attrib B-\), all others compilers cost enough and/or implement very small subset of C_++_ and/or require too many (like Win32). I don't consider there shell interpreters (_I_ don't know good DOS implementation, if not count horrible sets of compromises above command.com's ugly language like 4DOS), although often NDOS cover my requirements. But 4DOS/NDOS can't be used for kernelt writing. :( As result, I must say: DOS is bad in terms of _expansion_ becuase 16-bit model and ugly design. I think, redesigned DOS be (and must?) have a likeness with original Unixes (like Linux, may be). But, if we talk about current state, then DOS (as I say before) can cover most specialists requirements, so they state must be present in sources as is (for compatability reason) before going to next projects, and _first_ step must be development of develompent ;) tools. B-| [...] > I also want to add a comment. I don't wish to offend anyone so please > don't take this personally. I've been looking onto 32- and 64-bit > versions of an OS derived from my current work. This is not just a > simple recompilation because many issues surface when you target a new > platform. For example, the tool chain required is often unique and very > few commercial or free compilers and assemblers fit the bill (if you're > interested in what I've found, send email and we'll discuss it off > line). There are also architecture issues above and beyond > big-endian/little-endian, i.e., bus support, memory management details, > task models, etc. as well as debugging issues. P.S. I recently look at listing from BC++ and think - what about "addon", which optimizes code through listing or .OBJ? What you think about? ;)