Booting the correct fdppkrnl.sys

[dosemu2]

Booting the correct fdppkrnl.sys

[stsp]

I don't think you need to package fdpp
to hdimages. Can you package dosbox's
DOS into a hdimage? You can't. And you
even don't need to, as hdimage doesn't
even need to be bootable if you have fdpp.
It may be available as drive C, be unbootable,
but fdpp will still boot. So what use case do
you want to cover?

dosemu2 always prefers any user-supplied DOS
over fdpp in fatfs-boot mode. So I don't see where
the empty fdpp suits. Its you and only you started
to make fdpp visible at all, and now others follow. :)
Will you make dosbox's dos visible to C?

[andrewbird]

I can make the case that fdppkrnl.sys is never installed onto a DOS filesystem, either by file or symbolic link? It seems to me that if it's so unnecessary to be visible, it shouldn't even be a file at all, so why is it? Can't Dosemu2 call a libfdpp.so function that provides the fdppkrnl.sys data for fatfs.c to load. That's pretty much the premise of the 'dosemu2 fatfs boot' above, except for the empty file bit which is a crude switch between failing to boot anything in the case of missing DOS files and booting fdpp. If you are happy to always have a system boot fdpp in the case of missing startup files that's fine no need for empty file switch. The result is no version checking required, no installation required and no stale files hanging around?

You've dealt with the hdimage section, it's not required then, so disregard it.

Will you make dosbox's dos visible to C?

Nope, I have no interest in Dosbox.

[stsp]

I can make the case that fdppkrnl.sys is never installed onto a DOS filesystem,
either by file or symbolic link?

Of course.
install.c never installs it via a symbolic
link. It uses the env variable that contains
the full path. That maps to E.

Can't Dosemu2 call a libfdpp.so function that provides the fdppkrnl.sys data for fatfs.c to load.

This will mean a fatfs, boot-sector and linker hack.
I decided so many hacks are not worth the trouble.
At the end of the day, it doesn't matter whether you
load it from the lib or from the system-wide file, unless
someone decides to make it visible and locally copied. :)
Then suddenly there are differences.

If you are happy to always have a system boot fdpp in the case of missing startup files that's fine no
need for empty file switch. The result is no version checking required, no installation required and no
stale files hanging around?

It mainly is already so, if you don't make it
"installed" (wrongly) by hands. Having it
system-wide or embedded into a lib - is the
same thing, really.

You've dealt with the hdimage section, it's not required then, so disregard it.

Having it in a hdimage will also mean an
unbootable hdimage because of a version
mismatch.

[andrewbird]

Mapping specific drives to boot is what I'd like to avoid. Regarding linker tricks etc how about during the build doing:

# build fdppkrnl.sys first 
xxd -i fdppkrnl.sys > fdppkrnl_sys.c
# then include it in build of libfdpp.so to return when dosemu's fatfs.c asks for it

Having it in a hdimage will also mean an
unbootable hdimage because of a version
mismatch.

I didn't want to include the fdppkrnl.sys in the hdimage, only a boot sector that knows how to ask libfdpp.so for it. The only versioning problem would occur if you changed the well known interrupt it used to ask. Anyway I was convinced that it's not a good idea, so just forget about it.

[stsp]

Mapping specific drives to boot is what I'd like to avoid.
Regarding linker tricks etc how about during the build doing:

Mapping the drive and linker trick - are 2 orthogonal
things. With linker trick you change the storage of the
file. To me the storage doesn't really matter, and having
the FS storage is cleaner.
Mapping the drive is to make it visible to fatfs loader.
It doesn't matter was it in a file or in another file - you
need to map the drive to make it visible to the fatfs loader.
Or you need some gross hack to fatfs, or maybe you
can have a completely custom loader in fdpp plugin code,
but this will be a copy/paste of the fatfs one.
Really, you need to try to implement your ideas to
properly evaluate them. I.e. you think changing the
storage is important, and I think its the same thing.
Only the working code will show the truth.

In any case, I already have an idea of how to make
this less "painful" for you two guys. If you promise
me to stop altering $_hdimage in a process, I'll give
you --Fimagedir for your dirty tricks fully, and spare
of the install.c. :) There is also --Flibdir that is now
vacant. I'll re-use it and there will be enough knobs for
all of us.

I didn't want to include the fdppkrnl.sys in the hdimage, only a boot sector
that knows how to ask libfdpp.so for it.

It doesn't work this way. FDPP has a standard boot-sector
from freedos, with a very minor optional extensions that
allow the better integration with dosemu2.

[andrewbird]

Mapping the drive is to make it visible to fatfs loader.
It doesn't matter was it in a file or in another file - you
need to map the drive to make it visible to the fatfs loader.

So are you saying that dos_read(fd, loadaddress, size); where fd is open fd of fdppkrnl.sys, then jump to CS:IP isn't enough and after the jump FDPP needs to find fdppkrnl.sys on the disk too?

If you promise me to stop altering $_hdimage in a process

Not sure I do anything with that, except set it in dosemu.conf, do you have an example of bad practice with it?

[stsp]

So are you saying that

... that there is a standard fatfs loader procedure,
which finds the file, identifies it and generates the
boot sector accordingly.

dos_read(fd, loadaddress, size); where fd is open fd of fdppkrnl.sys, then jump to CS:IP isn't enough

If course not. How about the standard protocol
of passing parameter in the registers? And BPB?

and after the jump FDPP needs to find fdppkrnl.sys on the disk too?

No.

Not sure I do anything with that, except set it in dosemu.conf, do you have
an example of bad practice with it?

Any changes.
I'll give you --Fimagedir for the unchanged $_hdimage.

[andrewbird]

I guess I'm just expecting FDPP to be unconstrained by usual DOS booting methods and just a whole lot easier.
No worries, I'm sure you'll find the best solution.

[stsp]

I guess I'm just expecting FDPP to be unconstrained by usual DOS booting
methods and just a whole lot easier.

If it wouldn't be converted from freedos and rather
written from scratches, then perhaps it would be similar
to the one of dosbox, w/o any real-mode kernel.
But as it has a freedos-derived realmode kernel, the
boot procedure is (at least for now) still the same.