dosemu2 / fdpp

FreeDOS plus-plus, 64bit DOS

fdpp

what is fdpp?

fdpp is a 64-bit DOS core.
It is based on a FreeDOS kernel ported to modern C++.
In short, FreeDOS plus-plus.

Can be compiled with clang (not gcc!) and booted under dosemu2.

building and installing

Run ./configure.meson [<build_dir>].
This creates and configures the build dir and prints the instructions for the further build steps. It should also inform you about any missing build-dependencies, which you need to install.

installing from pre-built package

For the ubuntu package please visit this PPA. Fedora packages are here. OpenSUSE packages are here.

running

The simplest way to get it running is to use dosemu2.
Get the pre-built dosemu2 packages from ubuntu PPA or from COPR repo or from OpenSUSE repo or build it from sources.

configuration

fdpp uses fdppconf.sys file at boot. This file has the standard format of config.sys with some syntax extensions. It is fully backward-compatible with the DOSish config.sys, and if fdppconf.sys is missing, config.sys is attempted instead.

but what it actually is? why dosemu2?

fdpp is a user-space library that, as any DOS, can run DOS programs. Being a library, it can't act on its own and needs a host program to operate. This also means it can't be booted from the bare-metal PC, as the original freedos could.
The host program needs to provide a couple of call-backs for running real-mode code in v86 or similar environment. See this code as an example of providing call-backs to fdpp, and this code as an example of the boot loader. Sufficiently DOS-oriented kernels like freedos-32 or pdos/386 are the good candidates for running fdpp in the future.

what fdpp technically is?

A meta-compiler that was initially able to compile the freedos kernel from its almost unmodified sources. As the project evolves, the ability to compile freedos from the unmodified sources have lost its value and was dropped, as our copy of freedos is now heavily modified. As the result, the compiler is very small and is targeted only to our coding patterns.
The main tasks of it are to parse FAR pointers and generate thunks to real-mode asm code of freedos. As with any other compiler, fdpp is supplied with a small runtime support library and a dynamic linker.

compatibility

Simply put, fdpp runs every DOS program we tried, so the compatibility level is supposed to be very high. Better than that of most other known DOS clones, including FreeDOS.
If you find some compatibility problems, please report a bug.

portability

fdpp can work in any environment with STL/C++ runtime & minimal posix support. The build requirements are in line with today's posix-compatible environments: you'll need the full stack of tools like bison, autoconf, sed etc. Additionally you'll need a clang tool-chain as clang++ is the only compiler to build fdpp with. That said, building fdpp under itself may be a challenge. :)

related projects

FreeDOS

FreeDOS kernel is a DOS-compatible kernel that is used as a core of fdpp.

dosemu2

dosemu2 is a virtual machine that allows you to run DOS software under linux. It is a primary host platform for fdpp.

similar projects

dosbox

dosbox has a good built-in DOS written in C++. It is tightly coupled to dosbox; you can't easily port it to your project, whereas fdpp is designed to be plugable. Also it uses host APIs and libraries for filesystem access, CD-ROM playing and similar things. fdpp uses no host APIs or libraries, which may be good or bad, depending on your use-case. dosbox is cleanly written in C++, whereas fdpp wraps the C-coded freedos kernel into a C++ framework, resulting in a nuclear C/C++ mix.

freedos-32 (inactive)

freedos-32 is a kernel written with DOS compatibility in mind. It has a rich user-space part with libc. Very good candidate for running fdpp. Unfortunately, the kernel was scrapped, and currently something else is being developed.

NightKernel

NightKernel is A 32-bit drop-in replacement for the FreeDOS kernel, as they call themselves. In fact, it is an assembly-written ring-0 kernel, currently w/o any DOS compatibility at all. Can't be used to run fdpp because it doesn't support user-space add-ons.

PDOS/386

pdos/386 is a Public Domain Operating System with a user interface as simple as MSDOS. It supports a "theoretical 32-bit MSDOS API" (probably similar to that of 32-bit DOS extenders) and some of the Win32 API, allowing a subset of Windows executables to be run. PDOS/386 is good enough to run gcc, as, and ld to rebuild itself.
As for running fdpp - pdos/386 is a very promising project, but its author seems to be reluctant at adding v86 support, preferring to switch to real mode for bios calls. The lack of v86 leaves very small room for fdpp and for DOS programs in general unfortunately.

fdpp's Issues

freecom crashes with small env

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.

track far pointers properly

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.

dosemu2 crashes when running DataRescue IDA 3.7 freeware installer

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.

get rid of -mfar-function-if-far-return-type

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.

speed up farptr cache

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.

freedos-specific problems

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.

Does freedos define its own printf types?

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?

get rid of jwlib/jwlink

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

arrays in arg not handled properly

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.

reboot is broken

Crashes on Ctrl-Alt-Del.

clean up relocation madness

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.

FDPP gets confused about boot drive

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

dir on non-redir partition takes too long

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

document related projects

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.

Running Dosemu with FDPP from build directory without any global install

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.

update IVT when relocating inthandlers

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.

call previous inthandlers

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

use placement new for creating dos objects

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.

args not properly aligned

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

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

DiskTransferBuffer OOMs dosobj

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.

asm funcs use inexact types

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

convert fcb code to flat pointers

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.

stdin doesn't work

Reading from stdin always returns error.

crash with UMB at A0 and EMS disabled

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...

inputptr sym doesn't work

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.

move fdpp to separate dir

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

audit MK_FAR_STR_SCP uses

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

Booting the correct fdppkrnl.sys

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.

FCB Rename failing

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"}

FCB Rename causes FDPP crash

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

FDPP aborts on exit / termination of PC/GEOS

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.

placement new UB/DSE

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.

build issues

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?

strange ubsan errors

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

valgrind reports uses of uninitialized vars

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.

plt doesn't handle near/far calls

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.

selectable default drive for device=

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

frequent hangs waiting for F5/F8

Can be un-hanged by any key press.

cmd line may be invisible

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.

Trying to understand the fdppkrnl.map

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] 

track object relationship

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.

find different fix for IDA installer

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...

dbgsym packages should build automatically

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! :(

investigate memory usage

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.

support any boot drive

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.

relocate fdpp-specific data

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

add rpmbuild and debuild support

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.

[Question] Testing FDPP

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?

fcb rename wildcard expansion

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

rfe: support noreturn funcs

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).