FreeDOS kernel enhancements for Win 3x

[andrewbird]

I'm not sure if there's anything useful for FDPP here, but it's reportedly helping FreeDOS kernel to run Win 3x in all modes
https://sourceforge.net/p/freedos/mailman/message/37326256/

[stsp]

Not sure either.
We already have win3x running, modulo
some kvm bugs.
Do they have smaller patches in git to
maybe cherry-pick the most obvious ones?

[andrewbird]

I haven't seen anything appear in git yet. Apparently the changes were first tried out in a development kernel, so I read the commit log on the UNSTABLE branch but found no mention of anything seemingly related. Back then merges were time consuming so I doubt nice little patches per feature or fix exist, but perhaps now it's being looked again breaking it up into understandable commits is a possibility.

[stsp]

I can't parse what you say. :)
Do you mean there is nothing in their
git, but there is some external mega-patch,
and a kernel built on top of it in-house,
only for the video for now? Hmm, doesnt
sound like the usual practice.

[andrewbird]

But IIRC we are not calling
redirector functions from lfn.c
directly.

Indeed you can't if the redirector function itself uses functions that need a DOS stack.

[stsp]

Why would I even want to do that?
There are 2 cases:

1. Legacy DOSes support.
   This is achieved via tricks when
   mfs.c identifies the lfn.c caller.
   This case already works fine
   because all LFN calls are mapped
   to the SFN ones and the DOS
   call is done (upon which mfs.c
   identifies the caller and gets the
   LFN by other means).
2. fdpp. With that you can call
   the lfn.c funcs as redirector funcs
   from DOS, and they will be able
   to get CDS.

[andrewbird]

Certainly (2) is the ideal situation, but knowing that legacy DOS also has to be supported means that any new functions added by us into the redirector have to be written for this duality. An example is the new redirector function int2f/11/42 added by ecm dosemu2/dosemu2@0759b73, it gets called by FDPP kernel with DOS stack, but it also gets called by lfn.c for legacy DOSes with user stack. I hope for some solution where the lfn.c could setup a DOS stack too prior to calling the redirector. Obviously this code is working fine with the user stack, but say for some reason we needed to check if a name matched a loaded character device driver. DOS has a function for that int2f/1223 which we should use in the redirector but it has the DOS stack requirement, so we would end up walking the driver list obtained via LoL In my ideal world lfn.c would become a small shim that only provided the stack setup and call to the redirector for legacy DOSes. Why is this attractive? Well I think that LFN functions belong in the redirector since they are specific to each file system. If we had a second redirector, perhaps SMB or NFS, then the mangling, canonicalisation and path resolution provided by lfn.c would be incorrect for those. IMHO each redirector should provide those specialised functions.

There are probably better things to wish for than how to find the DOS stack, but I thought I'd mention why it irks me. 😄

[stsp]

An example is the new redirector function int2f/11/42

Yes, its an example of NEW redirector functions.
They are new not because they support LFNs,
but rather because they take SFT on input.
Let's say, they represent a design exception.
The rest of LFN support should IMHO be
done by calling the counterpart SFN int21
API which will call the redirector with DOS
stack, and then redirector should do the
detection magic, like CREATE_TRUNCATE
now does:

        if (!file_exists && userStack[7] == BIOSSEG &&
                            userStack[ofs] == LFN_short_name) {
          /* special case: creation of LFN's using saved path
             if original DS:{DX,SI} points to BIOSSEG:LFN_short_name */
          strcpy(fpath, lfn_create_fpath);
        }

... and/or for case 2 adding the NEW
redirector functions, but only for fdpp.

Does this look reasonable?

[stsp]

So in short: if we currently already
have 2 redirector functions that may
potentially be called on user's stack,
let's not multiple them. We had to
create those two because they take
SFT, and we were lucky they are
not interested in a DOS stack.
Let's not do that again, unless there
is a serious reason to (like some
other func needing SFT, or alike).

[andrewbird]

This patch just got added to FreeDOS FDOS/kernel@dd91e3c. I noticed that current fdpp code does split up the transfers. On freedos-devel there's some talk about differences in virtual environments support for it; see https://sourceforge.net/p/freedos/mailman/message/37327695/ . Is this patch or variation of it useful for FDPP?

[andrewbird]

It's comcom32! Switching to use freecom gives me the 120 sector transfers

[stsp]

  do
    {
    byte_count = fread(transfer_buffer, 1, 32768, source_stream);
    if (byte_count > 0)
      {
      if (fwrite(transfer_buffer, 1, byte_count, dest_stream) != byte_count)
        goto copy_error_close;
      }
    }
  while (byte_count > 0);

Would you like to fix that? :)

[andrewbird]

okay

[andrewbird]

So do you think that djgpp's fread() implementation is slicing it up into 512byte chunks?

[stsp]

Or maybe DOS.
You can't read something smaller
than 1 sector normally.