Comments (9)
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?
from fdpp.
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.
from fdpp.
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.
from fdpp.
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.
from fdpp.
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.
from fdpp.
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?
from fdpp.
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
.
from fdpp.
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.
from fdpp.
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.
from fdpp.
Related Issues (20)
- crash on redundant conversion
- Some FCB tests are now failing HOT 2
- Please relicense fdpp/smalloc.h HOT 8
- DOSLFN not working with FDPP HOT 5
- Windows' WinFile is setting the time in the future HOT 56
- Don't seem to be able to compile (maybe toolchain breakage) HOT 11
- unaligned reference UB
- evaluate gcc porting
- Building FDPP on Aarch64 HOT 16
- fdpp install doesn't produce fdppkrnl.elf HOT 3
- Error posted about redundant conversion HOT 5
- Build fails with `kernel.asm:110: error: ELF format does not support segment base references` and subsequent errors. HOT 28
- ELF format does not support segment base references HOT 2
- tests are failing again HOT 8
- prehistorik2 doesn't work HOT 5
- Exploring hard disk size limits HOT 14
- NASM-SEGELF Problem HOT 3
- thunk_gen: extend __CNV_PTR_VOID handling
- just run make? HOT 25
- use strip from binutils
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fdpp.