Crashes on Ctrl-Alt-Del.

VOID ASMPASCAL WriteATClock(BYTE *, BYTE, BYTE, BYTE);

plt only sees 2 arguments here, as the
argpack size here is 5 instead of 8.

I wonder if those can be added to the
plain makefiles, w/o adding an autoconf.
Presumably if they can pass us PREFIX,
all should be well.

I see there's a kernel map file, are the addresses contained within absolute DOS addresses or do they need to be offset by some value? I want to find the CDS so before I start chasing for it, I thought I'd look for something simple and obvious like the OS version. The MAP file has this

0079:0090      _os_setver_minor                                                 
0079:0091      _os_setver_major                                                 
0079:0092      _os_minor                                                        
0079:0093      _os_major                                                        
0079:0095      _version_flags                                                   
0079:0096*     os_release                                                       

But if I d that in dosdebug I don't see any recognisable values

0079:0090 6C F6 0F 08 FF FF 00 D9 00 00 10 31 C0 8E D8 A0  [email protected] 

15 seconds if built with -O0, and 3 seconds
if built with -O2. Neither is very good.
And CPU load is 100%.

Tracking bug.

dosemu2/dosemu2#50
https://github.com/stsp/dosemu2/blob/devel/src/dosext/misc/xms.c#L128
dosemu2/dosemu2#478

@andrewbird I've seen you were reporting some
bugs to the original freedos kernel, and even with
patches. How about moving them here and testing
your patches? Redirector works long ago, everything
is set and ready for a try.

ASMFUNC/ASMPASCAL funcs use inexact
types like int, unsigned, long.
Should be replaced with exact types.

DiskTransferBuffer gets frequently assigned
to __DOSFAR() - the casual far pointers that
don't carry an object ownership. This OOMs
dosobj quickly.
Buffer needs to be moved to asm.

init_call_p_0() is a noreturn function.
It pops the return addr from stack, which
is not where it expects it to be.
Fortunately it doesn't use that addr, so
no crash happens.
If the parser is extended to understand
noreturn attribute, then the proper stack
adjustment will be done, plus releasing
of resources (in case of dosemu2 -
coopth thread can be released).

gcc-ia16 has -mfar-function-if-far-return-type switch
to work around bugs. Namely, when parsing int __far foo(void);
it assumes __far applies to int and ignores it, but with
-mfar-function-if-far-return-type it applies it to the function too.

It appears my parser works as if -mfar-function-if-far-return-type
is specified, applying FAR to both function and return val.
void FAR *DetectXMSDriver(VOID); is a near function with
far return type, which is handled wrongly.
Plus, it seems when pointer is returned, its "farness" is lost
in a parser, and the thunk assumes to be always far.

If UMB at A0 is enabled and EMS disabled,
command.com cannot be started.
Similar bug was fixed by a21e02f, but for
some reason it appears to fix the problem
only if EMS is enabled...

Just as currently done for SHELL=,
we need to allow setting a default
drive for DEVICE= to allow the
relocation of the system drives.

But they are not!
So I added this patch: ac8b689
@skitt could you please help me? :)
Once again I don't understand why the
debug packages are not automatically built.
Same thing was with dosemu in the past,
but now for dosemu they are built automatically,
and I can't find the difference! :(

Some ubsan errors seems to be false-positives.
Filled this ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1643318
Lets see.

As pointed in #34 (comment),
FcbNameInit() didn't work properly with this macro.
Another wrong use is newstuff.c:339.
The rest seems safe.

VOID ASMPASCAL WriteATClock(BYTE *, BYTE, BYTE, BYTE);

Currently thunk generator thinks the first
arg is a string, which it is not.
As a quick hack, this can be converted to
the farobj machinery. But the real fix would
be to extend parser, write converter for arrays
and/or do some manual conversion of all such cases.
Another possibility is to use the "void converter"
that understands the things like:
VOID ASMPASCAL WriteATClock(VOID *, int len, BYTE, BYTE, BYTE);

Hmm. Perhaps as a first step I should make
the parser to reject any near pointers other
than char * and void * (for which the converters
already exist), but even this is not too easy as
currently lexer aliases BYTE and char.

Can be un-hanged by any key press.

Study how Bart did that for FreeDOS and do the same here.

I tried to revert the change to the rfcb structure introduced in e8196ab and pack to match the DOS definition as per

diff --git a/hdr/fcb.h b/hdr/fcb.h
index 252af47..ad2ae07 100644
--- a/hdr/fcb.h
+++ b/hdr/fcb.h
@@ -113,8 +113,8 @@ typedef struct _rfcb {
   BYTE renOldName[8];           /* Old Filename                 */
   BYTE renOldExtent[3];         /* Old File Extension           */
   BYTE renReserved1[5];
-  AR_MEMB(struct _rfcb, BYTE, renNewName, 8);           /* New Filename                 */
+  BYTE renNewName[8];           /* New Filename                 */
   BYTE renNewExtent[3];         /* New FileExtension            */
   BYTE renReserved2[9];
-} rfcb;
+} PACKED rfcb;

but now I get an FDPP compilation error what's the fix here, please?

clang++ -std=c++11 -iquote /clients/common/fdpp.git/fdpp/../hdr -Wall -c -fno-threadsafe-statics -fno-rtti -fpic -Wno-format-invalid-specifier -Wmissing-prototypes -ggdb3 -fdebug-macro -O0 -DI386 -DWITHFAT32 -I . -I /clients/common/fdpp.git/fdpp/../kernel/ -I /clients/common/fdpp.git/fdpp -DDATADIR=/usr/local/share/fdpp -DKRNL_NAME=fdppkrnl.sys -DCURDIR=/clients/common/fdpp.git/fdpp -o fcbfns.o fcbfns.cc
fcbfns.cc:557:20: error: no viable overloaded '='
      pFromPattern = lpRenameFcb->renNewName;
      ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
./farptr.hpp:139:7: note: candidate function (the implicit copy assignment operator) not viable: no known conversion from 'BYTE [8]' to 'const FarPtr<const char>' for 1st argument
class FarPtr : public FarPtrBase<T>
      ^
1 error generated.
makefile:139: recipe for target 'fcbfns.o' failed
make[1]: *** [fcbfns.o] Error 1
make[1]: Leaving directory '/clients/common/fdpp.git/fdpp'
makefile:105: recipe for target 'all' failed
make: *** [all] Error 2

Previously(with PACKing) the structure seen in gdb was

(gdb) p *(struct _rfcb *) &lowmem_base[(6588<<4)+286]
$19 = {renDriveID = 0 '\000', renOldName = "testa   ", renOldExtent = "bat", renReserved1 = "\000\000\000\000", renNewName = {<MembBase<char, &_rfcb::off_renNewName>> = {<No data fields>}, 
    sym = "testb   ", static len = 8}, renNewExtent = "bal", renReserved2 = "\000\000\000\000\000\000\000\000"}

It seems the relocation scheme is intentionally
obfuscated.

struct RelocationTable {
  UBYTE jmpFar;
  UWORD jmpOffset;
  UWORD jmpSegment;
  UBYTE callNear;
  UWORD callOffset;
} PACKED;

struct RelocatedEntry {
  UBYTE callNear;
  UWORD callOffset;
  UBYTE jmpFar;
  UWORD jmpOffset;
  UWORD jmpSegment;
} PACKED;

These 2 defs just swap places of call and jump,
and indeed, there is a code like this:

        struct RelocatedEntry FAR *rel = (struct RelocatedEntry FAR *)rp;

        fmemcpy_n(&rtemp, rp, sizeof(rtemp));
      
        rel->jmpFar = rtemp.jmpFar;
        rel->jmpSegment = NewKernelSegment;
        rel->jmpOffset = rtemp.jmpOffset;
        rel->callNear = rtemp.callNear;
        rel->callOffset = rtemp.callOffset + 5; /* near calls are relative */

... that casts between these two, and swaps
places of call and jump.
We need to de-obfuscate this and only have
one relocation struct, preferably the one not
containing any call at all, only long jump.

https://github.com/stsp/fdpp/blob/master/fdpp/farptr.hpp#L98
This placement new can trigger DSE:
https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse
The problem was caused by a21427f.
Clang doesn't seem to support -fno-lifetime-dse option.
I wonder if the patch should be reverted.
But the revert will likely cause strict aliasing violation.

Before this patch: b59a716
freecom was getting 256 bytes for env
by default, unless you use shell=.
Under fdpp that crashes if UMB is
not available.
So if fdconfig.sys has:

DOS=UMB,HIGH
device=e:\dosemu\umb.sys
shellhigh=c:\command.com /e:256 /k e:\autoexec.bat

(now with the patch, 256 should be explicitly
forced), then no crash. But remove line 1 or 2
and it crashes.

Currently fdpp (and freedos) hooks the
interrupts and does not call the previous
handlers (set by BIOS).
Make it so that it does.

Currently plt.asm has no idea whether the
call is near or far. This of course leads to
early crash.
Needs to extend plt generator.

With the last efforts, the memory pool after
boot looks like this:

Total size: 300
Available space: 33
Largest free area: 33
Memory pool dump:
	area: 12 bytes, used
	area: 13 bytes, used
	area: 67 bytes, used
	area: 67 bytes, used
	area: 24 bytes, used
	area: 31 bytes, used
	area: 22 bytes, used
	area: 15 bytes, used
	area: 16 bytes, used
	area: 33 bytes, free

Which is much better than what was before,
but still far from the gloriously wonderful zero.
Who eats this memory? I suppose some leaks
are produced by the NORETURN calls that
can't clean up after themselves. Maybe I should
stop using longjmp() for NORETURN, as it
is an UB according to the standard, and use C++
exceptions?
Anyway, there seems to be a leak somewhere,
and probably an UB in NORETURN impl.

When relocating the int handler, we need to update
IVT entry so that it always points to the handler, not
to PLT. This is needed so that the shared headers
can be added.
But first, it must be checked if its not the case already.

Currently fdpp reserves ~1K of conv memory
and doesn't know how to relocate it.
Conv memory is expensive.

Booting the same disk configuration under FreeDOS and FDPP gives different results. On FreeDOS the boot proceeds as expected, on FDPP it can't find the files referenced in config.sys or autoexec.bat itself.

FreeDOS 1.20

FDPP from git

I've attached the installation files
test-imagedir.tar.gz

Run from dosemu build directory as

bin/dosemu.bin -n -f test-imagedir/dosemu.conf -D+dRW -o test.log --Fimagedir test-imagedir

Firstly with your fdppkrnl.sys in test-imagedir/dXXXXs/c then replace that with kernel.sys from FreeDOS 1.20

As shown in #34, the FcbRename() function's data
flow is too difficult for fdpp to compile properly.
Hacks like this:
7348473
are not plugging all the holes.
It may be good to convert it to flat pointers.
Or maybe think up something else, but not
multiple the nasty hacks.

I'm thinking about adding FDPP to my dosemu test suit.

What does ver /r relate to?

One boot test checks the version string, but I want to know what part of fdpp that relates to: the DOS boot code or the libfdpp.so?

C:\>ver /r
 
FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
DOS version 7.10
FDPP kernel - GIT (build 0001) [compiled Oct 14 2018]
C:\>

Packaging DOS for testing

With other DOSes my test suite unpacks a tar file that contains everything for the tests on that OS such as IO.SYS MSDOS.SYS COMMAND.COM etc. But on FDPP there's an additional complication in that there's libfdpp.so to consider.

• Do you think it's possible to have the matching libfdpp.so bundled with the fdkrnl.sys and use LD_PRELOAD or LD_LIBRARY_PATH to force dosemu to pick that up in preference to any system installed copy?
• What are the implications to dosemu of running with a different copy of libfdpp.so that what it was compiled against?

After getting tn_printf() in truename to print to dosemu I find that dosemu crashes. I find it's when a debug statement tries to print %P with GET_FP32(cdsEntry) as its arg. Strangely commenting it out also makes the DOS prompt look correct too.

What should the correct fix be, add %P to dosemu, or something else?

valgrind reports hundreds of

==162323== Conditional jump or move depends on uninitialised value(s)
==162323==    at 0x66DF6B2: InitPrinters() (main.cc:681)
==162323==    by 0x66DE192: init_kernel() (main.cc:306)
==162323==    by 0x66DD63C: FreeDOSmain() (main.cc:127)
==162323==    by 0x66F032C: FdppThunkCall(int, unsigned char*, unsigned char*) (thunk_calls.h:19)
==162323==    by 0x66EFDA3: FdppCall (thunks.cc:305)
==162323==    by 0x186027: dos_helper (int.c:723)
==162323==    by 0x186066: inte6 (int.c:209)
==162323==    by 0x186066: _inte6_ (int.c:2641)
==162323==    by 0x180EDE: run_caller_func (int.c:1744)
==162323==    by 0x1810A5: do_int_from_thr (int.c:2349)
==162323==    by 0x1A5C4A: coopth_thread (coopth.c:479)
==162323==    by 0x1A72CF: co_runner (pcl.c:49)
==162323==  Uninitialised value was created by a stack allocation
==162323==    at 0x66DF670: InitPrinters() (main.cc:673)

error all around the code base.
I think they all are false and opened a bug to valgrind:
https://bugs.kde.org/show_bug.cgi?id=398445
I wonder if I should please valgrind and add an extra
initializers.

Hi there, I thought time I tried this out but I'm having a problem building it

ajb@polly:/clients/common/fdpp.git$ cd kernel/
ajb@polly:/clients/common/fdpp.git/kernel$ make
cat thunk_calls.tmp | ../utils/thunk_gen >thunk_calls.h || (rm -f thunk_calls.h ; false)
/bin/sh: 1: ../utils/thunk_gen: not found
makefile:165: recipe for target 'thunk_calls.h' failed
make: *** [thunk_calls.h] Error 1
ajb@polly:/clients/common/fdpp.git/kernel$ cd ../utils/
ajb@polly:/clients/common/fdpp.git/utils$ make
clang -I../hdr -o patchobj.com patchobj.c
In file included from patchobj.c:22:
In file included from /usr/include/stdlib.h:314:
In file included from /usr/include/i386-linux-gnu/sys/types.h:132:
../hdr/time.h:42:9: error: unknown type name 'UWORD'
typedef UWORD _time;
        ^
1 error generated.
makefile:10: recipe for target 'patchobj.com' failed
make: *** [patchobj.com] Error 1

Do I have some build prerequisites missing?

7b43711#diff-a42557ec73b3bb8176e23e5c47dc0659R417

This disables the previous speed-up hack.
Now the reliable optimization is needed, and
that should be an STL map.
So rewrite farhlp.c to C++ must be done.

I'm wondering if a method of getting the current fdppkrnl.sys from FDPP itself might be possible? I know that you put some effort into getting install etc to install the current version if it's missing and that you check versions on startup etc, which is great.

Is this possible?

• Native hdimage

  • install a special boot sector for an fdpp bootable image
  • boot sector calls a well known interrupt routine to load the current fdpp kernel code to memory
  • boot sector jumps to it

• Normal dosemu FATFS startup

  • if an fdppkrnl.sys file exists(could be empty) in the current directory only its presence is used to select an fdpp boot.
  • dosemu boot code uses new fdpp function call to load the fdppkrnl.sys as now.

If it is I think it could alleviate a lot of the potential for fdppkrnl.sys to become out of sync with the installed FDPP, could allow portable hdimages between FDPP aware systems (dosemu2, nightkernel? etc), and remove the need to install any meaningful fdppkrnl.sys on a new install.

inputptr is a symbol defined as word,
but is used as a near ptr to char.
Currently glob_asm.h defines it as
char *, which doesn't work.
Clearly it requires a new symbol type
that resolves to NearPtr template.
But NearPtr template currently only
works with dosobj.
So either apply some macro hackery
to inputptr, or generalize NearPtr
template to parse more pointer types...
It looks like inputptr is the only offender,
so whether generalizing NearPtr worth
the trouble, is unclear.

This blocks #7.

The hacks like this:
ff9a805
are not too evil by themselves, but their need is
undetectable w/o lots of manual debugging.
We need to track object relationships so that we can:

• relax the pointer scope requirements (get rid of the above hack)
• automatically detect the problematic places,
  like getting the pointer to dosobj w/o transferring
  the ownership.

Describe the bug
dosemu2 crashes when I try to run the installer for DataRescue IDA 3.7 freeware.

ERROR: Fault in dosemu code, in_dpmi=0
ERROR: cpu exception in dosemu code outside of VM86()!
sig: 8 trapno: 0x00  errorcode: 0x00000000  cr2: 0x00000000
eip: 0x7fd3dde9db61  esp: 0x7fd3c48a6c10  eflags: 0x00010246
cs: 0x0033  ds: 0x0000  es: 0x0000  ss: 0x0000
fs: 0x0000  gs: 0x0000
fsbase: 0x7fd3dfc37700 gsbase: (nil)

ERROR: Please install gdb, update dosemu from git, compile it with debug
info and make a bug report with the content of ~/.dosemu/boot.log at
https://github.com/stsp/dosemu2/issues
Please provide any additional info you can, like the test-cases,
URLs and all the rest that fits.

To Reproduce

• Unpack ida37fw.zip (below).
• Run install.exe under dosemu2 like so: dosemu -D9+D -t -quiet -K install.exe.
• Under install.exe, select "Install Program".

Attach the binaries

• ida37fw.zip (also available at textfiles.com).

Attach the log

• boot.log.

As per PR #42, for which I've lost interest in fixing, here are the test binaries.fcb_rename.zip

The problem:
I want to be able to run Dosemu/FDPP without any global installation on the system, but when I do I see messages about there being no bootable drive.

The old solution:
I know we spoke about this a while ago (Nov 2018) and I did have a working solution back then by setting FDPP_KERNEL_DIR, but that no longer seems to be enough to get the FDPP plugin to recognise a bootable drive.

To replicate:

• To replicate my problem you'll need to uninstall any global FDPP in /usr or /usr/local
• build fdpp
  • (cd fdpp.git && make clean all)
• build dosemu
  • cd dosemu2.git
  • make distclean && env PKG_CONFIG_PATH=pwd/pkgconfig ./default-configure -d && make
  • cat pkgconfig/fdpp.pc

prefix=/usr/local
fdpplibdir=/clients/common/fdpp.git/fdpp
fdppincdir=/clients/common/fdpp.git

Name: fdpp
Description: DOS compatibility layer
Version: 0.1
Libs: -Wl,-rpath,${fdpplibdir} -L${fdpplibdir} -lfdpp
Cflags: -I${fdppincdir}

• try to run (still in dosemu2.git)

./runstandalonetest.sh 

GDB=""
+ GDB=
GDB_DOSEMU_ARGS=""
+ GDB_DOSEMU_ARGS=
if [ x${1} = "x-gdb" ] ; then
  GDB="gdb --args"
  GDB_DOSEMU_ARGS="-I 'cpuemu fullsim'"
fi
+ [ x = x-gdb ]

env FDPP_KERNEL_DIR=../fdpp.git/fdpp ${GDB} bin/dosemu.bin \
	-n -f test-imagedir/dosemu.conf -D+dRW -o test.log \
	--Fimagedir test-imagedir \
	${GDB_DOSEMU_ARGS}
+ env FDPP_KERNEL_DIR=../fdpp.git/fdpp bin/dosemu.bin -n -f test-imagedir/dosemu.conf -D+dRW -o test.log --Fimagedir test-imagedir
ERROR: Neither FreeDOS nor comcom32 installation found.
Use DOSEMU2_FREEDOS_DIR env var to specify alternative location.
ERROR: No system files found at /usr/local/share/dosemu/fdboot
ERROR: dosemu2 commands not found at /usr/local/share/dosemu/dosemu2-cmds-0.2
CONF aborted with: DOSEMU_LIB_DIR does not exist /usr/local/share/dosemu

• or if I specify a dummy libdir

./runstandalonetest.sh 

GDB=""
+ GDB=
GDB_DOSEMU_ARGS=""
+ GDB_DOSEMU_ARGS=
if [ x${1} = "x-gdb" ] ; then
  GDB="gdb --args"
  GDB_DOSEMU_ARGS="-I 'cpuemu fullsim'"
fi
+ [ x = x-gdb ]

env FDPP_KERNEL_DIR=../fdpp.git/fdpp ${GDB} bin/dosemu.bin \
	-n -f test-imagedir/dosemu.conf -D+dRW -o test.log \
	--Fimagedir test-imagedir \
	--Flibdir test-libdir \
	${GDB_DOSEMU_ARGS}
+ env FDPP_KERNEL_DIR=../fdpp.git/fdpp bin/dosemu.bin -n -f test-imagedir/dosemu.conf -D+dRW -o test.log --Fimagedir test-imagedir --Flibdir test-libdir
ERROR: Neither FreeDOS nor comcom32 installation found.
Use DOSEMU2_FREEDOS_DIR env var to specify alternative location.
ERROR: dosemu2 commands not found at /clients/common/dosemu2.git/test-libdir/dosemu2-cmds-0.2
ERROR: Your fluidsynth is too old and soundfonts not found
ERROR: alsa_midi (ALSA lib): rawmidi_hw.c:233:(snd_rawmidi_hw_open) : No such file or directory open /dev/snd/midiC0D0 failed
ERROR: Bootable drive not found, exiting

dosemu.conf

$_lpt1 = ""
$_hdimage = "dXXXXs/c:hdtype1"
$_debug = "-D+d"

test.zip

ajb@polly:/clients/common/dosemu2.git$ find test-imagedir
test-imagedir
test-imagedir/drives
test-imagedir/dXXXXs
test-imagedir/dXXXXs/c
test-imagedir/dXXXXs/c/autoexec.bat
test-imagedir/dXXXXs/c/version.bat
test-imagedir/dXXXXs/c/config.sys
test-imagedir/dXXXXs/c/command.com
test-imagedir/dXXXXs/c/dosemu
test-imagedir/dXXXXs/c/dosemu/exitemu.com
test-imagedir/dXXXXs/c/dosemu/speed.com
test-imagedir/dXXXXs/c/dosemu/emumouse.com
test-imagedir/dXXXXs/c/dosemu/unix.com
test-imagedir/dXXXXs/c/dosemu/dosdbg.com
test-imagedir/dXXXXs/c/dosemu/eject.com
test-imagedir/dXXXXs/c/dosemu/system.com
test-imagedir/dXXXXs/c/dosemu/blaster.com
test-imagedir/dXXXXs/c/dosemu/sound.com
test-imagedir/dXXXXs/c/dosemu/isemu.com
test-imagedir/dXXXXs/c/dosemu/cdrom.sys
test-imagedir/dXXXXs/c/dosemu/generic.com
test-imagedir/dXXXXs/c/dosemu/umb.sys
test-imagedir/dXXXXs/c/dosemu/emufs.sys
test-imagedir/dXXXXs/c/dosemu/xmode.com
test-imagedir/dXXXXs/c/dosemu/aspi.sys
test-imagedir/dXXXXs/c/dosemu/dpmi.com
test-imagedir/dXXXXs/c/dosemu/lredir2.com
test-imagedir/dXXXXs/c/dosemu/fossil.com
test-imagedir/dXXXXs/c/dosemu/ems.sys
test-imagedir/dXXXXs/c/dosemu/lredir.com
test-imagedir/dosemu.conf

Note: Dosemu itself creates test-imagedir/drives, I don't know why.

It seems to me that my adding --Flibdir is wrong and I only did it to get further, but without it a missing /usr/local/share/dosemu is fatal, even though I have a valid FDPP_KERNEL_DIR.

https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/src/dos/
http://freedos-32.sourceforge.net/
http://freedos.10956.n7.nabble.com/DOS-Development-Idea-td16159.html
https://sourceforge.net/projects/dos64/

Study what these guys are up to, and write a
readme chapter.

C++ gurus laughs at my coding.
They say I shouldn't be using the Cish
type-casts to create the C++ objects
directly from DOS pointers. They suggest
using "placement new" instead.
Listening to gurus always helps, so I need
to investigate this possibility.

Reading from stdin always returns error.

Currently they are put into a map, and never
removed (until reboot).
Would be nice if the proper life-time rules can
be established. This will speed up the look-ups
even more.
Needs to investigate that possibility and either
implement, or explain why not possible.

Happy to chase this one down myself, but perhaps you can indicate what I might be looking for

ERROR: fdpp booting, this is very experimental!
ERROR: fdpp: abort at ./farptr.hpp:191

Commit 23a04f8 fixed #48 and many
other problems, so it is good and needed.
But this MK_FAR_CHLD() is basically a
reincarnation of the static object tracker -
something I'd like to keep removed.
Needs to find the fix on freedos level,
rather than on fdpp level. If freedos can't
work w/o static object trackers, then it needs
to be fixed (and already was when I got rid
of MK_FAR_ST() stuff). These days I
prefer to adapt freedos to the fdpp model,
rather than to extend fdpp to cover all freedos
quirks.
I created the branch ddt where I tried to
address this on freedos level, but it doesn't
boot yet. Also it is adding another variation
of struct ddtstruct, and I wonder if it is good
to have 2 slightly different versions of the
same struct...

The good news first:
PC/GEOS starts up with "fdppkrnl.sys" and works fine as far I've tested it. That's really great!

But when I leave / exit PC/GEOS for returning to DOS, I get a crash of FDPP / DOSEMU2.

boot-fdpp.log
(boot.log has been renamed and shortened due to lots of dispatch lines)

My manual setup of drive_c use the current "fdppkrnl.sys" from GIT (20181102) and the "command.com" from FreeDOS (0.84-pre2).

I'd liked to try comcom32 too, but I'm still unable to compile it. Maybe someone has a short hint which Debian packet has the right compiler or where can I get a precompiled one.

In dosemu's dumb terminal mode, neither the
typing, nor cmd line are visible. Fine with freedos.
Not sure if its a dosemu or fdpp bug.

freedos (and fdpp) takes fdconfig.sys from
C: even when boots from other drive.
Same is for command.com, unless altered
with shell=.
In the source code I don't see C: being
hard-coded, so I think this is a bug, not a
decision.
Whatever it is, we need to properly support
the boot drive.

Andrew, do you want to take a look at that?
Currently dosemu2 boots fdpp automatically
w/o any extra setup, so this is very easy to
reproduce.

fdpp files should be separated.
Build should happen in a different dir.