Windows' WinFile is setting the time in the future about fdpp HOT 56 CLOSED

A few days ago there were only fdpp
updates, so could you please check
if it is fdpp-specific?

from fdpp.

can't create local /var/run/user/0/dosemu2 directory

It's probably unconnected to your problem but that is very strange! What distro/hardware are you running on, or is it WSL?

from fdpp.

@andrewbird: Ubuntu 22.04 LTS virtual machine running in VirtualBox with nested virtualization enabled.
Additionally I'm running dosemu with '-s' (sudo) to be able to expose ETH devices to dosemu.

from fdpp.

I guess that 0 in the path is down to using -s.

from fdpp.

Yes, -s should now be fixed.
Of course you are aware about slirp
and tap, both allowing to avoid -s?

As for windows, the log has things
like LFN: using WIN date/time -
never seen such. :) Andrew, do you
know what these do?

from fdpp.

@stsp: I need a real ethernet interface for my stuff, and the bridge approach has stopped working after updating from 20.4 to 22.4 LTS. Attaching a tap device to a bridge returns EPERM, even as root.

Yes, w/out '-s' the warning goes away. I didn't pay attention and didn't file a bug. Thanks!

from fdpp.

man tunctl will hint you about
the -u option. And you can use
the pre-set tap under dosemu.

from fdpp.

It seems that I'd need some help to debug this w/out fdpp. With MS-DOS 6.22 I get "KERNEL: unsupported DPMI server" from WIN and I have no idea which kind of EMM386 do I have to load (if any?).

from fdpp.

@stsp something seems to be using int21/714e findfirst and it surprises me that WFW would do this. However I notice that there are no tests to cover these so I've no idea if those calls work with the 64bit time format http://www.ctyme.com/intr/rb-3203.htm.

from fdpp.

It might be 4DOS, which is my default shell. AFAIK it has some LFN support.

Edit: for the records: it's unrelated to 4DOS. With FreeCom same date/time issue.

from fdpp.

I installed windows and its barely
working. Multiple regressions again. :(
Will need to bisect.

from fdpp.

So I'm wondering now whether the file dates are changing, or just that we are returning bad data that 4DOS displays. Can you try switching to FreeCOM (which also has LFN support, but uses DOS date/time) and see what the timestamps are?

from fdpp.

@robert-j you anticipated my question, it seems!

from fdpp.

So run me through the procedure to create a bad timestamp on a file.

from fdpp.

okay, I've manged to configure & run MS-DOS 6.22: the error disappeared, so it's how @stsp predicted: a fdpp issue.

from fdpp.

What was the problem?
It doesn't work well with ms-dos 6.22
for me too now.

from fdpp.

It's fdpp related.

With MS-DOS 6.22 I can start the same pre-configured Windows, which I usually run under fdpp, then open WinFile and terminate Windows: date/time is still correct, error does not occur.

from fdpp.

But what was the problem about a
DPMI server?

from fdpp.

Ah, this one: Well, I didn't configure the boot floppy correctly and one of the dosemu drivers was not loaded. This was my bad.

from fdpp.

OK, I bisected the windows problem
and opened dosemu2/dosemu2#2007
Hope Andrew can deal with the files
in a mean time. :)

from fdpp.

I think the lfn file time is a red herring, I didn't read the full thread until now. The issue appears to be that the system time changes.

from fdpp.

@andrewbird: the file times are correct, probably because they are solely controlled by dosemu.

dir > foo
dir foo

shows the current date/time of the system. It's probably only the int 21 getdate function, which is returning bad values.

Edit: not probably. 100% INT21 AH=2A is returning garbage.
Edit2: when I'm correcting the date with AH=2B then it remains correct until I start Windows+WinFile again.

from fdpp.

Edit2: when I'm correcting the date with AH=2B then it remains correct until I start
Windows+WinFile again.

Please see what changes on a native
FS are seen from these actions.

from fdpp.

@stsp I think this might be a packing issue with struct dosdate it seems it's used to set registers!

from fdpp.

struct dosdate
{
  unsigned short year;
  unsigned char monthday, month;
};

I don't see the packing problems
here (members are sorted by size),
and sizeof() gives 4.

from fdpp.

Sizes look okay here, but I wondered if the version of clang used would affect things?

from fdpp.

No because sizes are sorted properly:
"short" goes before smaller "char".
You may want to read about alignment
and padding rules, they are not essentially
trivial. :)

from fdpp.

You may want to read about alignment
and padding rules, they are not essentially
trivial. :)

Yes I've been a bit lazy on that front. I have it boiled down to just two options:
I don't care about alignment and padding as the struct is internal, so let the compiler do whatever,
and I do care because the struct has to be portable, so pack it.

from fdpp.

That approach doesn't work if you
use -Wpacking option. It will warn
on redundant packing, which, on
clang-16, is not redundant at all!
So what clang-16 does, contradicts
itself. Of course, after I reported that,
they decided to break also -Wpacking
option, instead of fixing things up.
Because the "bug" is not following
gcc these days, rather than what
actually breaks things. :(

from fdpp.

There are more problems to that
approach. Namely, whatever is packed,
is treated by gcc as misaligned! Even
when its actually not. So fdpp won't
even compile if you pack too much.
And unfortunately clang devs almost
threaten me with porting that bug from
gcc too. :(

from fdpp.

So overall you can't pack w/o actually
reading about alignment and padding
rules.
If you do, you will either get a punishment
from -Wpacking, or, in case it is gcc -
will drown in its bugs, but your code won't
work.

from fdpp.

Is there a DPMI layer on top of the real mode INT 21 handler in dosemu? I'm asking because INT 21 2A/2B need a real mode to protected mode translation. Maybe is that place the culprit.

Edit: scratch this, the APIs are solely register-based.

from fdpp.

Is there a DPMI layer on top of the real mode INT 21 handler in dosemu?

Yes.

I'm asking because INT 21 2A/2B need a real mode to protected mode translation.

Not above the one mandated by dpmi
specs, where the register values are
propagated to PM as-is.

from fdpp.

I've tried this:

• start Windows+WinFile
• terminate Windows
• check date: yes, it's wrong
• write to a DOS-native file system, mounted as a floppy
• got this crash:

ERROR: fdpp: abort at /build/fdpp-xbqHwh/fdpp-1.6-1352/fdpp/farptr.hpp:571

This is 100% reproducible.

Observations:

• when I start Windows and don't execute WinFile: no crash.
• when I run any other app in place of WinFile (Office, Delphi, Borland Pascal): no crash.
• EDIT: when I run WinFile and correct the date with INT 21 AH=2A2B after Windows' termination: crash!

Another observation: When I check INT 21 AH=2A in Windows using a Windows protected mode app, then
the date is correct before invoking WinFile, wrong during WinFile and wrong after WinFile terminates.

from fdpp.

Please attach the log of the crash.

from fdpp.

bug-222.log.xz.zip, actually an xz file.

I've redacted everything containing /drive_c/ for privacy reasons.

from fdpp.

Please don't use -s when doing this log.
Also you need to install the dbgsym package
for fdpp and dosemu2. See this comment on how to:
dosemu2/dosemu2#1987 (comment)

You need to grep the resulting log for
"No debugging symbols found"
and
"Could not attach to process."
strings. Once they are not there, the log
should be good.

from fdpp.

bug-222-2.log.xz.zip, actually an xz file.

It looks like it contains the backtraces you want.

from fdpp.

Hmm, it seems fdpp compiler got confused
with this statement at fatfs.c:408:
j = sp->sftt_count, sftp = sp->sftt_table.
Its too difficult for him. :)
Could you please try this change:

diff --git a/kernel/fatfs.c b/kernel/fatfs.c
index 79498de..5ddec1e 100644
--- a/kernel/fatfs.c
+++ b/kernel/fatfs.c
@@ -405,7 +405,8 @@ STATIC int merge_file_changes(f_node_ptr fnp, int collect)
   i = 0;
   for (sp = sfthead; sp != (sfttbl FAR *) - 1; sp = sp->sftt_next)
   {
-    for(j = sp->sftt_count, sftp = sp->sftt_table; --j >= 0; sftp++, i++)
+    sftp = sp->sftt_table;
+    for(j = sp->sftt_count; --j >= 0; sftp++, i++)
     {
       if (i != fnp->f_sft_idx && sftp->sft_count != 0
           && fnp->f_dpb == sftp->sft_dcb

That would reduce the complexity and
our dumb compiler will probably understand.

from fdpp.

How do I configure dosemu2 to use my custom fdpp from /usr/local?

from fdpp.

Just remove fdpp and dosemu2 packages
with apt-get, and in an absence of an alternative,
dosemu2 will find it in /usr/local.

from fdpp.

It's now crashing in sftp = sp->sftt_table;

from fdpp.

Could you please provide a ready to
reproduce hd image?

from fdpp.

Not an hd image but a "drive_c" together with the FD image file on which it crashes when I try to write on it after Windows terminates. Is this okay?

from fdpp.

If fd image alone is enough (I have
win3.1 here too), then that alone.

from fdpp.

The image could be a new, empty one. I've just created a new one and it seems that the bug is not related to my image at all.

My .dosemurc is just this:

$_cpu_vm = "kvm"
$_floppy_a = "dos622.img"
$_attrs_support = (off)

dos622.img is the empty (but formatted) image.

from fdpp.

So what needs to be done?
Is copying of some file to floppy
in winfile is enough?

from fdpp.

I've sent you an e-mail with the subject "FDPP Bug 222".

No, it's much easier:

• start Windows
• start WinFile
• close WinFile
• exit Windows

Then:

cd a:
dir > test

Translation (as it's a German Windows): WinFile is called "Datei-Manager" and can be found in the "Hauptgruppe" ;)

from fdpp.

OK, it appeared to have nothing to
do with the compilation process. Its
a genuine freedos bug.

from fdpp.

@stsp, thank you!

The actual issue (date in the future) of this bug entry isn't fixed, though. You can reproduce the same way as the SFT bug:

• start Windows
• start WinFile
• exit Windows
• type date at the command prompt when back in DOS.

The SFT issue arose while we were arguing about the date bug.

from fdpp.

So date shows the correct date and time.
What should I see?

from fdpp.

I've sent you an e-mail with the subject "FDPP Bug 222"

The URL from mail shows error.

from fdpp.

Yes, I have deleted the link when the bug was closed ;) I've sent you a new one.

You should see a date in the future: 2025-2028. I believe the time remains correct, although I did not explicitly check it.

from fdpp.

Will try later.

from fdpp.

Should now be fixed, good catch!

from fdpp.

Also we recently fixed many other
windows regressions, and I suppose
windows support is in a good shape
again. :)

from fdpp.