Mail Archives: opendos/1997/12/24/16:12:53
X-Comment-To: Pat Villani
Hi!
24-δΕΛ-97 08:16 patv AT iop DOT com (Pat Villani) wrote to FreeDOS Developer's list <fd-dev AT list DOT freedos DOT org>:
> 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? ;)
- Raw text -