Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

A0 01 #249

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

A0 01 #249

wants to merge 1 commit into from

Conversation

andrewbird
Copy link
Member

For discussion

andrewbird referenced this pull request in andrewbird/fdpp Mar 9, 2024
@andrewbird
wip2
725fb3e
stsp
stsp reviewed Mar 9, 2024
View reviewed changes
kernel/network.c Outdated Show resolved Hide resolved
@andrewbird
lfn: Implement int21/71a0 get volume information
46317fe 
If the volume is local then return suitable information, as either
FAT or FAT32. Currently FDPP and FreeDOS don't support LFN
natively, so values are chosen to reflect that. If DOSLFN is loaded
then its own handler will used in preference.

If the disk is remote then query the respective redirector via
int2f/11a0 (an extension) for the relevant values. If the redirector
dosen't support the extension, then we pretend that the kernel doesn't
support int21/71a0.
@andrewbird
Copy link
Member Author

What are your thoughts about the $_lfn_support = (on) setting in dosemu.conf? I can see it made sense when lfn support was processed before any TSR, but now dosemu's lfn is only a fallback is it still relevant?

@stsp
Copy link
Member

stsp commented Mar 9, 2024

What do you propose?

@andrewbird
Copy link
Member Author

I was thinking of removal of that config option, but I suppose it may be too early. I'll just need to disable the test for it under FDPP.

@stsp
Copy link
Member

stsp commented Mar 9, 2024

Yes, I think its mainly historic.
There were times when some DOSes
were unbootable once you enable
lfn support (eg 198bc9c), and even
in dosemu2 history we have the wtf
things like f1002e0 13f4867 bf281b9

But I guess disabling LFNs should
never be a cure, esp since we do
support LFNs in comcom64.
It can also be moved to emuconf.com
to allow disabling dynamically (in
case some program fails with LFNs).
So the question is how "deeply" to
remove it. Removing from dosemu.conf
sounds good, maybe also from parsers,
but leave in the code and eventually
add to emuconf.com?
@bartoldeman do you have an opinion
on that?

@stsp
Copy link
Member

stsp commented Mar 9, 2024

Ah, commit hashes didn't work,
as we are in fdpp, not dosemu2...

@andrewbird
Copy link
Member Author

That would be
dosemu2/dosemu2@198bc9c
dosemu2/dosemu2@f1002e0
dosemu2/dosemu2@13f4867
dosemu2/dosemu2@bf281b9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@stsp stsp stsp left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@andrewbird @stsp