Success and problems with Descent, Jazz Jackrabbit, AuGoS, XCOPY BUG!!
Eric Auer <[email protected]> Mon, 11 Nov 2002 02:07:37 +0100 (MET)
| Newsgroups | gmane.os.freedos.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, I have done some more experiments...
First, XCOPY does not work.
At least it does work in a strange way:
xcopy /s /f /l d:\foo\baz\*.* d:\foo\test\
does not copy subdirectories, neither full nor empty.
xcopy /s /f /l d:\foo\baz d:\foo\test\
does not copy anything.
xcopy /s /f /l d:\foo\baz\ d:\foo\test\
does not copy anything.
The /l flag means simulation mode, but without it, I get the same
results. Once I got an even stranger result, where the only existing
file of the CURRENT directory would have been copied to all subdirectories
of the target directory that also exist in the source directory.
Yep, here we go: If I reproduce (by hand, xcopy fails to create any
directories!) the source directory structure under the target directory,
then all files in the SOURCE directory are copied to all EXISTING sub-
directories of the target directory, even when not matching subdirectories
of the source directory.
I think something got completely messed up in the recursion logics
of xcopy, recursing the TARGET instead of the SOURCE :-(.
Anybody who can fix this?
Okay, now for Jazz Jackrabbit and AuGoS:
I figured out that the mere EXISTENCE of a BitDisk RAMDISK (same for TDSK,
but TDSK even crashes LCD when you try to LCD into it), without any
environment variable pointing to it, makes those two DPMI16BI based
applications crash. BITDISK expert anybody??? Otherwise, Jazz Jackrabbit
and AuGoS work fine with FreeDOS (need protected mode, of course).
Finally, DESCENT (DOS shareware version, old 3d space tunnel shooter):
It crashes with a General Protection Fault (exception 0d, you know it
from Windows...) when I boot with NO drivers at all and when I boot with
FDXXMS+UMBPCI. Offset is 24D7, all register values look non-exotic.
Descent cannot be run as "CWSTUB DcntShr.exe" nor as "DOS4GW DcntShr.exe"
as they do not recognize the file format. However, it internally IS an
DOS/4G program (no exact quote, see my other mail with all the version
strings of the used DOS extender).
Descent DOES run fine, both with and without UMBPCI, when I run it as:
DOS32A DcntShr.exe -Verbose -NoNetwork
I could even copy *.* g:\ (g: being the BITDISK RAMDISK) and run it there!
I would have liked to xcopy, but alas... see above.
Without DOS32A (you only need dos32a.exe, but the downloadable zip file on
http://dos32a.sourceforge.net/ contains the whole sources, some
testing tool, a version of DOS4GW and lots of other stuff. Hm. I
am not sure about the sources. At least, the smallest I could get
contained a mirror of the homepage in the zip... Whatever.
Another option to run Descent is to use DR-DOS emm386 (no special
options needed. In particular, emm386 CRASHES for me when I try
to activate its builtin DPMI, no matter what I do to emm386 and
no matter what XMS drivers I do or do not load. Maybe related to
the kernels automatic HMA jump, but I even tried to remove the
DOS=HIGH,UMB line...).
However, you must run "emm386 pic=on" at the prompt (does not
accept this option in config.sys, sigh) to enable some needed
compatibility feature. Then, descent works. From DRemm386.exe /?:
PIC={ON¦OFF} When PIC=ON VCPI applications are informed that the PIC
is not re-vectored. Set to OFF for all applications
except if experiencing difficulty with 4GW DOS Extender
applications. The recommended settings for use with 4GW
applications are as follows:
Single Tasking: EMM386 PIC=ON
Multi Tasking: DPMI OFF
EMM386 PIC=ON
Oh yes, talking about bugs: In LBAcache, the percentage of hits is not
calculated correctly :-). Will be fixed. Not harmful.
Eric