re: re: Re: Beta vs. Stable
Eric Auer <[email protected]> Sat, 9 Nov 2002 03:33:05 +0100 (MET)
| Newsgroups | gmane.os.freedos.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi again. I recommend to CHANGE the spec at this points:
- requirement to compile with MASM (whoever invented that one?)
- description of BUFFERS= behaviour and FCBS= behaviour
> "All FreeDOS programs *must* be 100% compatible with MS-DOS commands
> out-of-the-box. Any additional features may be added as extensions, or
> using different command line options or config files."
I recommend to make our MEM accept the MS DOS syntax in addition to its
own syntax.
I will not make UNDELETE act like Norton ("MS") undelete. If you want, we
can rename it to make that point clear. Not only the command line syntax
but also the workings differ a lot. What MS DOS version introduced undelete?
I think we can meet the requirements without an 100% MS workalike. Otherwise,
a wrapper/shell as described in my UNDELETE update mail (I called it UNERASE
there) must be written that calls UNDELETE several times and when done, copies
the rescued files to the drive where the deleted files were...
For my question on non-working software, we have:
- Windows 3.x
- Norton Cache 8.0 "div by 0"
As Tom has pointed out that SMARTDRV, while not working with FDXMS (did you
try all of: FDXMS 0.9, FDXXMS 0.9, FDXMS286 0.01 ?), works fine with our
HIMEM, I would like to know if the Norton Cache problem is a kernel one or
one with one/all of our XMS (and maybe EMS) drivers. Anybody able to do a
test?
This list is "too short to be true", what else do we have? As mailed,
Descent only runs with DR-DOS emm386 EMS available and PIC=ON. It crashes
when only XMS is available, strange enough. I seem to remember that it did
work with MS HIMEM even with no EMS available. And I think it should work
with no memory driver installed, too.
The readme.txt says that you need at least 4 MB and MS DOS 5.0 - this means
that it needs more DOS RAM than DOS 4.01 usually gives you, I guess :-).
The readme also says that with < 8 MB RAM, the DOS extender will cause lots
of disk swapping (file will be called *.swp in current directory: at least
descent.bat contains "if exist *.swp del *.swp"). The readme does not say
anything about the KIND of memory needed (raw, XMS, EMS), so I guess all
kinds are okay!
Among software that does not run because it needs EMS and protected mode both
at the same time, there is Lemmings 3d demo. Hardly any other software that
I use is not satisfied with plain XMS. A few programs use EMS and need no
protected mode, for those I can use FreeDOS emm386. No real problem for me, I
just use DR-DOS emm386 because I am non-commercial... :-).
> Download http://fd-doc.sourceforge.net/spec/dosints.zip
> It's an extract of RBIL, but it's not complete and many things that are
> not relevant to the FreeDOS kernel are left in there.
This makes me not download dosints.zip - it will not give me a clear idea
of what is missing and what is meant to stay out of FreeDOS, kernel-wise.
I am not planning to read a huge RBIL cut-and-paste collection plus the
whole kernel sources just to still have to know myself which parts of the
RBIL cut-and-paste were not meant to say "needed in the kernel" and which
"needed in the kernel" things are not part of dosints.zip ... If I want a
RBIL, I prefer reading the full list which I have anyway.
> > BO> - fcbs - this one is stupid in the FreeDOS context; we simply don't need
> > BO> system FCBs for the FCB functions. It is parsed but ignored.
> > So what the problem with this?
> That the spec doesn't describe the kernel behaviour.
Then we need to change the specs and be happy that we can do FCB stuff without
having to allocate any FCB space :-).
Eric