VOGONS

Common searches


File Timestamp (DOSBOX Windows XP+)

Topic actions

First post, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Due to some requests I ripped the DOS_SetFileDate() patch from ykhwong's sources. This adds the functionality of setting proper timestamp on files with int 21/57 (used by some archivers when extracting files). I haven't found it anywhere, except in ykhwong's full source tree from 2007, so I'm posting the patch here if anybody is interested.

All credits go to ykhwong (assuming he wrote it 😀), I just made a separate patch and modified it to apply to current cvs 😀

Attachments

  • Filename
    dosbox-time.diff
    File size
    5.35 KiB
    Downloads
    391 downloads
    File license
    Fair use/fair dealing exception

http://www.si-gamer.net/gulikoza

Reply 1 of 38, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Moved to the patches forum

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 2 of 38, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

This is greatly appreciated. Thank-you very much. I have been using ykhwong's build for the sole reason of installing games within DosBox, as I cannot stand everything having the same current date. It prevents me from quickly identifying which files contain configuration information written by a SETUP program, and which files are unmodified game resources.

Reply 3 of 38, by leileilol

User metadata
Rank l33t++
Rank
l33t++

Agreed, I always hated dates lost.

Linux disagrees though. One time I backed up using that and all my modified dates were reset.

NEVER AGAIN

by the way, DOSBox is not for running Windows 9x

Reply 4 of 38, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

Does anyone point me to the utime.h and types.h? That patch adds those includes to local_drive.cpp, but I cannot find them in the DOSBox source, Yhkwong's source or DOSBox-X's source. Without them, the program cannot compile.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 5 of 38, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I think those should be provided by your compiler.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 6 of 38, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

FYI, the patch doesn't address the shell COPY command, which some installers use, and destination files will still get a current stamp. I believe the Daum SVN build uses a COPY.EXE program on the Z: drive to replace the internal command as a workaround. Using an alternate shell like 4DOS is probably another option.

Reply 7 of 38, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
Dominus wrote:

I think those should be provided by your compiler.

Gotcha, I just had to manually point to the VC include directory and it compiled just fine.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 8 of 38, by Great Hierophant

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

FYI, the patch doesn't address the shell COPY command, which some installers use, and destination files will still get a current stamp. I believe the Daum SVN build uses a COPY.EXE program on the Z: drive to replace the internal command as a workaround. Using an alternate shell like 4DOS is probably another option.

For hard installs that rely on commands like XCOPY, I typically use real MS-DOS to install them.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog

Reply 10 of 38, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Here's an updated diff against r3858 and added support for COPY command (credits to FeedingDragon).

Attachments

  • Filename
    dosbox-time.diff
    File size
    5.5 KiB
    Downloads
    40 downloads
    File license
    Fair use/fair dealing exception

http://www.si-gamer.net/gulikoza

Reply 11 of 38, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I recall from my attempt, that I had a lot issues with getting the date and time to consistenly report to be same inside dosbox, (when external factors changed, like Daylight Saving or changing the timezone).

The reason this is important is the following. Some upgrades (at least one of the apogee games) check the filedates of the installed game. So if you install an upgrade/update later (which is imho totally possible) and the daylight saving changed, then the filedate/time should not be influenced.

Another important part was transferring the data to a different place in the world. (different timezone).
Maybe this patch properly takes care of that. I didn't get a satisfactory version, but maybe I messed something up with the conversions.

I haven't tested this patch yet though. So maybe all of this is a moot point.

Water flows down the stream
How to ask questions the smart way!

Reply 12 of 38, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

IMHO that might be an overkill and actually unusable. For the time to be reported consistently, DOSBox would always have to show GMT or something like that and convert from local timezone. But that would mean dosbox would have to be in the future for western timezones and in the past for eastern... Also one would have to consider that some filesystems (NTFS) change timestamps when time changes and others do not...

If the patch does not consider that, even in the worst case (wrong timezone, changing DST...), DOSBox would work the same as now (timestamps wouldn't match). But in all other cases, it would work.

http://www.si-gamer.net/gulikoza

Reply 13 of 38, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

I have no idea what the change does in that regards. I basically used someone else's code (it's available in the first post.) All I did is patched it in, and added in 2 lines so that the copy command would preserve the code as well. I'd say that 99% (if not more,) of the games used in DOSBox will not be having any future patches, and those installing them now would probably patch them immediately. I don't see much of a problem with it. It is a concern, an should probably stay out of the official builds, but having it available to those that want it, and want to compile it, is a good thing IMHO. For those who want it, and cannot compile it, there are plenty of people (I'm sure,) who would be willing to supply a compiled version. If not, Daum's build does incorporate it in one way or another as well, I'm told. I believe that's where the original patch (in the first post,) came from.

Feeding Dragon

Reply 14 of 38, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Something's not right with this code --- DosBox sometimes crashes upon closing a file that had AX=5701 called prior to closing. I'm trying to find out under what circumstances it happens, but when it happens, then always upon closing a file.

Edit: it definitely has something to do with the length of the original (i.e. not within DosBox) path. Moving the offending sub-directory into the root directory makes the bug disappear, purposefully creating paths with more than 120 or so total characters triggers it.

Edit 2: It must have something to do with:

		char fullname[DOS_PATHLENGTH];
strcpy(fullname, basedir);
strcat(fullname, name);

DOS_PATHLENGTH is defined in dos_system.h with a value of 80. Clearly, that is not enough for NTFS file systems. The constant is used many times elsewhere in the code, but there it is only used for virtual (mounted) paths, as far as I can tell, not host paths. It is therefore incorrect to use DOS_PATHLENGTH in this context. Looking at Open(), the correct constant that is always used elsewhere with local paths is CROSS_LEN, not DOS_PATHLENGTH. Replacing DOS_PATHLENGTH with CROSS_LEN indeed fixes the issue, which also occured in SVN Daum because that's where they are taken from.

Reply 16 of 38, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

It turns out that utime under Windows really does not get daylight savings time right. And neither does the Windows function LocalFileTimeToFileTime. This means that after using a utility within DOSBox that uses AX=5701 to set a file to a user-specified timestamp can result in the Windows Explorer displaying dates that are off by one and sometimes two hours compared to what the user specified. The only solution that produces accurate results is to use TzSpecificLocalTimeToSystemTime(), in a "#if defined (WIN32)" block, of course. I'll post a patch later, once I figure out why my own programs using this function compile well in MingW while adding this to DOSBox results in an "undefined reference to TzSpecificLocalTimeToSystemTime" message, even though I'm always linking against the same libkernel32.a which imports that function.

Reply 17 of 38, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Attached please find the promised update to gulikoza's patch. For Win32 targets only, it now uses TzSpecificLocalTimeToSystemTime from the Windows API to properly convert file times to the local system time, so that they will match with what is displayed in the Windows Explorer. Again, please refer to this and this page for an explanation of why this is needed. Other platforms should not be affected.

Note that when using MingW, the necessary function TzSpecificLocalTimeToSystemTime will only be known if _WIN32_WINNT has a value of at least 0x0501. This means after applying the attached patch against DOSBox SVN r4000, ./configure must be run (again) with an additional -D parameter, as shown below.

./configure --enable-core-inline LDFLAGS="-static-libgcc -static-libstdc++ -s" LIBS="-lvorbisfile -lvorbis -logg -lFLAC -lFLAC++ -lmt32emu" CPPFLAGS="-D_WIN32_WINNT=0x0501"

Attachments

  • Filename
    dosbox-time-win32.diff
    File size
    11.1 KiB
    Downloads
    10 downloads
    File license
    Fair use/fair dealing exception